Clicking both mouse buttons, status "left click pressed" remains
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
People
(Reporter: fabio_milocco, Assigned: mstange)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
MacOS 11.4 - externale Logitech Mouse (no touchpad)
- clicking both right and left mouse buttons (not touchpad) in a free area of a web page: the contextual menu opens
- Left click outside the menu to close it
- Every time the status of "left button pressed" remains, try to hover the mouse over the page text and it will be selected, but I'm not pressing the button anymore!
It's a bug of version 89 only, never happened before.
Actual results:
Trying to hover the mouse over the page text it will be selected, but I'm not pressing the button anymore
Expected results:
Nothing!
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•4 years ago
|
||
Could you run mozregression to see when this started happening?
|
Reporter | |
Comment 3•4 years ago
|
||
I tried mozregression but after 11 downloads of Firefox 89a1 (different days and hours) stopped:
2021-06-08T20:39:06.204000: DEBUG : Found commit message:
Bug 1704838: Resolve mach_bootstrap compatibility with Python 2 r=sheehan
Python 2 isn't as happy with spread operators and doesn't
support "sys.base_prefix".
Differential Revision: https://phabricator.services.mozilla.com/D111898
2021-06-08T20:39:06.205000: DEBUG : Did not find a branch, checking all integration branches
2021-06-08T20:39:06.212000: INFO : The bisection is done.
2021-06-08T20:39:06.213000: INFO : Stopped
So i tried to download Firefox 90 beta and 91 alpha: there is the same bug. All versions with new profiles, even with version 89.
Is there any possibility of downloading Firefox 88 release version?
|
|
||
Comment 4•4 years ago
|
||
(In reply to The_Blinded from comment #3)
I tried mozregression but after 11 downloads of Firefox 89a1 (different days and hours) stopped:
Did it give you a URL with a range of changesets? Something like this:
|
Assignee | |
Comment 5•4 years ago
|
||
This sounds very much like a regression from native context menus. I would have expected bug 1700706 to fix it, but apparently that's not the case.
|
|
Reporter | |
Comment 6•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #5)
This sounds very much like a regression from native context menus. I would have expected bug 1700706 to fix it, but apparently that's not the case.
I think too, mozregression stopped to work on release 89a1 19 april 2021 which, however, does not support the native menu of the mac but still the "old" one. In fact, on this builds the problem there isn't.
(In reply to Stephen A Pohl [:spohl] from comment #4)
(In reply to The_Blinded from comment #3)
I tried mozregression but after 11 downloads of Firefox 89a1 (different days and hours) stopped:
Did it give you a URL with a range of changesets? Something like this:
No.... only the error message that i'd already copy.
|
|
Assignee | |
Comment 7•4 years ago
|
||
We need to call frameSelection->SetDragState(false) when opening the menu, but it needs to happen in the content process.
Not sure how to easily achieve that. If there was a mousedowncancel event, we could dispatch it at the mousedown position...
|
||
Comment 8•4 years ago
|
||
But how was this working before native context menu? The non-native popup was after all opened in the parent process even before the change.
|
|
Assignee | |
Comment 9•4 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #8)
But how was this working before native context menu? The non-native popup was after all opened in the parent process even before the change.
Yes, but the mouseup event was still received in the parent process and forwarded to the content process, where it stopped the frame selection. Or at least that's what I think happens, I haven't confirmed it.
(In reply to Markus Stange [:mstange] from comment #7)
We need to call
frameSelection->SetDragState(false)when opening the menu, but it needs to happen in the content process.
Not sure how to easily achieve that. If there was a mousedowncancel event, we could dispatch it at the mousedown position...
We can probably just do this from the contextmenu event. That one fires in content processes just fine.
|
|
Reporter | |
Comment 10•4 years ago
|
||
The same thing happens in Firefox 93.
|
||
Comment 11•3 years ago
|
||
I have reproduced this issue with Firefox 96.0 on macOS Monterey 12.1 (21C52).
On the same machine I don't have the problem with Safari 15.2 and SeaMonkey 2.53.10.2.
Tell me if you need more tests.
Description
•