User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171205100345 Steps to reproduce: 1. Create a new profile. 2. Set browser.tabs.remote.warmup.enabled to true in about:config and restart the browser. 3. After the browser starts, open a link in that window. 4. Open a New Private Window and open a link there too. 5. Return to the non-Private Window and open a new tab. 6. Return to the Private Window and open a new link. I had this pref set to true since a long time and this issue first appeared in Build ID 20171204234137. Last good Build was 20171203220339. Unfortunately, I tried to run mozregression, but it was consistently failing to download a build and I wasn't sure how to proceed. The timing points at Bug 1397426 as the culprit. Actual results: In (5), instead of the activity stream, the new tab appeared blank. In (6), the new link seemed to load, the the title of the page appeared in the tab, but instead of the content, a spinning icon was presented. I'm attaching a screenshot for more clarification. Expected results: The new tab should appear normally in (5) and the content of the page should appear normally in (6).

According to bug 1423208 comment 18, this is still reproducible, so I'm de-duping.

Hey tgn-ff, I need some help reproducing this issue locally. When you say "open a link in that window" and "open a link there too" in comment 0, how are you opening these links? From Activity Stream? Or from some external application? Would you be able to post a screen recording of you reproducing the bug? That might be simplest. Thanks!

Hi, A screen recording is probably better.

(In reply to tgn-ff from comment #5) > Created attachment 8942741 [details] > Screen_recording > > Hi, > A screen recording is probably better. Yes, that was super useful, thank you! I can reproduce the issue now.

Hey mystor, Would you feel comfortable reviewing the patch I've posted assuming try comes back green for it? See the commit message for an explanation of what I'm trying to fix here. I'm also open to alternative solutions - this was the simplest thing I could come up with.

I saw this too today and also had it in my profiler. But given that you can reproduce yourself it might not be necessary anymore to add that data.

Not sure if this is the right place (and time), but permaspinners seem to appear way more often when WebRender is enabled. The whole content process seems to freeze with tab warming and WebRender enabled, making all tabs in that process show tabspinners.

That should be something different. I have seen this too two days ago, but haven't had the time to search for an existing bug or file a new one. It clearly happened with tab warming turned off.

(In reply to TMart from comment #10) > appear way more often when WebRender is enabled. The whole content process > seems to freeze with tab warming and WebRender enabled, making all tabs in > that process show tabspinners. Btw. this should simply be bug 1359819, and should also happen with webrender disabled.

Not in my experience. It only happens with WebRender, I don't see tabspinners anymore without. I'll wait then till tab warming is enabled by default and file a bug later, if necessary.

Comment on attachment 8943420 [details] Bug 1423200 - When setting up a new content viewer, if the previous PresShell was active, make the new one active too. https://reviewboard.mozilla.org/r/213740/#review219806 Seems fine to me :-)

Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1765a455cc35 When setting up a new content viewer, if the previous PresShell was active, make the new one active too. r=mystor

Hey tgn-ff, Can you confirm that this addresses the issue for you in the most recent Nightly?

Yes, I can confirm the fix. Thank you!

Thanks!