With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando
With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando
Converting about:preferences's root from a xul:window to an html:html involves moving the Fluent-translated title attribute to a title tag, which starts empty and is populated by Fluent. The initially-empty title tag causes the title bar to flash "about:preferences" on reload.
This patch ignores empty title updates via DOMTitleChanged events to prevent this. This is only done for internal pages (i.e. pages with a system principal).
Differential Revision: https://phabricator.services.mozilla.com/D52289
--HG--
extra : moz-landing-system : lando
Converting about:preferences's root from a xul:window to an html:html involves moving the Fluent-translated title attribute to a title tag, which starts empty and is populated by Fluent. The initially-empty title tag causes the title bar to flash "about:preferences" on reload.
This patch ignores empty title updates via DOMTitleChanged events to prevent this. This is only done for internal pages (i.e. pages with a system principal).
Differential Revision: https://phabricator.services.mozilla.com/D52289
--HG--
extra : moz-landing-system : lando
Previously we were returning the documentElement in order to match the old XUL behavior.
Now that we have a document.body we can just follow the normal HTML convention.
Differential Revision: https://phabricator.services.mozilla.com/D34021
--HG--
extra : moz-landing-system : lando
Updating tab
- mute state
- audio playing indicator state
- find bar state
- tab titles
- icons
is not necessary when the navigation is same-document. Avoid doing the work.
Differential Revision: https://phabricator.services.mozilla.com/D52109
--HG--
extra : moz-landing-system : lando
Previously we were returning the documentElement in order to match the old XUL behavior.
Now that we have a document.body we can just follow the normal HTML convention.
Differential Revision: https://phabricator.services.mozilla.com/D34021
--HG--
extra : moz-landing-system : lando
This prevents a brief flash of unstyled tab content that can be noticed especially
in debug builds.
What happens currently is that we first append child content into the tab
upon connection, then we do attribute inheritance which sets the relevant
styling properties.
With this change we first set up the child content and attributes _before_ appending
the tab into the DOM, so that it's ready to render after being appended.
Differential Revision: https://phabricator.services.mozilla.com/D50837
--HG--
extra : moz-landing-system : lando
The tool tip for a browser tab exposes information such as the process ids (on Nightly) and the container tab name.
It appears when a user mouses over the tab, but this isn't really accessible to screen reader users.
Ideally, we'd expose this information as the accessible description for all browser tabs.
However, doing this for all tabs and keeping it up to date is rather difficult and potentially expensive.
Instead, just expose this description for a tab when it gets focus; i.e. the user has to focus the tab bar to access it.
To enable this, XUL tab elements now fire an AriaFocus event on the ARIA focused tab when the ariaFocusedItem property is set.
Differential Revision: https://phabricator.services.mozilla.com/D38027
--HG--
extra : moz-landing-system : lando
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
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
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
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : rebase_source : affeda0295a5195124709f322de524aea3a28a3f
