369599 - [Linux] Combo box with container visible only on hover disappears when hovering its dropdown

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Marian POPESCU]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070206 BonEcho/2.0.0.2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070206 BonEcho/2.0.0.2pre

<Select> item list is completely unusable when its container is visible only when hovered.

Reproducible: Always

Steps to Reproduce:
1. Load attached testcase
2. Hover the paragraphs
3. Try to change the value of the select list
Actual Results:  
Hovered item dissapears before changing the value

Expected Results:  
The value list sould be displayed and items should be selectable

I guess this kind of behavior poses some accesibility problems, as well.

Comment 1

[Marian POPESCU]

Attachment: Testcase that show select behavior when its container is hovered

Comment 2

[Marian POPESCU]

I can reproduce the bug with FF 2.0.x and 3.0.x

Comment 3

[Martijn Wargers (dead)]

Worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070207 Minefield/3.0a3pre

Comment 4

[Marian POPESCU]

(In reply to comment #3)
> Worksforme, using:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070207
> Minefield/3.0a3pre
> 

You are right, WFM with Windows builds !
Tested with FF2.0.x on Windows ... 

So, it's Linux only !!

Comment 5

[Gábor Stefanik]

Maybe also on Mac, I will test it later.

Comment 6

[Marian POPESCU]

The bug is still there in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120504 Minefield/3.0b2pre and the attached test case is even better !! Impossible to change select list value using the cursor !!!
Can someone do something about it?

Comment 7

[Gábor Stefanik]

Linux-only, can't reproduce on a Mac as well. Looks like Firefox/Linux doesn't consider the dropdown a child of the combo box. (Frame construction bug? DOM bug? I don't know.) Anyway, this fits Layout:Form Controls much better than Layout:View Rendering.

Comment 8

[Gábor Stefanik]

Also, changing summary to be more descriptive.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Actually, this would be a widgetry or view issue, not a form controls issue, I would guess....

See also bug 281551 for a possibly similar issue.

Comment 10

[Matthew Gregan [:kinetik]]

I think what's going on is that when we display the dropdown list it causes the main window to receive a focus out event.  This results in the nsComboboxControlFrame losing focus, which causes the dropdown list to be hidden again.

Comment 11

[Gábor Stefanik]

Maybe we should make sure that combo box dropdowns are always visible and fully opaque. That is, even when the combo box itself is hidden in the process, the dropdown should remain. (It doesn't make sense to hide the dropdown or make it transparent, anyway.) Hacky, but it should work until a real fix is found.

Comment 12

[Gábor Stefanik]

Note: there is a different bug visible on Mac: move the mouse over "bbbb", then down until the combobox disappears. Make it appear again, and voilá, it has changed value! (Again, I think that the dropdown shouldn't disappear when the combo box itself is hidden.)

Comment 13

[Matthew Gregan [:kinetik]]

Attachment: possible fix

My earlier comment was incorrect--the parent window does not receive a focus out event when the popup window containing the dropdown list is shown.  The parent does, however, receive a leave notify event, and this eventually results in the hover being removed as a result of a call to |SetContentState(nsnull, NS_EVENT_STATE_HOVER);| due to nsEventStateManager::NotifyMouseOut being called with |aMovingInto == nsnull|.  This code is intended to handle the case where the pointer has moved out of the window where the :hover was active by clearing the hover state.

This bug has existed since Firefox 0.8 (and probably earlier) and occurred with both the GTK+ 1 and 2 backends.

This case is a bit special, because the window we are moving into is supposed to be grabbing pointer/keyboard control from the parent window, so the parent shouldn't see the pointer leave.  I think the solution is to detect this case and suppress leave notify processing on the parent, but I need to think about it more to be sure.

The attached trivial patch suppresses LeaveNotify handling for the duration of a rollup menu existing.  This fixes the reported problem and does not seem to cause any other problems, but I have a feeling that the fix in this patch is too heavy handed.

We don't see this behaviour on Mac because mouse exit tracking is emulated by watching mouse move events and generating NS_MOUSE_EXIT when the window is not active and the move is not over a rollup widget.  It also doesn't occur on Windows, but I'm not sure why because I haven't followed through the logic to work it out.

The other behaviour noted in comment #12 should be reported in another bug.  Note that the same behaviour also occurs on Windows (and Linux, when the problem reported in _this_ bug is fixed), so this behaviour is cross platform  (and may not be considered a bug?), at least.

Comment 14

[Matthew Gregan [:kinetik]]

Forgot to mention--the change to nsWindow::OnWindowStateEvent is not related, but fixes a minor bug where we would always dispatch an event when processing window state changes rather than just on window minimize/maximize/restore due C operator precedence issue in the if statement intended to filter on the changed_mask value.

Comment 15

[Matthew Gregan [:kinetik]]

Oops, the change in nsWindow::OnLeaveNotifyEvent is not required and was left in unintentionally.  Please ignore it.

The proposed change is indeed too heavy handed.  For example, it will cause us to leave popup menu items highlighted when the pointer moves out of the popup menu area.

I think we need to suppress only specific leave notify events in this case, not all of them while a rollup is active.  I'll post a better patch soon.

Comment 16

[Matthew Gregan [:kinetik]]

I now have a better understanding of what's going on, but I don't know what the correct fix is yet.

When the combo box is clicked and the dropdown is shown (via nsComboboxControlFrame::ShowList), the combo box frame calls CaptureMouseEvents on its mListControlFrame.  This ends up calling nsViewManager::GrabMouseEvents and passing the list control's view as the mouse event grabbing frame.  We then call CaptureRollupEvents on the widget associated with the list control.  This eventually calls nsWindow::GrabPointer which calls gdk_pointer_grab which in turn calls XGrabPointer.  The top level window widget receives a LeaveNotify event as a result of the call to XGrabPointer.

When processing the LeaveNotify event, we look up the appropriate view to use for event handling.  Because of the call to nsViewManager::GrabMouseEvents earlier, we end up using the combo box's list control as the view.  The coords of the LeaveNotify are outside the bounds of this view (because the list control is displayed underneath or above the combobox and the pointer is directly over the combobox), so we consider it a mouse exit and eventually unhover the div.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we just suppress LeaveNotify events that are generated by GrabPointer?

Comment 18

[Matthew Gregan [:kinetik]]

Attachment: patch

This is a better fix.  With this patch, when we receive the LeaveNotify, query GTK+ for the window under the pointer and compare it to the window the event occurred on.  If they compare equal, the pointer has not really left the window, so suppress the LeaveNotify rather than generating a mouse exit.

Comment 19

[Matthew Gregan [:kinetik]]

Comment on attachment 293058 [details] [diff] [review]
patch

Requesting approval.  This patch fixes an issue that makes combo boxes unusable when they are in a page that only shows the combo box during hover activation of an element.  The patch solves this by supressing mouse exit events generated at inappropriate times (i.e. in cases were they would not be generated on other platforms).  The problem affects Linux/GTK+2 only, and the patch touches only Linux/GTK+2 code.  The patch is in code which is called regularly (on every LeaveNotify event), so any regressions introduced by this change should be detected quickly during normal use.

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 293058 [details] [diff] [review]
patch

a=beltzner for 1.9

Comment 21

[Marian POPESCU]

Thank you all for your work on this; I would like to mention, though, that this bug is reproducible with 2.0.x branch as well ...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12pre) Gecko/20071217 BonEcho/2.0.0.12pre

Can two rabbits be taken down by one shot?

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This patch could be backported to branch fairly easily but it doesn't meet normal branch criteria.

Comment 23

[Reed Loden [:reed]]

Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.244; previous revision: 1.243
done

Comment 24

[Marian POPESCU]

(In reply to comment #22)
> This patch could be backported to branch fairly easily but it doesn't meet
> normal branch criteria.
> 
Sorry for my ignorance, but what are those criteria?

Otherwise, the patch did a really good job !! Thank you all !

Comment 25

[Sylvain Pasche]

Could this have caused bug 477068?

Comment 26

[Matthew Gregan [:kinetik]]

gdk_display_get_window_at_pointer requires a round trip to the X server, which can be expensive when using X remotely.  Looking at bug 477068, it looks like the underlying cause was libXcb.  It's likely that the patch in this bug made the underlying problem in libXcb much more visible.