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

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Dão Gottwald [:dao]]

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

Comment 1

[Neil Deakin]

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.

Comment 2

[Dão Gottwald [:dao]]

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?

Comment 3

[Neil Deakin]

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.

Comment 4

[Dão Gottwald [:dao]]

(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.

Comment 5

[7842.9]

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.

Comment 6

[kmike]

So does it mean this behavior effectively brings back bug 469139?

Comment 7

[Dão Gottwald [:dao]]

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.

Comment 8

[Dão Gottwald [:dao]]

Attachment: focus the browser unless the findbar is focused

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.

Comment 9

[Dão Gottwald [:dao]]

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. :(

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 11

[Neil Deakin]

Comment on attachment 397561 [details] [diff] [review]
focus the browser unless the findbar is focused

OK, we'll see.

Comment 12

[Dão Gottwald [:dao]]

Attachment: updated to trunk

Comment 13

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/ea9fed00597c

Comment 14

[Dão Gottwald [:dao]]

Attachment: landed patch

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+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.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 17

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c740102130a7

Comment 18

[Ed Lee :Mardak]

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.

Comment 19

[Dão Gottwald [:dao]]

(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.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.