Content steals focus from search field when page finishes loading (while typing in search field)

NEW
Assigned to

Status

10 years ago
8 years ago

People

(Reporter: urankoni, Assigned: murph)

Tracking

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.17) Gecko/20080915 Camino/1.6.4 (like Firefox/2.0.0.17)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.17) Gecko/20080915 Camino/1.6.4 (like Firefox/2.0.0.17)

Opening webpage steals focus from search bar.

Reproducible: Always

Steps to Reproduce:
1.Open camino browser
2.Click on search bar- start typing Mineral Man
3.Browser homepage pops up, and steals focus of search bar


Expected Results:  
Kept focus on search bar

Comment 1

10 years ago
Just so we're clear about what you're seeing, you only see this in the search bar, not the location bar, correct?
(Reporter)

Comment 2

10 years ago
It is only the search field, not the location bar.

Comment 3

10 years ago
I should add that what I see on trunk is the following:

1) Place cursor in search bar.
2) Start typing.
3) Cmd-T.

ER: Focus stays in search bar.

AR: Focus leaves search bar for location field (if no home page is set) or content area (if a home page is set).

We probably ought to protect the search focus the same way we do in the location bar.

Comment 4

10 years ago
Based on comment 2 and comment 3, I'm confirming this. I might have time to look into it soon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: Macintosh → All

Updated

10 years ago
Summary: Stolen focus → Focus moves to location bar (or content area) when opening a new tab while typing in search field
(Assignee)

Comment 5

10 years ago
cl, I think what you describe on comment 3 and the behavior Nicole notices are actually two separate cases.

The issue originally reported was when a page is finished loading, focus is transferred to the browser content as part of this code: http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#1909.  We currently only force focus to remain inside the location bar, but not the search field.  I actually noticed this the other day and thought about the fix approach, so if it's alright I'll take this one.

The second issue is when opening a new tab, focus should remain in the search field.  I think we definitely need to do this too, especially because the user could have started typing a search, realized they wanted to do it in a new tab, and then then have to re-focus their typing.

I think this bug should only be concerned about the first issue, and what you notice is very true but I think that should be a separate report since it's a totally different area of code.
Yeah, let's make this bug just be about the first issue, protecting search field focus during pageload.

The second issue (comment 3) might already be filed, but if not, it should go in a separate bug.
Summary: Focus moves to location bar (or content area) when opening a new tab while typing in search field → Content steals focus from search field when page finishes loading (while typing in search field)
(Assignee)

Updated

10 years ago
Assignee: nobody → murph
(In reply to comment #5)
> cl, I think what you describe on comment 3 and the behavior Nicole notices are
> actually two separate cases.
> 
> The issue originally reported was when a page is finished loading, focus is
> transferred to the browser content as part of this code:
> http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#1909.
>  We currently only force focus to remain inside the location bar, but not the
> search field.  I actually noticed this the other day and thought about the fix
> approach, so if it's alright I'll take this one.

We just need to plumb up similar code to userChangedLocationField for the search field, right?  Get the search string (e.g., http://mxr.mozilla.org/camino/source/camino/src/browser/BrowserWindowController.mm#2861), if it's not empty, set userChangedSearchField to YES, and then check for userChangedSearchField every (applicable) place we currently check for userChangedLocationField?
You need to log in before you can comment on or make changes to this bug.