The tooltip doesn't appear when the @title global attribute[1] is used inside shadow content. I would assume this should work and it does work in Chrome. I've already encountered some UI on the web which wasn't usable because I didn't know what some of the icons meant without a tooltip. Nightly 63.0a1 (2018-07-12) (64-bit) [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title [Tracking Requested - why for this release]: Regression compared to pre-shadow DOM behaviour

Still trying to find if we have any tests for e10s + tooltips remote: View your change here: remote: https://hg.mozilla.org/try/rev/a0c7a3589ebd0090ec212e245ef51536c901af23 remote: remote: Follow the progress of your build on Treeherder: remote: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a0c7a3589ebd0090ec212e245ef51536c901af23 remote: recorded changegroup in replication log in 0.124s

Hmm, this is actually tricky to get working with XBL and Shadow DOM. Need to do some best-effort approach.

And of course this whole thing is undefined in the spec https://github.com/whatwg/html/issues/3821

Not sure who should review this, but given this includes .webidl changes to expose assignedSlot always for chrome, this needs DOM peer review anyhow. "// release tooltip target if there is one, NO MATTER WHAT" is a comment used elsewhere in that relevant method. nsXULTooltipListener needs to look at shadow dom, since if there isn't such, it falls back to retargeter event.target so that tooltips work in XBL. Messy, but hopefully passes the tests :) remote: View your change here: remote: https://hg.mozilla.org/try/rev/3d280d9389180a49aa14e139cb4b1ebb28243270 remote: remote: Follow the progress of your build on Treeherder: remote: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d280d9389180a49aa14e139cb4b1ebb28243270 remote: recorded changegroup in replication log in 0.132s

Comment on attachment 8991964 [details] [diff] [review] shadow_dom_tooltip_with_test.diff Review of attachment 8991964 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/xul/nsXULTooltipListener.cpp @@ +178,5 @@ > // If the mouse moves while the tooltip is up, hide it. If nothing is > // showing and the tooltip hasn't been displayed since the mouse entered > // the node, then start the timer to show the tooltip. > if (!currentTooltip && !mTooltipShownOnce) { > + nsCOMPtr<EventTarget> eventTarget = aEvent->GetComposedTarget(); Why is this an nsCOMPtr and not a raw pointer? ::: toolkit/components/tooltiptext/tests/browser_shadow_dom_tooltip.js @@ +6,5 @@ > + ["dom.webcomponents.shadowdom.enabled", true]]}); > +}); > + > +add_task(async function test_title_in_shadow_dom() { > + let tab = await BrowserTestUtils.openNewForegroundTab(gBrowser); Any reason not to use BrowserTestUtils.withNewTab?

(In reply to Blake Kaplan (:mrbkap) from comment #5) > Comment on attachment 8991964 [details] [diff] [review] > shadow_dom_tooltip_with_test.diff > > Review of attachment 8991964 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: layout/xul/nsXULTooltipListener.cpp > @@ +178,5 @@ > > // If the mouse moves while the tooltip is up, hide it. If nothing is > > // showing and the tooltip hasn't been displayed since the mouse entered > > // the node, then start the timer to show the tooltip. > > if (!currentTooltip && !mTooltipShownOnce) { > > + nsCOMPtr<EventTarget> eventTarget = aEvent->GetComposedTarget(); > > Why is this an nsCOMPtr and not a raw pointer? just because the old code had nsCOMPtr > > +add_task(async function test_title_in_shadow_dom() { > > + let tab = await BrowserTestUtils.openNewForegroundTab(gBrowser); > > Any reason not to use BrowserTestUtils.withNewTab? Not sure what the difference is. I was just looking at the other tests in the same directory and used the same approach.

Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/015a00cd6768 @title tooltips should work also inside ShadowDOM, r=mrbkap

Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/50a16618593d CLOSED TREE, add missing semicolon, r=bustage

https://hg.mozilla.org/mozilla-central/rev/015a00cd6768 https://hg.mozilla.org/mozilla-central/rev/50a16618593d

I reproduced the issue on Mac OS X on Nightly 63.0a1 (2018-07-13). I verified it on Mac OS X, Ubuntu 16.04, Windows 10 and 7 on Nightly 63.0a1 (2018-08-09) and it is no longer reproducible. Marking the bug as Verified on 63.