Closed
Bug 37638
Opened 25 years ago
Closed 23 years ago
URL bar is given focus by default in new window [via accel+N or File > New Navigator Window]
Categories
(SeaMonkey :: Location Bar, defect, P3)
SeaMonkey
Location Bar
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: cks+mozilla, Assigned: jag+mozilla)
References
(Blocks 2 open bugs)
Details
(Keywords: access, polish, testcase, Whiteboard: [adt2 RTM] suntrak-n6 [ETA 04/26])
Attachments
(3 files, 3 obsolete files)
(deleted),
patch
|
bryner
:
review+
hewitt
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
samir_bugzilla
:
review+
hewitt
:
superreview+
jesup
:
approval+
|
Details | Diff | Splinter Review |
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•25 years ago
|
||
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•25 years ago
|
||
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?
Assignee: beppe → brade
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 3•25 years ago
|
||
Tab on Unix (Linux) doesn't change the focus; you must manually click
somewhere in the page body.
Updated•25 years ago
|
Target Milestone: --- → M17
Comment 4•25 years ago
|
||
ok; I'll fix this by backing out my change after we get editors to always be
instantiated (so D&D etc. work too)
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Comment 5•24 years ago
|
||
low priority polish issue, the first page that gets loaded has the url as
the focus, easy workaround is to tab to body.
Keywords: polish
Target Milestone: M17 → M19
Comment 6•24 years ago
|
||
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 "".
Assignee: brade → ben
Status: ASSIGNED → NEW
Component: Editor → XP Apps: GUI Features
QA Contact: sujay → sairuh
Updated•24 years ago
|
QA Contact: sairuh → claudius
Comment 9•24 years ago
|
||
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•24 years ago
|
||
>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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
*** Bug 58832 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
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•24 years ago
|
||
Worksforme with 022605 mozilla linux build on new loaded link and on back.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 24•24 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 25•24 years ago
|
||
The open in new window case will be fixed by 53549, which I'm about to checkin.
Comment 26•24 years ago
|
||
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•24 years ago
|
||
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
Updated•24 years ago
|
Component: XP Apps: GUI Features → URL Bar
Comment 28•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
*** Bug 82755 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
*** Bug 85285 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
although this is a urlbar bug it's really more about focus and keyboardnav
so I'm tossing the QA over to sairuh.
QA Contact: claudius → sairuh
Comment 39•23 years ago
|
||
I am seeing what rburdick@home.com 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•23 years ago
|
||
slice: you're hitting bug 76621, sidebar elements should not grab focus from
other parts of window.
Comment 41•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
reassign url bar bugs to new owner..
Assignee: alecf → blakeross
QA Contact: sairuh → claudius
Comment 44•23 years ago
|
||
See also bug 102598, ctrl+t should focus location bar in newly opened tab.
Comment 45•23 years ago
|
||
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.
Keywords: qawanted → mozilla0.9.6
QA Contact: claudius → sairuh
Summary: URL bar is given focus by default → URL bar is given focus by default in new window [via accel+N or File > New Navigator Window]
Comment 46•23 years ago
|
||
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•23 years ago
|
||
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Comment 48•23 years ago
|
||
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•23 years ago
|
||
This bug is missing the 4xp keyword.
Marcos.
Comment 50•23 years ago
|
||
*** Bug 119519 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
only the "Open in New Window" part doesn't work for me, Mac OS X 2002020418 build.
Comment 52•23 years ago
|
||
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•23 years ago
|
||
Comment 54•23 years ago
|
||
Comment on attachment 71997 [details] [diff] [review]
patch
r=bryner
Attachment #71997 -
Flags: review+
Comment 55•23 years ago
|
||
*** Bug 103758 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Whiteboard: suntrak-n6 → suntrak-n6[adt3]
Comment 56•23 years ago
|
||
*** Bug 130586 has been marked as a duplicate of this bug. ***
Comment 57•23 years ago
|
||
jag can't get enough of these bugs!
Assignee: hewitt → jaggernaut
Status: ASSIGNED → NEW
Component: URL Bar → XSLT
this ended up in the wrong component somehow
Component: XSLT → URL Bar
Comment 59•23 years ago
|
||
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•23 years ago
|
||
shouldn't affect this...
Updated•23 years ago
|
Assignee | ||
Comment 61•23 years ago
|
||
Attachment #71997 -
Attachment is obsolete: true
Comment 62•23 years ago
|
||
Comment on attachment 77775 [details] [diff] [review]
Updated to trunk
r=bryner
Attachment #77775 -
Flags: review+
Comment 63•23 years ago
|
||
*** Bug 136473 has been marked as a duplicate of this bug. ***
Comment 64•23 years ago
|
||
(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•23 years ago
|
||
see comment #52
Comment 66•23 years ago
|
||
*** Bug 136573 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 67•23 years ago
|
||
Attachment #77775 -
Attachment is obsolete: true
Comment 68•23 years ago
|
||
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
Attachment #78644 -
Flags: review+
Comment 69•23 years ago
|
||
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
Attachment #78644 -
Flags: superreview+
Comment 70•23 years ago
|
||
Changing to [ADT2 RTM]. Removing adt1.0.0. Pls check this into the trunk. Let's
look at resolve this one after beta.
Whiteboard: suntrak-n6[adt3] → suntrak-n6[adt2 RTM]
Comment 71•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
>I was having problems where I couldn't scroll documents from the keyboard.
That might be bug 135851.
Comment 75•23 years ago
|
||
We still feel that it is better to consider this for RTM
Whiteboard: suntrak-n6[adt2 RTM] → suntrak-n6 [adt2 RTM]
Comment 76•23 years ago
|
||
My question is: Why?
Assignee | ||
Comment 77•23 years ago
|
||
Note: this was checked into the trunk on the 10th. Bug is still open for
potential landing on the branch.
Updated•23 years ago
|
Keywords: mozilla1.0
Comment 78•23 years ago
|
||
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•23 years ago
|
||
what are the results of testing on the trunk with this fix?
Comment 80•23 years ago
|
||
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•23 years ago
|
||
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?
Keywords: qawanted
Comment 82•23 years ago
|
||
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.
Keywords: qawanted
Comment 83•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
Keywords: qawanted
Comment 87•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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).
Keywords: qawanted
Comment 90•23 years ago
|
||
Comment 91•23 years ago
|
||
forgot to mention: test results are at the end of attachment 79518 [details].
Comment 92•23 years ago
|
||
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.
Assignee | ||
Comment 93•23 years ago
|
||
(e) is a different bug.
Trudelle, what problems are you seeing?
Comment 94•23 years ago
|
||
see comment #81. What bug # is (e)?
Comment 95•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Don't bother, that is a tiny edge case, and not worth your time right now, IMO.
Comment 99•23 years ago
|
||
Comment on attachment 79518 [details]
test cases for this bug
more recent info coming up...
Attachment #79518 -
Attachment is obsolete: true
Comment 100•23 years ago
|
||
Updated•23 years ago
|
Updated•23 years ago
|
Whiteboard: suntrak-n6 [adt2 RTM] → [adt2 RTM] suntrak-n6
Comment 101•23 years ago
|
||
adding adt1.0.0+. Please checkin to the branch as soon as possible and add the
fixed1.0.0 keyword.
Assignee | ||
Comment 102•23 years ago
|
||
Comment 103•23 years ago
|
||
Comment on attachment 80573 [details] [diff] [review]
Minimal patch for the branch
sr=hewitt
Attachment #80573 -
Flags: superreview+
Comment 104•23 years ago
|
||
Comment on attachment 80573 [details] [diff] [review]
Minimal patch for the branch
r=sgehani
Attachment #80573 -
Flags: review+
Comment 105•23 years ago
|
||
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•23 years ago
|
||
When's the minimal patch for the branch going into 1.0? ETA Needed ...
Whiteboard: [adt2 RTM] suntrak-n6 → [adt2 RTM] suntrak-n6 [ETA Needed]
Assignee | ||
Comment 107•23 years ago
|
||
Tomorrow. I thought I already had a=drivers.
Assignee | ||
Updated•23 years ago
|
Whiteboard: [adt2 RTM] suntrak-n6 [ETA Needed] → [adt2 RTM] suntrak-n6 [ETA 04/26]
Comment 108•23 years ago
|
||
Comment on attachment 80573 [details] [diff] [review]
Minimal patch for the branch
a=rjesup@wgate.com for branch checkin. Finally!!!!! :-)
Attachment #80573 -
Flags: approval+
Comment 109•23 years ago
|
||
jag checked this into the 1.0.0 branch, so marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 110•23 years ago
|
||
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•23 years ago
|
||
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.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 112•23 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 113•23 years ago
|
||
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.
Depends on: 141295
Comment 114•23 years ago
|
||
removing the adt1.0.0+. We can work on the remainder of the bug for rtm. What
are the remaining issues?
Keywords: adt1.0.0+
Comment 115•23 years ago
|
||
remaining issues:
bug 138237: open URL in new tab has bad focus (cases (e)).
bug 141295: focus in content area is erratic.
Blocks: 138237
Comment 116•23 years ago
|
||
Bug 139862 wants to reverse this change.
Comment 117•22 years ago
|
||
marking this verified...since open issues have separate bugs filed for 'em.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•