Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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 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.
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
DevTools wants to use wake lock to keep screen. But since MozWakeLock is
removed by bug 1369194, there is no way to unlock wake lock from script.
So this issue adds nsIWakeLock to unlock wake lock.
Differential Revision: https://phabricator.services.mozilla.com/D7158
--HG--
extra : rebase_source : 4d6069fce27a7d85ce484a1418a8a17de83166f1
Because it's just a wrapper for js_free().
Furthermore, JS_smprintf() and friends return a JS::UniqueChars, which is also
wired up to free with js_free(). So having the indirection via
JS_smprintf_free() obfuscates things.
--HG--
extra : rebase_source : 1db80199dc801a2684fffe2a5fd5349a42c6941b
We have to run the navigator checks in sub-iframes as we need to set preferences which affect navigator's API
which may or may not be already initialised with the current settings. The sub-iframes will have a navigator
object set up with the expected preferences for the test.
The iframes all call into the parent to publish the test results, this is because the SimpleTest infrastructure
doesn't cope with results being published from sub-iframes.
MozReview-Commit-ID: GFVQHMVkbMP
--HG--
rename : dom/power/test/test_bug957899.html => dom/power/test/test_bug957899_iframe.html
rename : dom/presentation/tests/mochitest/test_presentation_availability.html => dom/presentation/tests/mochitest/test_presentation_availability_iframe.html
rename : dom/tests/mochitest/gamepad/test_check_timestamp.html => dom/tests/mochitest/gamepad/test_check_timestamp_iframe.html
rename : dom/tests/mochitest/gamepad/test_gamepad_connect_events.html => dom/tests/mochitest/gamepad/test_gamepad_connect_events_iframe.html
rename : dom/tests/mochitest/gamepad/test_gamepad_extensions.html => dom/tests/mochitest/gamepad/test_gamepad_extensions_iframe.html
rename : dom/tests/mochitest/gamepad/test_gamepad_frame_state_sync.html => dom/tests/mochitest/gamepad/test_gamepad_frame_state_sync_iframe.html
rename : dom/tests/mochitest/gamepad/test_gamepad_hidden_frame.html => dom/tests/mochitest/gamepad/test_gamepad_hidden_frame_iframe.html
rename : dom/tests/mochitest/gamepad/test_gamepad.html => dom/tests/mochitest/gamepad/test_gamepad_iframe.html
rename : dom/tests/mochitest/gamepad/test_navigator_gamepads.html => dom/tests/mochitest/gamepad/test_navigator_gamepads_iframe.html
rename : dom/tests/mochitest/geolocation/test_geolocation_is_undefined_when_pref_is_off.html => dom/tests/mochitest/geolocation/test_geolocation_is_undefined_when_pref_is_off_iframe.html
rename : dom/workers/test/test_navigator.html => dom/workers/test/test_navigator_iframe.html
rename : dom/workers/test/test_navigator.js => dom/workers/test/test_navigator_iframe.js
extra : rebase_source : fe0f3e342cb55b5e9da7038acb59b5e2a5c8767e
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
