Build Identifier: http://hg.mozilla.org/mozilla-central/rev/953f9620f395 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110720 Firefox/8.0a1 ID:20110720030844 http://hg.mozilla.org/releases/mozilla-aurora/rev/579cbf7a9add 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. Reproducible: Always 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)) Actual Results: Location Bar is still focused. Expected Results: Content should be focused. Regression window(cahed m-c hourly): Works: http://hg.mozilla.org/mozilla-central/rev/d04cae0f5d22 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1 ID:20110523061111 Fails: http://hg.mozilla.org/mozilla-central/rev/0ad1aae1c559 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1 ID:20110523073652 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d04cae0f5d22&tochange=0ad1aae1c559 Suspected: 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] patch 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] comments addressed
(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