We only have a handful of <tabs> elements, these should be straightforward, with the exception of #tabbrowser-tabs which is big, gnarly, and intertwined with lots of other bits of the browser front end.

Most of the work here is in the tab strip (#tabbrowser-tabs).
The current code is full of assumptions that the dom structure
looks like a <tabs> element with individual <tab> elements as
its immediate and only children. Rather than try to preserve
that structure, this patch adds new properties on tabs and tab
elements (tabs.tabChildren and tab.container) to navigate the
logical <tabs>/<tab> relationships instead of using the dom
directly.

This wip patch is part of the way there, I still have some test failures to green up, but I'd like to get feedback about this approach before pushing the rest of the way through. Gijs and Dão, I suspect you two know the tab strip as well as anybody, are you on board with this approach or is there something else worth pursuing?

Since we don't have f? any more, lets go with ni?

(In reply to Andrew Swan [:aswan] from comment #1)

Most of the work here is in the tab strip (#tabbrowser-tabs).
The current code is full of assumptions that the dom structure
looks like a <tabs> element with individual <tab> elements as
its immediate and only children. Rather than try to preserve
that structure, this patch adds new properties on tabs and tab
elements (tabs.tabChildren and tab.container) to navigate the
logical <tabs>/<tab> relationships instead of using the dom
directly.

This makes sense to me.

Commented in phabricator. I have concerns about tabs.tabChildren. Otherwise I think this is fine, as these things are implementation details abstracted away behind gBrowser.tabs and gBrowser.tabContainer -- as long as we keep these two, the changes should be manageable.

These tests are full of too many problems to catalog here.
This patch just rewrites them to make them less insane.

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.firstElementChild -> this.firstTab
this.lastElementChild -> this.lastTab
this.children.length -> this.tabCount
this.children[i] -> this.getItemAtIndex(i)
this.children -> this.allTabs

One subtle difference is that the allTabs property on a <tabs> element
which used to return a live HTMLCollection now returns an Array. Accessing
allTabs is also more expensive than the old .children property, so various
callers have been updated to use .tabCount, .getItemAtIndex, etc as
appropriate.

Here's a linux-only try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=432e78cd2848622b562f0f8ac846c4a49a45d91c

I'll do a broader run and a talos run shortly...

There's a decent amount of orange here but it appears to all be known intermittents (or tier 2 jobs that I didn't look closely at)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ee6697de9e25955d523f6dfde89c18d6d01679d

Backed out 3 changesets (bug 1555060) for causing test_tabbar.py to perma fail

push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=a5c6deeda8a9475ac0268a4351417c8ff659c962&searchStr=en-us

failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=a5c6deeda8a9475ac0268a4351417c8ff659c962&searchStr=linux%2Cx64%2Cdebug%2Cfirefox%2Cfunctional%2Ctests%2C%28local%29%2Ctest-linux64%2Fdebug-firefox-ui-functional-local-e10s%2Cfxfn-l%28en-us%29&selectedJob=253798771

backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/0be464c5cc7deada9ff92db2966fc929a1bcb344

Also perma fails:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=253803889&searchStr=os%2Cx%2C10.10%2Cshippable%2Copt%2Cmochitests%2Ctest-macosx1010-64-shippable%2Fopt-browser-screenshots-e10s%2Cm%28ss%29

At this point it might make sense to postpone until 69 merges to beta on July 8th. When you reland this, please make sure to put the reviewers in the commit messages.

https://hg.mozilla.org/mozilla-central/rev/58831b7309de
https://hg.mozilla.org/mozilla-central/rev/5f9198b156f7
https://hg.mozilla.org/mozilla-central/rev/8f15ea3b3223

(In reply to Dão Gottwald [::dao] from comment #12)

At this point it might make sense to postpone until 69 merges to beta on July 8th. When you reland this, please make sure to put the reviewers in the commit messages.

Sorry, in my haste to wrap this up last week I didn't see this comment until after it was re-landed (and so it also re-landed without the r= strings, ack)
I'll be watching closely for regressions, but I didn't want anybody to get the idea that I was deliberately ignoring the comment...