1476227 - [meta] Review isAnonymous flag behavior for shadowAnonymous elements

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Julian Descottes [:jdescottes]]

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.

Comment 1

[Julian Descottes [:jdescottes]]

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

Comment 2

[Brian Grinstead [:bgrins]]

(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.