The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
extra : intermediate-source : a5c6deeda8a9475ac0268a4351417c8ff659c962
extra : histedit_source : 5eb8b3d14027f2aeca5c52534096837cd0343104%2Ca23a07ddd5e1fb8bd084644dd6db0ee028b7c4b4
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : rebase_source : 6b2b0ed9b01958d1b2db605ab300c4bebcaa461c
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
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
Our standard <button> binding has been carrying around an extra <label>
just to support search highlighting in about:preferences. This patch
removes that overhead by moving the tweaks that about:preferences needs
into a custom element used only within about:preferences.
Differential Revision: https://phabricator.services.mozilla.com/D28511
--HG--
extra : rebase_source : f7fe120f29630c76a1af77ddf16a422d3c946c58
As of this change, instances of xul <button> use a custom element.
The button-base xbl binding remains for now, since it is still used
by toolbarbutton, it will be removed soon.
Differential Revision: https://phabricator.services.mozilla.com/D27742
--HG--
rename : toolkit/content/widgets/button.xml => toolkit/content/widgets/button.js
extra : rebase_source : 2be8ee3fa9bb43866013f62211d8cb3706dbf1ab
For now, only add the MozMenuPopup base class to MozElements,
and don't define a custom element for it with
`customElements.define`. This is to help avoid conflicts in
de-xbl work. (See the bug for details.)
Includes a function to do 'manual slotting', moving child
elements into place. Dynamically adding, modifying, or
removing child nodes after the element is connected needs
to be handled manually as well.
Differential Revision: https://phabricator.services.mozilla.com/D25467
--HG--
rename : toolkit/content/widgets/popup.xml => toolkit/content/widgets/menupopup.js
extra : moz-landing-system : lando
***
Bug 1523957 - Part 0: Whitespace changes in tree.js, r=bgrins
***
Bug 1523957 - Part 1.1: Naively convert tree to a custom element, r=bgrins
***
Bug 1523957 - Part 1.2: Properly mixin BaseControl and extend XULTreeElement, r=bgrins
***
Bug 1523957 - Part 1.3: Use Shadow DOM for slotting children, r=bgrins
***
Bug 1523957 - Part 1.4: Properly handle key events in combination with shift modifiers, r=bgrins
***
Bug 1523957 - Part 1.5: Lint for the lint gods in tree.js, r=bgrins, standard8
***
Bug 1523957 - Part 2.1: Naively convert places-tree to a custom element, preserving history, r=bgrins
***
Bug 1523957 - Part 2.2: Lint for the lint gods in places-tree.js, r=bgrins
***
Bug 1523957 - Part 2.3: Fix browser_passwordmgr_editing.js, r=MattN
***
Bug 1523957 - Part 2.4: Fix browser_bookmarksProperties.js, r=bgrins
***
Bug 1523957 - Part 2.5: Make the edit bookmark tree lazily constructed so there aren't any trees left in the browser window markup, r=bgrins
***
Bug 1523957 - Part 2.6: Add eslint globals to places-tree.js, r=bgrins, standard8
--HG--
rename : browser/components/places/content/tree.xml => browser/components/places/content/places-tree.js
In the regressing bug I accidentally removed a special-case for
min-{height/width}: 0 that treated it as auto for XUL trees:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bf8e35be76d8#l34.94
I can put it back if you think it's better, but these two lines of code were
here before min-width: auto even existed (min-width: 0 used to be the default).
I think this is better than changing the platform back to special-case
min-width: 0, and I don't see many other problematic uses of min-height /
min-width: 0, so let's try this.
Differential Revision: https://phabricator.services.mozilla.com/D20071
--HG--
extra : moz-landing-system : lando
This custom element replaces XBL <content> usage by directly prepend the two needed child nodes when the element is connected.
This is doable because
- There isn't any direct access of child nodes under <menulist>. Everyone seems to access via .menupopup, which is usually the only child.
- We don't need to move the children under <menulist>. If we need to and if the child is a <xbl:children> (which could happen if <menulist> is inside an XBL <content> that just get cloned to the document), the layout will get very confused and crash (see finding in bug 1514926)
Differential Revision: https://phabricator.services.mozilla.com/D16149
--HG--
rename : toolkit/content/widgets/menulist.xml => toolkit/content/widgets/menulist.js
extra : moz-landing-system : lando
With all the previous efforts, the scrollbox binding now does nothing but to create an inner box element holding the scrolling content.
It turned out that inner box can be easily removed. The padding set by the document sheets can be moved to the srollbox element directly.
The only gotcha is XULScrollElement::ScrollByIndex() -- it can now reach the child item frames directly from the scrolled frame.
Depends on D15169
Differential Revision: https://phabricator.services.mozilla.com/D15170
--HG--
extra : moz-landing-system : lando
