>>> My Info: Win7_64, Nightly 48, 32bit, ID 20160403030243 STR_1_simplified: 1. Open attachment 8714031 [details] , focus location bar 2. Open new tab (Ctrl+T) 3. Switch back to tab from Step 1 (Ctrl+Shift+Tab), click in <textarea> AR: [screencast] <textarea> is focused for a moment, but then urlbar steals focus ER: Urlbar shouldn't steal focus because of latency STR_1_detailed (146% reliable): 0. Open new window, open 10 tabs with http://www.rp-online.de/ , close other tabs If your PC is super fast, open more tabs with http://www.rp-online.de/ 1. Open attachment 8714031 [details] in a new tab 2. Select all text in <textarea>, then focus location bar in tab from Step 1. 3. Press Ctrl+Shift+Tab 3 times to switch to a tab with http://www.rp-online.de/ 4. Move mouse pointer to the area on the screen where <textarea> was placed in tab from Step 1 5. Hold Ctrl 6. Press Tab key 3 times with pauses of 0.5-1 second, then immediately hold left mouse button over <textarea> (without 'mouseup') 7. (unnecessary) Release left mouse button and Ctrl key. AR: You see the text blink, but then urlbar becomes focused. ER: Urlbar shouldn't steal focus using latency as excuse. <textarea> should stay focused. Notes: 1) See also bug 1252183 - it's a stress-test and e10s doesn't pass it. 2) I can reproduce this bug without any effort, because I usually open 20+ tabs, but Step 0 in STR_1_detailed should make it easy for you too. It's an emulation of real-life loaded browser // In fact, STR_1_detailed are so great that I should be granted a free Firefox account for a year

Michelle, this could be a good bug to try reproducing on the lower-end hardware we bought.

Acknowledge: yes - will proceeded

QA Wanted Update: Could reproduce but not in a consistent manner: Acer Aspire SW3-013 ; Windows 10 x32bit OS; 2GB; (Windows NT 10.0) Nightly Build ID 20160407030234 Windows 7 - more consistent in reproducing but still not every time. Version 48.0a1 Build ID 20160407030234 Update Channel nightly User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0

I checked the new Summary by setting 'click' event listener. Now it seems to me that urlbar is being focused several_times, i.e. sometimes when I switch to tab, urlbar is focused almost instantly, but if I click on page, urlbar looses focus and then gains it again. The delay time depends on how loaded PC is, and on how many tabs/processes I switch in Step 6

(In reply to arni2033 from comment #6) > (Nobody really cared to check this bug, because > nobody cares about quality) I don't really think that's fair to say. The bug has been marked P1, meaning that it's high priority for the team to fix (though not as high priority as some release blockers we're currently working on).

Out of curiosity Gijs, is the URL bar stuff you're working on likely to impact this bug? I suspect not, but thought I'd check.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #8) > Out of curiosity Gijs, is the URL bar stuff you're working on likely to > impact this bug? I suspect not, but thought I'd check. I doubt it... that's more about the contents than about focus, and it's not e10s-specific, whereas at least the summary implies that this bug *is* e10s-specific.

Mike/Gijs - should this be placed in the component Location Bar?

(In reply to Michelle Funches - QA from comment #10) > Mike/Gijs - should this be placed in the component Location Bar? I don't know, it might be a generic focus bug. Neil is more likely to have something useful to say about what causes this issue than either of us, I suspect.

No, this is just because someone can click in the content area faster than the tab switching can keep up.

The async tab switcher can / should probably be modified to check if the focused element has changed since the async tab start, and if so, perhaps bypass focusing the URL bar.

This looks like it got fixed by some of the recent focus fixes. I can repro on 2016-04-07 which is when this bug got filed, but not on a recent nightly. --> wfm.