|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
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.
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.
moments later "Product" select buggy. Something racy is going on here.
I wonder of this is the same problem as 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. ;)
We should back out bug 430745 until we can get this issue figured out. This is a pretty clear Nightly blocker to me.
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?
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.
Actually, a possible easy fix may be to just move the setting of gMenuJustOpenedOrClosed from OpenMenu to PopupOpened.
Jared, can you attach your patch here?
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.
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.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/c7c83bfdd97a Prevent immediate opening and closing of select dropdowns when anchored on selection r=enndeakin+6102
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.
Neil, can you take a look at what could be going wrong here?
I don't see any issue and have tried many different ways.
(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?
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.
I cannot reproduce this using the trackpad. Reproducible with a usb mouse.
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?
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.
(In reply to Neil Deakin (not available until Aug 9) from comment #25) > 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. Yes. If I hold my mouse extremely steady with one hand and perform the click with the other hand, the mouse doesn't move and this bug isn't reproducible. It seems there is no room for mouse "slip" here. The mouse I use and my hand aren't always perfectly steady on mouse click, thus a pixel or so of movement often happens during a rapid click. Is there a way to allow a little bit of mouse pointer "slip?" Say a couple pixels?