Closed
Bug 1144418
Opened 9 years ago
Closed 9 years ago
[WebComponents] updating textContext of a shadowRoot on a link breaks the link
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla42
Tracking | Status | |
---|---|---|
firefox42 | --- | fixed |
People
(Reporter: lukich, Assigned: smaug)
References
Details
(Keywords: reproducible, testcase)
Attachments
(3 files, 1 obsolete file)
310 bytes,
text/html
|
Details | |
2.08 KB,
patch
|
wchen
:
review+
|
Details | Diff | Splinter Review |
2.42 KB,
patch
|
Details | Diff | Splinter Review |
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•9 years ago
|
Flags: needinfo?(lukich)
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•9 years ago
|
Attachment #8588376 -
Attachment is obsolete: true
Comment 4•9 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
Comment 5•9 years ago
|
||
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)
Assignee | ||
Comment 6•9 years ago
|
||
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
Assignee | ||
Comment 8•9 years ago
|
||
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28902
Flags: needinfo?(bugs)
Assignee | ||
Comment 9•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=078c0a344a7a
Assignee: nobody → bugs
Attachment #8629720 -
Flags: review?(wchen)
Updated•9 years ago
|
Flags: needinfo?(wchen)
Attachment #8629720 -
Flags: review?(wchen) → review+
Assignee | ||
Comment 10•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Comment 11•9 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
Closed: 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•