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.
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
Thanks! I knew I was missing the pref. I can reproduce, don't know if it's expected though. Moving to the right place.
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).
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.
Created attachment 8629720 [details] [diff] [review] wip1 https://treeherder.mozilla.org/#/jobs?repo=try&revision=078c0a344a7a