1802215 - Let <panel-list>s be optionally embedded in a <xul:panel> so that they can float over other things

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, task)

Description

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

Attachment: WebRTC screen sharing permission panel

Up until now, <panel-list> has been restricted to in-content pages, and when they appear, they're restricted to the content area of the document they're embedded in.

For the most part, this has been fine, since most of those documents are sufficiently large enough for the list to appear in.

Now consider the WebRTC screen sharing permission panel (see screenshot).

The dropdown in there uses a <xul:menulist> very similar to what exists for <select> elements in content. The menulist is a popup that is ultimately controlled by the XULPopupManager to put a top-level window-like widget over top of things to show a native-like menu.

As we converge on using reusable components in more places, it'd be pretty convenient to be able to use <panel-list> for things like this dropdown. Unfortunately, the content area for that permission panel happens to be the outer panel, so a sufficiently long list would quickly get cropped off once it reaches the edge of the panel. The same goes for content modals, like the one we're building for migration in bug 1801313.

I'd like to propose that we make <panel-list> items that can be embedded in <panel> elements. The idea would be that given this structure:

<panel>
  <panel-list>
    <panel-item>...</panel-item>
    ...
  </panel-list>
</panel>

in panel-list.js's show method, after setting open = true, we would check to see if the direct ancestor of the <panel-list> is a <panel> in the XUL namespace. If so, it'd call openPopup on it, passing in the right arguments to have it anchor to the lastAnchorNode.

Knowing that we're embedded in a panel, we should then disable all of the position: absolute and automatic positioning behaviour of the <panel-list>.

So, interested callers could opt into this augmentation by making the <panel-list>'s direct ancestor a <panel> - which can only happen in environments where <panel>'s can exist, so we can avoid having a lot of "are we in a window that supports XUL" logic in panel-list.js.

And, to be clear, if the parent element is not a <panel>, then the <panel-list> would behave as it currently does.

Comment 1

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

Attachment: Bug 1802215 - Let the PanelList reusable component be embedded in <xul:panel> elements. r?mstriemer!

This gives us the ability to use the styling of a PanelList, but have the ability to break
outside of the document area using a <xul:panel> for things notification popups and dialogs.

Comment 2

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

Attachment: Bug 1802215 - Make sure panel-list anchoring works with targets within Shadow DOM. r?mstriemer!

The rAF and setTimeout in setAlign makes it so that the triggeringEvent will have
finished bubbling outside of any Shadow DOM root that contained its original target.
In that case, the composedPath() will be empty, and the _savedComposedTarget will
be overwritten with undefined.

This updates getTargetForEvent to only update the _savedComposedTarget if the
event's composedTarget or composedPath()[0] actually point to non-null values.

Depends on D166123

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1b4c48882a57
Let the PanelList reusable component be embedded in <xul:panel> elements. r=mstriemer
https://hg.mozilla.org/integration/autoland/rev/26cacd18b61e
Make sure panel-list anchoring works with targets within Shadow DOM. r=mstriemer

Comment 4

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/1b4c48882a57
https://hg.mozilla.org/mozilla-central/rev/26cacd18b61e