Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Inconsistent number of clicks when dismissing the downloads panel + dropmarker

RESOLVED DUPLICATE of bug 1362207

Status

()

Firefox
Downloads Panel
RESOLVED DUPLICATE of bug 1362207
11 months ago
2 months ago

People

(Reporter: alindeac, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 53
All
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox48 unaffected, firefox49 unaffected, firefox50 unaffected, firefox51 wontfix, firefox53 fixed)

Details

(Whiteboard: [CHE-BACKLOG][CHE-BUG])

MozReview Requests

()

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

Attachments

(8 attachments)

Created attachment 8789827 [details]
first issue.mp4

[Affected versions]:
- Nightly 51

[Affected platforms]:
- Windows 10

[Steps to reproduce]:
1. Launch Firefox.
2. Start a download and wait for it to complete
3. In the toolbar, click on the downloads button 
4. In the downloads panel click twice on the dropmarker 
5. Open the downloads panel again
6. click on the dropmarker
7. Click twice outside the panel's content


[Expected result]:
- In step 4: on the second click, the dropmarker is dismissed 
- In step 7: on the second click both the dropmarker and the panel are dismissed 

[Actual result]:
- In step 4: the second click does not dismiss the dropmarker (only the third click dismisses the dropmarker) please see first issue screencast.
- In step 7: the second click does not dismiss the dropmarker+downloads panel (sometimes 3 clicks are necessary to dismiss the dropmarker+downloads panel)- please see second issue screencast

[Regression range]:
- not a regression

[Additional notes]:
- not reproducible on Ubuntu 14.04 and Mac OS X 10.11
- so far I only reproduces the issue on Windows 10
Created attachment 8789828 [details]
second issue.mp4
Reproducible also on Windows 7.
OS: Windows 10 → Windows

Updated

10 months ago
Whiteboard: [CHE-MVP][CHE-BUG]
Created attachment 8798478 [details]
Event Log

eMouseDown is only triggered at popup showing moment in Linux and MacOSX (correct behavior),
but eMouseDown is triggered in nsMenuFrame::HandleEvent [1] for every left-click from users in Windows.

================
Let's see the behavior in Windows...
a. 1st click sends eMouseDown to nsMenuFrame::HandleEvent to show the panel. (correct)
b. 2nd click sends eMouseDown to nsMenuFrame::HandleEvent to show the panel again. (incorrect)
c. 3rd click sends eMouseDown to nsMenuFrame::HandleEvent, and [2] ("return false") blocks the panel showing then the panel is hidden.
d. 4th click sends eMouseDown to nsMenuFrame::HandleEvent to show the panel. (correct)
e. 5th click sends eMouseDown to nsMenuFrame::HandleEvent, and [2] ("return false") blocks the panel showing then the panel is hidden.
Then repeating step d. and e. so on.

BTW, eMouseActivate is sent to nsMenuFrame::HandleEvent only at 2nd click (b.)

================
Let's see the correct behavior in Linux and MacOSX...
a. 1st click sends eMouseDown to nsMenuFrame::HandleEvent to show the panel.
b. 2nd click doesn't send eMouseDown to nsMenuFrame::HandleEvent, so no flicker panel is here.
Then repeating step a. and b. so on.
There is no eMouseActivate in both Linux and MaxOSX.

Thanks a lot for the support of Stone and Tom to guide me to trace these behaviors.

The attachment is the detail log for Windows, Linux and MacOSX. Please see the log patch at [3].

[1] http://searchfox.org/mozilla-central/rev/76609a05d6ef7ba4223ed79e479c73fb2543a107/layout/xul/nsMenuFrame.cpp#374
[2] http://searchfox.org/mozilla-central/rev/76609a05d6ef7ba4223ed79e479c73fb2543a107/layout/xul/nsXULPopupManager.cpp#1773
[3] https://github.com/weilonge/gecko/commit/55ba82301aeefdf5a4f8dcb135d108a230c4aa8e.patch
Hi Stone,

Could you provide your suggestion for the extra eMouseDown event in Windows? or anyone is familiar with this kind of issue?
Thanks a lot for your guidance!
Flags: needinfo?(sshih)

Comment 5

10 months ago
I don't think the eMouseDown event fired at the second mouse click is an extra event. I think this bug is caused by [1] which listens windows message to control rollup of the popup menu. At the second mouse click on the "Show All Downloads", Windows fires WM_ACTIVATE(with wParam=WA_CLICKACTIVE) and WM_LBUTTONDOWN. WM_ACTIVATE (see [2] for more about it) triggers rollupListener->Rollup in [1]. It changes the popup menu state to ePopupClosed. Then WM_LBUTTONDOWN generates eMouseDown which triggers nsXULPopupManager [3] to show the popup menu (it shows popup menu because its state is ePopupClosed).

BTW, I tested on my laptop with windows10.

[1] http://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#7659
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms646274(v=vs.85).aspx
[3] http://searchfox.org/mozilla-central/source/layout/xul/nsXULPopupManager.cpp#742
Flags: needinfo?(sshih)

Comment 6

10 months ago
Wondering should we trigger rollupListener in [1]?

Comment 7

10 months ago
(In reply to Ming-Chou Shih [:stone] from comment #6)
> Wondering should we trigger rollupListener in [1]?

In the case of WM_ACTIVATE (with wParam=WA_CLICKACTIVE).
When the second time we click dropmarker, Windows will fire WM_MOUSEACTIVATE, WM_ACTIVATE(LOWORD(aWParam) == WA_CLICKACTIVE)), WM_LBUTTONDOWN to dropmarker. In that case, we [1] leave WM_MOUSEACTIVATE to be handled in wndproc because we click dropmarker (not click inside the popup nor its children). We trigger rollup listener to rollup the popup in [2] because we don't meet the criteria in [3]. When handling WM_LBUTTONDOWN, it trigger rollup listener again and show the popup.

Check MSDN document in [4], Windows will fire WM_ACTIVATE(LOWORD(aWParam) == WA_CLICKACTIVE)) when firing WM_MOUSEACTIVATE. Considering the behavior of handling WM_MOUSEACTIVATE and had some discussions with seanlee, we think the solution may be ignore the event WM_ACTIVATE(LOWORD(aWParam) == WA_CLICKACTIVE)). Is it make sense to you?

[1] http://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#7612
[2] http://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#7659
[3] http://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#7573
[4] https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms646274(v=vs.85).aspx
Flags: needinfo?(masayuki)
Hmm, sounds like too risky change. Should we always ignore even if ShouldRollupOnMouseActivate() returns false??

And when you change around here, please test with a lot of touchpads on Win7 or Win8.1 as far as possible because starting Win10, mouse wheel messages are sent to the window under the mouse cursor.  However, on older Windows, they are sent to focused window, therefore, some touchpad utilities may set focus under the mouse cursor forcibly.  That broke our popup window behavior, for example, dropdown list was closed at scrolling the list by touchpad. I reported and fixed it when I found the case with old Zenbook. See bug 953146.  Although, I don't have the environment because I upgraded it to Win10. I'll check it later if I can test it on Win10, though.
Flags: needinfo?(masayuki)
Many thanks for your information. I'll followup to test on more Windows versions to figure out the solution for this bug.
Hi Stone, nice to meet you! Since this is the MVP of our project we're following it ~3 times a week project-wise, so would like to know the status here. Would you kindly share us the latest progress here? Thanks!
Flags: needinfo?(sshih)
Now we had found the cause and try to figure out the solution. We need to take windows 7 or 8.1 into consideration when implementing the solution. You can find more details in comment 9.
Flags: needinfo?(sshih)
Thanks for the prompt update, Stone.
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #9)
> Hmm, sounds like too risky change. Should we always ignore even if
> ShouldRollupOnMouseActivate() returns false??

The rollup listener will also be triggered by WM_LBUTTONDOWN. If we also trigger popup listener when WM_ACTIVATE with LOWORD(aWParam) == WA_CLICKACTIVE, the the popup will be hided then be showed by WM_LBUTTONDOWN.

Compare the logic of WM_ACTIVATE(LOWORD(aWParam) == WA_CLICKACTIVE) and WM_MOUSEACTIVATE when user click the parent of popup, we leave WM_MOUSEACTIVATE to be handled by wndproc but we trigger popup listener for WM_ACTIVATE. That's why I'm wondering if we can leave WM_ACTIVATE(LOWORD(aWParam) == WA_CLICKACTIVE) to be handled by wndproc w/o trigger popup listener.
Hi Masayuki:

This is EPM Wesly, nice to meet you! 

I just finished a discussion with Stone and some project members, and realized it's a bug that needs enough familiarity in this area in order to fix it well, so wondering is it feasible for you to help us on it (take this bug)?

We care about this issue because it blocks some of our implementation originally planned in FFX nightly 52 (I know it seems a bit hurry now), and we may now re-target this one (and relevant feature) to nighty 53. We've also considered to have Stone work on this bug, but it looks hard to meet our timeline due to his current assignments in hand (also checked with his manager).

Thanks.
Flags: needinfo?(masayuki)
Hi Wesly,

About the question "What is the test scenario if we ask helps from softvision", I think the test scenario is
1. click on the download button in the toolbar.
2. click on the dropmarker.
3. click on everywhere and check if dropmarker / download panel is showed or hided correctly.
Unfortunately, I don't have much time to work on this bug for now...
Flags: needinfo?(masayuki)
(Thanks for Masayuki's reply and Stone's information!)

Hi Morpheus:

We had some further discussion with Stone and would like to ask for UX's comment.

With more plays on the device in problem (Win 7/8.1/10 NB with touchpad of Elantech or Synaptics) we are not sure if they are all desired behaviors when dismissing the downloads panel + dropmarker (to dismiss both or not). See the attached video:

Once you've opened the "downloads panel + dropmarker"

Case 1 (~ 7s in the video). move the mouse cursor (no click) to the web page area behind/outside the "downloads panel + dropmarker", then scroll the touchpad
Case 2 (~10s in the video). move the mouse cursor (no click) to main menu, then scroll the touchpad

Case 3 (~25s in the video). move the mouse cursor (no click) to the web page area behind/outside the "downloads panel + dropmarker", then click the mouse twice
Case 4 (~30s in the video). move the mouse cursor (no click) to main menu, then click the mouse twice.

Case 5 (~39s in the video). move the mouse cursor (no click) to tool bar then click the homepage icon twice.

Btw, after case 2 (~16s in the video), you will see the browser icon in windows task bar blinks, we assume this should not be expected?

Looks to me in most cases one mouse click will only dismiss the dropmarker, then the 2nd click to dismiss main menu, and touchpad scroll has no effect. The exception is case 4 which main menu should be kept since you click that area. Is that the correct understanding and expected behavior?

Thanks.
Video link for comment#18.
Video link for comment#18.

https://drive.google.com/a/mozilla.com/file/d/0Bz6aW3cbHgB8Y1RURlRDcUpGb1k/view?usp=sharing
Flags: needinfo?(mochen)
Created attachment 8806251 [details]
Download panel dropdown menu.png

Hi all,

I've attached an illustration trying to keep the rules simple since it's complicated to click twice for dismissing panel and sub-menu separately. Please find my comments below for more details, thanks.

(In reply to Wesly Huang (Firefox EPM) from comment #18)
> (Thanks for Masayuki's reply and Stone's information!)
> 
> Hi Morpheus:
> 
> We had some further discussion with Stone and would like to ask for UX's
> comment.
> 
> With more plays on the device in problem (Win 7/8.1/10 NB with touchpad of
> Elantech or Synaptics) we are not sure if they are all desired behaviors
> when dismissing the downloads panel + dropmarker (to dismiss both or not).
> See the attached video:
> 
> Once you've opened the "downloads panel + dropmarker"
> 
> Case 1 (~ 7s in the video). move the mouse cursor (no click) to the web page
> area behind/outside the "downloads panel + dropmarker", then scroll the
> touchpad

The web content will be scrolled but panel and sub-menu won't be dismissed 

> Case 2 (~10s in the video). move the mouse cursor (no click) to main menu,
> then scroll the touchpad

Nothing happens when scrolling on the main panel. However, downloads will be scrolled only if there is no space for displaying 5 downloads in the panel. (ex. pretty low-resolution computer)

> Case 3 (~25s in the video). move the mouse cursor (no click) to the web page
> area behind/outside the "downloads panel + dropmarker", then click the mouse
> twice

Clicking outside of the panel only one time will dismiss both the panel and sub-menu.

> Case 4 (~30s in the video). move the mouse cursor (no click) to main menu,
> then click the mouse twice.

1. Clicking on any spot where doesn’t trigger any following action or on sub-menu button will dismiss the sub-menu
2. Clicking on any spot where triggers action will dismiss entire panel and execute the action
3. Clicking on any spot where triggers action within the panel will dismiss the sub-menu

> Case 5 (~39s in the video). move the mouse cursor (no click) to tool bar
> then click the homepage icon twice.

Toolbar is counted as "outside of the panel" too.  

> Btw, after case 2 (~16s in the video), you will see the browser icon in
> windows task bar blinks, we assume this should not be expected? 

Yes, this looks like a bug.

> Looks to me in most cases one mouse click will only dismiss the dropmarker,
> then the 2nd click to dismiss main menu, and touchpad scroll has no effect.
> The exception is case 4 which main menu should be kept since you click that
> area. Is that the correct understanding and expected behavior?
> 
> Thanks.
Flags: needinfo?(mochen)
(Thanks Morpheus's clarification!)

Hi Stone, 

Please feel free to say shall you have any question about the suggested design, or problem about the feasibility to fix the issue with it, thank you.
Flags: needinfo?(sshih)

Comment 23

8 months ago
Stone, any update on this bug?
After discussing with Wesly Huang, btian, hsinyi and seanlee, we'd like to focus on the original problem [1] mentioned in this bug and handle the others in follow ups. 

In the case of [1], down panel was clicked to show drop marker. The active rollup listener [2] is drop marker. When clicking download panel to hide the dropmarker, Windows fires WM_ACTIVATE with LOWORD(aWParam)=WA_CLICKACTIVE to the window of down panel. So it won't meet the condition in [3] and will rollup dropmarker.
>        if (EventIsInsideWindow(popupWindow) ||
>            !GetPopupsToRollup(rollupListener, &popupsToRollup)) {
>          return false;
>        }

Referring to the logic of [3], I refined it as checking whether the current window is popup to decide rolling up popups or not.

[1] Inconsistent number of clicks when dismissing the downloads panel + dropmarker 
[2] http://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#7458
[3] http://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#7573
Flags: needinfo?(sshih)
Comment hidden (mozreview-request)
(Thanks to Stone's effort on it!)

Hi Ben:

Let's open necessary follow-up bugs and let the bug here focus on the original (reported) symptom which Stone is going to fix. 

I'll log one bug for the "blink" problem in comment 18 case#2. Would you help work with Sean to create the other(s), mainly the design Morpheus put in comment 21? (You can have a suitable breakdown that best fits your judgment)

Thanks.
Flags: needinfo?(btian)
See Also: → bug 1317920
Sorry for the delay to review. I current have urgent bug on release build and I'd like to test your patch before review, so, please give a few days to check this.

Comment 28

8 months ago
mozreview-review
Comment on attachment 8810792 [details]
Bug 1301708 - nsWindow::DealWithPopup() should do nothing at receiving WM_ACTIVATE for a popup window and its wParam includes WA_CLICKACTIVATE.

https://reviewboard.mozilla.org/r/93100/#review94844

Okay, this works fine on my environments including odd touchpad driver.

However, please modify commit message before landing. The summary should explain what this patch does. For example, "nsWindow::DealWithPopup() should do nothing at receiving WM_ACTIVATE for a popup window and its wParam includes WA_CLICKACTIVATE". And please explain why we should do so in the commit message after inserting an empty line after the summary.

I'm really sorry for the delay.
Attachment #8810792 - Flags: review?(masayuki) → review+

Comment 29

8 months ago
Assign to Stone since he's already working on this bug.
Assignee: nobody → sshih
https://treeherder.mozilla.org/#/jobs?repo=try&revision=23a6503c702b890c2b3dcd11f6f12b2d17583baa
Comment hidden (mozreview-request)

Updated

8 months ago
Keywords: checkin-needed
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #28)
> Comment on attachment 8810792 [details]
> Bug 1301708 - nsWindow::DealWithPopup() should do nothing at receiving
> WM_ACTIVATE for a popup window and its wParam includes WA_CLICKACTIVATE.
> 
> https://reviewboard.mozilla.org/r/93100/#review94844
> 
> Okay, this works fine on my environments including odd touchpad driver.
> 
> However, please modify commit message before landing. The summary should
> explain what this patch does. For example, "nsWindow::DealWithPopup() should
> do nothing at receiving WM_ACTIVATE for a popup window and its wParam
> includes WA_CLICKACTIVATE". And please explain why we should do so in the
> commit message after inserting an empty line after the summary.
> 
> I'm really sorry for the delay.

Many thanks for your review.

Comment 33

8 months ago
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/36a118cbe815
nsWindow::DealWithPopup() should do nothing at receiving WM_ACTIVATE for a popup window and its wParam includes WA_CLICKACTIVATE. r=masayuki
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/36a118cbe815
Status: NEW → RESOLVED
Last Resolved: 8 months ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
Blocks: 1320259
I have reproduced this bug with nightly  51.0a1 (2016-09-09) (64-bit) on Windows 7 , 64 Bit !

This bug's fix is verified with latest Nightly

Build    ID  20161126030207
User  Agent  Mozilla/5.0(Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
[bugday-20161123]
Hi Simona, should we set this issue to VERIFIED FIXED per Maruf's help on Comment#35? Thanks!
Flags: needinfo?(simona.marcu)
Created attachment 8815214 [details]
issueStep4.mp4

I can still reproduce this issue on the latest Nightly 53.0a1 on Windows 10 (it's highly intermittent and depends on how fast you click the mouse)

Please see the screen casts.

Reopening the bug.
Flags: needinfo?(simona.marcu)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 8815215 [details]
issueStep7.mp4

Screen cast with the issue from step 7.
According to the video, it looks like a double click. In our current implementation, we don't handle Windows double click message to roll up the popup windows. So even we click twice, only one popup window is rolled up.
According to comment#21

> > Case 3 (~25s in the video). move the mouse cursor (no click) to the web page
> > area behind/outside the "downloads panel + dropmarker", then click the mouse
> > twice
> 
> Clicking outside of the panel only one time will dismiss both the panel and
> sub-menu.

If we dismiss the panel and sub-menu when clicking outside of the panel, the problem found in comment#37 should be no longer exist. So we should handle comment#21 case 3. Created bug1321712 for it.
Depends on: 1321712

Comment 41

7 months ago
Per comment 40, comment 38 problem (comment 21 case 3) differs from original one (case 4-1 & 4-3). Bug 1321712 will track comment 38 problem. Remove this bug's dependency on bug 1321712.

Simona, can you verify this bug again with comment 0 scenario?
Flags: needinfo?(btian) → needinfo?(simion.basca)

Updated

7 months ago
No longer depends on: 1321712
Created attachment 8818265 [details]
Dropdown dismiss.mp4

This is getting a bit confusing. I'd agree that it's easier to see it as two different bugs, but IMHO there are two faces of the same issue: dismissing the dropmarker by:

1 - clicking on the Dropmarker down arrow
2 - clicking outside the dropmarker

For 2nd behavior - bug 1321712 was logged (according with Comment 40) --> still reproducible.

As for the first behavior, that is still reproducible as well. For a better understanding I'm attaching a new screen cast. Please note that I'm not doing a double click, it's just left clicking, although faster. But for the sake of argument, why a double click shouldn't be supported?
Flags: needinfo?(simion.basca)

Comment 43

7 months ago
ni? Stone to help clarify comment 42.
Flags: needinfo?(sshih)
(In reply to Simona B [:simonab ] from comment #42)
> 1 - clicking on the Dropmarker down arrow
> 2 - clicking outside the dropmarker
> 
> For 2nd behavior - bug 1321712 was logged (according with Comment 40) -->
> still reproducible.
Yes. It's ongoing.

> As for the first behavior, that is still reproducible as well. For a better
> understanding I'm attaching a new screen cast. Please note that I'm not
> doing a double click, it's just left clicking, although faster. But for the
> sake of argument, why a double click shouldn't be supported?
I only can reproduce it when the Windows fires WM_LBUTTONDOWN and WM_LBUTTONDBLCLK. If I slow down a bit, the messages fired by Windows are two WM_LBUTTONDOWN and the problem is no longer reproducible. 

> But for the sake of argument, why a double click shouldn't be supported?
For the 2nd behavior, we don't need to handle double-click to roll up popups because of 1321712, we should already roll up download panel and sub-menus at WM_LBUTTONDOWN.

For the 1st behavior, I think we should handle it to roll up the sub-menus. I'll try to work on it.
Flags: needinfo?(sshih)

Comment 45

7 months ago
Simona, please refer to comment 44 and let us know if you are fine to verify original problem only or have further question. Thanks!
Flags: needinfo?(simona.marcu)
It seems to me that the problem from comment#0 step4 is not yet fixed. I do not follow if that shall be fixed or what exactly am I supposed to verify at this point. According to the Comment #44, the mouse event that reproduces the issue is WM_LBUTTONDBLCLK. (:stone, could you please suggest a mouse event listener that i could use)
(In reply to Ming-Chou Shih [:stone] from comment #44)
> For the 1st behavior, I think we should handle it to roll up the sub-menus.
> I'll try to work on it.
Does this make the comment#0 ActualResult step4 issue a Not Fix or is it :stone attempting to fix it?
Flags: needinfo?(simona.marcu) → needinfo?(btian)
Flags: needinfo?(sshih)
(In reply to Simona B [:simonab ] from comment #46)
> It seems to me that the problem from comment#0 step4 is not yet fixed. I do
> not follow if that shall be fixed or what exactly am I supposed to verify at
> this point. According to the Comment #44, the mouse event that reproduces
> the issue is WM_LBUTTONDBLCLK. (:stone, could you please suggest a mouse
> event listener that i could use)
Please use dblclick.

> Does this make the comment#0 ActualResult step4 issue a Not Fix or is it
> :stone attempting to fix it?
Yes, I'm attempting to fix it.
Flags: needinfo?(sshih)

Comment 48

7 months ago
Clear my ni? as Stone replied in comment 47.
Flags: needinfo?(btian)

Comment 49

7 months ago
Simona, does Stone's comment 47 suggestion of mouse event listener work?

Updated

7 months ago
Flags: needinfo?(simona.marcu)

Updated

7 months ago
See Also: → bug 1321712
(In reply to Ming-Chou Shih [:stone] from comment #47)

> Please use dblclick.

Could you please be more specific?
Flags: needinfo?(simona.marcu)
Flags: needinfo?(sshih)
(In reply to Simona B [:simonab ] from comment #50)
> (In reply to Ming-Chou Shih [:stone] from comment #47)
> 
> > Please use dblclick.
> 
> Could you please be more specific?

I use document.addEventListener("dblclick", (e) => {console.log(e.type);}) to test if it's a double click event or not (I use it the test the case of clicking outside of the download panel)

Another way is to adjust double click speed of Windows mouse setting. If you change it to faster, it would be harder to reproduce the problem.
Flags: needinfo?(sshih)
(In reply to Ming-Chou Shih [:stone] from comment #51)
> (In reply to Simona B [:simonab ] from comment #50)
> > (In reply to Ming-Chou Shih [:stone] from comment #47)
> > 
> > > Please use dblclick.
> > 
> > Could you please be more specific?
> 
> I use document.addEventListener("dblclick", (e) => {console.log(e.type);})
> to test if it's a double click event or not (I use it the test the case of
> clicking outside of the download panel)

Sorry for the late response, somehow this fell of my radar.
Indeed, if I use this event listener each time I reproduce this issue by clicking outside the panel, dbclick is displayed in the console (even if to me it does not feel like a double click)
 
> Another way is to adjust double click speed of Windows mouse setting. If you
> change it to faster, it would be harder to reproduce the problem.

I adjusted the mouse speed to the maximum fast and I could not reproduce the issue.
We've built 51 RC. Mark 51 won't fix.
status-firefox51: affected → wontfix
Based on bug 1321712 comment 10 (see below), the behavior at comment 38 can be reproduced on the "Page Bookmarked" panel as well.

(In reply to :Paolo Amadini from comment #10)
> One of the examples made is when you click the star button on the toolbar to
> open the "Page Bookmarked" panel, then open the "Folder" dropdown to make a
> choice. At present, you can click anywhere in the browser window to close
> the dropdown, but the panel remains open to allow other edits. With this
> change, if you wanted to close the dropdown but keep the panel open, you
> would have to click inside the panel.
After discussed the issue with Sean and Stone, I think it's a long hang bug which did not specifically affect to download panel, but influence any drop maker in Firefox (like the bookmark case Paolo mentioned). Therefore, I think it shall not block the development of the drop marker feature on the download panel.

I've tried it on Nightly 54 on Windows 10. Although I can not robustly reproduce the bug every time I double-click outside of the panel (maybe I don't have a metronome hand), it does disturb me a bit when the panel stick and would cost my third click to dismiss that. However, I wonder how serious the user will perceive that issue in real download context. Now, we all wearing a laser point lens focusing on that "double-click," so probably we are much sensitive to the bug we found. Meanwhile, considering that open drop marker is not a major use case, I think we can treat it as a backlog and move forward.

In general, I see two questions ahead:
1. How to solve the click recognition issues in Windows
2. Should we dismiss the panel+drop marker in one or two clicks?

Ideally, the users should be able to dismiss the panel+drop marker in one click as I assume their focus is already shifted. But doing so might cost lots of engineering works to think how to refactoring Firefox as a whole to avoid regression. Meanwhile, even if we choose the one click solution it only hides the bug, and we don't know where it will be up to the surface again. Thanks Simona to discover it, and I think it is worth to keep observing bugs that related to the click recognition issues.

Comment 56

6 months ago
To sum up, comment 37 bug:
- occurs only if OS sends incorrect double click event (comment 52), and disappears with max mouse speed 
- is an existing bug (comment 54)
- is not a major use case and should not block the dropmarker feature per UX designer suggestion (comment 55)
Whiteboard: [CHE-MVP][CHE-BUG] → [CHE-BACKLOG][CHE-BUG]
Per discussion with Project & Product we will not enable dropmaker beyond Aurora, and move this issue to backlog. People are free to take it before we are back and resume the work.

Updated

3 months ago
Assignee: sshih → nobody

Updated

3 months ago
Status: REOPENED → RESOLVED
Last Resolved: 8 months ago3 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1362207
You need to log in before you can comment on or make changes to this bug.