Right now shadowAnonymous elements in the inspector share most of the limitations of the other anonymous nodes (ie XBLAnonymous, NativeAnonymous). See below a review of how our current anonymous flags are created and used: Usage of anonymous flags; - shadowAnonymous: - used for isNativeAnonymous ``` const isNativeAnonymous = (node) => hasBindingParent(node) && !(isXBLAnonymous(node) || isShadowAnonymous(node)); ``` + Implementation: similar to what we do in css-selector.js "getShadowRoot()" - isXBLAnonymous: - used for isNativeAnonymous (see snippet above) - used in standardTreeWalkerFilter ``` // Ignore all native and XBL anonymous content inside a non-XUL document. // We need to do this to skip things like form controls, scrollbars, // video controls, etc (see bug 1187482). if (!isInXULDocument(node) && (isXBLAnonymous(node) || isNativeAnonymous(node))) { return nodeFilterConstants.FILTER_SKIP; } ``` + Implementation: Is in bindingParent.getAnonymousNodes and is not a shadowAnonymouns - isNativeAnonymous: - used in standardTreeWalkerFilter (see snippet above) + Implementation: has a bindingParent, is not XBL, is not Shadow - isAnonymous: - used in markup-container.js isDraggable() (anonymous nodes are not draggable) - used in rules.js refreshAddRuleButtonState() (anonymous nodes cannot have new rules defined) - used in style-inspector-menu.js _openMenu() (again to prevent defining new rules) - used in rule-editor.js isSelectorEditable() (anonymous stylesheets cannot be edited) - used in inspector.js canAddHTMLChild() _openMenu() (flags isEditableElement, isDuplicatableElement) duplicateNode() isDeletable() + Implementation: ```getRootBindingParent(node) !== node;```, should be true for any of the more specialized isXxxAnonymous As you can see, the generic "isAnonymous" prevents a lot of actions. But for instance, let's look at all the limitations from inspector.js: can't edit the element, can't delete the element etc... Does this really make sense for shadow anonymous nodes? I think ultimately shadowAnonymous (not sure if we should actually keep calling them that) should behave more like elements from a nested iframe than like elements from a XBL binding.

Brian, how do you feel about that, should we turn on certain inspector features for shadow anonymous nodes?

(In reply to Julian Descottes [:jdescottes][:julian] from comment #1) > Brian, how do you feel about that, should we turn on certain inspector > features for shadow anonymous nodes? Sorry for missing this question. If individual context menu items / features make sense for nodes in Shadow DOM then yes, enabling them specifically for shadow anonymous makes sense to me. Thanks for breaking that down into bugs.