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

NEW
Unassigned

Status

()

Core
DOM: Content Processes
a year ago
a year ago

People

(Reporter: Clemens Eisserer, Unassigned)

Tracking

(Blocks: 1 bug)

48 Branch
Points:
---

Firefox Tracking Flags

(e10s-, firefox48 wontfix, firefox49 affected, firefox50 affected, firefox51 affected)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

a year ago
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.
tracking-e10s: --- → ?
pdfium conversion should address this.
Blocks: 1049218
tracking-e10s: ? → -
(Reporter)

Comment 2

a year ago
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.
(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
(Reporter)

Updated

a year ago
(Reporter)

Comment 4

a year ago
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.
Created attachment 8788512 [details]
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.
Status: UNCONFIRMED → NEW
status-firefox48: --- → wontfix
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
Component: Untriaged → DOM: Content Processes
Ever confirmed: true
Product: Firefox → Core
Version: 49 Branch → 48 Branch
You need to log in before you can comment on or make changes to this bug.