Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=992245 (Rejected in favor of Servo Only)
Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=992245 (Rejected in favor of Servo Only)
Required for majority of WebComponent Demos. e.g. Fancy-Tabs.
Someone else will need to have a look at implementing this, but it does seem to me that modifications to
dom/xbl/nsBindingManager.cpp are needed due to our need to “Walk the rules in shadow root” to check for CSS changes.
This is the work wchen did, minus non-working
nsBindingManager.cpp changes which have been commented out. It should be a good starting point for someone to take and modify as needed and build.
I don’t have much to add to what g4jc wrote, but I think it’s worth noting the following:
The wchen work he’s citing in that text file above isn’t all from bug 992245, a good deal of it is actually from bug 1082060:
Mozilla themselves declined to implement host-context because Emilio objected to the way it works. wchen’s work apparently would have required them to implement host and host-context in an interdependent way, which I think is part of why it was rejected.
As far as adapting wchen’s old Shadow DOM v0 patch to UXP, this information might be helpful:
The important things to note are that we no longer have older or younger shadows because each shadow host can have only one shadow root now. However, we do have to account for open and closed shadow roots, which was not the case in v0. Also, not any element can be a shadow host. Finally, anything that deals with insertion points needs to be modified to account for slots instead, because slots replace insertion points in v1.
@g4jc I’m not entirely sure how much of this has already been relayed through other channels but we discussed the situation (of you handing over implementation) on IRC and both @athenian200 and I are in the same boat: we both should know enough about C++ to successfully implement this from scratch (or based on wchen’s work) but we don’t know what we’re looking at or how it all fits together.
It needs an account of the changes made so far to DOM for shadow dom and custom elements, to help us understand what was changed, how and why. Not the code side but the structural (macro) side of things.
Without that, both #1592 and this issue become impossible to implement because we don’t have the information needed to make it behave as intended or connecting the right pipes of the plumbing.
Here’s the logging stitched together from what I had (since
#binaryoutcast on freenode logs have been wiped, apparently). https://pastebin.com/duXPaMGh
The main problem is that you @g4jc are currently the only person with the knowledge about (shadow) dom structures and customelements to continue -- and you said you can’t because you run into code issues or things being Rust/Servo and can no longer port code. If you want to hand over the implementation torch for new code, then it needs a document describing what was done so far, what structures were changed (and how), and how all this new code fits in with how we handled DOM before with a singular document root and structure. Which APIs were added, which structures were created and how do they connect to the existing document structures prior to your changes? Why were these changes made, exactly? Help us understand :)
(as you yourself said the day before: if you want something implemented you have to take the time to understand all of it)
I greatly appreciate the status update (which is the thing we’ve actually been waiting for for quite a while yet and what Tobin has been asking for so we can let others/the public know where our development progress stands in this respect), but that isn’t what I asked for here.
Unfortunately, I do not have Doxygen or equivalent for API tracking.
Since I’ve never touched anything significantly in
/layout, the code here should be the same as it has always been. We would know if the API had changed since all of CSS would be busted after the amount of work that has already been done in DOM. The only significant difference from existing code in DOM would have been the aforementioned removal of Shadow DOM v0’s Multiple Roots since it changed the way roots work making wchen’s work non-functional.
I’m willing to poke around the code for any missing APIs you think we may need, but I have literally no clue how the existing plumbing between layout/CSS and DOM works - especially in relation to
XBL changes which seem to be required here.
I’ve also added some more pseudo-selector changes we were missing to the status update post. I literally just discovered them while poking around for pseudo-element bugs. For reference, there’s already a meta bug for CSS Pseudo-Elements Module Level 4 as well which I have not included there since it exceeds the scope of what we are trying to do to in order to get WebComponents working.
I’m sorry but you don’t seem to understand what’s needed here?
I’ll try again:
For the bugs you’ve ported that make structural changes, we need to know (in a descriptive explanation) in what way things have changed, and what the new structure is like/how it fits into the document/DOM/etc. structures handled by the browser. I’m assuming you understand enough of what you’ve ported to make a top-down/high level description of what the code changes actually do. All we have so far is bottom-level technical implementations and no overview of what it actually means.
Compare it to me telling you I exchanged Fibble for Quack. You’d understand that I swapped one thing for another, and if there is a technical description of what Fibble and Quack are made up of (API descriptions/spec reference) then you can sort-of guess how they might relate to each other or to similar things, but if you don’t know that they are both part of e.g.
<div> nodes, then it’s impossible to know what exchanging Fibble with Quack means for the document.
Assume we know nothing about shadow DOM (which in effect we don’t, since v0 was shoved in with the fork and v1 is all-new code you have implemented) or CustomElements (same story).
We need something to understand where the various APIs play a role, and how they affect the node tree and elements when used. You’ve taken the time to research what you’ve implemented (at least I sincerely hope so!); I’m asking that you condense that research and the knowledge of CE and shadow DOM you gained through that research into something we can use as a structural document to work from implementing things from scratch using both it and the spec.
Compare it to me telling you I exchanged Fibble for Quack.
The only significant change up to this point that is going to affect layout is
DocumentOrShadowRoot:: instead of
StyleScope::. I have a high level overview of meta bugs which is how I keep track of any of this, otherwise I feel like I don’t know Quack from Fibble.
That list is available here: https://ethercalc.org/f816fs4khnxp
I can also upload an
.xls if it is preferable.
The only significant change up to this point that is going to affect layout is DocumentOrShadowRoot:: instead of StyleScope::.
And how is that going to help us implement ::host and ::slotted?
if you want something implemented you have to take the time to understand all of it
otherwise I feel like I don’t know Quack from Fibble
So how can you say both things? You have no idea what you changed and how documents are affected by what you did?
How can you have implemented all these things that are marked implemented in your status report, without at least having a basic understanding of what you’ve been working on and what you have changed!?
Well, here’s my two cents. I don’t know if any of this helps, but I was looking at that document G4JC linked, and I saw something potentially relevant he hasn’t touched yet...
This bug allows XBL documents to know about their insertion points, rather than just their insertion parents. He didn’t implement this because it breaks the GUI of our applications. The reason I think it’s relevant is because WebComponents is loosely based on XBL to a degree, and this bug talks about things like distributed children and parents of elements, slots, etc. It’s also worth noting that something called an insertion point was used in Custom Elements v0, and slots are the v1 equivalent of insertion points.
So as far as I can tell, the plumbing needed to implement something like :host and :host-context would require similar plumbing to what’s being touched in this bug for XBL for GetXBLInsertionParent/GetXBLInsertionPoint, correct? Some plumbing that knows how to get the parent or host of a Custom Element, and then we need some logic to make that work with a CSS pseudo-class.
I suspect Mozilla’s early non-Servo implementation of Custom Elements depended partly on XBL patches that make it work more like WebComponents, because Shadow DOM + Custom Elements is an awful lot like XBL.
It seems like in order to implement :host, (and I know this is a lot of work) we might need to clone at least some of the stuff in layout/CSS that deals with XBL under a different name, and try to mess with it and hook it up to what we already have for Shadow DOM and Custom Elements on the DOM side of things while looking at the current spec and seeing where we fall short.
So what we need, broadly, is a Custom Elements implementation for CSS/Layout that more or less parallels what we already have for XBL, but which stays separate from XBL as much as possible to avoid busting it. The reason I’m proposing this is because the alternative appears to be just turning our XBL implementation into a Custom Elements/Shadow DOM implementation, and that’s likely what Mozilla would have done if not for Stylo absorbing most of the CSS changes WebComponents required.
Okay, so if you look at the XBL code immediately above or below what wchen’s patches did, it’s obvious he did, in fact, adapt pieces of what was already in XBL to process Shadow DOM stuff and got it work somehow. I’ve been playing around with the patch and while getting it to compile is fairly easy after accounting for a refactor or two that was done after he wrote it, I can’t seem to get it to work in a way that doesn’t either crash the browser or cause it to freeze when it encounters the :host selector.
The core problem is that the original patch was written to deal with multiple shadow roots, and now we don’t have multiple shadow roots, but do have to worry about slots. It’s really difficult to account for all that and visualize what code accounting for all that looks like.
Here are some notes I’m made as I tried to get this working...
Significant refactor in nsBindingManager since wchen (for comparing against original patch):
Removal of multiple shadow roots and HTMLShadowElement:
Addition of HTMLSlotElement:
Node distribution for shadow tree slots:
Functions in nsIContent that seem potentially relevant:
/** * Gets the ShadowRoot binding for this element. * * @return The ShadowRoot currently bound to this element. */ inline mozilla::dom::ShadowRoot *GetShadowRoot() const; /** * Gets the root of the node tree for this content if it is in a shadow tree. * This method is called |GetContainingShadow| instead of |GetRootShadowRoot| * to avoid confusion with |GetShadowRoot|. * * @return The ShadowRoot that is the root of the node tree. */ virtual mozilla::dom::ShadowRoot *GetContainingShadow() const = 0; /** * Gets the shadow host if this content is in a shadow tree. That is, the host * of |GetContainingShadow|, if its not null. * * @return The shadow host, if this is in shadow tree, or null. */ nsIContent* GetContainingShadowHost() const;
That should be the case, I think. I also found some stuff in FragmentOrElement, again right next to the XBL stuff:
/** * ShadowRoot bound to the element. */ RefPtr<ShadowRoot> mShadowRoot; /** * The root ShadowRoot of this element if it is in a shadow tree. */ RefPtr<ShadowRoot> mContainingShadow; /** * The assigned slot associated with this element. */ RefPtr<mozilla::dom::HTMLSlotElement> mAssignedSlot;
The thing about wchen is that he apparently knew a lot about XBL’s implementation details. That’s why he knew to go to nsBindingManager and make use of existing code the way he did. I feel like this would all be fairly easy if I understood those implementation details myself, but as things stand I’m struggling to piece all this together.
Making things worse is that there isn’t much recent work done at Mozilla with respect to CSS selectors that I can refer back to, most of the actual serious implementation work is in patches are 17-20 years old from back when everything was poorly documented and scattered patches because they used CVS. They did not like touching this code at all, at least not for anything more than bugfixes, cleanup or refactoring. Not that I’m complaining, it’s just hard to develop a sense of confidence that I understand what’s going on with this code in light of that.
Yeah unfortunately I can’t do much to help because I’m in the same boat as you are; I haven’t really touched CSS selector parsing code, nor XBL.
In the meantime I’ve been putting work into #618 to get us completely up to spec in that respect since I’m the only one of our team who’s versed enough in the innards of SpiderMonkey to work on that, and that’s taking a lot of time but is necessary work for WebComponents too since it will more extensively use module type scripting in WebComponent-based frameworks.
Ah, that makes sense. I noticed you’re doing a lot of good work there, and that is a load off my mind. I had a feeling that would be the next big hurdle, and it’s in a completely different part of the code than the DOM/Layout stuff we’ve been working with. This way we won’t struggle through the CSS stuff and then get blindsided by module type scripting.
Anyway, G4JC and I are starting to feel that without someone on our team who knows CSS selectors and XBL, we really only have two options here:
We need to study and document this code ourselves, because Mozilla barely touched this code for years and then just ripped out everything we want to work with. This will have to be done in a way that goes beyond the scope of this issue because we’ll trying to understand the broader context of how XBL and CSS selectors are handled in Goanna right now before trying to figure out how to hook in Shadow DOM v1 CSS Selectors to that existing code and make it all work together. I’ve tried to keep my study of the available Shadow DOM functions and such in this issue largely on-topic, but it’s looking like we need to go deeper in order to get a handle on this. I don’t know if there’s a process in place to follow for evaluating existing code in our codebase that’s not well-understood or documented already. I’m guessing we would either create an issue here, or a forum thread in Development discussion.
The only other option would require us to find someone who worked with XBL and/or the pre-Stylo CSS implementation prior to 2017 to help us out, either with mentoring and explanations, or by offering to write code for us. I was able to reach out to a volunteer who was involved with the Mozilla Taiwan team (a fan of XUL) and get a response, but he was more of a coordinator than a developer, and apparently none of the developers he contacted even responded. I don’t think English was his first language, but he understood well enough to try and get me in touch with the developers. I don’t think anyone he contacted responded, though. It seems like e-mails he had for those people (as well as those we could find) were out of date because all those people left Mozilla soon after Stylo was implemented.
Deleting a branch is permanent. It CANNOT be undone. Continue?