1262670 - [e10s] chrome (e.g. Location bar) steals focus when I switch to tab and click on web page content and vice versa

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect, P1)

Description

[arni2033]

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

Comment 1

[arni2033]

Attachment: screencast 1 (bug 1262670) - [e10s] Location bar (urlbar) steals focus.webm

Comment 2

[Ryan VanderMeulen [:RyanVM]]

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

Comment 3

[Michelle Funches - QA]

Acknowledge: yes - will proceeded

Comment 4

[Michelle Funches - QA]

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

Comment 5

[arni2033]

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

Comment 6

[arni2033]

Also happens with Findbar. (Nobody really cared to check this bug, because nobody cares about quality)

Comment 7

[Mike Conley (:mconley) (:⚙️)]

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

Comment 8

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 9

[:Gijs (he/him)]

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

Comment 10

[Michelle Funches - QA]

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

Comment 11

[:Gijs (he/him)]

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

Comment 12

[Neil Deakin]

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

Comment 13

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 14

[arni2033]

(In reply to Mike Conley (:mconley) - PTO until Jan 3 from comment #7)
> (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

Do you agree now, after this bug was ignored for SEVEN MONTHS?
So you don't fix it, it's OK, but you don't need to lie at least. Why people in Mozilla just can't say they don't care about some real bugs, and ignore them in favor of "improvements" like bug 1219794?
Please don't pretend about your goals, it only brings more confusion.

Comment 16

[:Gijs (he/him)]

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.