Closed Bug 175701 Opened 22 years ago Closed 8 months ago

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

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: iezibeij-bugzilla.mozilla.org, Unassigned)

References

Details

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.
See also 90919, "URL bar should not lose focus until (non-error) page starts to load" (for Mozilla rather than Chimera).
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
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.
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. ***
(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
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.