[WebComponents] updating textContext of a shadowRoot on a link breaks the link

RESOLVED FIXED in Firefox 42

Status

()

Core
DOM
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: lukich, Assigned: smaug)

Tracking

({reproducible, testcase})

Trunk
mozilla42
x86
Mac OS X
reproducible, testcase
Points:
---

Firefox Tracking Flags

(firefox42 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce:

var a = document.getElementById('test');
var sh = a.createShadowRoot();
sh.textContent = 'GO!!!!!!!';

where #test is an href node.


Actual results:

The textContent got updated, but the link stopped being clickable.  I was able to revert the behavior by adding a second shadowRoot to element a and setting its innerHTML to "<content></content>"


Expected results:

I was expecting the link to still work.  Identical steps in Chrome produce a working link with a new text.  Also,  this tutorial: html5rocks.com/en/tutorials/webcomponents/shadowdom
demonstrates identical action on a button, so I would expect a link to work as well.
Comment hidden (obsolete)

Updated

3 years ago
Flags: needinfo?(lukich)
(Reporter)

Comment 2

3 years ago
Created attachment 8588709 [details]
test_case.html
Flags: needinfo?(lukich)
(Reporter)

Comment 3

3 years ago
Hi, Nikolai.  I just tried it in nightly (40.0a1 (2015-04-06)) as well as latest developer edition. In both cases it didn't work for me.  I have modified your test case file slightly, because it had mismatched script tags and uploaded it here.  When I run it, the value of the link gets updated to GO!!!!!, but it stops being clickable.  The only preference I changed was enabling shadow dom (setting dom.webcomponents.enabled to true).

Please let me know if you need more info.
Thanks!
Luka

Updated

3 years ago
Attachment #8588376 - Attachment is obsolete: true

Comment 4

3 years ago
Thanks! I knew I was missing the pref. I can reproduce, don't know if it's expected though. Moving to the right place.
Component: Untriaged → DOM
Keywords: reproducible, testcase
Product: Firefox → Core
Summary: updating textContext of a shadowRoot on a link breaks the link → [WebComponents] updating textContext of a shadowRoot on a link breaks the link
Version: 36 Branch → Trunk
The click event (or for that matter other mouse events) is not propagating out of the shadow DOM at all in this case, afaict.   Why not?

In fact, we're not even ending up in EventStateManager::CheckForAndDispatchClick. Nor in EventStateManager::PostHandleEvent with the 301 event message (BUTTON_UP).
Flags: needinfo?(wchen)
Flags: needinfo?(bugs)
What kind of frame tree do we create in this case? Sounds really odd if ESM doesn't handle BUTTON_UP.

(compiling debug build, and then check if we get event PreHandleEvent, and if not, is it because we have aTargetFrame).

But this is interesting case... mouseevents should be targeted to elements, not to textnodes. So hit testing should give us 'a', and it probably does something else.
Comment 5 and 6 seems to confirm this bug report so I'm updating the status to NEW.
Status: UNCONFIRMED → NEW
QA Whiteboard: [triaged]
Ever confirmed: true
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28902
Flags: needinfo?(bugs)
Created attachment 8629720 [details] [diff] [review]
wip1

https://treeherder.mozilla.org/#/jobs?repo=try&revision=078c0a344a7a
Assignee: nobody → bugs
Attachment #8629720 - Flags: review?(wchen)

Updated

3 years ago
Flags: needinfo?(wchen)
Attachment #8629720 - Flags: review?(wchen) → review+
Created attachment 8630199 [details] [diff] [review]
for commit
Keywords: checkin-needed

Comment 11

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/530ecc275dd9
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/530ecc275dd9
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.