1301708 - Inconsistent number of clicks when dismissing the downloads panel + dropmarker

Status: RESOLVED DUPLICATE of bug 1362207

(Firefox :: Downloads Panel, defect)

Description

[Simona Badau, Desktop QA]

Attachment: 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

Comment 1

[Simona Badau, Desktop QA]

Attachment: second issue.mp4

Comment 2

[Simona Badau, Desktop QA]

Reproducible also on Windows 7.

Comment 3

[Sean Lee [:seanlee][:weilonge]]

Attachment: 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

Comment 4

[Sean Lee [:seanlee][:weilonge]]

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!

Comment 5

[Ming-Chou Shih [:stone]]

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

Comment 6

[Ming-Chou Shih [:stone]]

Wondering should we trigger rollupListener in [1]?

Comment 7

[Ming-Chou Shih [:stone]]

(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).

Comment 8

[Ming-Chou Shih [:stone]]

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

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 10

[Ming-Chou Shih [:stone]]

Many thanks for your information. I'll followup to test on more Windows versions to figure out the solution for this bug.

Comment 11

[Wesly Huang (EPM)]

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!

Comment 12

[Ming-Chou Shih [:stone]]

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.

Comment 13

[Wesly Huang (EPM)]

Thanks for the prompt update, Stone.

Comment 14

[Ming-Chou Shih [: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.

Comment 15

[Wesly Huang (EPM)]

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.

Comment 16

[Ming-Chou Shih [:stone]]

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.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Unfortunately, I don't have much time to work on this bug for now...

Comment 18

[Wesly Huang (EPM)]

(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.

Comment 19

[Wesly Huang (EPM)]

Video link for comment#18.

Comment 20

[Wesly Huang (EPM)]

Video link for comment#18.

https://drive.google.com/a/mozilla.com/file/d/0Bz6aW3cbHgB8Y1RURlRDcUpGb1k/view?usp=sharing

Comment 21

[Morpheus Chen [:morpheus] UX]

Attachment: 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.

Comment 22

[Wesly Huang (EPM)]

(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.

Comment 23

[Ben Tian (inactive)]

Stone, any update on this bug?

Comment 24

[Ming-Chou Shih [:stone]]

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

Comment 25

[Ming-Chou Shih [:stone]]

Attachment: Bug 1301708 - nsWindow::DealWithPopup() should do nothing at receiving WM_ACTIVATE for a popup window and its wParam includes WA_CLICKACTIVATE.

Review commit: https://reviewboard.mozilla.org/r/93100/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/93100/

Comment 26

[Wesly Huang (EPM)]

(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.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 29

[Ben Tian (inactive)]

Assign to Stone since he's already working on this bug.

Comment 30

[Ming-Chou Shih [:stone]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=23a6503c702b890c2b3dcd11f6f12b2d17583baa

Comment 31

[Ming-Chou Shih [:stone]]

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.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/93100/diff/1-2/

Comment 32

[Ming-Chou Shih [:stone]]

(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

[Pulsebot]

Pushed by [e-mail]:
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

Comment 34

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/36a118cbe815

Comment 35

[Mohammad Maruf Rahman]

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]

Comment 36

[Wesly Huang (EPM)]

Hi Simona, should we set this issue to VERIFIED FIXED per Maruf's help on Comment#35? Thanks!

Comment 37

[Simona Badau, Desktop QA]

Attachment: 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.

Comment 38

[Simona Badau, Desktop QA]

Attachment: issueStep7.mp4

Screen cast with the issue from step 7.

Comment 39

[Ming-Chou Shih [:stone]]

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.

Comment 40

[Ming-Chou Shih [:stone]]

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.

Comment 41

[Ben Tian (inactive)]

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?

Comment 42

[Simona Badau, Desktop QA]

Attachment: 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?

Comment 43

[Ben Tian (inactive)]

ni? Stone to help clarify comment 42.

Comment 44

[Ming-Chou Shih [:stone]]

(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.

Comment 45

[Ben Tian (inactive)]

Simona, please refer to comment 44 and let us know if you are fine to verify original problem only or have further question. Thanks!

Comment 46

[Simona Badau, Desktop QA]

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?

Comment 47

[Ming-Chou Shih [:stone]]

(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.

Comment 48

[Ben Tian (inactive)]

Clear my ni? as Stone replied in comment 47.

Comment 49

[Ben Tian (inactive)]

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

Comment 50

[Simona Badau, Desktop QA]

(In reply to Ming-Chou Shih [:stone] from comment #47)

> Please use dblclick.

Could you please be more specific?

Comment 51

[Ming-Chou Shih [:stone]]

(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.

Comment 52

[Simona Badau, Desktop QA]

(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.

Comment 53

[Gerry Chang [:gchang]]

We've built 51 RC. Mark 51 won't fix.

Comment 54

[Sean Lee [:seanlee][:weilonge]]

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.

Comment 55

[Bryant Mao [:bryantmao]]

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

[Ben Tian (inactive)]

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)

Comment 57

[Wesly Huang (EPM)]

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.