Closed Bug 509298 Opened 12 years ago Closed 12 years ago

updateCurrentBrowser leaves focus in location bar if no specific element is focused in that browser

Categories

(Firefox :: Tabbed Browser, defect, P2)

3.6 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 3.7a1
Tracking Status
status1.9.2 --- beta2-fixed

People

(Reporter: dao, Assigned: dao)

References

Details

(Keywords: regression, verified1.9.2)

Attachments

(1 file, 2 obsolete files)

STR:
1. In tab A, verify that the content area but *no* specific element (e.g. input field or hyperlink) is focused. Pressing Up/Down should scroll the page.
2. select tab B
3. focus the location bar
4. select tab A

Expected result:
content area has focus

Actual result:
location bar has focus
This is correct behaviour, as determined by a ui review from beltzner while implementing bug 178324. The comment at the end of updateCurrentBrowser specifically points this case out.
I've read that comment, but it seems to be designed for different use case (the find bar?). The behavior described in comment 0 seems unintuitive and unhelpful. Why would the user want to interact with the location bar just because he did in a different tab? If there is such a use case, why the distinction between a focused content element and no focused content element?
If there was something focused in the other page, then it seems reasonable to have it refocused when switching to it. If there wasn't something focused though, yet the user had intentionally moved the focus to the location bar, it seems more reasonable that the user doesn't want to focus to switch arbitrarily just because they went to a different tab.

There were various reasons (use cases) around why this was done, and you'd have to ask Mike about it.
(In reply to comment #3)
> If there was something focused in the other page, then it seems reasonable to
> have it refocused when switching to it. If there wasn't something focused
> though,

I would consider the document itself "something". I always find it annoying when the up/down/page-up/page-down keys suddenly stop functioning, similar to how I would find it annoying if a specific input element lost focus.

> yet the user had intentionally moved the focus to the location bar, it
> seems more reasonable that the user doesn't want to focus to switch arbitrarily
> just because they went to a different tab.

The location bar is a tab-specific control, so the fact that they went to a different tab seems very relevant to me.
Flags: blocking-firefox3.6?
Keywords: uiwanted
Version: Trunk → 3.6 Branch
Another effect of this bug seems to be that entering a url and pressing enter leaves the focus in the urlbar. This causes things like FAYT to not work until you unfocus the urlbar by pressing Esc or clicking in page. With the focus still in urlbar, characters end up at the end of the urlbar, instead of in the findbar.
So does it mean this behavior effectively brings back bug 469139?
Only in some cases. For instance, if you load two pages, hit Ctrl+L, Ctrl+C and Ctrl+W, focus will remain in the location bar rather than letting you immediately interact with the first page.
I don't necessarily think leaving focus in the findbar is useful, but leaving the findbar around unfocused also seems wrong, so maybe we should close it.

Is fm.setFocus(newBrowser, fm.FLAG_NOSCROLL) cheaper than newBrowser.focus()? Otherwise I see no reason to use the former.
Assignee: nobody → dao
Attachment #397561 - Flags: ui-review?(beltzner)
Attachment #397561 - Flags: review?(enndeakin)
Note that before bug 178324, we would restore focus in the location bar if it was previously there for a specific tab. I'm not sure how to restore that behavior. :(
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Blocks: 524813
Comment on attachment 397561 [details] [diff] [review]
focus the browser unless the findbar is focused

This seems right to me; if the "page" was focused (for keyboard scrolling) then we should maintain that focus. Sorry if my comment in the earlier bug was misleading.
Attachment #397561 - Flags: ui-review?(beltzner) → ui-review+
Comment on attachment 397561 [details] [diff] [review]
focus the browser unless the findbar is focused

OK, we'll see.
Attachment #397561 - Flags: review?(enndeakin) → review+
Keywords: uiwanted
Attached patch updated to trunk (obsolete) — Splinter Review
Attachment #397561 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/ea9fed00597c
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
Attached patch landed patchSplinter Review
Attachment #409190 - Attachment is obsolete: true
Attachment #409458 - Flags: approval1.9.2?
The patch on this bug will fix bug 524813 too which is marked as blocker3.6. That means we should reconsider the decision here.
Flags: blocking-firefox3.6- → blocking-firefox3.6?
Verfied fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091101 Minefield/3.7a1pre ID:20091101031119

Regarding the issue here and in bug 524813 it would be great to have an automated test.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-testsuite? → in-testsuite+
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Priority: -- → P2
Attachment #409458 - Flags: approval1.9.2?
Curious, any particular reason for not just restoring focus to whatever the tab had focused before switching away from the tab?

As we move to a "tab on top" model, I would expect anything that you can focus for a particular tab (page inputs, the document, location bar, find bar) to keep focus when switching to/away from a tab.
(In reply to comment #18)
> Curious, any particular reason for not just restoring focus to whatever the tab
> had focused before switching away from the tab?

Looking at attachment 382498 [details] [diff] [review], updateCurrentBrowser did this by setting focusedElement and focusedWindow on the browser elements. I'm not sure how much it would take to restore this. In any case, feel free to file a new bug.
Verified fixed on 1.9.2 with builds on OS X and Windows like: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre ID:20091106033745

(In reply to comment #9)
> Note that before bug 178324, we would restore focus in the location bar if it
> was previously there for a specific tab. I'm not sure how to restore that
> behavior. :(

Do we have already a bug filed on that issue?
Keywords: verified1.9.2
Depends on: 536576
(In reply to comment #20)
> > Note that before bug 178324, we would restore focus in the location bar if it
> > was previously there for a specific tab. I'm not sure how to restore that
> > behavior. :(
> 
> Do we have already a bug filed on that issue?

Looks like this is bug 536576 now.
You need to log in before you can comment on or make changes to this bug.