Closed Bug 249735 Opened 21 years ago Closed 13 years ago

F6 goes to the first focusable element instead of the address bar (does not focus on location bar)

Categories

(Firefox :: Keyboard Navigation, defect, P1)

Product:
Firefox
Component:
Keyboard Navigation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 12

People

(Reporter: nirvn.asia, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Keywords: access, user-doc-needed, Whiteboard: [workaround in comment 69][also ctrl/cmd+L])

Attachments

(1 file)

patch
3.27 KB, patch
enndeakin
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040627 Firefox/0.9.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040627 Firefox/0.9.0+ When you put the search bar object in the toolbar and press f6, the normal behaviour is broken and the focus will switch between the page and the search bar object Reproducible: Always Steps to Reproduce: 1.put the search bar in the toolbar 2.switch focus with f6 Actual Results: focus between page and search bar Expected Results: focus between page and location bar
Some odd things happen when the search bar is on the same row as the menus (File, Edit...). When the search bar is in that spot the text in the Address bar is not selected. I am not sure if this is the same problem that the reporter is getting. I don't have any problems when the search bar is placed on the bookmark toolbar or one of the personal toolbars.
Summary: f6 dont focus on location bar when you have the search bar on → f6 does not focus on location bar when you have the search bar on the menu bar
Forgot to mention my build id Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040703 Firefox/0.9.0+
right, its when the search bar is located in the same row as the system menu (file,edit,bla,bla,bla)
more on this: you will always get this problematic behaviour when you place the search bar _before_ the location bar (not only on the file,edit,view,etc. bar) in the array of objects placed in the bars e.g. of a scenario where it would happen and not placed in the first bar ---- File Edit View ... ---- rewind foward refresh stop !search bar! location bar ---- bookmark toolbar ---- (this scenario would lead to a bad behaviour) so this f6 thing is probably searching the first text box in the array of objects placed in the bars ... it should probably search instead for the location bar id or something
I did not find any dupes with a bugzilla search for Firefox, Status: all, and F6. Marking bug new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
any chance it will block the 1.0 final release? this breaks a shortcut (f6) that everybody is expecting from a web browser
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0?
-> bryner
Assignee: firefox → bryner
Component: General → Keyboard Navigation
QA Contact: firefox.general → bugzilla
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Whiteboard: no l10n impact
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040901 Firefox/1.0 PR (NOT FINAL) still doing it, breaking f6 in most customized scenarios (i.e. but the search next to the activity inticator, etc.)
after digging in the source code, I found out what was the cause of the problem... <taken from mozilla/ content/ events/ src/ nsEventStateManager.cpp> 5324 nsEventStateManager::ShiftFocusByDoc(PRBool aForward) [...] 5365 if (nextShell) { 5366 // NOTE: always tab forward into the document, this ensures that we 5367 // focus the document itself, not its last focusable content. 5368 // chrome documents will get their first focusable content focused. 5369 SetContentState(nsnull, NS_EVENT_STATE_FOCUS); 5370 TabIntoDocument(nextShell, PR_TRUE); 5371 } 5372 } so when you put the search text box before the location text box, it does what the code was made for "chrome documents will get their first focusable content focused." the work around would be to check if the chrome is the main toolbar, then it should focus on the location text box, not the first focusable content ...
please, assign this bug to someone and make it block 1.0 final, it's very irritating as it breaks a basic function (and it's easy to fix, I pointed out the problem) just change the f6 behaviour to be like the web search, when you do the keyboard shortcut for web search, it goes to the web search text box by its id, not go to the first focusable item in the main window chrome ... it's an easy shot, please dont miss it
nirvn.asia, can you come up with a patch that might work? that would help to increase the chances of this making 1.0.
if someone comes up with a patch we could consider it.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
I'll have a look at it ... I'm overtaken by real-life work though and never got very far into that section of the firefox code ...
It seems to me F6 gets stuck in the location bar, at least on the trunk version.
Blocks: firekey
Keywords: access
Resummarizing to reflect current behavior. Marking P1 because it's a flaw more people would see since it's on the main screen.
Flags: blocking-aviary1.1?
Keywords: helpwanted
Priority: -- → P1
Summary: f6 does not focus on location bar when you have the search bar on the menu bar → F6 gets stuck in the location bar
Also happening in Seamonkey.
This is WFM in nightly builds. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050318
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary1.1?
reopening this bug, it might be fixed in seamonkey but its still very present in firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050412 Firefox/1.0+
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This is still WFM. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050416
Hardware: PC → Macintosh
Keyboard shortcut Ctrl-L seems to be doing what F6 should - maybe you could mimick that behaviour?
My build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
This is still WFM
(In reply to comment #4) > more on this: you will always get this problematic behaviour when you place the > search bar _before_ the location bar (not only on the file,edit,view,etc. bar) > in the array of objects placed in the bars CONFIRMED on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060214 Firefox/1.6a1 Investigating...
(In reply to comment #20) > Keyboard shortcut Ctrl-L seems to be doing what F6 should - maybe you could > mimick that behaviour? The behavior is actually quite different. F6 cycles through location bar (allegedly) <--> web document. If the web content contains frames, F6 cycles through location bar --> frame 1 --> frame 2 --> frame 3 --> location bar. Ctrl-L always goes straight to the location bar. If focus is already on the location bar, Ctrl-L selects the existing URL in the location bar but does not change focus.
Assignee: bryner → mats.palmgren
Blocks: focusnav
Status: REOPENED → NEW
*** Bug 346034 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > (In reply to comment #20) > > Keyboard shortcut Ctrl-L seems to be doing what F6 should - maybe you could > > mimick that behaviour? > > The behavior is actually quite different. F6 cycles through location bar > (allegedly) <--> web document. If the web content contains frames, F6 cycles > through location bar --> frame 1 --> frame 2 --> frame 3 --> location bar. > > Ctrl-L always goes straight to the location bar. If focus is already on the > location bar, Ctrl-L selects the existing URL in the location bar but does not > change focus. > The above described functionality is almost what happens, however I do not get the scrolling through frames. Instead the F6 simply alternates between the location bar and the search field of the history of bookmark frame if open, or between the main display and the location bar if not. I understand that F6 can be used in the dsame way as ctrl+L or alt+D to select the location bar, maybe this is the issue and if the location bar is not selected, then this behaviour is overriding the scrolling between frames. Could assigning the scrolling between frames to another shortcut be an option, or removing the location bar from the F6 functionality?
QA Contact: bugzilla → keyboard.navigation
Blocks: fox3key
Flags: blocking-firefox3?
Toolbar customization isn't accessible, so this isn't an accessibility blocker IMO. We'd take a patch if it's timely and well tested, but this isn't a blocker.
Flags: blocking-firefox3? → blocking-firefox3-
With all the changes that have happened with the awesome bar and others, is this one still valid? Could someone sighted please test and close as WFM if it is no longer an issue? Thanks!
Bug still occurs in 3.0 RC2 on Linux (and it doesn't require toolbar customization either since the Search bar is always present nowadays).
(In reply to comment #29) > Bug still occurs in 3.0 RC2 on Linux That's probably rather bug 426850 (in case these aren't the same issue).
How is the "factory" layout of location-, search- and menu bar ? In the up-to-down direction I have first menu bar then, some tool buttons left with location bar in the middle and search bar right, then some tool buttons again. But I don't remember any more which part of this layout results from my personalization and what had its origin in the "factory" layout. It would be helpful information to know if I on myself have produced this problem by layout personalization. While having been used Fx 2.x I was able to alternate between location bar and document area. I don't remember also since when I have this personalization.
I see this bug with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12pre) Gecko/2009052004 GranParadiso/3.0.12pre Mozilla/5.0 (X11; U; Linux i686; eo; rv:1.9.1b5pre) Gecko/20090520 Shiretoko/3.5b5pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre
OS: Windows XP → All
Hardware: PowerPC → All
Version: unspecified → Trunk
(In reply to comment #32) > I see this bug That is, F6 goes to the search bar if it is on the menu panel, and either cycles between it and the content area, or is lost due to bug 426850. Not sure what the current summary is about.
Putting the proper summary based on the old one back.
Summary: F6 gets stuck in the location bar → F6 goes to the search bar instead of the address bar when the search bar is on the menu toolbar (does not focus on location bar)
I'm generalizing the summary from what Dão said in bug 558067: "F6 doesn't actually mean "focus the location bar" but something like "focus the first focusable element in the next frame". E.g. if you put the search bar before the location bar, it would have focused the search bar" Since now it also happens when the tabs are on top.
Summary: F6 goes to the search bar instead of the address bar when the search bar is on the menu toolbar (does not focus on location bar) → F6 goes to the first focusable element instead of the address bar (does not focus on location bar)
(In reply to comment #37) > I'm generalizing the summary from what Dão said in bug 558067: > "F6 doesn't actually mean "focus the location bar" but something like "focus > the > first focusable element in the next frame". E.g. if you put the search bar > before the location bar, it would have focused the search bar" For usability sake can something be hacked so the address bar is always "the first focusable element" on the top frame? Having to press <F6> and then <Tab> to get to the address bar is not optimal IMHO.
You can use the other keyboard shortcuts for the address bar: Alt+D Ctrl+L
(In reply to comment #40) > You can use the other keyboard shortcuts for the address bar: > Alt+D > Ctrl+L Then http://support.mozilla.com/en-US/kb/Keyboard+shortcuts needs an update. "Select Location Bar Alt+D F6 Ctrl+L"
(In reply to comment #42) I'd agree that that page should probably be updated. The other description of F6 on that page is AFAICT the correct description: "Move to Next Frame F6" If I have a sidebar open then F6 cycles the focus between the tabs (with tabs on top), the search field in the sidebar and the web page. FWIW in IE 7 F6 cycles between the web page, the location bar and the bookmarks toolbar (those two stars). And F6 is not listed in IE7's help file for keyboard shortcuts. It lists Alt-D to select the text in the address bar. Ctrl-L opens the open dialog. So people must be assuming that F6 focuses the address bar since the next frame after the web page is typically the location bar.
As a user, I'm really hoping this bug will get fixed instead of updating the manual. Firefox 4 changes the behavior compared to previous versions. I've been able to use F6 to focus the location bar pretty much as long as I can remember. So changing this behavior would in that sense be a serious usability regression (it's actually a reason I didn't like Opera every time I tried it). Why I really hope this will be fixed, is because it's: - been working for a very period (always?) - the only shortcut requiring only a single key (more important than it sounds) - actually one of the reasons for me to dislike Opera - a change/regression from a user perspective (even though it's not from a programming perspective, because the code hasn't changed, but for users the actual effect has significantly changed) - actually currently my major complaint about Fx4 (that's how much I like it otherwise)
(In reply to comment #42) > (In reply to comment #40) > > You can use the other keyboard shortcuts for the address bar: > > Alt+D > > Ctrl+L > Then http://support.mozilla.com/en-US/kb/Keyboard+shortcuts needs an update. > "Select Location Bar Alt+D F6 Ctrl+L" The 2nd and 3rd instance of "F6" in that document also need to be edited. | Move to Next Frame | F6 | | Move to Previous Frame | Shift+F6 | That bit of jargon ("Frame") is not defined anywhere in that document, and does not match the user's expectations. How to reproduce user confusion: 1) Go to http://images.google.com/ using 4.0b4pre (since Google Images uses a Lightbox for FF 3.6.8 but not for FF 4.0). 2) Search for "site:amazon.com" (or any image on a page with a search bar). 3) Click on any image. 4) There will now be two frames visible. 4a) The upper frame has "Google [site:amazon.com___] [Search images]" and "Remove frame [X]" in the lower right. 4b) The lower frame has "amazon.com" and "Search [Music ] [_____] (GO)". 5) Put cursor in lower frame's search box, then press F6 a few times. 5a) This does _not_ toggle from the upper frame to the lower. Instead, focus bounces between the first tab in the tab bar and the document as a whole (which includes both the upper and lower HTML frames). The documentation needs to be clear on what a "Frame" is. The tab bar, location bar plus search bar are one "Frame". The main document is the second "Frame". If a sidebar is active (Ctrl-B = Bookmarks or Ctrl-H = History), then it is a third "Frame". Is this behavior part of any published design specification? Is there a config setting to make F6 be synonymous with Ctrl-L/Alt-D again?
1. Put the tabs on top (default). Focus on the current page. Press F6 and the focus is shifted to Tabs instead of location bar. 2. Change the tabs to be at bottom. Focus on current page. Press F6 and the focus is shifted correctly to the location bar. I guess the correct behavior of F6 must be to go to location bar first irrespective of its frame number.
I think the problem here is that people are used to having a 1 key (not key-combo) shortcut to accessing the location bar. It's fast and easy, and I find that both Alt+D and Ctrl+L are awkward to type. To that end, I have a few suggestions 1) Keep F6 as a way to cycle through the frames, but instead of focusing the first available item, focus the primary item (i.e. content, location bar, history search bar). 2) Change F6 to cycle through the main window controls (content, location bar, tab bar, and possibly the search bar and page/bookmarks menu). Then have another key, say F8, cycle focus through the frames (possibly omitting the main window controls) 3) Leave F6 alone, but add another key, say F8, to cycle between the location bar and content. In a similar vein, it's be nice to have a key, maybe F9, that would cycle between the tab bar and content. Or possibly just have 1 key that cycles through all 3. Basically, my thought is that the location bar and tab bar are such important UI elements that they should be reachable by a 1 key shortcut. So perhaps #3 is the best solution.
Please note that F6 is a Windows standard key for address bar focusing. The OS itself and plenty of apps do conform to this standard. Why shouldn't the Firefox do this? Let's Firefox be user-friendly as it has to be.
Explorer.exe for Windows 7 uses F6 to cycle through the frames; it does not always go straight to the address bar. 1. Open Windows Explorer (Windows-Key + E). 2. Single-click on the C: drive. 3. Press F6 repeatedly. It will cycle through: a) Left-hand panel (with Favorites, Libraries, Computer, Network). b) Right-hand panel (with names of folders and files in C:\). c) Right-hand headers (with Name, Date modified, Type, Size). d) Address/Location bar (with Desktop, Computer, C_drive). e) Menu bar (with Organize, Share with, Burn, Compatibility files, New folder). f) Back to left-hand panel. To be compatible with this Windows behavior, F6 in Firefox must eventually bring focus to the Address bar, not necessarily after a single keypress. Fix: The Address bar needs to be in a frame of its own, separate from the frame that holds the tabs, so that repeated pressings of the F6 key will be able to select the Address bar (regardless of tabs-on-top or not).
@ Joe Smith, When pressing F6 on both explorer.exe and IE in Win7, the location bar is highlighted first, which should always occur in any application with a location (address) bar.
IE: Yes. Explorer: No. When focus is in the left side panel on Explorer, it takes 3 presses of F6 to ge to the address bar.
@ Joe Smith, Interesting, but on Firefox nightlies, it will never highlight the location bar with F6 for me.
(In reply to comment #48) > I think the problem here is that people are used to having a 1 key (not > key-combo) shortcut to accessing the location bar. Big +1 =) (In reply to comment #55) > on Firefox nightlies, it will never highlight the location bar > with F6 for me. As I said on comment #39 > For usability sake can something be hacked so the address bar is always "the > first focusable element" on the top frame? > Having to press <F6> and then <Tab> to get to the address bar is not optimal > IMHO.
(In reply to comment #39) > For usability sake can something be hacked so the address bar is always "the > first focusable element" on the top frame? > Having to press <F6> and then <Tab> to get to the address bar is not optimal > IMHO. Best solution. +10
(In reply to comment #39) > For usability sake can something be hacked so the address bar is always "the > first focusable element" on the top frame? > Having to press <F6> and then <Tab> to get to the address bar is not optimal > IMHO. Yes. This is the best solution. F6 must go to address bar first, regardless of the frame number etc. +100 Regards, Satish.
(In reply to comment #58) > (In reply to comment #39) > > For usability sake can something be hacked so the address bar is always "the > > first focusable element" on the top frame? > > Having to press <F6> and then <Tab> to get to the address bar is not optimal > > IMHO. > > Yes. This is the best solution. F6 must go to address bar first, regardless of > the frame number etc. +100 > > Regards, > Satish. I totally agree.
I wish we could edit the hot keys as we like, ie just like the menu/keybord editor in MS-Office. (In reply to comment #48) > 3) Leave F6 alone, but add another key, say F8, to cycle between the location > bar and content. In a similar vein, it's be nice to have a key, maybe F9, that That means you are steeling 2 more keys a web developer can you some thing else. And can accidentally trigger some action what we dont want. Eg:- Ctrl+D for bookmark and Ctrl+Shift+Del clear recent history are troubling a lot I always accidentally trigger Ctrl+Shift+Del as I am used to Ctrl+Ins for copy, Shift+Ins for paste and Shift+Del for cut from the time of Borland Turbo C and MS-QuickBasic editor. And I am used to F6 always switching next frame right/below. That is the common behavior since the time of DOS. Even though Ctrl+L is two keys, they are not far apart so even kids could activate them with single hand
(In reply to comment #48) > possibly just have 1 key that cycles through all 3. Bingo. And its name shall be "F6". It should also focus the location bar first, no matter what (, and then cycles through the tabs, content, etc.). Problem solved.
(In reply to comment #55) > @ Joe Smith, > > Interesting, but on Firefox nightlies, it will never highlight the location bar > with F6 for me. It does if you dissable "Tabs on Top"; the very reason why it's dissabled on my Minefield.
(In reply to comment #62) > (In reply to comment #55) > > @ Joe Smith, > > > > Interesting, but on Firefox nightlies, it will never highlight the location bar > > with F6 for me. > > It does if you [disable] "Tabs on Top"; the very reason why it's dissabled on my > Minefield. Yeah, I hope to get the best of both worlds though :p
https://addons.mozilla.org/en-US/firefox/addon/f6/ This extension selects location bar when tabs are on top and F6 is pressed.
nice! but can we use this same bug to ask for having F6 behave by default as it used to, so focusing the location bar?
Whiteboard: no l10n impact → no l10n impact [workaround in comment 69]
This should be fixed ASAP
This is affecting me too on both Ubuntu 10.04 and Windows XP. I'm using Firefox 5. Is there anything I should submit about my system to help fix this bug?
Whiteboard: no l10n impact [workaround in comment 69] → no l10n impact [workaround in comment 69][also ctrl/cmd+L]
It's not fixed yet...why mozilla thought F6 to focus on Tab (usually the first element) is a better choice?
(In reply to byzod from comment #75) > It's not fixed yet...why mozilla thought F6 to focus on Tab (usually the > first element) is a better choice? Because ctrl-l or alt-d is the one for the addressbar. F6 just used to work too in the past, since it went to the first focusable element, which used to be the location bar. But it isn't anymore if the tabs are on top.
(In reply to Jo Hermans from comment #77) > Because ctrl-l or alt-d is the one for the addressbar. F6 just used to work > too in the past, since it went to the first focusable element, which used to > be the location bar. But it isn't anymore if the tabs are on top. Well the question was "why is the new behavior a better choice?" and that doesn't really answer it. The fact that it uses logic "first focusable element" instead of "the address bar" is an unfortunate implementation detail. While changing the default browser layout, Mozilla developers inadvertently broke the old function of the F6 key. To sum it up: 1. It wasn't a deliberate change 2. It diverges from the behavior of other browsers 3. Nobody finds the new behavior useful (users complained about this even *before* tabs-on-top became the default) These points make it a "regression" in my mind and it should be fixed. It's clear from the number of comments, subscribers and votes on this bug that users want the old behavior back. They don't care about how it was implemented.
The only thing usable and useless at the same time F6 doing right now is swithcing between frames. Since frames are obsolete and useless by themselves functionality becomes double useless. Mass user - those of them who knows about F6 - might just switch over to another browser not finding expected behavior. This should be considered a regression.
Attached patch patch — — Splinter Review
Assignee: matspal → dao
Status: NEW → ASSIGNED
Attachment #583798 - Flags: review?(enndeakin)
Keywords: helpwanted
Blocks: 639202
Attachment #583798 - Flags: review?(enndeakin) → review+
Keywords: checkin-needed
http://hg.mozilla.org/integration/mozilla-inbound/rev/41200991490f
Keywords: checkin-needed
Whiteboard: no l10n impact [workaround in comment 69][also ctrl/cmd+L] → [workaround in comment 69][also ctrl/cmd+L]
Target Milestone: --- → Firefox 12
When is this going to be fixed? I am so sick of not being able to tap F6 to highlight the address-bar. Mozilla, please hurry up and fix this. This bug has existed forever. Pressing "F6" should highlight the address-bar (i.e., do the same thing as CTRL+L except with just the press of one button).
https://hg.mozilla.org/mozilla-central/rev/41200991490f
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 13 years ago
Resolution: --- → FIXED
Will this be pushed to Firefox 10/11 as well ?
Keywords: user-doc-needed
(In reply to Jason from comment #86) > When is this going to be fixed? I am so sick of not being able to tap F6 to > highlight the address-bar. This is going to be fixed in Firefox 12, which is scheduled to be released on April 24, 2012. If you can't wait, you can use nightly builds (http://nightly.mozilla.org/) or the F6 add-on (https://addons.mozilla.org/en-US/firefox/addon/f6/).
(In reply to sdrocking from comment #88) > Will this be pushed to Firefox 10/11 as well ? No, the patch most likely wouldn't be approved to land on the beta or aurora branches.
Thanks on the patch Dão. F6 now cycles through URL bar and content but no longer stops at the current tab on the tab bar. Holding Ctrl or Shift and pressing F6 cycles through content and the current tab on the tab bar but never stops at the URL bar. Is that by design or a bug? IMHO this is a small regression on keyboard navigation.
Resolution: FIXED → INCOMPLETE
F6 cycles between documents, and not on tab elements.
Resolution: INCOMPLETE → FIXED
(In reply to alex_mayorga from comment #91) > Holding Ctrl or Shift and pressing F6 cycles through content and the current > tab on the tab bar but never stops at the URL bar. I don't know what Ctrl is supposed to do here. Doesn't seem like a valid modifier key. For Shift, please file a new bug.
Depends on: 735233
(In reply to Dão Gottwald [:dao] from comment #93) > (In reply to alex_mayorga from comment #91) > > Holding Ctrl or Shift and pressing F6 cycles through content and the current > > tab on the tab bar but never stops at the URL bar. > > I don't know what Ctrl is supposed to do here. Doesn't seem like a valid > modifier key. For Shift, please file a new bug. Filed bug 735233 as requested.
I've always used F6 to move the focus onto open Tabs--then I can use Home, End, Arrow-keys to move among the tabs. Since F6 will move focus to the Address-Bar with Fx12, is there another way I can still quickly move focus to the Tabs for keyboard-control of them? Is there a new shortcut (like maybe F8 or something) to replace what F6 used to do?
Hi, Lindsey. To put the focus onto the Tab-bar in Firefox12+, use Ctrl+F6.
Ctrl+F6 should be the same as F6. There isn't a shortcut to focus the tabbar that I know of, nor was there intentionally one before. It only accidentally became possible to focus the tabbar with F6 when tabs moved to the top of the window, and thus because the first focusable content in the window. Recent versions of Firefox have changed this such that there is a special behaviour for the browser window to always focus the location bar first. Note that the F6 shortcut means focus the next document.
Why was F6 changed? Two shortcuts (Ctrl+L and Alt+D) already exist for putting focus on the URL-bar. Why is F6 needed for this as well? F6 has become a fantastic shortcut that is very useful and not offered by other web-browsers. F6 allows me to do so much with the tabs using only the keyboard--it is fantastic and a great accessibility feature of Fx!
(In reply to Lindsey from comment #98) > Two shortcuts (Ctrl+L and Alt+D) already exist for putting focus on the > URL-bar. Why is F6 needed for this as well? It isn't. F6 is the shortcut to switch between frames and panels in a window, for example between the browser window, the bookmarks sidebar, the document loaded in the window and its child frames, if any. As I said, the 'focus the tabs' feature wasn't intentional behaviour, nor was focusing the urlbar. The actual implemented behaviour was to focus the first visible thing in the window that could be focused. Recent versions have changed this to be consistent in focusing the urlbar when the main window is reached in the F6 cycle.
Unintentional or not. Being able to focus the Tab-bar is an incredibly useful accessibility feature. Hopefully, Mozilla will recognize this fact and awareness of it will help guide future decisions that keep this functionality healthy.
You can use Shift+Tab to shift focus from the location bar to the tabs.
Mozilla, please change F6 back. What is gained from making it focus the URL-bar? Before, when F6 put focus onto the Tab-bar it properly shifted between page elements (like Tab-bar, Bookmarks-pane, and Page-content). This is a very useful (understandable) shortcut. Having it put focus onto the URL-bar does not keep with the intent of shifting between page elements--for example, if pressing F6 once moves focus to the URL-bar, why doesn't pressing F6 twice move the focus to the Search-bar? My point is that the URL-bar is being improperly focused. Both the URL-bar and the Search-bar are major points of interaction and shouldn't be focused by F6. Truthfully, why was this change done? What positive thing was gained from this change? I can find no good reason for this change when I think about it. Can someone please explain what is gained from having F6 focus the URL-bar? Not only does it break the logical/understandable action of shifting between page-elements but all it does is add an additional shortcut for a function that already has multiple shortcuts. It seems that this change unnecessarily complicates a very useful feature of Firefox but added nothing.
(In reply to Chad from comment #102) > Truthfully, why was this change done? Seems you didn't read previous comments
I was ranting above in a comment about wanting F6 to put focus onto the Address Bar. This rant was a result of coming to firefox from Google Chrome. I expected Firefox to do the same thing as Google Chrome and when it didn't I prematurely assumed it a bug. I didn't realize it had an even more useful feature in its place. After reading the above comments, I started playing around with being able to put focus onto the Tab Bar. It is a great ability. I get frustrated now when using Google Chrome because I CAN'T but focus onto the Tab Bar. So I just wanted to recant my rant and say that being able to put focus onto the Tab Bar is a great idea.
(In reply to Jason from comment #104) > So I just wanted to recant my rant and say that being able to put focus onto > the Tab Bar is a great idea. This just shows how important it is to fix "popular" behavior bugs in a timely manner. Otherwise some people start relying on the other behavior and suddenly you can't please either group anymore.
(In reply to Marti Raudsepp from comment #105) > (In reply to Jason from comment #104) > > So I just wanted to recant my rant and say that being able to put focus onto > > the Tab Bar is a great idea. > > This just shows how important it is to fix "popular" behavior bugs in a > timely manner. Otherwise some people start relying on the other behavior and > suddenly you can't please either group anymore. Well said. This has been sitting for so many years before getting resolved.
Presently, if I had to choose where focus should land when I push F6, I would choose the Tab Bar. this is because I can use the other shortcuts (namely Ctrl+L etc) to put focus on the Location Bar. But far as I know, there is no other shortcut for putting focus onto the Tab Bar.
I just want to say THANKS to Mozilla for not removing the ability to put focus onto the Tab-Bar when addressing this bug report. Keeping the Ctrl+F6 shortcut for putting focus onto the Tab-Bar is much appreciated!
I want to second that thanks, especially having a pleasing solution to both groups of people (those who liked a shortcut to the tab bar and those to the address bar). I'd also like to bring up that http://support.mozilla.org/en-US/kb/Keyboard%20shortcuts will need to be updated. Does something like that belong in another bug?
(In reply to Stanley Chan from comment #109) > I'd also like to bring up that > http://support.mozilla.org/en-US/kb/Keyboard%20shortcuts will need to be > updated. Does something like that belong in another bug? The keyboard shortcut hasn't been changed, so nothing needs to be done. The F6 shortcut was 'Move to Next Frame' and is still 'Move to Next Frame'.
Should there be any mention of the Ctrl-F6 shortcut? (In reply to Neil Deakin from comment #110) > (In reply to Stanley Chan from comment #109) > > I'd also like to bring up that > > http://support.mozilla.org/en-US/kb/Keyboard%20shortcuts will need to be > > updated. Does something like that belong in another bug? > > The keyboard shortcut hasn't been changed, so nothing needs to be done. The > F6 shortcut was 'Move to Next Frame' and is still 'Move to Next Frame'.
There isn't a Ctrl+F6 shortcut as far as I know. If it does something other than what F6 does, it isn't intentional and should not be documented as such.
Should we file a bug report to make Ctrl+F6 "Intentional"?
The Tab-Bar is a frame as much as the Location-Bar is.
You can file a bug on adding some shortcut to focus the tabbar if you like. I'm not sure it would be implemented as there are limited keys available. Does Ctrl+F6 do something different than F6 currently? If so, maybe we should fix that. Or not. Dão?
(In reply to Neil Deakin from comment #115) > Does Ctrl+F6 do something different than F6 currently? If so, maybe we > should fix that. Or not. Dão? It does, but since this combination isn't documented I don't really care either way.
How do we get Ctrl+F6 documented so that you care?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: