1256710 - Firefox is sometimes sluggish when switching tabs when loading a large web page due to text layout

Status: RESOLVED INCOMPLETE

(Core :: Layout: Text and Fonts, defect)

Description

[Mark Banner (:standard8)]

I keep getting instances where I try to load a page with a large amount of text. 

When doing so, Firefox UI can switch tabs, but it doesn't display the tab content, nor can I switch back to the original tab, and I also can't cancel the tab load.

http://hg.mozilla.org/mozilla-central/rev/556628e979a3
http://hg.mozilla.org/mozilla-central/rev/18cbd790875f

are example urls, though I've had bigger ones which have taken several minutes to load, and I haven't been able to use FF in that time.

This is on the latest nightly builds over the last week or so, with e10s enabled by default.

Comment 1

[ovidiu boca[:Ovidiu]]

User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID 20160323030400

I have tested on Mac OS X 10.10 with FF Nightly 48.0a1 (2016-03-23) and for me the links are loaded in ~15 sec and I can see the tab content after the page is loaded, also I can cancel the tab load if I press 2 times on the "x" close button. 
Mark can you try retest this with the latest build?

Comment 2

[arni2033]

I reported this in bug 1256279.

Comment 4

[arni2033]

You just said that if you press 2 times on close button, it resolves this bug. It does NOT resolve
my bug 1256279. Why are you so sure they're the same?
Why everybody keep duping my bugs to other bugs that were reported later?

Comment 5

[Mark Banner (:standard8)]

(In reply to ovidiu boca[:Ovidiu] from comment #1)
> User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:48.0)
> Gecko/20100101 Firefox/48.0
> Build ID 20160323030400
> 
> I have tested on Mac OS X 10.10 with FF Nightly 48.0a1 (2016-03-23) and for
> me the links are loaded in ~15 sec and I can see the tab content after the
> page is loaded, also I can cancel the tab load if I press 2 times on the "x"
> close button. 

Cancelling isn't the only issue here. Its the fact you can't switch tabs / use other tabs when this happens.

> Mark can you try retest this with the latest build?

I've just had it occur on https://hg.mozilla.org/mozilla-central/rev/02f2f4c75007

I can't give exact steps to repeat, but I started loading the page, and either tried switching tabs or going back or clicking on something else.

In any case, I ended up in the state where the tabs were showing just the spinner and I couldn't do anything in the content area of the tabs. I could interact with the browser chrome - attempting to switch tabs, copy url etc - but the tab content for the other tabs wouldn't not show.

I frequently see the spinner on smaller pages, especially if I load then switch tabs. I also quite often see when that spinner is up, it blocks other tabs from starting actions.

Interestingly, now FF has loaded that page once it was better on a simple reload. A shift-reload still loaded it quicker but still gave me the spinner when attempting to switch tabs.

Comment 6

[ovidiu boca[:Ovidiu]]

I have tested this on Mac OS X 10.10 with FF Nightly 48.0a1 and I can reproduce this, open this page: http://hg.mozilla.org/mozilla-central/rev/18cbd790875f and after this if I open another tabs the contents for this wouldn't not show, but I am able to close the process if I click "X".

Comment 7

[Andrew Overholt [:overholt]]

Previous instances of this type of report were rooted in text layout not be interruptible so I'm moving this bug there.

Comment 8

[Mark Banner (:standard8)]

This is much better now, probably since we switched to true multiple processes. For example, loading https://hg.mozilla.org/mozilla-central/rev/02f2f4c75007, I'm able to switch between tabs, and interact with the content in the tabs that aren't in the same process that is loading the big page.

Tabs that are in the same process, still get the spinner.

Mike, is that "good enough", or should we keep this open for more performance investigations?

Comment 9

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

Glad to hear it's better, but we might want to keep this on file just in case we can find a way to make the text layout work interruptible.

Comment 10

[Andrew McCreight [:mccr8]]

This bug is pretty old. I think if somebody wants to work on this, a new bug is probably for the best.