Should return focus to URL bar after a connection timeout or similar failure

NEW
Unassigned

Status

Camino Graveyard
General
--
minor
16 years ago
9 years ago

People

(Reporter: Wincent Colaiuta, Unassigned)

Tracking

unspecified
Future
PowerPC
Mac OS X

Details

(Reporter)

Description

16 years ago
After typing an address into the URL bar, if there is a "connection refused"
error or a "could not be found" error, then after the warning sheet is dimissed
the focus will be in the browser view, not in the URL bar. This is a problem
because it prevents the user from immediately typing a new address, or hitting
return to try again.

Chimera build: 2002101804 nightly.

To reproduce: go to a non-responding site (eg. http://nowhere.org/ is failing
for me right now) or to a site where DNS lookup will fail (eg.
http://nonexistenthost-blah-blah.org.uk/) by typing into the URL bar and
pressing return. Dismiss the warning sheet that appears.

Expected behaviour: focus (cursor) should be in URL bar, where it was
previously. This will enable the user to hit enter to try again, or to correct
the address by typing directly.

Actual behaviour: focus is actually in browser view. In order to try again the
user must click on the URL bar to give it focus. This is particularly
frustrating because it ties in with bug 152987 (cannot press tab to move between
browser view and URL bar).

Additional comments: particularly in the case of the DNS failure this is
annoying, because the warning sheet actually says "check the name and try
again", thus it is explicitly expected that the user will have to be in the URL
bar, yet the user is forced to click the mouse (or press comm-L) to get there.
The user experience would be much smoother if Chimera helped out by anticipating
this need.

The worst case scenario occurs when one of these failures happens in a new (and
blank) tab. In this case the user is left with the focus trapped in a browser
view that is empty and therefore useless.

Comment 1

16 years ago
See also 90919, "URL bar should not lose focus until (non-error) page starts to
load" (for Mozilla rather than Chimera).

Comment 2

16 years ago
Confirmed.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
nice idea, not sure how to trap this case.
Assignee: saari → pinkerton
Target Milestone: --- → Camino1.0

Comment 4

13 years ago
Related to/duplicate of bug 157633?
*** Bug 157633 has been marked as a duplicate of this bug. ***
Some comments copied from the dupe:

Bug 157633 comment 2:

The focus should stay on the location bar until there are actionable items in
the content view (I don't know if the load event is a good approximation of this).

If an alert sheet pops up and grabs the focus, the focus should be returned
after dismissal to where it was before the sheet popped up, i.e.

- the location bar, if the sheet is a direct result of an action performed there

or else

- to the content view, if not empty

Bug 157633 comment 3:

I've noticed that if you start loading a page, then start typing a url in the
location bar, when the page loading finishes the focus is no longer on the
location bar, and you must click back on it to finish typing the url. Could this
be related?


And of course we still have this problem with the error pages and we again (it
was fixed at some point) can't tab between the toolbar and the content area and
vice-versa (bug 152987).
With the error pages, focus is now on the "Try Again" button (although you can't
see it because we have no focus rings on buttons).  That seems OK.  

So I think it's just sheets that are an issue now--the one I can think of is the
https certificate mismatch dialogue, where you can actually cancel page load. 
So there's no content in the page but focus is there instead of the URL bar.
The "site is not a registered protocol" sheet also causes this (when I forget to put my google keyword before 'site:mozilla.org some search term').
I doubt this will make 1.0.

Comment 10

13 years ago
I think this might depend on bug 90919 - not sure though. Probably a Gecko bug?
*** Bug 322660 has been marked as a duplicate of this bug. ***

Comment 12

13 years ago
(In reply to comment #7)
> With the error pages, focus is now on the "Try Again" button (although you
> can't
> see it because we have no focus rings on buttons).  That seems OK.  

Erm, it doesn't seem to be there for me. I have to hit tab twice to get the focus on that button. If I then hit shift-tab twice, I see the Gecko focus ring around the content area.

Has this behaviour changed in the last four months?

cl
(In reply to comment #12)
> (In reply to comment #7)
> > With the error pages, focus is now on the "Try Again" button (although you
> 
> Has this behaviour changed in the last four months?

Yes, it caused some bug/crash in Fx, so it was backed out shortly after I made comment 7.
-> 1.1
Target Milestone: Camino1.0 → Camino1.1
QA Contact: winnie → general
Target Milestone: Camino1.1 → Future
Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".
Assignee: mikepinkerton → nobody
You need to log in before you can comment on or make changes to this bug.