Closed Bug 639202 Opened 13 years ago Closed 12 years ago

Doorhanger breaks F6 navigation to the Location Bar

Categories

(SeaMonkey :: General, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: therubex, Assigned: philip.chee)

References

()

Details

(Whiteboard: [Halloween2011Bug])

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110305 Firefox/4.0b13pre SeaMonkey/2.1b3pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110305 Firefox/4.0b13pre SeaMonkey/2.1b3pre

 
If you do not reply authoritatively (i.e. say Yes) to a doorhanger prompt, an icon is added to the Location (URL) Bar.  An F6 keyboard navigation, which should cycle through various frames, including the Location Bar, never moves to the URL itself, instead jumping back to the browser window.
 

Reproducible: Always

Steps to Reproduce:
 
1. log into http://mail.yahoo.com/
(valid login credentials, or actual log in are immaterial, just enter bogus data)
2. doorhanger displays request to remember password
3. dismiss the doorhanger
4. press F6 key, repeatedly
 
Actual Results:  
 
F6 will traverse frames until it gets to the doorhanger icon on the Location Bar.
At that point, it skips the URL itself, & traverses back to the browser window.
 

Expected Results:  
 
F6 should either ignore the doorhanger icon & proceed directly to the URL, or proceed from the doorhanger to the URL, then back to the browser window (or whatever frame follows next).
 

 
Doorhangers can be disabled with the Preference, browser.doorhanger.enabled.
 
 
> Neil: mentions Ctrl+L & Ctrl+D

But neither of those cycle through frames as F6 does.

> Neil:  it just cycles between frames. xul windows happen to be unfocusable, so instead
> the first focusable object gets focus instead. historically this has been the urlbar,
> since there hasn't been much of a choice

Regardless, functionality now seems broken to me in this scenario.

> Neil: it's needed for accessibility of doorhangers
 
Compromise at the top of this section ? ;-)
(Doorhangers.  What a hideous beast.  I've kept them enabled just so I don't forget how much I dislike them!)

Still an issue, IMHO, though I'm fine with simply having this bug sit & stew.

Work-around by setting:  browser.doorhanger.enabled;true


Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20110511 Firefox/4.0.1 SeaMonkey/2.1
Oops .... s/true/false/ !!
Confirming issue still here
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [Halloween2011Bug]
Version: unspecified → Trunk
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Wrong Product Dão.
Status: RESOLVED → REOPENED
Depends on: 249735
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
Depends on: 735233
Attached patch Patch v0.1 WIP. (obsolete) — Splinter Review
> SM: [Bug 639202] Doorhanger breaks F6 navigation to the Location Bar.
>   FX: [Bug 249735] F6 goes to the first focusable element instead of the address bar (does not focus on location bar).
>   FX: [Bug 735233] Shift-F6 should focus the location bar rather than the first focusable chrome element.
Port Firefox fix. Works.

> SM: [Bug 641064] Pressing Alt+D on Location Bar doesn't select entire address.
Port Firefox fix. Not working!?!

> +++ b/suite/browser/win/platformNavigationBindings.xul
> +    <key id="focusURLBar2" key="&urlbar.accesskey;" modifiers="alt"
> +         oncommand="ShowAndSelectContentsOfURLBar()"/>
This doesn't work. Putting a keyhandler in urlbarBindings works but then it can't be localised.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
>> SM: [Bug 641064] Pressing Alt+D on Location Bar doesn't select entire address.
>>
 Port Firefox fix. Not working!?! 

Ah I missed removing the access key on the urlbar. See:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-01-18+22%3A46&maxdate=2004-01-18+22%3A46&cvsroot=%2Fcvsroot

So this patch ports the following Firefox patches to fix the F6 key:
> FX: [Bug 249735] F6 goes to the first focusable element instead of the address bar (does not focus on location bar).
> FX: [Bug 735233] Shift-F6 should focus the location bar rather than the first focusable chrome element.

This patch also includes a fix for:
> SM: [Bug 641064] Pressing Alt+D on Location Bar doesn't select entire address.
By porting from Firefox:
> [Bug 231381] Alt+D no longer selects all text in Location Bar -- it moves cursor to the end of the text there.
> [Bug 263755] #ifndef XP_MACOSX the Alt+D shortcut, because it doesn't work on Mac

Note: https://bugzilla.mozilla.org/show_bug.cgi?id=263755#c13
> On Mac option+letter is used to enter extended chars.
>> SM: [Bug 641064] Pressing Alt+D on Location Bar doesn't select entire address.
>>
 Port Firefox fix. Not working!?! 

Ah I missed removing the access key on the urlbar. See:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-01-18+22%3A46&maxdate=2004-01-18+22%3A46&cvsroot=%2Fcvsroot

So this patch ports the following Firefox patches to fix the F6 key:
> FX: [Bug 249735] F6 goes to the first focusable element instead of the address bar (does not focus on location bar).
> FX: [Bug 735233] Shift-F6 should focus the location bar rather than the first focusable chrome element.

This patch also includes a fix for:
> SM: [Bug 641064] Pressing Alt+D on Location Bar doesn't select entire address.
By porting from Firefox:
> [Bug 231381] Alt+D no longer selects all text in Location Bar -- it moves cursor to the end of the text there.
> [Bug 263755] #ifndef XP_MACOSX the Alt+D shortcut, because it doesn't work on Mac

Note: https://bugzilla.mozilla.org/show_bug.cgi?id=263755#c13
> On Mac option+letter is used to enter extended chars.
Attachment #610876 - Attachment is obsolete: true
Attachment #610892 - Flags: review?(neil)
Blocks: 641064
qrefresh needed for access key removal
Attachment #610892 - Attachment is obsolete: true
Attachment #610892 - Flags: review?(neil)
Attachment #610903 - Flags: review?(neil)
Comment on attachment 610903 [details] [diff] [review]
Patch v1.0a Really remove access key this time

>+  var fm = Components.classes["@mozilla.org/focus-manager;1"]
>+                     .getService(Components.interfaces.nsIFocusManager);
[Surprised this isn't in Services yet ;-) ]

>+  var element = fm.moveFocus(window, null, dir, fm.FLAG_BYKEY);
Hmm, what element do you get when you move focus to a window?

>+    <key keycode="VK_F6" oncommand="focusNextFrame(event);" modifiers="shift,any"/>
Nit: prefer "shift any" to show that any state of the shift key is acceptable, and use (e.g.) "shift,alt" to show that both shift and alt are required.
Comment on attachment 610903 [details] [diff] [review]
Patch v1.0a Really remove access key this time

>+  var element = fm.moveFocus(window, null, dir, fm.FLAG_BYKEY);
>+  if (element.ownerDocument == document)
I'm surprised that moveFocus always returns an element, in particular when moving to a blank document (it returns its <HTML> element, which seems wrong). Would you mind adding an element && null-check here? r=me with that fixed.

>+    <key id="focusURLBar2" key="&urlbar.accesskey;" modifiers="alt"
>+         oncommand="ShowAndSelectContentsOfURLBar()"/>
[I guess we don't need these changes now!]

>+    <key keycode="VK_F6" oncommand="focusNextFrame(event);" modifiers="shift,any"/>
F6 does something else on the Mac, I take it?
Attachment #610903 - Flags: review?(neil) → review+
Pushed to comm-central.
http://hg.mozilla.org/comm-central/rev/f24bab2b4cd8

>>+  var element = fm.moveFocus(window, null, dir, fm.FLAG_BYKEY);
> Hmm, what element do you get when you move focus to a window?
> 
>>+    <key keycode="VK_F6" oncommand="focusNextFrame(event);" modifiers="shift,any"/>
> Nit: prefer "shift any" to show that any state of the shift key is
> acceptable, and use (e.g.) "shift,alt" to show that both shift and alt are
> required.
Fixed.

>>+  var element = fm.moveFocus(window, null, dir, fm.FLAG_BYKEY);
>>+  if (element.ownerDocument == document)
> I'm surprised that moveFocus always returns an element, in particular when
> moving to a blank document (it returns its <HTML> element, which seems
> wrong). Would you mind adding an element && null-check here? r=me with
> that fixed.
Done.

>>+    <key id="focusURLBar2" key="&urlbar.accesskey;" modifiers="alt"
>>+         oncommand="ShowAndSelectContentsOfURLBar()"/>
> [I guess we don't need these changes now!]
Removed.

>>+    <key keycode="VK_F6" oncommand="focusNextFrame(event);" modifiers="shift,any"/>
> F6 does something else on the Mac, I take it?

On the Mac the function keys are reserved for hardware controls or operating system wide functions. On older Macs F6 toggles Num lock on G4s, mute on G3s. On newer Macs F6 increases keyboard brightness for backlit keyboards.

To access the function keys as normal application short cuts you need to press and hold down the Blue "Fn" key then the function key. The OS X preference settings allow you to flip this behaviour.
Attachment #610903 - Attachment is obsolete: true
Attachment #611472 - Flags: review+
No longer blocks: 641064
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: