37638 - URL bar is given focus by default in new window [via accel+N or File > New Navigator Window]

Status: VERIFIED FIXED

(SeaMonkey :: Location Bar, defect, P3)

Description

[Chris Siebenmann]

Build ID: 2000042809 and recent CVS pull

 Under Linux, when you open a new browser window (including starting
Mozilla up), the URL bar is given focus. This is bad, because it means
that no keyboard navigation shortcuts (such as spacebar to scroll down)
will work until you take a manual step to force Mozilla to put the focus
in the display area.

 Reproduction:
- start Mozilla, browsing http://www.mozilla.org/
- hit space. Observe lack of scrolling, and what the URL bar shows.

Comment 1

[Jesse Ruderman]

Funny, two days ago I asked for the focus to be given to the location bar, but 
only on about:blank.  Bug 37588 (flame me in either bug).

Comment 2

[Kathleen :Brade]

I'll take this bug since I am the person to gave the urlbar focus by default.  On 
Mac 4.72, the urlbar is given focus by default unless the page has JS to give one 
of its edit fields focus.

Can you press tab and then navigate?

Comment 3

[Chris Siebenmann]

 Tab on Unix (Linux) doesn't change the focus; you must manually click
somewhere in the page body.

Comment 4

[Kathleen :Brade]

ok; I'll fix this by backing out my change after we get editors to always be 
instantiated (so D&D etc. work too)

Comment 5

[rubydoo123]

low priority polish issue, the first page that gets loaded has the url as 
the focus, easy workaround is to tab to body.

Comment 6

[Kathleen :Brade]

This is an xpapps issue; it isn't a general editor issue but an urlbar issue.  
Since I'll be going on sabbatical this week, reassign bug to the appropriate 
group.

My understanding of what should happen for this bug is that the urlbar needs to 
be given focus so text can be dragged to it but also that the focus should only 
remain in the urlbar if the default url is "about:blank" or "".

Comment 7

[sairuh (rarely reading bugmail)]

*** Bug 47972 has been marked as a duplicate of this bug. ***

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

*** Bug 50509 has been marked as a duplicate of this bug. ***

Comment 9

[Jacob Kjome]

I think this bug has usage issues that are very important.  

For example, more than a few times, I have opened a new window either by 
starting mozilla newly or by using a target=_blank" or window.open().  

The page will load and then I immediately begin to attempt to scroll down the 
page using the down arrow.

What happens is that the URL bar goes blank and I can't get the text that was 
there back.

I guarantee IE users are going to take one look at this behavior and disregard 
this browser.  These basic usage issues can't just be cast aside.  Like it or 
not, the audience that will make or break this browser are lay people that 
won't know how to "work around" these basic issues.  Then you have the 
developers who will know workarounds, but then cast this browser aside and go 
with a browser they don't need to use workarounds for, IE4+.

I want this browser to succeed.  Please fix this for beta 3!!!

Jake

Comment 10

[Jesse Ruderman]

>the URL bar goes blank and I can't get the text that was there back

Escape key should revert url = bug 32194.

Comment 11

[Jacob Kjome]

I agree with the last coment by Jesse, however, I think the way that IE handles 
this is correct.  That is, hitting the up or down arrows when the URL bar has 
focus does absolutely nothing.  I agree that, if the URL disappears, you should 
have some way to get it back.  If the escape key will do that, great... 
however, it shouldn't go away in the first place.  Show me a lay user who 
accidentally makes the URL disappear and I'd put money on it that they have not 
a clue to hit the escape key to get the thing back.  Heck, I think of myself as 
an advanced user and I'm not sure I would have assumed that behavior.

bottom line, the up and down arrows have no purpose in clearing the URL bar.

Jake

Comment 12

[ohely]

An additional consequence of this bug comes up in more recent
nightly builds than M17, where the keyboard shortcut for "close window"
is "ctrl-W" rather than "alt-W".  In M17 the "alt" shortcut worked while focus
was still on the URL bar, but the "ctrl" shortcut just blanks the URL bar.

Comment 13

[Jacob Kjome]

That's interesting.  the issue about the url disappearing on key up/down seems
to be fixed.  Behavior now is that the URL bar is still focused upon opening a
page in a new window (window.open()), but pressing the up and down arrow in this
case now mimicks left and right arrows.  That is a good enough fix for me.

BTW, The reguarding the original issue, where there is no immediate keyboard
navigation.  IE 5.5 (and probably 4.0+) works exactly the same way.  I don't see
this as a true bug since a precidence for this behavior has already been set by
the most popular browser on the internet.

I don't see this one as a bug for sure.  Some more discussion will need to be
done about what is the correct behavior in the first place.

Jake

Comment 14

[Scott Anderson]

I'm sorry, but this is terrible. Please don't consider leaving the focus on the
URL bar... there are a lot of people (myself included obviously) who expect that
pageup/pagedown/updownarrows are going to be active when a page loads or a new
browser window is opened.

Classic sequence: I'm reading something like Slashdot, and want to middle-click
(this is on Linux) a number of links to let them load while I'm browsing the
main page. When I get to the other page, the navigation arrows and pageup/down
keys should work without clicking the page body. Not doing so imparts a horrible
UI cost (move to mouse, move pointer to body, click, move back to keyboard). Not
everyone uses a mouse to navigate, and I can see absolutely no reason for the
URL bar to have the focus on a newly loaded page! The page is going to be read,
not immediately replaced by typing in a new URL.

Sorry to get so vehement, but this is a huge issue IMO. Speed browsing is a pain
in the rear now because I have to keep getting to the mouse just to scroll the
page.  At the very least, make it an option so I can set it and ignore what the
rest of you heathens do... :-) This bug is nearly as bad as the inactive
left-arrow for the back button when it comes to using the browser with the keyboard.

One final note: I could care less what IE does. The old Netscape doesn't give
the URL bar the focus, and I don't expect Mozilla to do that either.

Comment 15

[Jacob Kjome]

Ok, I think I agree with Scott now.  

Not sure how I saw that IE 5.5 didn't give immediate keyboard navigation, 
because I retested and it does on documents opened by window.open().

I also tested NS 4.75.  It gives immediate keyboard focus the same way as above.

Actually, in no case that I have found does either IE or NS give focus by 
default to the URL bar.

I'm not sure why Mozilla does either.

On top of that, the issue about the URL disappearing that I said was fixed must 
have been a complete fluke.  The build I tried when I posted my last message 
appeared to have fixed the problem and it acted just as I described.  However, 
now it is back to clearing out the URL when you hit either the up or down keys.

The up/down keys, when the URL bar does have focus should either not do 
anytyhing or they should move through the list of URL's you've been visiting 
just like IE does.  If this is your first URL, then it, again, should do 
nothing.

If nothing else, the disappearing URL bar needs to be fixed.  It would be 
incredibly nice (and I would urge it be fixed!!!) to fix the keyboard pgup/pgdn 
focus by default problem, but at least the URL should not disappear for the 
user.

Jake

Comment 16

[Matthew T (active 1999-2002)]

Why not give the location field focus if the window is opened using File > New 
(or its shortcut), but give the page focus in a new window opened by any other 
method?

If you open a new browser window using File > New you're very likely to want to 
use it for visiting a particular URL, whereas if you open it by any other means 
(e.g. Open Link in New Window) you're very likely to want to scroll its contents 
instead.

Comment 17

[Jacob Kjome]

That sounds reasonable, however if you look at IE's behavior, if you open a new 
window from a previously opened browser, it grabs the entire session state of 
the old browser.  I use this to backtrack a few pages at times in development.  
In that case, I don't usually change the URL.  I just hit the back button.

If I want to start a new clean browser session, I click on the IE icon to get 
fresh new browser window.  Even in that case, you have to highlight the text 
there to get rid of it: eg... about:blank or your stated home page.  So, you 
have to manually put focus there anyway.

So, my recommendation would be to forget automatic focus of the URL bar 
altogether.  Never do this.  It will save a lot of headache and it will be more 
intuitive.


Jake

Comment 18

[Jesse Ruderman]

Hoju - there are ways to remove about:blank from the location bar without the 
mouse, such as Ctrl-A and Shift-home, as long as the url bar already has focus.


It seems to me that for this rfe to work, there would have to be some intuitive 
way to move focus from the location bar to the page without scrolling to the 
first link on the page.  Right now I don't think there's any way to move focus 
out of the location bar with tab.

Comment 19

[Jacob Kjome]

That's not quite the point I was making.  Forget about:blank, because that is 
slightly different case from when a window gets opened via, say, a window.open
() script or target="_blank".  

There is no reason for the extra mouse click or key stroke.  And, again, if you 
left this the way it is now, at least don't allow the URL to disappear at all. 
Even if there is a way to get it back, by, say, hitting the escape key, it is 
totally non-intuitive and you average user will have not know enough to hit 
that key.

Jake

Comment 20

[sairuh (rarely reading bugmail)]

*** Bug 58832 has been marked as a duplicate of this bug. ***

Comment 21

[Raghu Sakleshpur]

Adding suntracking string

Comment 22

[Peter Trudelle]

I agree with MPT.  When I have already specified the content to be loaded, I am
focussed on it, and I expect the browser to be also.  Only when I open a new
default browser window do I sometimes intend to edit the URL, although even then
I usually just want to see my default page.  Interacting with the URL bar is
something I do relatively infrequently, it is okay to have to click or hit a key
to get there.  Do we have any usability test results to help settle this?

Comment 23

[Asa Dotzler [:asa]]

Worksforme with 022605 mozilla linux build on new loaded link and on back. 

Comment 24

[Chris Siebenmann]

 Unfortunately, this bug is not resolved for me (on Linux, on an up to the
moment CVS pull and build); I am reopening.

 The current behavior I see is that anything you do to open a new browser
window (whether using the middle mouse button on a link, File | New Navigator
Window, or even using the X remote control stuff, causes the URL bar to be
focused. Only once you click on a link (or click in the text) does the focus
go to the text body.

 This is especially annoying for people who make frequent use of 'open link
in new window' (button-2) functionality; your new window with the new web
page opens, all ready to be interacted with ... except that first you have
to click your mouse (pointlessly, IMHO) so you can do that.

Comment 25

[Blake Ross]

The open in new window case will be fixed by 53549, which I'm about to checkin.

Comment 26

[Ben Ruppel]

I like MPT's idea.  If you "Open link In New Window", certainly, focus the
content.  But if you hit ctrl-N, it is reasonable to assume you'll want to edit
the contents of the location bar, so the location bar should have focus with the
text selected.  

If this behavior was implemented, bug 19446 (Key-combo to move focus to URL Bar
(ALT+L/ctrl-space?)) would be easily resolved.  The dialog box that comes up
with ctrl-L would not be needed to open an url in a new window, as ctrl-N would
already have the url selected.  ctrl-L could then be used as a shortcut to get
to the urlbar when needed.

Once tabbing is completely fixed, tab will get focus to the content area.

Comment 27

[Aaron Leventhal]

Hi all,

A crucial bug we've been ignoring is that you can't Tab out of the URL bar into
the content.
The main reason it's been ignored is the lack of a clear definition of what we want.
This is not about whether tab goes to links or form elements, that's another issue.

After talking it over with mkaply, lordpixel and se, we have a proposal:

1. Tab presses when focus is in URL bar: the next tab goes to the content frame.
2. Tab presses when focus is in first content frame: the next tab should go to
the first item in that frame.
3. Once a user tabs past the last item in a frame, it should go to the next
content frame. At this point the focus should be offered back to the URL bar.
4. Initial focus when new page is entered (by typing in URL or clicking on a
link): first content frame
5. Exception: when new browser window is opened, and the user hasn't explicity
specified content for it yet (for example using Accel+N to open a new window),
focus should go directly to the URL bar. This will allow users to immediately
type in the new URL they want.
6. Frame/pane navigation is done with Control+(Shift)+Tab or (Shift)+F6, to
cycle through the set of all panes and frames

How does this sound? I want to get a definite answer from people so I can post
our solution to the relevant bugs, and get this into embedding 1.0.

Oh, and related bug numbers:

http://bugzilla.mozilla.org/show_bug.cgi?id=37638
http://bugzilla.mozilla.org/show_bug.cgi?id=71497
http://bugzilla.mozilla.org/show_bug.cgi?id=31809
http://bugzilla.mozilla.org/show_bug.cgi?id=67977
http://bugzilla.mozilla.org/show_bug.cgi?id=44257

Comment 28

[Peter Trudelle]

Giving focus to newly loaded content is a fundamental feature of most windowing 
apps. It is the way Navigator works on most platforms, the way IE, Word, Excel 
and other popular programs work everywhere.  The only exception I know of is Mac 
Nav 4.x, which splits keyboard focus so that alphanumeric keys go to the URL 
bar, but even it sends cursor keys to the first content frame. I think our users 
will expect this browser to work in a similar way as other apps they use. I 
think that we should have strong, user-centered reasons for going against this 
common behavior, and they should be backed by impartial data, not personal 
preference. Don't we have any data on this from our usability testing?

Comment 29

[Stephen Ostermiller]

How related are these bugs?

bug 37638 - URL bar is given focus by default (in new window)
bug 62765 - Selecting url from menu/toolbar doesn't set focus to content area.
bug 69421 - using a bookmark should focus content area (from location bar, etc)
bug 67977 - Focus lost after clicking link (causing arrow keys/space to not
scroll until clicking on new page)
bug 71493 - content area doesn't keep focus following links
bug 72357 - Content area doesn't receive keyboard focus after load is completed

These are all either duplicates or very closely related.  If they are not dups
would it be possible to get a meta bug for all the times that the content area
doesn't get focus when it should?  

Comment 30

[Sam Rowe]

Would it be possible to have the URL-bar be aware of window commands such as ^w
and ^n etc? I don't propose this as a solution to the focus issue, but I can't
imagine an instance where I'd want the URL-bar to "draw" a ^w when it has focus,
but I can imagine the URL bar having focus and wanting to close the window w/o
re-focusing.

Comment 31

[Peter Trudelle]

I'm open to the idea of split focus, but it does raise other issues.  For
instance, what should happen when users type a space after loading an URL? 
Should we replace the URL with a space (assuming it is selected), or scroll the
page? Personally, I think the simple solution is better - always focus on the
content you just loaded.

Comment 32

[Marko Macek]

URL bar must be aware of window commands. And all the rest from the main menus.

Window commands are global... Anything else is just a *terrible* bug!

But, the URL bar should only get focus when a new blank window opens, not when
the window already has content to load.

Comment 33

[timeless]

sam: on windows and macos the behavior you are asking for already happens.

marko: i'm assuming you're using X11. just disable emacs bindings and you'll 
get the behavior you expect.  That is outside the scope of this report.

Peter: split focus is really dangerous for emacs binding users.  On macos it's 
sensible, but everywhere else it at least partially conflicts w/ intuition.

On windows if I type into a combobox, I expect the down arrow to drop down the 
list of items, not send a down stroke to some other window element.  I even 
expect page down to be sent to the listbox. *I prefer ie's non destructive 
pagedown behavior [it drops down the listbox and selects the item where 
pagedown would be, but does not navigate to that location] over nc4's 
destructive behavior [it just navigates to the item that pagedown would select]

QA: can you update the status of this bug on the major os's? -- sorry to make 
such a request.
steps:
run mozilla
press:
 down, escape, page down, escape, tab, down, escape, page down, escape
accel-n [if this doesn't create a new window, please indicate]
{file>new window}
 down, escape, page down, escape, tab, down, escape, page down, escape
shift-accel-l
 www.mozilla.org enter
 down, escape, page down, escape, tab, down, escape, page down, escape

hrm, that's a lot of steps and i guess i want feedback for each key.  Sorry 
that's too much work, but if someone could attach a page describing the result 
for each of those steps, that'd be wonderful.

Oh, and perhaps someone should fill out those steps to indicate the expected 
behavior. aaron?

Comment 34

[Keyser Sose]

*** Bug 82755 has been marked as a duplicate of this bug. ***

Comment 35

[Duncan Findlay]

*** Bug 85285 has been marked as a duplicate of this bug. ***

Comment 36

[rburdick]

Just a user commenting.

Currently it seems that anytime I open a new window with ctrl-N (my preferred
method of opening a new window) the search textbox in the search sidebar gets
focus.  This might only be after doing a search where the sidebar is populated
(ie: searching bugzilla).  Whatever your preferences for setting focus on new
window opening (URL or content), I don't think this behaviour makes much sense.
 It is especially bizarre when the sidebar is closed, as you can't tell what has
focus.  (It may make a difference that I use about:blank as my default page when
trying this)

As for what I expect when I open a new window, I expect a blank window to have
the URL bar as the focus as that is what I am going to modify 95% of the time
(the other 5% is picking something from my bookmark list).  I use about:blank as
my default though.  When I open a window with content (ie: open in new window) I
would expect the content to have focus, so I could scroll with the up and down
arrows.  If I had a page with content as my default, then I would expect ctrl-N
to open assign the focus to the content as well.

Comment 37

[sairuh (rarely reading bugmail)]

i filed a separate bug for focus going to the URLbar when opening a new browser
via the Open Web Location dialog [ie, no forms]: bug 87946.

Comment 38

[Claudius Gayle]

although this is a urlbar bug it's really more about focus and keyboardnav
so I'm tossing the QA over to sairuh.

Comment 39

[slice1900]

I am seeing what [e-mail] sees, and have seen it for 0.91, 0.92 and now
0.93, running on Linux.  When I use the middle mouse button to open a link in a
new window, the focus is on neither the page (as it should be) or the URL bar
(the bug others have reported)  I disabled the annoying search sidebar thing a
long time ago, so I never ever considered it, but I opened it up and middle
moused a link and presto, that's where my missing keyboard focus is.  Since the
truly annoying bug where a loading page stole (viewing) focus was fixed for 0.93
(thank you thank you thank you) this is IMHO the biggest remaining focus bug. 
These are the sorts of things that seem like a trivial matter but to your
average user who is used to doing things in either IE or NS 4.x it will appear
quite large.  It is IMHO one of those end user usability things that needs to be
fixed for Mozilla/Netscape to have a truly polished appearance.

From reading the text and perusing other bugs while trying to figure out where
this bug was, I see there are a mass of such focus bugs, some contradictory,
some claiming resolution months ago, some open.  It appears that the behavior of
this bug/class of bugs has been evolving over the months, and at some point
someone will need to attempt to nail down where all the problems are on a single
build, and see if behaviors differ on the major platforms.  It kind of looks
like that as one focus bug gets fixed it either causes a new bug elsewhere or
brings back a previously fixed bug from the dead, and no real progress is made
overall.

Comment 40

[Jesse Ruderman]

slice: you're hitting bug 76621, sidebar elements should not grab focus from
other parts of window.

Comment 41

[Tim Powell]

It appears that the URL bar is no longer given focus by default, but it still
isn't giving the content area focus. Since I right-click open in new window and
immediately scroll with keyboard in other browsers all the time, this is quite
frustrating. I can easily and always reproduce this with Mozilla nightly build
2001082109:

Start mozilla and go to any long page with links, such as a bugzilla bug list
Notice that you can scroll the page up and down with arrow keys/pgup/pgdn
Right click a link and select open in new window
Notice that you can not scroll up and down with arrow keys, you must focus the
content area first with a mouse click. It's almost impossible to tab into the
content area  (I feel like it takes a random number of tabs. If you press down
arrow after the wrong one, you end up messing with the autocomplete box.)

More investigation seems to indicate that the sidebar is stealing focus. This
should NEVER occur with it is collapsed (which is always is on my machine), but
it is. I guess that's bug 76621.

Comment 42

[Dan Mellem]

I just installed 2001091303 on two computers running Windows '98 and Windows
2000 (respectively). On the 2000 machine a ^N created a new browser with the
focus in the location bar. On the '98 machine (same copy of the installer) ^N
did not create focus. I hit TAB four times and got focus in the location bar.

Personally I'd prefer the focus goes to the address bar with TAB taking me to
the content. If possible the PAGE UP/DOWN should scroll the content regardless
of focus unless the location bar/current focus is in the process of an
autocomplete (or other) drowdown. I usually use the scroller on the mouse or
PAGE DOWN to page through the window.

Comment 43

[Alec Flett]

reassign url bar bugs to new owner..

Comment 44

[Jesse Ruderman]

See also bug 102598, ctrl+t should focus location bar in newly opened tab.

Comment 45

[sairuh (rarely reading bugmail)]

nominating for moz0.9.6, and clarifying summary.

blake, should this go to someone else, if you don't have for it? i was thinking
either bryner (who'll just be overjoyed, lol ;) or saari...

would *this* bug cover the fact that File > New Navigator Window from mail or
the editor results in focus in the URL bar?

anyhow, i've filed bug 103758 for the case where focus should be in the page
content by default upon startup.

Comment 46

[sairuh (rarely reading bugmail)]

and another case --which may or may not be this same bug: first time [in a
session] clicking a link in mailnews opens a browser window where the focus is
in the url bar.

Comment 47

[Blake Ross]

Joe was dying to have these bugs. Who am I to say no?

Comment 48

[Peter Eckersley]

One particularly pathological case for this bug arises when mozilla windows are
opened by external apps, such as gnome-terminal (the "open in browser" command).

If people can't agree absolutely on when the default focus should go to the
urlbar, perhaps there should be a preference option to change it?

Comment 49

[mdimitrio]

This bug is missing the 4xp keyword.

Marcos.

Comment 50

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 119519 has been marked as a duplicate of this bug. ***

Comment 51

[Bill McGonigle (not currently reading bugmail; please contact directly)]

only the "Open in New Window" part doesn't work for me, Mac OS X 2002020418 build.

Comment 52

[Peter Trudelle]

nsbeta1+ per Nav triage team.  focus should always go to content when it is
loaded, only possible exception is when loading about:blank.

Comment 53

[Joe Hewitt (gone)]

Attachment: patch

Comment 54

[Brian Ryner (not reading)]

Comment on attachment 71997 [details] [diff] [review]
patch

r=bryner

Comment 55

[Brian Ryner (not reading)]

*** Bug 103758 has been marked as a duplicate of this bug. ***

Comment 56

[Boris Zbarsky [:bzbarsky]]

*** Bug 130586 has been marked as a duplicate of this bug. ***

Comment 57

[Joe Hewitt (gone)]

jag can't get enough of these bugs!

Comment 58

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

this ended up in the wrong component somehow

Comment 59

[sairuh (rarely reading bugmail)]

side note: see also bug 124990, where joki is doing an event handling rewrite.
it may or may not affect this bug --but thought it should be mentioned here,
just in case...

Comment 60

[saari (gone)]

shouldn't affect this...

Comment 61

[jag (Peter Annema)]

Attachment: Updated to trunk

Comment 62

[Brian Ryner (not reading)]

Comment on attachment 77775 [details] [diff] [review]
Updated to trunk

r=bryner

Comment 63

[R.K.Aa.]

*** Bug 136473 has been marked as a duplicate of this bug. ***

Comment 64

[Tony Tovar]

(Just some quick comments copied from dupe bug 136473 and based on WinNT experience)

- when using "Open Link in New Window", I think the keyboard focus should be on
the document window so that all keyboard scrolling options are available (arrow
keys, PgDn)
- when a new window is opened using cmd-N, though, I think the keyboard focus
should be on the URL so the user can immediately type a new address
- finally, for new cmd-N windows, I think the arrows keys (and PgDn) should
access the Recent Documents list instead of a blank list; currently,
mouse-clicking on the drop-down arrow is the only way to access the list.

FYI - I'm only submitting this because I don't see any commentary in the recent
notes re what change is being submitted.

Comment 65

[Peter Trudelle]

see comment #52

Comment 66

[R.K.Aa.]

*** Bug 136573 has been marked as a duplicate of this bug. ***

Comment 67

[jag (Peter Annema)]

Attachment: Focus content area unless we're a blank page, fix callers to remove now obsolete openDialog parameter

Comment 68

[Brian Ryner (not reading)]

Comment on attachment 78644 [details] [diff] [review]
Focus content area unless we're a blank page, fix callers to remove now obsolete openDialog parameter

r=bryner

Comment 69

[Joe Hewitt (gone)]

Comment on attachment 78644 [details] [diff] [review]
Focus content area unless we're a blank page, fix callers to remove now obsolete openDialog parameter

sr=hewitt

Comment 70

[Jaime Rodriguez, Jr.]

Changing to [ADT2 RTM]. Removing adt1.0.0. Pls check this into the trunk. Let's
look at resolve this one after beta.

Comment 71

[Peter Trudelle]

cc Jaime. Ability to scroll content is fundamental, extremely visible: why
wouldn't we want it correct in beta?  It could generate a lot of dups and
complaints.

Comment 72

[Tony Tovar]

I'm sorry I didn't learn about this bug until recently.  So, at the risk of
annoying those of you who've been involved longer than I, let me say that I
*like* the URL bar having focus on New Windows.  

The only reason I spawn a new window is so I can go to a new URL.  If I'm going
to manually enter the URL, it's great to already have focus.  My only complaint
is that *focus does not automatically shift to the document* after pressing ENTER.

FWIW -- I was researched bugs related to URL bar focus because I was having
problems where I couldn't scroll documents from the keyboard.  I thought it was
something with the Open Link In New Window command but, now that I'm watching
out for it, I haven't been able to recreate it. Instead, I think the problem is
the focus not switching...

Comment 73

[Peter Trudelle]

If that is the only reason you open a new window, then setting your home page to
about:blank will get the desired behavior.

Comment 74

[Andrew Hagen]

>I was having problems where I couldn't scroll documents from the keyboard. 

That might be bug 135851.

Comment 75

[Jaime Rodriguez, Jr.]

We still feel that it is better to consider this for RTM

Comment 76

[Peter Trudelle]

My question is: Why?

Comment 77

[jag (Peter Annema)]

Note: this was checked into the trunk on the 10th. Bug is still open for
potential landing on the branch.

Comment 78

[Jaime Rodriguez, Jr.]

Pls Note: You can mark this one as Resolved/Fixed. However, when bugs are fixed
on the 1.0 branch, pls replace adt1.0.0+ with fixed1.0.0 keyword. After QA has
verified the fix is in the branch, pls replace fixed1.0.0, with verified1.0.0.

The ADT scans for all adt1.0.0 nominations, even if they are marked
resolved/fixed, and have been checked in the trunk. thanks!

Comment 79

[scottputterman]

what are the results of testing on the trunk with this fix?

Comment 80

[Dimitrios]

For "Open Link in New Window" works as expected. "Open New Window" when the home
page is not blank also sets focus on content area. "Open New Window" when home
page is blank sets focus to urlbar. All seem good and there are no regressions,
as far as I can tell (I was almost sure we would face many of them). Anyone else?

Comment 81

[Peter Trudelle]

Doh!  New Window is failing for me in NS build 2002041503 (today's trunk) with
the default home page.  Focus seems lost, or goes to the active sidebar tab, if
the sidebar is open.  Open Link in New Window works in both cases.  With a plain
HTML home page, everything works fine.  Is home.netscape.com doing something
wierd to the focus?  QA Wanted: Sairuh, could you please test this?

Comment 82

[sairuh (rarely reading bugmail)]

heh, just finished testing this on the trunk and saw trudelle's last comment...

anyhow, this is still broken for me i tested two cases: (a) initial focus upon
startup (my homepage is http://mozilla.org, not about:blank) and (b) initial
focus with a new browser window (brought up via accel+N).

* linux rh 7.2 (2002.04.15.09 comm) and mac 10.1.3 (2002.04.15.07 comm): in both
cases, initial focus seems to be in lala land: hitting space, pageUp, pageDown,
arrow keys has no effect --no scrolling occurs. focus is not even in the urlbar.
workaround: hit tab once, focus goes to urlbar; hit tab a second time, focus
goes to the content area.

* win2k (2002.04.15.08-gmake comm): in both cases, initial focus is (still) in
the urlbar. workaround: hit tab once, focus moves to content area.

Comment 83

[sairuh (rarely reading bugmail)]

update: crap, now this is working for me on linux and mac. i'm confused as to
why it kept failing --i had even created a new profile to test this.

one thing that might've "interfered" to "make this work": i've been going btwn
trunk and branch builds (linux and mac). after testing this, i quit the app and
did some other testing with branch builds --and i used the same profile i had
created with the trunk. then after i quit using the branch and restarted using
the trunk, then the fix for this seemed to work.

muy bizarro.

(note: this still is a problem on win2k...but, then again, i haven't gotten a
branch build yet there...!)

Comment 84

[sairuh (rarely reading bugmail)]

more testing:

just to be sure, i created another profile with the trunk builds. these newest
ones work now on linux and mac...but still broken on win2k.

so, perhaps i accidentally created the profile (in comment 83) using branch
builds? *shrug* still doesn't quite explain why this fails on win2k (trunk, no
branch available afaik).

Comment 85

[Dimitrios]

There might be some relation to the content and the speed you are browsing (but
I tested on slow web connection and on intranet pages and didn't notice any
difference). I still see expected behaviour in open link, open home page and
open about:blank (Win2K, 2002041503, modern/classic). But there are 3 cases
where focus is still incorrect:
1. "Open in New Tab" *doesn't* work in all cases (I hadn't noticed that before
because I'm not using tabs). 
2. Clicking on throbber (to get the http://www.mozilla.org page).
3. Frames. Focus seems going to the wrong frame (e.g. the one with scrolling="no").

My testing was performed on various Bugzilla, mozilla.org and personal pages.
The profile I use is at least 1 month old but I get the same results after
creating a new profile too. Perhaps there is an unknown crucial difference
between your settings and mine. Anyway, an example of test procedure is the
following:
1. Open Mozilla browser (home page is www.mozilla.org).
2. Open New Window.
3. From www.mozilla.org, open any link in new window.
In my case, both 2 and 3 work as expected (can scroll page with keyboard or
PgUp/PgDn or mousewheel).

Comment 86

[Peter Trudelle]

Sairuh, just to be sure, could you try these tests on the branch builds?  Given
the number of regressions this functionality gets, something else could have
stepped on both trunk and branch.

Comment 87

[sairuh (rarely reading bugmail)]

removing qawanted --i am actively testing this issue. :)

yes, i'll test these cases --but did you want me to test using current branch
builds, even though this hasn't even been checked into the branch? the behavior
on the branch has been unchanged for some time. :) anyhow, i'll do more thorough
testing in a bit.

oh quick note: i grabbed today's trunk builds and compared the regular win2k
trunk vs the win2k gmake (which should still be trunk, afaik) --it's the gmake
build which seems screwed up (per comment 84). the regular trunk build behaves
quite nicely with the fix: startup window, new window and new tab all have focus
in the content (scroll as expected).

why would the gmake builds not work? unless they somehow didn't get the fix?

Comment 88

[Peter Trudelle]

This fix hasn't gone into the branch, so if we see similar behavior there, it
would have to be due to another cause.  I'm just trying to determine what the
difference between current trunk and branch is, rather than assuming the branch
is perfect.

Comment 89

[sairuh (rarely reading bugmail)]

i'll attach trunk and branch test results soon.

an internal version is at http://hopey.mcom.com/tests/bug37638.txt

the only case which doesn't seemed to be fixed on the trunk is (e) selecting
"open in new tab" from a link context menu. should that be fixed here, or should
i spin off another bug for that?

here are the basic tests that i'm using:

a. upon startup. eg, homepage set to http://mozilla.org/

b. new browser window. eg, accel+N or File > New > Navigator Window. assumption:
homepage is not about:blank.

c. new tab., eg, accel+T or File > New > Navigator Tab. since it's about:blank,
enter a url in the urlbar (http://mozilla.org/) then hit enter to load in this
new tab.

d. context menu for link: "open in new window".

e. context menu for link: "open in new tab".

f. control test: click a link which loads its target in the same window (very
common case, this is just a sanity check).

Comment 90

[sairuh (rarely reading bugmail)]

Attachment: test cases for this bug

Comment 91

[sairuh (rarely reading bugmail)]

forgot to mention: test results are at the end of attachment 79518 [details].

Comment 92

[Peter Trudelle]

Thanks Sairuh, that's valuable data. I think I may be seeing more failure cases
because I have the 'hide tab bar...' pref disabled.  Looks like the trunk is
doing better than the branch on this, but still failing in more cases than we'd
like.  

Comment 93

[jag (Peter Annema)]

(e) is a different bug.

Trudelle, what problems are you seeing?

Comment 94

[Peter Trudelle]

see comment #81.  What bug # is (e)?

Comment 95

[sairuh (rarely reading bugmail)]

jag, would (e) be bug 125589? not sure if it is, since i cannot reproduce using
the test case provided in that bug...

trudelle: i'll do some testing with the sidebar open. my previous tests were
with the sidebar closed (absent). there are several big accessibility issues
concerning the sidebar (see bug 48251, bug 89148), but i'm not sure if they'd be
the cause of  what you see in comment 81. what are people's thoughts there?

re: displaying the tab toolbar when there's only one tab. what exactly are the
failure cases there? i'm somewhat inclined to put this in the "edge case"
testing category, since by default we don't display this toolbar with only one
tab (even though there might be bugs here).

Comment 96

[Martin Macok]

When I open new window now, the bookmark sidebar has the focus. I must click in
content to be able to scroll document etc...

See bug 76621.

Comment 97

[sairuh (rarely reading bugmail)]

latest test results with the sidebar open are at
http://hopey.mcom.com/tests/bug37638.txt

i sometimes saw what martin sees wrt focus being stolen by sidebar content.
however, it was either erratic and mac only, or due to case (e) on only win2k.

will look into the "tab toolbar open with only one tab" case in a bit...

Comment 98

[Peter Trudelle]

Don't bother, that is a tiny edge case, and not worth your time right now, IMO.

Comment 99

[sairuh (rarely reading bugmail)]

Comment on attachment 79518 [details]
test cases for this bug

more recent info coming up...

Comment 100

[sairuh (rarely reading bugmail)]

Attachment: test cases, and results as of 18 april

Comment 101

[scottputterman]

adding adt1.0.0+.  Please checkin to the branch as soon as possible and add the
fixed1.0.0 keyword.

Comment 102

[jag (Peter Annema)]

Attachment: Minimal patch for the branch

Comment 103

[Joe Hewitt (gone)]

Comment on attachment 80573 [details] [diff] [review]
Minimal patch for the branch

sr=hewitt

Comment 104

[Samir Gehani]

Comment on attachment 80573 [details] [diff] [review]
Minimal patch for the branch

r=sgehani

Comment 105

[sairuh (rarely reading bugmail)]

the weirdness i saw in gmake builds (comment 82 and comment 87) seems to have
gone away, using 2002.04.25.08-WIN_GMAKE commercial bits on win2k.

Comment 106

[Jaime Rodriguez, Jr.]

When's the minimal patch for the branch going into 1.0? ETA Needed ...

Comment 107

[jag (Peter Annema)]

Tomorrow. I thought I already had a=drivers.

Comment 108

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 80573 [details] [diff] [review]
Minimal patch for the branch

a=[e-mail] for branch checkin.	Finally!!!!!  :-)

Comment 109

[sairuh (rarely reading bugmail)]

jag checked this into the 1.0.0 branch, so marking fixed.

Comment 110

[sairuh (rarely reading bugmail)]

ran through tests (a) and (b) (see comment 89), focus on startup and focus after
opening a new window via accel+N, respectively. i looked at today's branch and
trunk bits on three platforms, and unfortunately focus isn't reliably set in the
content area.

snippet from the test results page at http://hopey.mcom.com/tests/bug37638.txt

branch, 2002.04.29.0x-1.0.0 (no sidebar)
----------------------------------------
* all platforms:

(b) somehow only worked when http://home.netscape.com/ was set as the home page.
oddy, these tests FAILED when a more simple home page (http://mozilla.org/ or
http://kith.org/) --had to hit Tab twice to get focus into the content area.

(a) focus on startup worked erratically, alas. as with (b), it sometimes failed
with simple pages as the home page; however, it didn't fail when
home.netscape.com was used.


trunk, 2002.04.29.0x-trunk (no sidebar)
--------------------------------------
* linux rh7.2 and mac 10.1.4:
like the branch builds: (b) somehow only worked when http://home.netscape.com/
was set as the home page. oddy, these tests FAILED when a more simple home page
(http://mozilla.org/ or http://kith.org/) --had to hit Tab twice to get focus
into the content area.

as with the branch, (a) focus on startup worked erratically, alas. as with (b),
it sometimes failed with simple pages as the home page; however, it didn't fail
when home.netscape.com was used. 

* win2k:
(a) and (b), oddly, worked fine regardless of home page.

Note: home.netscape.com has been a real PITA to test today because am *always*
getting a bunch of popups each time i load that page. not sure if that'd
influence this issue (i close the popups before testing scrolling).

Comment 111

[sairuh (rarely reading bugmail)]

reopening based on comment 110. (had tested with a new profile, fwiw.)

however, cases (c), (d) and (f) pass. (new tab via accel+T, opening link in new
window, and clicking a link, respectively.) case (e) still behaves the same way,
per respective platform. (tested both on branch and trunk.)

Comment 112

[sairuh (rarely reading bugmail)]

okay, this works fine for me using trunk builds from 4/22, 4/25 and 4/27.

just to be sure, i retested using the 4/29 branch and trunk builds. and now
they're somehow working. *sigh* not sure what went on there (thought the new
profiles would simplify things. *shrug*)

okay, re-resolving this. will check with tomorrow's bits for verification.

Comment 113

[sairuh (rarely reading bugmail)]

this is indeed a heisen-bug... with today's branch and trunk bits, sometimes (a)
and (b) work, sometimes they don't.

since i cannot verify this bug reliably, i've filed bug 141295 as a blocker to
this one.

Comment 114

[scottputterman]

removing the adt1.0.0+.  We can work on the remainder of the bug for rtm.  What
are the remaining issues?

Comment 115

[sairuh (rarely reading bugmail)]

remaining issues:

bug 138237: open URL in new tab has bad focus (cases (e)).
bug 141295: focus in content area is erratic.

Comment 116

[Jesse Ruderman]

Bug 139862 wants to reverse this change.

Comment 117

[sairuh (rarely reading bugmail)]

marking this verified...since open issues have separate bugs filed for 'em.