Closed Bug 31809 Opened 25 years ago Closed 24 years ago

Can't hit tab to get focus into URL bar

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: sfraser_bugs, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: access, helpwanted)

Attachments

(3 files)

proposed fix
10.26 KB, patch
Details | Diff | Splinter Review
fix for tabbing into collapsed sidebar
2.05 KB, patch
Details | Diff | Splinter Review
wallpaper
573 bytes, patch
Details | Diff | Splinter Review
Hitting the tab key on a new browser window should take the focus to the URL bar (and select all the text in there). This is not currently possible.
Status: NEW → ASSIGNED
Target Milestone: M17
*** Bug 33069 has been marked as a duplicate of this bug. ***
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
*** Bug 36278 has been marked as a duplicate of this bug. ***
While 33069 is a duplicate bug, 31809 isn't actually a duplicate of the bug 36278 it's been linked to. THAT bug is that shifting focus to the address bar, by whatever means (apparently tabbing DOES work on Windows NT; it does not on Macs) doesn't cause the URL in the address bar to be select-all'd/highlighted for replacement. THIS bug is that you can't tab into the address bar at all. I would add that Reuben's comment, from the duplicate [of 31809, not THIS bug report, 36278] bug 33069 is somewhat wide of the mark: "I sugges having an Interface like IE 5, that lets you use ALT+D to move the focus to the Location Bar, and highlight all the contents as well. I use this very often, and find it a very useful feature." That's all well and good for Windows users, but "Alt-D" wouldn't make any sense at all to a Mac user. I think what's called for is *behavior as consistent as possible with other browsers*. On a Mac this means that hitting tab anywhere in a browser window moves from field to field, including form fields and the address bar. See al
Okay: bug #33069 is a dup of bug #31809 bug #36278 is a dup of bug #28583 However, I'm not going to make a change: they still resolve as duplicates. This bug remains "Can't hit tab to get focus in URL bar".
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
should get better at the beginning of nsbeta3 with joki's tabbing changes.
Keywords: nsbeta3
nsbeta3-, wouldn't hold the release for this.
Whiteboard: [nsbeta3-]
Target Milestone: M21 → Future
*** Bug 52027 has been marked as a duplicate of this bug. ***
Adding self to CC list. Moving Platform/OS to All because this doesn't work on Win32 either. It would be really helpful if this got fixed before rtm. It seems to me this can't possibly be hard to fix (but of course I could be wrong), and it has a rather *huge* payback, for I know a LOT of people (including myself) who find this bug very, very annoying (if not a reason not to use Mozilla at all until this is fixed), and it would definately be a BIG step back from NS4 if this doesn't work in Mozilla anymore!
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Nominate for mozilla0.9
Keywords: mozilla0.9
See also bug 19446, which asks for a keyboard shortcut to get into the location bar that would work even if a page element already had focus.
I agree, not being able to get to the location bar by hitting tab once is very annoying, and I would too say this could be a definite reason not to use mozilla (such a step back from NS4.x looks very bad for a commercial release).
So if I open a new window on Mac, focus is in the URL bar. Where do you want the focus to be so that you hit tab once and end up in the url bar? Give me a specific sequence please.
Target Milestone: Future → mozilla0.9
Here's how I see it: Like you said, when you *open* a new window, focus is in the urlbar. However, the text in there isn't selected then (like in Navigator), so I can't just start typing: I have to select the text first, either by double-clicking or pressing SHIFT-HOME or whatever other means. It should behave like in Navigator. If I then open a page (say, Mozilla.org) in my newly opened window, and click somewhere in the page (anywhere that's not a link or form), the focus changes to nothing (which is different from Navigator behaviour, which doesn't change focus at all when clicking in the page - but I think Mozilla's behaviour in this is better). However, after the focus has been changed to nothing in this way, pressing TAB should take the focus back to the URL bar (and select all the text in it (!)), but currently, that doesn't work. Pressing TAB repeatedly again after that should take the focus through the links in the page, like it does now. Clicking in a blank space again should set focus to nothing again (like it does now), pressing tab should take me to the urlbar again, etc. So, basically, this bug is about two things: 1) Making the text in the url bar selected when it gets focus 2) Make TAB shift focus to the urlbar when focus is nowhere Moz should at least behave as described above, however even better IMHO, but somewhat more radical, would be: Drop the support for scrolling through all the links in a page with TAB. I know of *no one* who actually uses that and I can hardly imagine anyone would (but of course I might be mistaking in that). Instead, make pressing TAB *always* return focus to the URL bar unless focus is in a form, in that case scroll focus through the form, until you arrive in the last editbox/button/whatever, and then set focus to the urlbar again. So basically, tabbing is then for scrolling through forms, and in pages without a form, tab will just always return focus to the location bar. I hope this is helpful
The focus isn't "nothing" when you can scroll the page with the keyboard, but rather on the document. How would you handle framed sites? IMO, clicking in an empty area of the document and then pressing tab should move to the first focusable element on the page after where you clicked.
Okay, so when the focus is on the document (or in one of it's frames if it has more), the focus isn't on any of the link is the page, and you can scroll the document/frame with the keyboard. I think the whole point of this bug is that pressing TAB once should *not* move focus to the first focusable element, but rather to the location bar. After moving to the urlbar, and tabbing again, you can always still move focus to the first focusable element. Having to press tab twice for moving focus to the first element, isn't nearly as bad as not being able to tab to the locationbar at all! Also I think not that many people will be affected by having to press tab twice because not a lot of people use tab to jump between focusable elements on a page other than forms. However it seems a lot more people are annoyed by the fact that tabbing doesn't set focus to the urlbar. As for your comment on how to handle framed sites, I don't really see how frames would matter? You can read 'frame' everywhere where I wrote 'document' (or where I said focus was 'nowhere' - sorry I got that wrong). If focus is on/in a frame, pressing tab once will still get me to the url bar, and tabbing again will still get me to the first focusable object. After you moved through all focusable objects in a frame you can move to the next frame. Exactly like the way Navigator does now. The only difference will be that when I put the focus on a document (or frame) as a whole, and thus remove focus from any of the focusable objects in it and I press tab, I want focus in the location bar the first time, not on the first focusable object. I wanna press tab two times for that :).
Specific sequence as suggested by Saari ... this covers other bugs as well, but that's so you can see it in context of overall Tab behavior. Action Expected behavior ------------------------------------------------------------------------------- 1. Type URL and press Enter. Location field retains focus (bug 54321). 2. Content begins to appear in page. Focus moves to first frame in page, as a whole (see also bug 55225 and bug 42758). 3. Press Tab. Focus moves to location field (*** bug 31809 ***), and selects location field contents (bug 28583). 4. Press Tab again. Focus moves to the first link or form element in the first frame (bug 44257). If there are no links or form elements in this frame, go directly to behavior of step 7 below. 5. Press Tab again. Focus moves to the next link or form element in the first frame (see also bug 54406). If there are no more links or form elements in this frame, go directly to behavior of step 7 below. 6. Click in a non-link/input part of Focus moves to that frame, as a whole. any frame. 7. Press Tab. Focus moves to location field, and selects location field contents. 8. Press Tab again. Focus moves to frame which last had focus, as a whole. This mini-spec does not cover the use of Ctrl+Tab, which should switch between HTML frames, the location field, and the sidebar (bug 30864). Arnoud's `radical' suggestion of ditching Tab altogether for link navigation is a big accessibility no-no -- it would make it impossible for people to surf the Web with the keyboard only.
Sorry, `as suggested by Saari' --> `as requested by Saari'. (I'm not trying to put words into Saari's mouth.:-)
This sequence looks very good, except for one minor thing: It isn't implicitly clear what happens after step 8, or how someone could tab through *all* the links in a page twice (hey, if that can't be ditched, it should at least work well :)). I would therefore suggest you change step 8 to: Focus moves to frame which last had focus, as a whole, if it was a frame that last had focus (because of step 6). If step 8 was reached by tabbing though all the links/form elements in the page (and thus the last element that had focus was not a frame), then go back to step 2. Now this sequence can be repeated infinitely, so someone can tab through all the links multiple times if they like, and all is great!
I think that it's worth noting that with bug 38865 open ([RFE] URL autocomplete in Open Web Location dialog), there seems to be no way of using the autocomlete feature without a mouse. this is really bad for us RSI'ed folks. :)
Summary: Can't hit tab to get focus in URL bar → [access]Can't hit tab to get focus in URL bar
This bug requires some very complex behavior which will make Tab move to the location bar *some of the time*, breaking other behavior along the way, such as bug 66597. I think it would be better to implement a location bar shortcut that will work almost all of the time, such as Alt+D or Alt+L bug 19446.
Blocks: 55416
On reflection, I suggest getting rid of step 3 and step 7. Just use Tab to cycle through {address field} --> {frame} --> {link} --> {link} ... --> {frame} --> {link} --> {link} --> ... --> {address field}.
Keywords: access
Summary: [access]Can't hit tab to get focus in URL bar → Can't hit tab to get focus in URL bar
->bryner, p2. Not sure what should happen here, but this is an accessibility issue, so we need to be careful, lest the product remain unusable by people with vision impairments.
Assignee: saari → bryner
Status: ASSIGNED → NEW
Keywords: nsbeta3
Priority: P3 → P2
Summary: Can't hit tab to get focus in URL bar → Can't hit tab to get focus into URL bar
Whiteboard: [nsbeta3-]
Status: NEW → ASSIGNED
*** Bug 69116 has been marked as a duplicate of this bug. ***
mpt: so should this bug be wontfix? In that case, we should file new bugs for - making the first tab from the location bar focus the first frame and not the first element in the first frame. This might be covered by bug 44257. - tabbing between frames (currently, trying to tab between frames ends up stuck in the location bar). Btw, it's looking like the shortcut to focus and select the location bar will be Ctrl+L (the dialog will become Ctrl+Shift+L). See bug 19446.
The problem is, hitting tab to get the focus is ingrained behavior is many NS4.x and IE users. Having Shift-L as a reliable way to get there is good, but I thought matching 4.x behavior was a prime directive.
I don't know what version of Internet Explorer Ben is using; but in IE 5.0 for Windows, when the content area has focus, pressing Tab does not focus the address field -- it focuses the first focusable element in the content area (e.g. the first link or form control). Only once you have tabbed to the last focusable element in the content area, will pressing Tab once more take you back to the address field. Yes, I think this should be wontfix, but I'm not the one to make the call.
mpt - so, in IE, if the content area has focus and you shift-tab, does that give focus to the URL bar?
shift-tab will reverse the cycle direction. (So on a page with one button followed by one link, when you initially load the page, TAB will go to button then link then urlbar, and SHIFT-TAB will go link then button then urlbar).
mpt: I am using IE 5.5. I did not say "when the content area has focus", but in general, when the browser window is first opened, tab brings you to the urlbar with the contents selected. You can just start typing and go "where you want to go today." I think this is because the urlbar is given the first position in the index of tabbable items. Same for NS4.x. The way ie works, if you have clicked at all in the content area, hitting tab will bring you right to the element closest to where you have clicked. Regardless, if you tab your way all the way through the elements, the cycle will eventually get back to the first item, the urlbar. If you shift tab, you just work backwords back to the urlbar. All this takes it making the urlbar to first (zero-eth?) item in the tab cycle.
IE uses Tab/Shift+Tab to cycle focus through: * first link/control in first frame ... * last link/control in last frame * address field. The Tab/Shift+Tab cycle I suggest for Navigator is as follows: * first frame as a whole * first focusable item (bug 58997) in first frame ... * last focusable item in first frame * second frame as a whole * first focusable item in second frame ... * last focusable item in last frame * address field. This is basically the same as IE's Tab/Shift+Tab cycle, except that it also includes whole frames for accessibility reasons (see bug 34357).
[point of clarification -- IE 5.5 for Win does include the frames themselves in the tab/shift-tab cycle]
Okay, I'm not sure if mpt's tab cycle schemes were supposed to represent order, but if they were I think it's important to make this clear: In IE5.5, win32, if you havn't clicked anywhere within any frames, the FIRST item in the tab cycle is the *address field*, not the last as in the recently presented schemes. It is also this way in NS4.x. Having the address field be the last item in the cycle isn't useful and is just plain destructive of a good feature that people are already used to.
Also, while tabbing, the dotted line that indicates focus was not going away when the focus was removed.
Priority: P2 → P1
Attached patch proposed fix — — Splinter Review
Saari, this is basically what we were discussing a couple of weeks ago. Can you pound on this some with your tabbing tests and see if it causes any regressions?
Bryner: what tab order does your patch set up?
No longer blocks: 37587
*** Bug 75604 has been marked as a duplicate of this bug. ***
r=saari, it can only be made better :-)
Good except for: + nsIContent* rootContent = document->GetRootContent(); + if (!rootContent) return NS_ERROR_FAILURE; + NS_ADDREF(rootContent); This looks like you have two extra addrefs with no release (one from GetRootContent, and the other from the NS_ADDREF). Seems like this should be: nsCOMPtr<nsIContent> rootContent(getter_AddRefs(document->GetRootContent())); if (!rootContent) return NS_ERROR_FAILURE;
Checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Bug 52027 (which is marked as a dup of this) does not state "on a new browser window." I would like to see that last part of bug 52027 resolved. In any other web browser, if I hit TAB, I go to the location bar, as if it were the first link/field on the page. The second TAB press will get me to the first link/field and if I then cycle back (SHIFT+TAB) I get back to the location bar. This does not happen in Mozilla (as of nightly 2001041020), therefore bug 52027 should not be closed or should not be a dup (or perhaps open a new bug ...is there already a bug on this tiny aspect?). I am posting a similar comment on bug 52027.
mz: I had this working a couple of weeks ago, but something seems to have regressed in setting the initial focus since then. See bug 76450.
76450 was fixed 4/24, but this doesn't appear to work properly on 4/25. Using ctrl-N to open a new browser window puts the focus on the URL bar, but using tab doesn't put the focus anywhere - you have to click the mouse to get focus back.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
<ESC> should also select and highlight the URL.
When I open a new window using yesterday's build on win98, it puts focus in the *collapsed* sidebar, so that tab and up-arrow have me moving through the disembodied search engine popup menu. very strange. also happens on linux. When sidebar is collapsed, initial focus is in the URL bar, which is also incorrect.
Target Milestone: mozilla0.9 → mozilla0.9.1
Is sidebar not using the normal visibility = collapsed? I'm pretty sure focus doesn't go into collapsed frames...
The behavior I get is in win2k is this: When I open a new Window with Accel+N, the caret is at the end of the location bar, and I can type. If I right click on a link a select "open in a new window", then i can press tab after the window opens, and the caret is again at the end of the location bar. Here are 2 observations about that: 1. The initial focus shouldn't be different for those 2 scenarios. 2. If you tab to the location bar, it should all be selected, because it's easier to see and you're probably going to be replacing what's in there if you do type.
Aaron, the different behavior with Open in New Window is intentional. The thought being that if you did that command, you're more likely to want to scroll the content next, not type in a new URL
Perhaps it's working for me then. However, I do think it should select the contents when you focus there, like IE does. That's much more convenient. I believe that's what we used to do. Should that be a different bug?
Blocks: 65632
Why when I hit tab the url bar has the focus only after the 3rd hit? And the contens is not selected (so I must manually delete the contents for typing-in a new URL). :(
Selecting the contents of a text field when it is focused is bug 28583. It is completely separate from this bug.
Status: REOPENED → ASSIGNED
Do we have a spec for focus tabbing behavior? The various bugs and comments I've seen seem to me a hodge-podge; I don't think we have understanding, let alone agreement.
There is no spec that covers everything in sufficent detail, especially not when you start talking about inter-window behavior, selection in relation to focus, etc. Following IE or 4.x is as close to a behavior spec as we have right now.
We are having an issue related to the patch checked in for this bug. When and/or why is it necessary for the document itself to ever have the focus as per http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.c pp#2457 ??? In our embedded gecko case, the user tabs through the links of the document. When the user reaches the last link, we expect a call to our implementation of nsIWebBrowserChromeFocus::FocusNextElement(). Instead, the focus seems to disappear as the document itself takes focus. The next tab then results in the expected behavior (at which point, we use FocusNextElement() to move to focus outside of the embedded window). Clearly, there is no clean spec for tabbing/focus behavior, but I don't understand the point of giving the focus to the document as a whole. Can someone clarify this for me? What does an accessibility user get out of having the document (as opposed to the tabbable elements in the document) gain focus?
IE doesn't do that, nor does Nav 4.x...
What do you mean by "that"?
Document needs focus sometimes: Scrolling with the keyboard! Sometimes there are no links or form elements in it.
A bit of additional explanation about the patch: The sidebar panel document is contained in an <iframe> which is inside of a <box>. When the sidebar is collapsed, it sets collapsed=true on the box. The box then lays out all of its children with 0 width and height. So, I simply added this check for whether the document's root frame is not 0x0, and make the call to nsDocShell::SetFocus fail if it is. I then had to fix the loop in FocusAvailable so that it did not error out when SetFocus returns failure. I am wondering, though, if SetFocus should be changed to return a boolean of whether it accepted focus; or at least invent an error code other than NS_ERROR_FAILURE so that we can tell the difference between a legitimate error and simply refusing to take focus.
Aaron - I recognise that, in the extreme case, that a document has no links or tabbable content whatsoever, it would need focus. But as long as there IS tabbable content, why should the focus be given to the document at any point while tabbing through the document's contents? At the moment, for a non-accessibility user, this means that the keyboard focus seems to disappear between tabbing to the last element and tabbing out of the embedded window. As far as I can tell (testing with our embedded example, IE, NS), the arrow keys scroll the document even though a link (and not the document itself) has the focus.
Right. IE and Nav 4.x don't seem to give focus to the document itself when there is something else focussable(the "that" I referred to too tersely above), but they do allow scrolling the document with the keyboard, although I expect the focussed element could sometimes handle some of those keys itself. Don't those events normally bubble up to the document when not handled by child elements?
IE and NS 4.7 do give the document focus. Type Ctrl+N or Right click on a link and select "open in new window" The focus starts out on the document. If the focus is not visible, that's a bug in it's own right.
Aaron -- right now, the document is getting focus at the END of the tab order of elements. For accessibility and keyboard scrolling (in a doc with no links), we would like to see the document at the head of the tabbing order. That is, on load, the document, not the first focusable element, should have focus. The order would then be DOCUMENT -> FIRST LINK/ELEMENT -> ... -> LAST LINK/ELEMENT -> OUT OF DOCUMENT -> DOCUMENT (loop back to document level) Comments?
This is not me backpedalling. I did some more testing and agree with Aaron's case for the document having the focus. However, I have issues with the tabbing order. I think Ken's suggestion is right on. It seems much more intuitive to me as a user that the focus is on the document initially (rather than when the user is about to step out of the document and into the embedding window). This does not seem to be the case right now: the first element (if any) gets the focus and the document will not get the focus until the user has traversed all other focusable elements.
how would this affect complicated things like browser: [url-bar] [s-|Brow] [ib|ser-] [da|Wind] [er|ow. ] specifically having the document appear twice in the tab cycle (i believe document should be before its content in the tab cycle, i'm just not sure about having it again after its content)
We're asking that it be removed from the end of the tab cycle and only included ONCE (in the beginning of the tab cycle).
Yes, the document should get the initial focus and remain FIRST in the tab order. I am unsure how this affects the url bar, etc., as I am embedding gecko.
If the document is at the beginning of the tab cycle, then we run into another problem. What I think we want (and what IE does) is give the document focus initially, then one tab puts you in the URL bar. If the document was in the tab cycle before the contents, the next tab would not go to the URL bar.
Yes, I've noticed how IE initially puts the focus on the document, and the first tab goes to the url bar. Subsequent tabs cycle through the links, and recycle back to the url bar. The document never gets focus again unless the user clicks the document page. I thought this could go one step better by cycling back to the document after the last link (and then to the url bar, etc.). This would allow, for example, a blind person using a screen reader to cycle his/her screenreader back to the document without having to click within the window.
Yes, I've noticed how IE initially puts the focus on the document, and the first tab goes to the url bar. Subsequent tabs cycle through the links, and recycle back to the url bar. The document never gets focus again unless the user clicks the document page. I thought this could go one step better by cycling back to the document after the last link (and then to the url bar, etc.). This would allow, for example, a blind person using a screen reader to cycle his/her screenreader back to the document without having to click within the window. Also, I just wanted to add that I have not looked into the code, but was wondering why the focus cycle could not just set the initial focus to the first item in the loop, which would be the document, the second would be the url bar, the (third .. n) the links/elements in the page, etc..., back to the document as first item again.
Agreed. This works well in IE.
That sounds like exactly what we do now, except that the urlbar is the beginning of the tab sequence, then the links, then the document, and we start off on the document. It's functionally the same.
IMO, we should drop the "Tab once to get to the location bar" behavior and only support Ctrl+L, since Tab - can't work on framed pages without requiring a very complicated and confusing tab order. (If the location bar is between the document and the document elements kind of works for single-frame documents, what do you do on multiple- frame documents? Put the location bar between the first frame and the elements in the first frame? Put it between the largest frame and the elements in the largest frame?) - doesn't work when the user has already clicked on the page or an element on the page. - doesn't work when the page focuses a textbox onload. (NS 4.x would move to the location bar on the first tab, even if there were additional form elements. See http://www.itsajob.com for an example of why 4.x's behavior was annoying.) - probably won't work when the location bar isn't visible (see bug 81331 for making Ctrl+L work in this case).
Referring to the last comments by David about dropping this altogether, I must say that there wouldn't have been so much activity on this bug and the others related to it if users didn't care about it. This is behavior that people have come to expect from browsers, because that is what they have done for so long. Dropping it is like (no as bad as, but like) dropping the back button. It breaks the browser paradigm. It may be troublesome to implement from a programmer's point of view (although it has been done before, so what's the big deal), but users take it for granted. They won't take its absence for granted though. Let's not give people another reason to say Mozilla behaves in a strange/non-standard way. Anyhow, there's one long time browser user's perspective. Now let me go and add one of my votes to this bug, and I hope others will do the same.
patch looks reasonable enough, r=saari
Does this affect dialogs? Shouldn't dialogs still come up with the first element in focus?
Brian, my experience with embedding is that the first link/element gets initial focus. That is bad. We need the document to get the initial focus.
Ken- In mozilla, the document _is_ getting the initial focus on a page load. From what you're saying, it sounds like this might work differently in an embedding case. I'll see if I can reproduce that.
sr=hyatt
Brian - Here's the deal with regards to the embedded case - Unlike the browser, we are embedding gecko in a window/dialog that has many controls (not just a single url bar). Now, if the document is at the end of the tabbing order AND has the initial focus, it means that the user must tab through all of the parent window's gui before ever getting to the links within the document. Clearly, in a case where this doesn't involve two keypresses (one tab to url bar, one tab out of url bar) the result is a tedious (7 tabs) user experience while simply attempting to get to that first hyperlink. To only be concerned with the browser case is doing a disservice to any future embedders of gecko. We would like to see the following - A flag set somewhere during window/document creation that determines whether the document gains focus at the head or tail of the tabbing order. If the default value was the tail, then the browser implementation need not concern itself. Embedding applications would, however, have the option of determining whether users will be forced to traverse all UI before stepping through the document's contents. The document would still get the initial focus regardless. Oh, and to clarify, the document DOES indeed get the initial focus if you call nsWebBrowser::Activate(). The reason the first tabbable element had focus upon our initial document load was because we were calling nsWebBrowser::SetFocus() (which calls nsDocShell::SetFocus, which sets the focus to the first tabbable content)). So, that's not an embedding default. It's something we were doing because the alternative isn't really acceptible.
I think the original reported issue here is now fixed -- you can tab into the URL bar from a new browser window. Please open separate bugs on the embedding problems with initial focus and tab order. Thanks.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
This causes a serious regression. When you click on a link in the mail three- pane, we now crash because presShell->GetRootFrame() returns a null root frame.
Attached patch wallpaper — — Splinter Review
r=saari on the wallpaper, but I am surprised that we get a null root for a given presshell. Isn't that not supposed to happen?
Component: XP Toolkit/Widgets → ActiveX Wrapper
Target Milestone: mozilla0.9.1 → M1
Is this really fixed? In Win2K/build 2001060308, if you open a new window or go to some page (via typing or a bookmark), pressing tab doesn't select and give focus to the URL bar, which is the original issue. Maybe a regression?
Component: ActiveX Wrapper → XP Toolkit/Widgets
Target Milestone: M1 → mozilla0.9.1
As I told Bryner on IRC, this works on Linux and Mac. Sorry about the product/milestone change, I have no idea what happened. :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: