Some select boxes flicker and do not remain open on click

REOPENED
Assigned to

Status

()

Core
Layout: Form Controls
P2
normal
REOPENED
8 months ago
6 months ago

People

(Reporter: tracy, Assigned: Jared Beach)

Tracking

({regression})

Trunk
mozilla53
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox49 unaffected, firefox50 unaffected, firefox51 unaffected, firefox52 unaffected, firefox53 fixed)

Details

(Whiteboard: tpi:+, URL)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Reporter)

Description

8 months ago
With latest Nightly 52.0a1, 20161110030211 on macOS 10.12

1) In this bug click on the select box for "Product"

Tested results: the select list flickers a few times. Then the select box returns to not selected state.

Expected results:  the list doesn't flicker and the list remains visible for perusal.  (Click on the select box for "Component" to observe correct behavior)

Neil:  jimm said you have been doing some work recently on select.  This appears to be a very recent regression.  I began seeing it in yesterdays build, but haven't confirmed that is the actual first regressed build.
(Reporter)

Comment 1

8 months ago
wtf, now Product select works? bizarre, it fails in other bug reports.   anyway, reproduce by clicking either of the select boxes for "Platform"  Seems like it is more likely to happen if the select box has a smaller list.  Less likely to happen of the list is long.
(Reporter)

Comment 2

8 months ago
moments later "Product" select buggy.  Something racy is going on here.
(Reporter)

Updated

8 months ago
Priority: -- → P2
Whiteboard: tpi:+

Updated

8 months ago
status-firefox49: --- → unaffected
status-firefox50: --- → unaffected
status-firefox51: --- → unaffected

Comment 3

8 months ago
I wonder of this is the same problem as bug 1316991?
(Reporter)

Updated

8 months ago
Duplicate of this bug: 1316991
[Tracking Requested - why for this release]: Regression in common user-facing UI.

Copying over the relevant info from the other bug: this is a regression from bug 430745.

Also copying over testcase and moving to the component where the regressing bug lived...  And copying the tracking nomination.

This is really a case where dupping the other way might have made more sense.  ;)
Blocks: 430745
tracking-firefox52: --- → ?
Component: Widget: Cocoa → Layout: Form Controls
Flags: needinfo?(jaws)
Flags: needinfo?(beachjar)
We should back out bug 430745 until we can get this issue figured out. This is a pretty clear Nightly blocker to me.
Flags: needinfo?(jaws)
I backed out bug 430745 so this issue will no longer affect Firefox 52.

However, this bug is still reproducible with the patch from https://hg.mozilla.org/mozilla-central/rev/d67c6dcba478

Neil, are you able to reproduce it? Do you see what could be going wrong?
status-firefox52: affected → unaffected
tracking-firefox52: ? → ---
Flags: needinfo?(beachjar) → needinfo?(enndeakin)
I can see it sometimes. I don't see it for menulists though.

There's a check for this in nsMenuFrame that ignores a mouseup immediately after a menu is opened unless another mousedown or mousemove occurs. It's possible that this check isn't applying to this case.

Alternatively we could implement a more correct check that distinguishes between a click or a menubutton and a quick down+hold.
Flags: needinfo?(enndeakin)
Actually, a possible easy fix may be to just move the setting of gMenuJustOpenedOrClosed from OpenMenu to PopupOpened.
Duplicate of this bug: 1317818
Jared, can you attach your patch here?
Assignee: nobody → beachjar
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)
Comment on attachment 8812229 [details]
Bug 1316597 Prevent immediate opening and closing of select dropdowns when anchored on selection

Neil will be the better reviewer for this change.
Attachment #8812229 - Flags: review?(jaws) → review?(enndeakin)

Comment 14

7 months ago
mozreview-review
Comment on attachment 8812229 [details]
Bug 1316597 Prevent immediate opening and closing of select dropdowns when anchored on selection

https://reviewboard.mozilla.org/r/94062/#review94896

Let's try it.
Attachment #8812229 - Flags: review?(enndeakin) → review+

Comment 15

7 months ago
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c7c83bfdd97a
Prevent immediate opening and closing of select dropdowns when anchored on selection r=enndeakin+6102

Comment 16

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c7c83bfdd97a
Status: ASSIGNED → RESOLVED
Last Resolved: 7 months ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
(Reporter)

Comment 17

7 months ago
With the latest Nightly 53.0a1, 20161123030208, this isn't fixed. This bug occurs more randomly than before.

Sometimes select boxes flicker (like the animation for an item being selected) and do not remain open on first click. However, click again and the second attempt results in expected behavior; no flicker and open select list.  If you have trouble reproducing, focus on one select box,  like "Need more information from" select below.  go back and forth between clicking on the default item, of the list, and clicking on the select box icon. soon enough, you'll see the unexpected buggy behavior.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Neil, can you take a look at what could be going wrong here?
Flags: needinfo?(enndeakin)
I don't see any issue and have tried many different ways.
Flags: needinfo?(enndeakin)
(In reply to Tracy Walker [:tracy] from comment #17)
> With the latest Nightly 53.0a1, 20161123030208, this isn't fixed. This bug
> occurs more randomly than before.
> 
> Sometimes select boxes flicker (like the animation for an item being
> selected) and do not remain open on first click. However, click again and
> the second attempt results in expected behavior; no flicker and open select
> list.  If you have trouble reproducing, focus on one select box,  like "Need
> more information from" select below.  go back and forth between clicking on
> the default item, of the list, and clicking on the select box icon. soon
> enough, you'll see the unexpected buggy behavior.

I'm having no luck reproducing this either. Hey tracy, would you be able to post a screenrecording of you reproducing this?
Flags: needinfo?(twalker)
(Reporter)

Comment 21

7 months ago
Created attachment 8815898 [details]
bug1316597FlickerSelect.gif

Happened a bit more often than usual during this recording.  It is rather random whether the flicker happens or not.
Flags: needinfo?(twalker)
(Reporter)

Comment 22

7 months ago
I cannot reproduce this using the trackpad. Reproducible with a usb mouse.

Comment 23

6 months ago
STR
I _think_ I've got a reproducible test case:

This is both reproducible with a mouse and a trackpad, but I definitely find it easier with a mouse.

1) On OS X, visit https://bug1266575.bmoattachments.org/attachment.cgi?id=8753475
2) Make sure "Volvo" is selected, and that the menupopup overlaps the <select> when it is open.
3) Make sure the <select> popup is closed.
4) This part is tricky and might take a few times: Click on the <select> dropdown, and move the mouse within the rect of the first menuitem "Volvo" _before_ the menupopup appears (there's a very small window of time to do this - maybe easier on slower machines).

ER:

The popup should display.

AR:

The mousemove seems to be interpreted as a selection on the menuitem, and so the item is selected and the popup closes.
Hey Enn - is this at all related to the work you're doing in bug 1311279? Part 3 in particular appears to cancel capture on mousemove... do you think that will fix this bug?
Flags: needinfo?(enndeakin)
I can't reproduce this at all so I don't know. Note that moving the mouse after mousedown should select the item and close the menulist.
Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.