This test is already somewhat racy. At least locally, I could see the
background-image test fail sometimes in chaos mode. This is because we don't
wait for the background-image to load. But that's a different bug in any case.
Anyway, this failure happens because we're sending an event to the <iframe>,
but the context menu code expects the target of the event to be a node inside
the cross-origin iframe, in order for this check to work:
https://searchfox.org/mozilla-central/rev/b4e790d05f5a146d186c238bac5601a553581d23/browser/actors/ContextMenuChild.jsm#1036
Since <iframe> is cross-origin, stuff in it may not have been laid out yet.
This will also be a problem with fission, afaict, where that check wouldn't
even be possible, I think. If stuff there hasn't been laid out, the thing
getting the event (the contextmenu's target) is the <iframe>, rather than the
content document's target.
Make sure to target content under the subframe for now. This change is a bit
subtle, in the sense that what ensures stuff is getting laid out after this
change is the getBoundingClientRect() calls in:
https://searchfox.org/mozilla-central/rev/b4e790d05f5a146d186c238bac5601a553581d23/testing/mochitest/tests/SimpleTest/AsyncUtilsContent.js#75
However we rely on those all over the place already (even before my change), so
I think this is the easiest / better test fix for now.
With Fission we'll probably need to change how those context-menu checks work so
that they work when targeting the <iframe> or forward to the nested child
process or something.
Differential Revision: https://phabricator.services.mozilla.com/D29943
--HG--
extra : moz-landing-system : lando
The button is already hidden when underflow fires, so the clientWidth is 0. Instead,
store it during _lockTabSizing so we know how much space to fill when tabs are being closed
by the mouse, to allow the close button to remain underneath the mouse cursor.
Differential Revision: https://phabricator.services.mozilla.com/D29227
--HG--
extra : moz-landing-system : lando
I also made a few gratuitous code formatting cleanups. I hope you don't mind.
We are unable to properly analyze shutdown crashes and deduce the right action
to take when that happened. This leads to surprising occurrences of the
'about:sessionrestore' page shown, especially when a full restore is expected
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D29676
--HG--
extra : moz-landing-system : lando
Require `extensions.htmlaboutaddons.discover.enabled` to be enabled
before the HTML-based discopane is shown. This allows the feature
to be turned on and/or off independent of the other HTML views.
Differential Revision: https://phabricator.services.mozilla.com/D29478
--HG--
extra : moz-landing-system : lando
* Create new network.trr.resolvers pref which is a JSON array of objects with a name and url representing each resolver
* Add menulist to represent the resolver choices, and a "custom" option to use the network.trr.custom_uri as the trr.uri value
Differential Revision: https://phabricator.services.mozilla.com/D29393
--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
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
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
Alphan Chen
monikamaheshwari
Emilio Cobos Álvarez
Luca Greco
Dorel Luca
phoenixabhishek
Brian Grinstead
Andreea Pavel
Jared Wein
Mike de Boer
Rob Wu
ffxbld
Dale Harvey
Erica Wright
Paul Zuehlcke
Jonathan Kingston
Ed Lee
Coroiu Cristina
Mihai Alexandru Michis
Dão Gottwald
Tom Prince
Michael Kaply
Ryan VanderMeulen
Andrea Marchesini
Nihanth Subramanya
Sam Foster
Drew Willcoxon
Johann Hofmann
Andrei Oprea
Simon Fraser
Julian Descottes
Nika Layzell
Chris Peterson
Julien Cristau
Bogdan Tara
Barret Rennie
Myk Melez
Ehsan Akhgari