Converts layout.framevisibility.numscrollportwidths and layout.framevisibility.numscrollportheights to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D69615
--HG--
extra : moz-landing-system : lando
Converts `layout.testing.overlay-scrollbars.always-visible` to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D69611
--HG--
extra : moz-landing-system : lando
Converts `dom.disable_beforeunload` and `dom.require_user_interaction_for_beforeunload` to static pref.
Differential Revision: https://phabricator.services.mozilla.com/D69600
--HG--
extra : moz-landing-system : lando
When the build is stalled for some random reason, and mach executed a
python subcommand (this may or may not be limited to python 3, I'm not
sure, and it doesn't really matter since it's a problem on python 3,
which matters most), the subcommand may not have actually sent its last
bits of output before the stall because its output is a pipe and in that
case python uses buffered outputs.
Now, when your build is completely stalled and you ctrl+C, you end up
without these bits of output, and in some cases, those bits of output
can contain actual information, like... tracebacks.
A real life example of this is bug 1624670 when running mach build or
mach configure with the patches from bug 1627163 applied, and configure
stalls without printing out the ValueError message at all.
Differential Revision: https://phabricator.services.mozilla.com/D69925
--HG--
extra : moz-landing-system : lando
By loading whatwg-url like this, we replace the worker global URL property
(among others), which means that code that uses `URL` and expects it to be the
version that is built into Firefox may not get what they expect.
Differential Revision: https://phabricator.services.mozilla.com/D69933
--HG--
extra : moz-landing-system : lando
There are no remaining users of mozbrowser in our tree, so this patch removes
the logic which used to exist for handling window.open differently within
mozbrowser frames.
Differential Revision: https://phabricator.services.mozilla.com/D67057
--HG--
extra : moz-landing-system : lando
This method is no longer necessary, as frontend will always make the correct
decisions for the remoteness of the intial content browser by reading
openWindowInfo.
Differential Revision: https://phabricator.services.mozilla.com/D67058
--HG--
extra : moz-landing-system : lando
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
--HG--
extra : moz-landing-system : lando
The interface changes which ssb.jsm is being updated for are performed in
earlier parts. This patch just covers the required changes to frontend code to
propagate this information down to the nsFrameLoader when it is created.
Differential Revision: https://phabricator.services.mozilla.com/D67055
--HG--
extra : moz-landing-system : lando
The interface changes which GeckoViewNavigation.jsm is being updated for are
performed in earlier parts. This patch just covers the required changes to
frontend code to propagate this information down to the nsFrameLoader when it is
created.
Differential Revision: https://phabricator.services.mozilla.com/D67054
--HG--
extra : moz-landing-system : lando
The interface changes which browser.js and tabbrowser.js are being updated for
are performed in earlier parts. This patch just covers the required changes to
frontend code to propagate this information down to the nsFrameLoader when it is
created.
Differential Revision: https://phabricator.services.mozilla.com/D67053
--HG--
extra : moz-landing-system : lando
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
--HG--
extra : moz-landing-system : lando
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
This type replaces the individual properties, like nextRemoteTabId and
presetOpenerWindow, which were passed around by frontend code for window opening
requests performed by Gecko. This new type is intentionally native-only to make
it easier to pass more information down to newly created windows in the future.
Differential Revision: https://phabricator.services.mozilla.com/D67050
--HG--
extra : moz-landing-system : lando
This is necessary as, by this point, the BrowsingContext has already been
attached, and can no longer have its nsILoadContext flags updated.
Differential Revision: https://phabricator.services.mozilla.com/D67049
--HG--
extra : moz-landing-system : lando
Previously, a load of the URI within a chrome docshell would start before the
chrome docshell has had a chance to be configured. This could cause problems, as
the load would be configured incorrectly.
After these changes, starting the load is delayed until after nsILoadContext
configuration is complete.
Differential Revision: https://phabricator.services.mozilla.com/D67048
--HG--
extra : moz-landing-system : lando
Many of these setters are redundant, and duplicate work done elsewhere. As it is
no longer correct to set nsILoadContext attributes at these times, they're being
replaced with assertions.
Differential Revision: https://phabricator.services.mozilla.com/D67047
--HG--
extra : moz-landing-system : lando
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
This also moves nsDocShell's implementation of nsILoadContext to be based on its
BrowsingContext.
This patch does not, by itself, fix all places which try to mutate
`nsILoadContext`. Those are fixed by the other parts of this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67045
--HG--
extra : moz-landing-system : lando
This is OK, as all chrome BrowsingContext instances are always in the same
BrowsingContextGroup, so we don't need to have the initial opener avaliable when
creating the BrowsingContext to determine its BrowsingContextGroup.
This is used in part 7.2 to avoid propagating the opener window around when
creating chrome windows.
Differential Revision: https://phabricator.services.mozilla.com/D67044
--HG--
extra : moz-landing-system : lando
This could cause issues, as we could incorrectly override the decision made by
nsWindowWatcher, and then override the decision again after the method returns.
This could cause the initial content browser to be configured incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D67043
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
This flag tries to change nsILoadContext flags late during browser creation,
which won't be possible after this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67041
--HG--
extra : moz-landing-system : lando
Unfortunate, but it gets us back to where we were before `fix_stacks.py` came
along, and getting it working isn't worth the effort right now.
Differential Revision: https://phabricator.services.mozilla.com/D69928
--HG--
extra : moz-landing-system : lando
Also moves `nsThreadShutdownContext` to `nsThread.h` so it can be used by `nsThreadPool`.
Differential Revision: https://phabricator.services.mozilla.com/D69657
--HG--
extra : moz-landing-system : lando
