1811002 - Filter selector closes on interaction with the select

Status: VERIFIED FIXED

(DevTools :: Inspector: Rules, defect, P2)

Description

[Rägnar O'ock]

Attachment: Animation.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

Inspect an element with a filter property applied to it.
Click the filter icon next the the filter property value to open the filter editor widget.
Click the select to open it.

(see attached GIF for reproduction)

Actual results:

When the select is clicked the editor widget closes preventing the selection of a new filter.

Expected results:

the Widget should not close when the select is clicked.

Comment 1

[Julian Descottes [:jdescottes]]

Thanks, would be nice to know when this regressed.

Comment 2

[Julian Descottes [:jdescottes]]

It seems to be because the mouseup event ends is triggered on the menupopup with id=ContentSelectDropdownPopup, which fails the _isInTooltipContainer check in HTML tooltip:

  _isInTooltipContainer(node) {
    // Check if the target is the tooltip arrow.
    if (this.arrow && this.arrow === node) {
      return true;
    }

    const tooltipWindow = this.panel.ownerDocument.defaultView;
    let win = node.ownerDocument.defaultView;

    // Check if the tooltip panel contains the node if they live in the same document.
    if (win === tooltipWindow) {
      return this.panel.contains(node);
    }

    // Check if the node window is in the tooltip container.
    while (win.parent && win.parent !== win) {
      if (win.parent === tooltipWindow) {
        // If the parent window is the tooltip window, check if the tooltip contains
        // the current frame element.
        return this.panel.contains(win.frameElement);
      }
      win = win.parent;
    }

    return false;
  },

This function is not handling cases where we have a "popup" in the tooltip, and said popup is not a child of the tooltip container. So I guess at some point the selectbox implementation changed so that the contextmenu element is no longer created in the same spot as the select itself.

Comment 3

[Julian Descottes [:jdescottes]]

Hi Emilio,

We have this logic for tooltips in devtools, where we hide the tooltip when we detect a mouseup on an element which is not in the tooltip container (ie, tooltip container is not an ancestor of the mouseup target).

One of those tooltips uses a select, and the select options are rendered in a menupopup living somewhere else in the DOM.

I am tempted to simply ignore mouseup events occurring in a menupopup for our tooltip logic, unless there is a way I can link a given menupopup to the select which created it? What do you think?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Yeah we don't have any machinery to go from the select menupopup to the select element right now. We could add this, but it'd be specific to the same-process case and thus probably more trouble than it's worth. So that sounds fine.

Comment 5

[Julian Descottes [:jdescottes]]

Attachment: Bug 1811002 - [devtools] Ignore mouseup events from menupopup elements in HTMLTooltip

menupopup elements created for select widgets will not be children of the select itself.
Therefore the check in HTMLTooltip to ignore events if they are triggered from within the tooltip container is not working.
There is no straightforward way to link the select to its popup, and we also can't do a coordinate check (because the menupopup might expand outside
of the initial tooltip), so for now we just ignore all events coming from a menupopup element.

A browser mochitest for the filter widget has been modified to verify this scenario.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/93fb6e15bf89
[devtools] Ignore mouseup events from menupopup elements in HTMLTooltip r=nchevobbe

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/93fb6e15bf89

Comment 8

[Daniel Bodea [:danibodea]]

This is quite an old regression:
Tested mozilla-central build: 2022-01-17 (verdict: bad)
Tested mozilla-central build: 2022-01-16 (verdict: good)
Mozregression could not go further as there aren't as old builds to bisect.

I've reproduced it in Beta v110.0b5 and verified the fix in Nightly v111.0a1 (2023-01-27) in Windows 10.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

I'm guessing it was bug 1744009 given the regression range.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9ef0614a5962&tochange=352dec7d8c13

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox110 to wontfix.

For more information, please visit auto_nag documentation.

Comment 11

[Julian Descottes [:jdescottes]]

Old regression, can ride the trains. Also would like to make sure that the proposed fix does not create other issues in other devtools tooltips.

Wontfix for 110.