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
The imported version is just one commit over 0.2.2 and solves the crash for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D28343
--HG--
extra : moz-landing-system : lando
We want to drop the cascade data memory as soon as possible, so bug 1544546
introduced an UpdateStylistIfNeeded call from ShellDetachedFromDocument.
Unfortunately, this call can reenter into the global user-agent cascade data if
some of the CSS values kept alive by the cascade data keep alive an SVG
document, see the stack on this bug for an example. Make sure to drop the
user-agent cascade datas when not holding the cache lock to avoid this
situation.
Before bug 1535788, we just destroyed the stylist, so we kept holding a
reference from the cache, and that reference will be dropped sometime later when
other document updated their user-agent stylesheets (if they happened not to
match the cache of course).
Seems to me this doesn't ended up happening in our automation, but it could
happen in the wild, in theory at least.
It's nice that Rust made this a safe deadlock caught by our tests rather than a
very subtle and infrequent memory corruption.
The relevant SVG documents are probably the <input type=number> rules:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/layout/style/res/forms.css#1050
Differential Revision: https://phabricator.services.mozilla.com/D28299
--HG--
extra : moz-landing-system : lando
Turns out these suites were hardcoded to be non-e10s in the mochitest harness.
So while it looked like they were working with e10s in treeherder, they were
actually still running with it disabled.
Turning e10s on causes both suites to permafail due to timeouts.
Depends on D28386
Differential Revision: https://phabricator.services.mozilla.com/D28387
--HG--
extra : moz-landing-system : lando
This was regressed by bug 1544816 but the test never ran on the push that regressed.
This patch also updates the 'files-changed' for the tryselect task.
Differential Revision: https://phabricator.services.mozilla.com/D28386
--HG--
extra : moz-landing-system : lando
This patch should prevent a guest user from putting a non-guest user's (existing) BITS download in a failure state. If, however, the guest user is the first user to try BITS, it will fail and will still put BITS in an error state, falling back to nsIIncrementalDownload.
Differential Revision: https://phabricator.services.mozilla.com/D28258
--HG--
extra : moz-landing-system : lando
Most wrapper cached C++ objects are held alive by their wrapper. The
cycle collector takes advantage of this in many classes and ignores
the C++ object if the wrapper is marked black.
However, this is not true for the outer window's wrapper. Instead, the
outer window's wrapper keeps the inner window alive. The inner window
usually keeps its outer window alive, but not after it has been
unlinked. For reasons I do not yet understand, the outer window's
wrapper can be kept alive after the inner window it is a proxy for is
unlinked.
This patch fixes the cycle collector optimization for the outer window
by only applying it if the outer window still has a weak reference to
the inner window, which it will until the inner no longer holds the
outer alive. This in turn fixes, or at least helps fix, window leaks
seen intermittently when the lifetime of outer windows and docshells
are tied together.
The code comment is based on a review comment by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D27981
--HG--
extra : moz-landing-system : lando
This override has no effect in CoreAnimation-backed windows. The upcoming
patches will implement an alternative approach.
Differential Revision: https://phabricator.services.mozilla.com/D22644
--HG--
extra : moz-landing-system : lando
The synchronous paint was only needed a long time ago when we were calling this
method during drawRect. We're not doing that any more, we usually call it from
viewWillDraw now. But even at the time, forcing a synchronous paint *within*
a paint was extremely sketchy, so best just to remove the code.
Differential Revision: https://phabricator.services.mozilla.com/D22642
--HG--
extra : moz-landing-system : lando
FxR uses these prefs and they might be helpful to other embedders so we can
just add them to GeckoRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D28232
--HG--
extra : moz-landing-system : lando
This patch fixes a bug about when the
privacy.restrict3rdpartystorage.userInteractionRequiredForHosts should be
considered.
Differential Revision: https://phabricator.services.mozilla.com/D28155
--HG--
extra : moz-landing-system : lando
Alexander Surkov
Oana Pop Rus
Gurzau Raul
Emilio Cobos Álvarez
Ed Lee
Alex Chronopoulos
Daosheng Mu
Andrew Erickson
Avery Berninger
Grisha Kruglov
Bogdan Tara
Andrew Halberstadt
Jeff Gilbert
Miko Mynttinen
Kirk Steuber
shindli
Sylvestre Ledru
Andrew McCreight
Jason Laster
Markus Stange
Aaron Klotz
Agi Sferro
Nan Jiang
Andrea Marchesini
Tim Nguyen
Barret Rennie