Closed Bug 770773 Opened 12 years ago Closed 3 years ago

Don't show the menu bar when pressing Alt if the mouse has been clicked before Alt is released.

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: KWierso, Unassigned)

References

Details

(Keywords: regression)

I use the Alt button to select the displayed text in links without navigating to the link when I click in it. That all still works, but the Alt button also toggles the old menu bar's visibility when I release the Alt button, stealing focus away from the selected text, which makes it more difficult to then copy the text with Ctrl-C. It would be nice if clicking either mouse button while Alt is currently pressed would prevent the menu bar from being activated when you let go of Alt.
(In reply to Wes Kocher (:KWierso) from comment #0) > when I release the Alt button, stealing focus away from the selected > text, which makes it more difficult to then copy the text with Ctrl-C. I confirm this behavior. However, it doesn't always happen. I have found 2 scenarios that work for me on Win7. Please tell if they are working for you and if note in my "expectations" part is correct. STR: 1. Open page data:text/html,<a href="http://example.org">Long_test_link</a><br><input value = "input_string"><br><textarea>textarea_string</textarea><br><iframe src="data:text/html,asdf"> (A) 2.A) Alt-select word "test" within the link text. 3.A) Alt-select text in one of 4 areas: {input, textarea, iframe, location bar} (B) 2.B) Click into one of 4 areas: {input, textarea, iframe, location bar} 3.B) Alt-select word "test" within the link text. RESULT: Menu bar appeared EXPECTATIONS: Menu bar shouldn't appear. Current behavior is inconsistent: If in Step 3.A) I select another part of link text, then menu bar doesn't appear. NOTE: Alt+selecting text should work fine with selecting normal text too, not just <a> // Philipp, please tell if I shouldn't request so much info from you. I just very worried about UX issues in Fx (A LOT of them); don't they have higher priority? Also this issue is specific for Fx...
Flags: needinfo?(philipp)
It also happens with Alt+Click hotkey in Developer Tools - Inspector STR: (Win7, Nightly 42.0a1 (2015-08-10)) 1. Open page data:text/html,<body><div><span><br> 2. Open devtools -> Inspector, Focus "search with CSS selectors" field 3. Press Alt 4. Click dropmarker near <div> element to open all subtrees (this is what hotkey for) 5. Release Alt Result: Menu bar appeared Expectations: Menu bar shouldn't appear
Hm, I wasn't able to reproduce your issue on Windows 10, Nightly 43. When I press alt, click/select something and then release alt, the menu doesn't appear.
Flags: needinfo?(philipp)
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #3) > When I press alt, click/select something and then release alt, the menu doesn't appear. Maybe Win10 handles this differently, but my STR are NOT just "press alt, click/select and then release alt". Are you sure that none of two scenarios don't cause issue for you?
See Also: → 1203103
This was regressed between 2012-02-14 and 2012-02-15 by bug 625151: > pushlog_url: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=60edf587f4af&tochange=d45c7d7b0079 THIS WAS SO ANNOYING BUG ALL ALONG!!! So basically now I have proofs that (A) This bug does exist. (B) People are unreliable in following trivial steps-to-reproduce. I will ever show this bug to them.
Blocks: 625151
Severity: enhancement → major
Has STR: --- → yes
Keywords: regression
Flags: needinfo?(masayuki)
What are you asking me?
Flags: needinfo?(masayuki) → needinfo?(arni2033)
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #6) > What are you asking me? There are many obvious reasons to NI the assignee of a bug which regressed something. At the very least: 1) So that he/she confirmed that the described behavior wasn't planned (from what I saw on bugzilla, everybody just applies changes he/she likes, so it's better to ask the same person) At the most (not hoping for the actual fix currently v_v ): 2) So that he/she told what changes to the code must be applied to eliminate the issue Also, there're minor reasons like 3) I've seen hundreds of times how people NI an assignee of a bug that caused regression 4) If I don't NI anybody, this bug will never be fixed _for_sure_ (note that it was initially marked as "enhancement") 5) If I notify a person of his/her errors, he/she will most likely be more careful in applying questionable changes 6) I strongly believe that I have the right to ask a person who made me suffer for almost 4 years
Flags: needinfo?(arni2033)
At least for me, ccing me is enough. Looks like that auto repeat keydown events of Alt key re-enables nsMenuBarListener::mAccessKeyDown which was disabled by blur event handler. So, I think that we should ignore key events whose mIsRepeat is true in keydown event handler. Unfortunately, I need to rewrite all platforms' keyboard event handler for fixing long standing bug. If I'd have much time during it (e.g., waiting a lot of reviews), we could work on this. Otherwise, I cannot work on this at least for a couple of months. So, if you believe this should be fixed ASAP, I recommend you to find another person or write a patch by yourself (I'll review it).
Component: Menus → XP Toolkit/Widgets: Menus
Product: Firefox → Core
See Also: → 1231173
Component: XP Toolkit/Widgets: Menus → XUL

I couldn't manage to reproduce this issue. Since the bug was a long time ago, most likely isn't reproducible anymore for the reporter also.
Closing this bug as resolved: Worksforme.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.