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
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
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
So it is still preventDefault()able once non-primary clicks aren't web visible.
Don't let browser.js' contentAreaClick handle any non-primary clicks.
ClickHandlerChild.jsm handles them first anyway. Can probably rip it out
entirely in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D26791
--HG--
extra : moz-landing-system : lando
For videos that break after alreading being in Picture-in-Picture, we keep the toggle enabled so
that the user can exit Picture-in-Picture.
Differential Revision: https://phabricator.services.mozilla.com/D27951
--HG--
extra : moz-landing-system : lando
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
For videos that break after alreading being in Picture-in-Picture, we keep the toggle enabled so
that the user can exit Picture-in-Picture.
Differential Revision: https://phabricator.services.mozilla.com/D27951
--HG--
extra : moz-landing-system : lando
This should make it easier to tell whether a particular window is
fission-enabled as testing with fission enabled improves.
Differential Revision: https://phabricator.services.mozilla.com/D26561
--HG--
extra : moz-landing-system : lando
This code builds on top of the E10S "remote tabs" configuration system to add a
system for specifying that remote subframes should be used. Fission can be
enabled for a window by including the "fission" flag in options when opening
the window.
Differential Revision: https://phabricator.services.mozilla.com/D26560
--HG--
extra : moz-landing-system : lando
onLocationChange does not get the simulated events. We need to be hiding the icon from the onContentBlockingEvent as it was before, since that seems to cover all of them.
Differential Revision: https://phabricator.services.mozilla.com/D27166
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
nsUpdateService should use BITS for download. If the BITS download fails, it will fallback to the existing download mechanism (nsIIncrementalDownload).
Differential Revision: https://phabricator.services.mozilla.com/D25162
--HG--
extra : moz-landing-system : lando
We need to handle autofilling the first result separately from autofilling results in general (which happens in UrlbarInput.setValueFromResult), so add a new UrlbarInput.autofillFirstResult method. The controller calls it instead of setValueFromResult. I ported the logic from nsAutoCompleteController, as described in the bug.
Other changes are related to the new test for this.
As part of this work, I was interested in learning how awesomebar handles browser_autoFill_typed.js, so I added it to the legacy tests, with a small tweak in the test for awesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D26852
--HG--
extra : moz-landing-system : lando
