1811031 - Broken functionality when holding mouse click down on a menu UI element, and then releasing over a menu option to trigger it

Status: NEW

(Core :: XUL, defect)

Description

[Re Qu]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

1. Hold down left mouse button on an UI element with a menu (e.g. titlebar menu, new tab button with containers, back/forward buttons, bookmarks menu button, bookmark folder)
2. Move cursor so that it hovers over one of the options within the menu
3. Release left mouse button

Actual results:

The menu option triggers inconsistently, possibly depending on how fast the actions are done. (Seems to work less when trying to do it quickly.)

Happens on Widows 10 in both 110 Beta and 111 Nightly, but not in 109 Release.

Expected results:

The menu option should consistently trigger every time.

Comment 1

[Ina Popescu, Desktop QA]

Hello Re Qu,
Would it be possible to make a screen recording of this issue and attach it to this bug?
That would be really helpful in order to reproduce your issue.

Comment 2

[Re Qu]

Attachment: Video of problem occurring in v111 (Nightly)

Added a video of the problem as an attachment. It's pretty difficult to see because it doesn't show when I'm holding down left mouse button, but each time I start holding it above the new tab button, then move the cursor to be above the "No Container" option, and only then release left mouse button.

Comment 3

[Re Qu]

Attachment: Video of problem NOT occurring in v109 (Release)

Another video of the functionality working consistently on release version 109 for comparison.

Comment 4

[Ina Popescu, Desktop QA]

I've managed to reproduce this issue on the latest version Nightly 111.0a1 on Windows 10 x64.
Moving to Core - Widget: Gtk . If this is not the correct component, please feel free to change it to a more appropriate one.

Last good revision:9d96d2c96d8fe1d9365fdaee30d8fda048c48aa1
First bad revision:13af43e59e415ec120b5116c4ce2d8e77f6bb825
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d96d2c96d8fe1d9365fdaee30d8fda048c48aa1&tochange=13af43e59e415ec120b5116c4ce2d8e77f6bb825

Comment 5

[BugBot [:suhaib / :marco]]

:emilio, since you are the author of the regressor, bug 1807482, could you take a look?

For more information, please visit auto_nag documentation.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

The real regressor is bug 1805414. I'll take a look anyways of course.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Hmm, so I was sure this was a regression from bug 1805414, but I can't reproduce this on Linux, at least... Ina, would it be possible to get a narrower regression range?

Comment 8

[Ina Popescu, Desktop QA]

I've managed to narrow down the regression range to the following, but the same regressor Bug 1805414 is indicated there:

Last good revision: 0c989b2bcd7882a9e7106e7879ab8933c2e09071
First bad revision: 47c002d3637247e71ee901f32421deaecc9d8ea3
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0c989b2bcd7882a9e7106e7879ab8933c2e09071&tochange=47c002d3637247e71ee901f32421deaecc9d8ea3

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Alright, let me try to investigate more on Windows.

Comment 10

[lilydjwg]

I can reproduce this on Linux. It needs to be fast focusing one menu entry and stop there to trigger.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

So I'm confused. I can repro that, but it's expected and I can repro that in release, and it's this code, but my patch just moved it around.

Comment 12

[Re Qu]

Attachment: Video of additional problem (extra tab opening) occurring in v117 (Beta)

Version 117 seems to have broken this further, as releasing the left mouse button now opens an additional containerless tab. The original problem also still persists.