Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110720 Firefox/8.0a1 ID:20110720030844
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110720 Firefox/7.0a2 ID:20110720042003
Content will not be focused after I type URL or TEXT or Keywod & TEXT in LocationBar and click GO button.
*This does not happen if I Press ENTER instead of clicking GO button.
*This does not happen if I middele-mouse-click GO button.
*This does not happen if I Press Alt-ENTER.
*This does not happen if I click a Autocomplete item in pull down popup.
*This does not happen Firefox6.0beta build2 and Firefox5.0.1.
Steps to Reproduce:
1. Start Firefox with clean profile.
2. Open new blank tab.
3. Input http://mozilla.jp/firefox/ in Location Bar.
4. Click GO button.
5. Check focused element. (Push DOWN ARROW key))
Location Bar is still focused.
Content should be focused.
Regression window(cahed m-c hourly):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1 ID:20110523061111
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1 ID:20110523073652
e5663e0e20b3 Gavin Sharp — Bug 658383: ensure that we avoid inheriting the owner principal when clicking the Go button, r=dao
I'm a little bit confused here - the bug doesn't occur in Firefox6.0beta build2, but it regressed between Firefox/6.0a1 ID:20110523061111 and Firefox/6.0a1 ID:20110523073652?
So it existed for 6.0 at some point, but then was fixed there, but wasn't fixed on 7/8? That would be pretty odd.
Created attachment 547208 [details] [diff] [review]
This is the minimal change to restore the previous behavior, but I'd like to simplify this logic. I'll attach an alternate patch.
Created attachment 547211 [details] [diff] [review]
patch with additional cleanup
My understanding is this:
- in this method, content.focus() and selectedBrowser.focus() are effectively the same thing (this method isn't called on background windows)
- for loads in new tabs, we want to focus the content *before the new tab opens* so that focus is on content when returning to the tab that triggered the load
- for other loads in the same tab, we just need to focus the content (before or after doesn't matter)
I think just unconditionally focusing the content before doing anything achieves all of these goals.
Oh, I guess we might also need to focus again afterwards so that the new tab's content is focused?
(In reply to comment #4)
> Oh, I guess we might also need to focus again afterwards so that the new
> tab's content is focused?
If nothing else, updateCurrentBrowser should do that.
Comment on attachment 547211 [details] [diff] [review]
patch with additional cleanup
With e10s, 'content' doesn't exist in the chrome process, and even if it was made to work, it would probably be less efficient, so I think we want gBrowser.selectedBrowser.focus().
Created attachment 547220 [details] [diff] [review]
(In reply to comment #1)
> I'm a little bit confused here - the bug doesn't occur in Firefox6.0beta
> build2, but it regressed between Firefox/6.0a1 ID:20110523061111 and
> Firefox/6.0a1 ID:20110523073652?
> So it existed for 6.0 at some point, but then was fixed there, but wasn't
> fixed on 7/8? That would be pretty odd.
Sorry , My bad.
This also happen on 6.0beta build2.
OK, thanks - that matches my understanding :)
This also affects Firefox 6 and Firefox 7. I'm not sure whether it's worth fixing there, though.
Verified fixed using Firefox 8.0b1