Perma-orange: browser_bug{455852,520538}.js location bar is focused for the new tab

[Mardak]

Also see Bugzilla/PR https://bugzilla.mozilla.org/show_bug.cgi?id=1374768

These similar tests have been consistently failing:

TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug455852.js | location bar is focused for the new tab - Got [object XULElement], expected [object HTMLInputElement] 

https://treeherder.mozilla.org/logviewer.html#?job_id=106084575&repo=pine&lineNumber=3619

TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug520538.js | '--new-tab about:blank' focuses the location bar - Got [object XULElement], expected [object HTMLInputElement]

https://treeherder.mozilla.org/logviewer.html#?job_id=106084575&repo=pine&lineNumber=4152

[Mardak]

Bisected this regression to mconley's fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1367596
https://hg.mozilla.org/mozilla-central/rev/fb99ac0fe4e3

The [object XULElement] that has focus seems to be the xul:browser instead of the location bar on closing the last tab of the window when browser.tabs.closeWindowWithLastTab is false.

[dmose]

@Mardak I'm not seeing this failure locally at all. Is there anything specific you needed to do to reproduce it?

[dmose]

Never mind; I see now that this is Linux-only failure. Installing VM...

[dmose]

And looking more closely at pine, I see that it is failing on OS X debug too. Hmmm...

[Mardak]

Yeah, the latest pine push has it failing on mac as well. I'm trying to see what I did before when bisecting. Pretty sure I needed to run the two tests together as one would set up the focus and the second would maintain the broken focus (instead of moving).

https://treeherder.mozilla.org/logviewer.html#?job_id=108589851&repo=pine&lineNumber=5429

./mach mochitest --setpref browser.newtabpage.activity-stream.enabled=true browser/base/content/test/general/browser_bug{455852,520538}.js

However, that isn't failing for me right now…

[Mardak]

Aha! This is what I actually used. It happens to pull in one other test that moves focus before the 455852 test runs and fails.

./mach mochitest --setpref browser.newtabpage.activity-stream.enabled=true browser/base/content/test/general/browser_bug4*2.js

[Mardak]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374768

[Mardak]

Notes from mconley about the regressing change:

So this is part of a tab switch optimization where we feel like in certain cases, it's appropriate / acceptable to switch to out-of-process browsers synchronously, and show a blank white content area.
The typical example being a tab that has just opened and started (but not yet finished) loading a thing
It is possible, however, to load a tab in the background, wait for a while before seeing it, having it finish loading, and then switching to it. I do that all of the time when browsing r/aww on Reddit. Just a ton of cute animal GIFs and images in background tabs waiting for me.
In those cases, we judge in a very rough way that a tab has "sufficiently loaded" when the throbber is no longer being displayed for it at that point, the tab switcher decides that we can't take the "blank" shortcut I described earlier, and does an async tab switch, to avoid a flash of white

If shouldBeBlank is false, then yes, we'll attempt an asynchronous tab switch

add a new method to tabbrowser that takes in a URI and says whether or not it's something that'd show progress
so both mTabProgressListener and the async tab switcher can call it
then inside updateDisplay, have it pass the URI and use that to determine if we're "sufficiently loaded"

[Mardak]

Will need to be addressed later now that content process is being backed out in #2756 but will need to be fixed to turn it back on for #2777.

[Mardak]

https://hg.mozilla.org/mozilla-central/rev/8c55a7d1e55c
https://bugzilla.mozilla.org/show_bug.cgi?id=1374768