1293345 - Busy pdf.js tab can block rendering of other tabs for dozens of seconds [e10s]

Status: NEW

(Core :: DOM: Content Processes, defect)

Description

[Clemens Eisserer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160802125802

Steps to reproduce:

1. Openend the following PDF: http://de.free.aero/contents/Saison2016-D-300.pdf
2. Clicked some link in the PDF, and rpessed the back-button
3. While PDF.js was loading the pdf again, I tried to switch to other tabs


Actual results:

The rendering of the other tabs was blocked for several seconds (> 15s), instead only a white page was shown.

This behaviour was observerd even with E10S / multi-process enabled.

I captured the behaviour in the following screencast: https://youtu.be/KX_FqTK0fhw


Expected results:

There should be no noticeable delay caused on other, not content loading tabs, especially with e10s enabled.

Comment 1

[Jim Mathies [:jimm]]

pdfium conversion should address this.

Comment 2

[Clemens Eisserer]

It might hide exactly this sympthom, however pdf.js is just regular javascript code.
As I saw this behaviour also with other websites/applications (although far not that pronounced), the question is how one tab can stall all others for such an eternety - especially with e10s enabled.

Comment 3

[Jim Mathies [:jimm]]

(In reply to Clemens Eisserer from comment #2)
> It might hide exactly this sympthom, however pdf.js is just regular
> javascript code.
> As I saw this behaviour also with other websites/applications (although far
> not that pronounced), the question is how one tab can stall all others for
> such an eternety - especially with e10s enabled.

If the js in one tab janks, all tabs jank because we currently only support one content process for all tabs. The e10s multi project [1] is currently working on expanding the number of processes. You can experiment around with it by upping the processCount pref.

[1] https://wiki.mozilla.org/Electrolysis/Multiple_content_processes

Comment 4

[Clemens Eisserer]

I upped the "processCount"-pref to 4, yet the issue is still reproduceable.

With processCount=4 some tabs stay responsive, while others are still blocked by the busy pdf.js instance. It is almost if the assignment WebWorker-Process <---> Tab is static. So while some Tabs are lucky and get an idle WebWorker, others are statically assigned the WebWorker currently blocked by pdf.js.

Comment 5

[Simona Badau, Desktop QA]

Attachment: e10s.mp4

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0

I can confirm this issue also. 

The steps I used are:
1. Launch Firefox
2. In a new tab, navigate to CNN and read several articles
3. In 3 new different tabs - navigate to some websites of your choice (wait for them to completely load)
4. Go back to CNN and click on the Back button
5. Switch to the tabs opened in step 3 

Actual results: 
In step 5 - white content is displayed for a couple of seconds - please see the attached screen cast for more details.
Reproduced on Firefox 48 and Nightly 51 with e10s enabled. Not reproducible if e10s is disabled.

(In reply to Jim Mathies [:jimm] from comment #1)
> pdfium conversion should address this.
Also Jim, as you notice in my above steps, I didn't used a PDF, just normal pages. Even if the problem is less visible without using such a big content as a PDF page would contain, the problem is still visible.

Comment 6

[Jens Stutte [:jstutte]]

Hi Simona, would you mind checking this again with a current version? I'd assume that with Fission and up to 4 processes per domain we will see quite some improvement here.

Comment 7

[Simona Badau, Desktop QA]

(In reply to Jens Stutte [:jstutte] from comment #6)

Hi Simona, would you mind checking this again with a current version? I'd assume that with Fission and up to 4 processes per domain we will see quite some improvement here.

I can no longer see this issue, tried on the latest Nightly 100.0a1 and on Firefox 98.0.2 on Windows 10 x64.