in website history, either nothing happens on middle mouse button release, or something like "place:sort=4&maxResults=15" appears
Categories
(Firefox :: Bookmarks & History, defect, P5)
Tracking
()
People
(Reporter: a47zes0ir, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
- Create new profile
- enable "display menu bar"
- open a few pages like youtube, google, bugzilla, and an empty tab.
close all pages - click on "History" in menu bar
- hover mouse over "recently closed tabs"
- now either:
A. hold mouse-wheel-button on an entry, then move up or down to another entry and release mousebutton.
or
B. hold mouse-wheel-button on "recently closed tabs", and while holding, move mouse cursor onto an entry in the list and release.
Actual results:
A. nothing.
B. a new tab opens with something like "place:sort=4&maxResults=15" in the URL-bar.
Expected results:
A. should open the website (that the user releases the mouse-wheel on) in a new browser-tab.
B. same as above, as A.
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
Thanks for submitting this issue! Reproduced on all latest Firefox versions and back to Firefox 69 as well on Windows 10 x64. Earlier builds would not even close the submenu on mouse-wheel-button release.
Mouse-wheel-button works on each entry from Recently Closed Tabs tho, suggesting S4 severity since this is more of an edge case as per the scenario the reporter described.
Would suggest S3, as especially variation A. tends to accidentally happen on high-res displays where the menus don't have a big height. Only needs tiny hand-twitching move and nothing happens. (expected is "should open the website (that the user releases the mouse-wheel on) in a new browser-tab.")
|
|
||
Comment 3•4 years ago
|
||
Fair enough, it is indeed more reachable on high-res displays for A variation.
Result A. is still happening (at step 6 A.), very very frustrating, please increase priority for this bug.
|
|
||
Comment 5•4 years ago
|
||
Hey Dan,
Priority will be set up by developers once they will review this issue so I can't help you with that one. As for the severity, the following guideline is followed: https://firefox-source-docs.mozilla.org/bug-mgmt/guides/severity.html.
when will they finally review this issue?
When will developers finally review this issue? It's so frustrating :/
|
||
Comment 8•4 years ago
|
||
I'm not sure why I was needinfo'd on this bug, this isn't a region I'm that familiar with. At any rate, I think Firefox :: Bookmarks & History is probably the more appropriate place for this bug.
Sorry, I assumed it was a region you're familiar with, my apologies. Thanks for the component change.
|
||
Comment 10•4 years ago
|
||
This sounds like a selection problem, it should never be possible to "open" the root node of the view, but somehow these steps workaround that.
I don't think this an high priority to fix, and it can be easily workarounded reopening the right page. Mostly an annoyance.
|
Reporter | |
Comment 11•4 years ago
|
||
Mostly an annoyance.
exactly. And I was hoping that it's easy to fix. Because I (and possibly many others too) would probably solely use that MBB-feature if it'd work flawless. :)
|
|
Reporter | |
Comment 12•4 years ago
|
||
Nice, someone fixed it in FF 90, I still hope we can get it fixed for FF 89 aswell though, before 89 releases in 4 weeks.
|
|
||
Comment 13•4 years ago
|
||
The only way to tell is to actually look for an inverse mozregression range to figure out which fix addressed the problem, and unfortunately atm I don't have the time for that.
If you wish to try you can use this util for that https://mozilla.github.io/mozregression/, but you should mark "good" builds with the bug and "bad" builds with the fix to find an appropriate range.
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 14•4 years ago
|
||
FF 90 isn't available in mozregression o_O Any idea how I can add it there?
|
|
||
Comment 15•4 years ago
|
||
(In reply to Dan from comment #14)
FF 90 isn't available in mozregression o_O Any idea how I can add it there?
that's strange, anyway if you only specify --bad VV, then as good version it should use the most recent build. Or you can use --good 2021-05-06 (today) I think.
|
||
Comment 18•4 years ago
|
||
Done. 81767b81 was the last bad one, it was fixed in fd72fcc0.
Bug 1704948
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0c0c1834fbd1df9f0494306951626ace6b52e15b&tochange=fd72fcc0fa52d52635fa4a5690b2c416cdd43d3f
Who can access the uplift request that is pictured in the lower image here? https://release.mozilla.org/tooling/bugzilla/2018/10/03/uplift-form
|
|
||
Comment 19•4 years ago
|
||
Usually Mozilla engineers use that uplift form.
In this case we cannot uplift that bug further, it's in 89 Beta, it cannot go to 88 because only critical security fixes can. Thus it will be relased once 89 is released. It has been uplifted to 89 4 days ago, so it should be in the next beta if it's not there yet.
Thank you very much for your help and time finding that fix, hopefully this experience may also be useful in the future to help tracking other bugs you may hit.
I'm marking as fixed based on your verification and findings.
|
|
||
Comment 20•4 years ago
|
||
Thanks for your assistance! :)
Description
•