Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
The idea of this patch is to try to not use oberver mechanism as possible. To
achieve that, it introduces deleteByOriginAttributes() to cleaners. Different
from other methods, it would only be executed if it's implemented from a
cleaner.
It doesn't remove oberver mechanism entirely since some cleaners are still using
that for other deleteByXXX() functions. So, it only applies removing stuff to
PushService, QuotaManagerService, ServiceWorkerManager, nsPermissionManager,
nsApplicationCacheService, and nsCookieService.
Since the original issue is related to QuotaManagerService, it adds xpcshell
test under the dom/quota/test/unit/ to ensure the behavior won't be changed
accidentally in the future.
Differential Revision: https://phabricator.services.mozilla.com/D33758
This reference is necessary when sending session storage data for
all browsing context to the parent process. Note that it entails
making SessionStorageManager a cycle collection participant, since
adding this reference creates a cycle.
Differential Revision: https://phabricator.services.mozilla.com/D55659
This reference is necessary when sending session storage data for
all browsing context to the parent process. Note that it entails
making SessionStorageManager a cycle collection participant, since
adding this reference creates a cycle.
Depends on D55276
Differential Revision: https://phabricator.services.mozilla.com/D55659
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
This patch introduces a Speech Recognition Service which interfaces with Mozilla's remote STT endpoint which is currently being used by multiple services
Differential Revision: https://phabricator.services.mozilla.com/D26047
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
layout/build/nsLayoutModule.cpp:95:6 [-Wmissing-prototypes] no previous prototype for function 'nsLayoutModuleInitialize'
layout/build/nsLayoutModule.cpp:176:11 [-Wmissing-prototypes] no previous prototype for function 'CreateXMLContentSerializer'
layout/build/nsLayoutModule.cpp:178:11 [-Wmissing-prototypes] no previous prototype for function 'CreateHTMLContentSerializer'
layout/build/nsLayoutModule.cpp:180:11 [-Wmissing-prototypes] no previous prototype for function 'CreateXHTMLContentSerializer'
layout/build/nsLayoutModule.cpp:182:11 [-Wmissing-prototypes] no previous prototype for function 'CreatePlainTextSerializer'
layout/build/nsLayoutModule.cpp:184:11 [-Wmissing-prototypes] no previous prototype for function 'CreateContentPolicy'
layout/build/nsLayoutModule.cpp:188:11 [-Wmissing-prototypes] no previous prototype for function 'CreateGlobalMessageManager'
layout/build/nsLayoutModule.cpp:189:11 [-Wmissing-prototypes] no previous prototype for function 'CreateParentMessageManager'
layout/build/nsLayoutModule.cpp:191:11 [-Wmissing-prototypes] no previous prototype for function 'CreateChildMessageManager'
layout/build/nsLayoutModule.cpp:225:10 [-Wmissing-prototypes] no previous prototype for function 'Construct_nsIScriptSecurityManager'
layout/build/nsLayoutModule.cpp:237:10 [-Wmissing-prototypes] no previous prototype for function 'LocalStorageManagerConstructor'
layout/build/nsLayoutModule.cpp:255:6 [-Wmissing-prototypes] no previous prototype for function 'nsLayoutModuleDtor'
Differential Revision: https://phabricator.services.mozilla.com/D21854
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
NS_NewLayoutDebugger() is defined in nsLayoutDebugger.cpp.
layout/base/nsLayoutDebugger.cpp:44:10 [-Wmissing-prototypes] no previous prototype for function 'NS_NewLayoutDebugger'
Differential Revision: https://phabricator.services.mozilla.com/D21853
The layout module is a little weird. It's described as being loadable
in the GPU process, but very few of the contracts and CIDs it contains
are also marked as such. In fact, the sole reason the layout module is
marked as being loadable in the GPU process is so that the power manager
service can be registered; everything else is inconsequential. This
setup also means that the initializer for the layout module has to
specifically check whether it's running in the GPU process (or several
other processes...), so we don't try to spin up a bunch of stuff we
don't need, like xpconnect and similar.
This setup is silly: we should have a module solely for the power
manager's use and that module can be loaded in the GPU process. Then
the layout module can go back to being an ordinary module, and we don't
have to play games in its initialization method.
The concrete classes of nsIContentIterator are enough complicated, but they
are not tested simply. Therefore, it's dangerous to touch them even if we
meed bugs of them. Additionally, it's used in some hot paths, therefore,
I'd like to keep them simple as far as possible.
Therefore, this patch creates a mediator class between script and each
nsIContentIterator instance. So, this change shouldn't affect any of
actual behavior nor performance.
Differential Revision: https://phabricator.services.mozilla.com/D15285
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
nsLayoutModule must be initialized in order to call into JS, but I
don't want to have to rely on calling a service in that
module. Instead, always initialize the module very early in component
manager initialization. This also makes initialization more
consistent, so things like errors in manifests won't affect when it
happens, which can result in different behavior in different builds.
I also made nsLayoutModule initialization infallible, because I can't
imagine that we can do much that is useful without it.
Another change I made is that gInitialized is set to true even in a
GPU process. This simplifies checking whether initialization has
happened already when we start up the layout module.
Differential Revision: https://phabricator.services.mozilla.com/D9583
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
