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
Add a 'View Saved Logins' footer to the password manager autocomplete popup.
Differential Revision: https://phabricator.services.mozilla.com/D19602
--HG--
extra : moz-landing-system : lando
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
This patch implements a new, preffed-off tab opening/closing animation where the tab slides up and down in place. In addition, it adjusts some tests and code that were relying on the max-width transitionend event happening. The intent of the patch is to land it preffed-off and iterate on the design in the tree
Differential Revision: https://phabricator.services.mozilla.com/D15955
--HG--
extra : moz-landing-system : lando
This patch implements a new, preffed-off tab opening/closing animation where the tab slides up and down in place. In addition, it adjusts some tests and code that were relying on the max-width transitionend event happening. The intent of the patch is to land it preffed-off and iterate on the design in the tree
Differential Revision: https://phabricator.services.mozilla.com/D15955
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
The APNG version is still used by the TabsList which can't support the SVG version of the throbber currently.
Differential Revision: https://phabricator.services.mozilla.com/D13461
--HG--
extra : moz-landing-system : lando
The URL bar is used for showing the URL, but also as a way to start a search.
A placeholder text is shown to let the user know about these possibilities.
In right-to-left (RTL) interface, URLs are forced to be displayed from left-to-right (LTR) to avoid confusion.
This creates an undesired side-effect, causing the placeholder text to also display LTR.
Following changes in bug 1449317, this placeholder text now contains both localized text, and names of search engines (such as Google), which causes a break in the bidi flow of text.
Differential Revision: https://phabricator.services.mozilla.com/D11565
--HG--
extra : moz-landing-system : lando
This removes the wrapping box inside the anonymous content, and replaces
the anonymous label with an ::after CSS rule that sets text based on
the [title] attribute.
Because it doesn't replicate the anonymous wrapping box with light DOM:
- Calling JS don't need to be updated (the child added via appendChild
is still a direct descendant of the element).
- Many CSS selectors don't need to be updated (if they were targeting the
slotted children as direct descendants. However, CSS selectors that were
targeting the anonymous content directly do need to be updated, since those
nodes are removed.
Differential Revision: https://phabricator.services.mozilla.com/D12172
--HG--
extra : moz-landing-system : lando
