Continuing the discussion about displaying shadow roots in the markup view with the deepTreeWalker (from https://bugzilla.mozilla.org/show_bug.cgi?id=777674#c51 to https://bugzilla.mozilla.org/show_bug.cgi?id=777674#c62). Once we have anonymous content inspection we will want to show shadow roots in the inspector.
It would be good to narrow down what to show and how it should displayed in the markup view (especially with regards to older shadow roots and insertion points, I think). Angelina, with the work and research you've done with using web components, did you find that the implementation in Chrome's inspector covered everything you needed, or was it lacking anything? Any other thoughts or ideas about what we should be showing to developers in the inspector as they are working with shadow DOM?
Created attachment 8477120 [details] Screenshot of a test/demo with multiple shadow roots in Chrome developer tools In the screenshot I've attached You'll see that there are three separate shadow roots on a single (custom) element, airship-omnibar. In Chrome, every time you add another shadow root, it is appended onto the markup in the inspector. There is no visual indication of which shadow root is the youngest shadow root, or the older shadow root. We should have a visual indication of which tree is the youngest shadow and which is the older shadow. I suppose it's fairly intuitive that the 'last one added is at the bottom, and it's the youngest' but we can be more clear than that about the state of the trees and their relationship. In the case where one shadow root is embedded in another, it might be nice to click on a <shadow> tag, and then have the corresponding shadow that is at that insertion point highlight in the inspector. Similarly, when clicking on <content select="someSelector"> tags, highlight the corresponding children of the parent node that are distributed at that insertion point. The 'line down the side' to indicate which elements are a part of the shadow tree (kind of like comment threads found around the 'net) I'm not a fan of, I think when you have a few trees nested (and IMHO I don't know why you'd have more than two, but still, imagine a complicated parent tree structure to the shadow trees) that interface idea tends to break down and look visually cluttered - instead perhaps we should tint the background a light grey or light blue - some visual contrast that isn't vertical lines, basically.
This is great stuff Angelina, thanks, and what do you think about the problem we discussed in the comments mentioned above? I think https://bugzilla.mozilla.org/show_bug.cgi?id=777674#c58 is the best summary. Both William and I are against the approach chrome took in general, and would prefer to focus on representing the composed tree by default.
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #3) > This is great stuff Angelina, thanks, and what do you think about the > problem we discussed in the comments mentioned above? I think > https://bugzilla.mozilla.org/show_bug.cgi?id=777674#c58 is the best summary. > Both William and I are against the approach chrome took in general, and > would prefer to focus on representing the composed tree by default. I'm not sure I fully understand the suggested approach in https://bugzilla.mozilla.org/show_bug.cgi?id=777674#c58. Regarding 'Children of a host node are very different from the shadow root', where else would you put them in the markup view? Maybe it would help me understand if you could give an example of what you think the markup tree would ideally look like in attachment 8477120 [details]. Here is the tree from the screenshot as I see it in Chrome: <div id="userInterface"> ▶ <airship-tabbar>…</airship-tabbar> ▼ <airship-omnibar> ▼ #shadow-root ▶ <style>…</style> ▶ <input type="text"> ▶ <input type="submit"> ▼ #shadow-root ▶ <h1>HI THERE FRIEND</h1> ▼ #shadow-root <span>There should be a greeting after this:</span> <shadow></shadow> <airship-omnibar> </div>
(In reply to Brian Grinstead [:bgrins] from comment #4) > I'm not sure I fully understand the suggested approach in > https://bugzilla.mozilla.org/show_bug.cgi?id=777674#c58. Regarding > 'Children of a host node are very different from the shadow root', where > else would you put them in the markup view? > > Maybe it would help me understand if you could give an example of what you > think the markup tree would ideally look like in attachment 8477120 [details] > [details]. Here is the tree from the screenshot as I see it in Chrome: Since I don't have the code for this tree and the picture shows only a subsection of it, that does not show the most important <conent> instantiation points, I cannot do that. But if you open up http://w3c.github.io/webcomponents/spec/shadow/ and go to section 3.4, there is a very useful image there. On the left hand side there are the light DOM tree and on the right hand side the composed tree. What I think Chen was pointing out that as you can see in the the composed tree (what is actually rendered to the screen and hence the most important thing to inspect imo) the layout is very different than what you see in the light DOM tree. If anyone is curious ever about the layout on the left hand side, one can just look at the code and it will tell you exactly that structure, regards of parents/children. But sometimes it can be very difficult to imagine the actual layout that will be rendered, which is the composed tree, just by reading the code, even this tiny example is hard to follow at first. This is the reason why I would like to let users inspect this composed tree instead. What Angelina suggested, is basically showing the light DOM tree + coloring the nodes that will be selected when a content/shadow insertion point is selected. It is one big step forward from what chrome has. It might be a viable alternative. But for example it does not show the order of the colored nodes. Also, if one of those nodes is another shadow insertion point, then what should happen exactly? It feels to me that for real life complex examples will be still a big challenge to see the actual composed tree even with the help of the colored highlighter helper... So let me try. I will denote the children with c[n] and shadow hosts with sh[n] also the children without number on the last image will be c4 and c5. The composed tree would look like this: (right) ▼ Document ▼ sh 1 ▼ sh2 ▼ c4 ▼ c1 ▼ c3 ▼ c5 ▼ c2 While the light DOM version would look like: ▼ Document ▼ c1 ▼ # shadow-root ▼ sh1 ▼ <content select=...></content> ▼ c3 ▼ #shadow-root ▼ c4 ▼ <content ...></content> ▼ c5 ▼ <content select=...></content> <-- selecting this will color c4 ▼ c2 Let me know if it makes sense now or not... (And sorry if I made any mistake in these examples, but I hope they good enough to illustrate the two different concepts)
There is a report in Bug 1079185 that landing the current level of inspection for shadow DOM is less useful than it was before we landed anonymous content inspection (for a page like: http://gaia-components.github.io/gaia-components). It's worth checking out, it seems pretty related to this discussion.
I'm pretty sure that the end of this, is that we need to support inspection for both the light DOM and the for the composed tree. I'm not sure how should we show both word, or maybe we should just add a switch somewhere...
Brian, while I'm fixing bug 1079185, do you think you have some time to go forth with the other inspection mode? Since I think we will need both and then just add a flag to switch between the two, or do some more fancy UI for delivering it nicely. It should be simple, you should just use the deeptreewalker, without showing anon content, and then check the nodes if they have shadowRoot (it's a prop on the nodes). It returns the youngest shadow root, and then you can get olderShadowRoot recursively until there is any more to get all the shadow roots attached to that node. Finally you should be able to create another deeptreewalker on these document fragments (show anon content still off) and this way you will be able to see the light DOM version of the shadow trees. Does this make any sense? Let me know if something is not clear, or if something is broken with the approach.
We had a discussion about a better way to visualize things. I'm thinking that this new way will require quite some work on the frontend, so I'm now feeling like we should proceed with the idea in Comment 8 to show a view by default similar to what Chrome does. And then iterate on that to improve the visualization to help people better understand how things are being displayed.
We from gaia QA automation would very much like this to have this for webIDE. It would make the search for elements much easier (with shadow DOM we currently use a workaround). Should I file a new about this for webIDE or would this one also cover webIDE?
(In reply to Martijn Wargers [:mwargers] (QA) from comment #10) > Should I file a new about this for webIDE or would this one also cover > webIDE? No, this bug is enough. There is nothing WebIDE specific. You should convince this bug needs more attention...
Was reminded about this bug again today by Sara Soueidan. See https://twitter.com/SaraSoueidan/status/598311324104396800 and https://twitter.com/patrickbrosset/status/598413884974825472 This bug isn't on my TODO list right now but if no one works on it in the meantime, I might take a look in a about month.
ping, what's the status here? Still getting pinged by people about it: https://twitter.com/anatudor/status/628684488470605825
(In reply to Jeff Griffiths (:canuckistani) from comment #14) > ping, what's the status here? Still getting pinged by people about it: > > https://twitter.com/anatudor/status/628684488470605825 (In reply to Jeff Griffiths (:canuckistani) from comment #14) > ping, what's the status here? Still getting pinged by people about it: > > https://twitter.com/anatudor/status/628684488470605825 Backlogged after promise debugger work on my queue.
(In reply to Jeff Griffiths (:canuckistani) from comment #14) > ping, what's the status here? Still getting pinged by people about it: > > https://twitter.com/anatudor/status/628684488470605825 It's also worth noting that the feature itself is still off by default for web content: https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#1101
(In reply to Brian Grinstead [:bgrins] from comment #16) ... > It's also worth noting that the feature itself is still off by default for > web content: > https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all. > js#1101 Yeah, that is helpful. If there is a bug for enabling shadow roots or whatever, that bug should block this bug.
From the looks of that pref, bug 811542 should block this I guess.
I really would like to have something like this for WebIDE, fwiw.
Inspector Bugs Triage - Filter on CLIMBING SHOES