1412390 - Cannot click bottom part of buttons when their panel is open

Status: NEW

(Firefox :: Toolbars and Customization, defect, P5)

Description

[Florens Verschelde :fvsch]

Attachment: firefox-photon-panel-arrow-blocks-clicks.png

Steps to reproduce:

1. Click the main menu button, so that the main menu panel is open
2. Click the bottom part of the menu button, just 2 or 3 pixels below the bottom bar of the "hamburger" icon.

Expected result:
The main menu panel closes.

Actual result:
Nothing happens.

The click is caught by the dropdown panel, because we're clicking on the invisible part that contains the arrow (triangle) decoration.

If we add a background color to the panel, we can see the full area that is blocked (see screenshot).

#downloadsPanel, #widget-overflow, #appMenu-popup, #customizationui-widget-panel {
    /* show area that overlays toolbar buttons */
    background: #0F08;
    margin-top: -6px;
}

This issue can be problematic because if a user opened the panel by clicking the bottom third of a button, they cannot click again to close the panel. It also blocks access to the bottom third of all nearby toolbar buttons, giving the impression that the UI is unresponsive.
This can also be a problem when a user targets the middle part of the button but "undershoots".

Possible fixes:

In HTML I would position the arrow outside of the main container, with a negative margin or with absolute positioning, and make sure the arrow has `pointer-events:none`. I tried that in the Browser Toolbox but it looks like I’m hitting some XUL limitations maybe?
- abspos -> could not make it work
- negative margin -> works but the arrow gets clipped
- `pointer-events:none` -> seemed to have no effect

Comment 1

[Sam Foster [:sfoster] (he/him)]

pointer-events:none on the arrowbox should do it. If not, it might be because the pointer events are not getting passed through the popup window?

Comment 3

[:Gijs (he/him)]

(In reply to Sam Foster [:sfoster] from comment #1)
> pointer-events:none on the arrowbox should do it.

This doesn't seem to be enough, at least on macOS. :-(

> If not, it might be
> because the pointer events are not getting passed through the popup window?

I guess so. Neil, can we fix this somehow?

Comment 4

[Neil Deakin]

pointer-events only handles mouse events passing through to somewhere on the same native widget.

But that's not actually the issue here. What you want is for the popup rollup code to treat some portions of the panel as not actually part of the panel. Currently, this uses the popup widget's rectangle to determine whether a mouse event is in the panel or not. The code to do this is platform-specific; for example on Mac it is done by nsCocoaUtils::IsEventOverWindow.

Some options:

1. Have something that allows one to specify specific regions of the panel as not part of the panel. This is the most flexible but hardest option to implement as it requires writing code and testing on multiple platforms and I'm not sure what this mechanism would be.
2. Just allow one to specify a margin around the panel as not part of it. This also requires platform code but would be easier to implement. The arrow would be treated as outside the panel though; maybe that is desired?
3. Add a mousedown listener to the transparent area around the arrow that hides the panel manually. The disadvantage is that the mouse event would not get redirected to whatever was behind the panel which is the normal behaviour on Windows.

I would expect that we've always had this issue though. Is the arrow been moved up to make it more noticeable?

Comment 5

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #4)
> pointer-events only handles mouse events passing through to somewhere on the
> same native widget.
> 
> But that's not actually the issue here. What you want is for the popup
> rollup code to treat some portions of the panel as not actually part of the
> panel. Currently, this uses the popup widget's rectangle to determine
> whether a mouse event is in the panel or not. The code to do this is
> platform-specific; for example on Mac it is done by
> nsCocoaUtils::IsEventOverWindow.

I take it this applies 'even' to mousemove/over events, not just to clicks?

Could we take the pointer-events state of the bit 'under' the mouse in the panel into account if the event is 'over' the window? Seems like that would be like option 1 but then we can piggy-back on CSS to do the regions stuff and hopefully it wouldn't be that complicated to implement then?

> Some options:
> 
> 1. Have something that allows one to specify specific regions of the panel
> as not part of the panel. This is the most flexible but hardest option to
> implement as it requires writing code and testing on multiple platforms and
> I'm not sure what this mechanism would be.
> 2. Just allow one to specify a margin around the panel as not part of it.
> This also requires platform code but would be easier to implement. The arrow
> would be treated as outside the panel though; maybe that is desired?

What would the consequences here be? Ideally, it shouldn't be the case that clicking the arrow itself would click "through" the arrow... If that's what this would cause, I don't think it would be ideal... You would also start seeing hover effects 'through' the arrow, which seems like it'd be unfortunate...

> 3. Add a mousedown listener to the transparent area around the arrow that
> hides the panel manually. The disadvantage is that the mouse event would not
> get redirected to whatever was behind the panel which is the normal
> behaviour on Windows.

So this would just hide the panel, but not click the button you meant to click, I take it? I guess this also wouldn't fix the hover state issue we have right now (ie hovering buttons "through" the transparent bit of the panel also doesn't work). :-(

> I would expect that we've always had this issue though. Is the arrow been
> moved up to make it more noticeable?

Maybe this is more noticeable on nightly with bug 1033395 landed. I don't know if the reporter tested on release, beta or nightly.

Comment 6

[Neil Deakin]

(In reply to :Gijs (no reviews; PTO recovery mode) from comment #5)
> > But that's not actually the issue here. What you want is for the popup
> > rollup code to treat some portions of the panel as not actually part of the
> > panel. Currently, this uses the popup widget's rectangle to determine
> > whether a mouse event is in the panel or not. The code to do this is
> > platform-specific; for example on Mac it is done by
> > nsCocoaUtils::IsEventOverWindow.
> 
> I take it this applies 'even' to mousemove/over events, not just to clicks?

What I described only applies to mouse events that are mousedown and wheel events as well as various non-mouse events.

For mousemove events, it is likely because nsLayoutUtils::GetPopupFrameForEventCoordinates only handles checking the popup's rectangle. From my testing, mousemove does appear to work for elements in other background windows in that panel margin, so I'm pretty sure that is the issue. I'm not familiar enough with what would need to be done instead though.

Comment 7

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #6)
> (In reply to :Gijs (no reviews; PTO recovery mode) from comment #5)
> > > But that's not actually the issue here. What you want is for the popup
> > > rollup code to treat some portions of the panel as not actually part of the
> > > panel. Currently, this uses the popup widget's rectangle to determine
> > > whether a mouse event is in the panel or not. The code to do this is
> > > platform-specific; for example on Mac it is done by
> > > nsCocoaUtils::IsEventOverWindow.
> > 
> > I take it this applies 'even' to mousemove/over events, not just to clicks?
> 
> What I described only applies to mouse events that are mousedown and wheel
> events as well as various non-mouse events.
> 
> For mousemove events, it is likely because
> nsLayoutUtils::GetPopupFrameForEventCoordinates only handles checking the
> popup's rectangle. From my testing, mousemove does appear to work for
> elements in other background windows in that panel margin, so I'm pretty
> sure that is the issue. I'm not familiar enough with what would need to be
> done instead though.

Who would be a good person to ask about that? :-)

Comment 8

[Neil Deakin]

Essentially the question we want to know is, given a mouse event and a list of the open popups, how would we determine whether the mouse event corresponds to a transparent area of the popup. I'm assuming that only entirely transparent is all that is relevant here.

I tried to use GetFrameForPoint but it didn't seem to work for this and would always return the popup itself or one of its elements, even when it was transparent and/or had pointer-events: none. mstange seemed to think that would work but I may just need to investigate more.