This patch introduces a new type of content process, which has a dynamic name.
This type of content process is labeled as `webIsolated=${SITE_ORIGIN}` and is
used within fission-enabled windows.
To enable this, additional information about the fission status of the target
window must be passed into E10SUtils. This was done by updating every call site
manually to pass an extra boolean. A better solution perhaps should be used in
the future.
With this patch enabled, we now perform process switches, but only when
navigating to HTTP URIs. If we navigate to a non-HTTP URI in an iframe with
fission enabled, it will not behave correctly. This must be done in a
follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29570
--HG--
extra : moz-landing-system : lando
When UrlbarInput.uninit is called after customize mode ends, uninit calls this.inputField.controllers.removeControllerAt(0), which is supposed to remove the input's CopyCutController inserted in the constructor. But the controller at index 0 at that point is not the CopyCutController. Instead it's some built-in controller that supports these commands (at least these): cmd_charPrevious, cmd_charPrevious, cmd_beginLine, cmd_endLine. (Verified by adding logging to nsXULControllers::GetControllerForCommand.) That's why arrow left/right and home/end don't work after ending customize mode.
The problem is that this.inputField.controllers in the constructor and this.inputField.controllers in uninit (when customize mode ends) are not the same. I wasn't able to track down why, but I'm guessing that the textbox or something in its state is being reset or cloned when customized mode ends or maybe right after it starts. The CopyCutController isn't in the controllers array at all on uninit. (Verified by adding support for cmd_adw and iterating through the controllers array, looking for a controller supporting cmd_adw.)
Note that urlbarBindings.xml has a try-catch around removeController(), I'm guessing for what turns out to be this reason: https://searchfox.org/mozilla-central/rev/7944190ad1668a94223b950a19f1fffe8662d6b8/browser/base/content/urlbarBindings.xml#190
However, CopyCutController *is* in the controllers array when customize mode starts. So I added a new gURLBarHandler.customizeStart method that calls a new UrlbarInput.removeCopyCutController method.
Other things I tried or thought of doing:
Call gURLBarHandler._reset on customize start instead of end. Problem with that is that the UrlbarInput ends up getting immediately recreated because some other parts of the browser access gURLBar at that time. (Of course I replaced the `gURLBar = this.urlbar` assignment in _reset with another lazy getter definition.)
Just don't worry about removing CopyCutController at all. That seems bad because then we'd leak it, unless the controller is removed or the controllers array is emptied at some point by XUL, and I'm not at all certain about that. (Although I guess this is effectively what awesomebar does, given the link above!)
Differential Revision: https://phabricator.services.mozilla.com/D29613
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We made changes to change the visibility of this button whenever the panel is opened, so
more lazily. I think this caused some intermittents where the assertion was runinng before
the hide/show code executed.
Differential Revision: https://phabricator.services.mozilla.com/D28628
--HG--
extra : moz-landing-system : lando
The reason why this fixes it is a bit subtle, let me try to explain.
XBL has this mechanism where all attributes in the binding `<content>` element
get auto-propagated to the bound element (the `<panel>` in this case).
This doesn't seem to be a very used feature looking at:
https://searchfox.org/mozilla-central/search?q=%3Ccontent&case=false®exp=false&path=xml
The panel binding uses it to add the `side` attribute:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/toolkit/content/widgets/popup.xml#264
The key here is that this attribute addition is silent (`aNotify=false`):
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/dom/xbl/nsXBLBinding.cpp#341
This means that the presence of this attribute is not supposed to change the
rendering of the page. It'd also be unsafe to notify at the point at which we
create XBL bindings.
So the way this happens is:
* We compute the initial style of the `<panel>` element (which doesn't have a
`side` attribute, and thus doesn't match the rules, and has a computed
opacity of 1).
* The XBL service _silently_ sets the `side` attribute. This should cause a
style change, but it doesn't since it's silent, so we remain with the
opacity of 1.
* We open the popup, and the XBL binding listens for the `popupshowing` event
and adds the `animate` attribute. The style system notices, and eventually
we compute the new style. Issue is, it has again an opacity of 1, so we
don't fire the transition.
Same with transform and such of course.
So far so good, but then, why does it work if there's a `<resources>` element
with an empty stylesheet? Fun that you ask!
We explicitly re-resolve the style of the element if there are any stylesheets:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/dom/xbl/nsXBLService.cpp#551
And thus grab the correct initial opacity of zero, and trigger the transition.
Given arrow panels always have a `side` attribute (and same for the bookmarks
thing), making their style not depend on the silent attribute additions from
`<content>` fixes the bug.
We could fix the bug with an alternative patch (re-resolving style if there's a
`<content>` element with attributes in the binding). This wouldn't be completely
sound anyway in presence of combinators, and given that it'd remain being
unsound anyway, we should probably just remove that feature.
Also, the simplification of the stylesheets seems worth it anyway.
I'll follow-up removing the `<resources>` implementation, and we should probably
investigate removing the `<content>` attribute propagation, since it's the
really unsound thing here.
Differential Revision: https://phabricator.services.mozilla.com/D28310
--HG--
extra : moz-landing-system : lando
