Before this change, we would initialize IOThread much earlier during startup, before Preferences are available to read (which depends on the XPCOM component manager). After this change, starting the IOThread is done during XPCOM component startup, meaning preferences are available.
This will allow us to customize IPC configuration at startup based on Preferences in the parent process. Content processes still cannot depend on Prefs to be available.
Differential Revision: https://phabricator.services.mozilla.com/D256503
This reverts commit 50659c4eb4.
Revert "Bug 901050 - Part 5: Don't initialize IOThread until Prefs are available, r=ipc-reviewers,mccr8"
This reverts commit 8358951e9a.
Revert "Bug 901050 - Part 4: Use IPC::Channel::Mode to indicate brokering status, r=ipc-reviewers,jld"
This reverts commit 7added392b.
Revert "Bug 901050 - Part 3: Add an IPC::ChannelMach Backend, r=ipc-reviewers,jld"
This reverts commit 21f9270e40.
Revert "Bug 901050 - Part 2: Add mach port watching support to the IO thread, r=ipc-reviewers,jld"
This reverts commit 1cb4ea55a2.
Revert "Bug 901050 - Part 1: Make IPC::Channel virtual, r=ipc-reviewers,jld"
This reverts commit 0c9d93c0c2.
Before this change, we would initialize IOThread much earlier during startup, before Preferences are available to read (which depends on the XPCOM component manager). After this change, starting the IOThread is done during XPCOM component startup, meaning preferences are available.
This will allow us to customize IPC configuration at startup based on Preferences in the parent process. Content processes still cannot depend on Prefs to be available.
Differential Revision: https://phabricator.services.mozilla.com/D256503
The class is used only for creating `nsFrameIterator`, but it's unnecessary
so that we can get rid of it and its interface.
Differential Revision: https://phabricator.services.mozilla.com/D197143
The class is used only for creating `nsFrameIterator`, but it's unnecessary
so that we can get rid of it and its interface.
Differential Revision: https://phabricator.services.mozilla.com/D197143
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.
Sylvestre Ledru