Opened 6 months ago

Last modified 4 weeks ago

#22788 new defect

PDF.js overloads CPU when opening large PDFs on higher security slider levels

Reported by: teor Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security-slider
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When downloading a large PDF, such as https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf , other tabs failed to render, open, or close correctly.

In particular:

  • tabs would be slow to load,
  • the visible area would be rendered, but scrolling outside the visible area would show white space,
  • reloads of Google Docs when activating JavaScript using NoScript opened new tabs, rather than reloading existing tabs, and
  • closing tabs by clicking the x in the tab header would sometimes work particularly if I held the trackpad down for a while. But a quick click would often fail to close tabs.

I think this is new behaviour in Tor Browser 7.0.1 in high security mode on macOS 10.12.5. (I have done similar things in the 6.0 series, and it was ok.)

This is reproducible in high security mode. The only issues reproducible in low security mode are:

  • tabs would be slow to load,

which I believe to be an expected behabviour when downloading a large file over the same guard connection.

It does not happen in Firefox 54.0.

Child Tickets

Change History (9)

comment:1 Changed 6 months ago by cypherpunks

Isn't this expected since JIT is disabled in those higher security settings? Or should there be a whitelist for anything pdf.js (at least for the Medium security setting)?

I agree with you teor, loading PDFs in those security settings can be annoyingly slow, especially PDFs containing scans of books. Hopefully with FF59esr and their switch to Chromium's PDFium we wont get such problems (although it's written in C++ = memory unsafe).

Last edited 6 months ago by cypherpunks (previous) (diff)

comment:2 in reply to:  1 ; Changed 6 months ago by teor

Replying to cypherpunks:

Isn't this expected since JIT is disabled in those higher security settings? Or should there be a whitelist for anything pdf.js (at least for the Medium security setting)?

No, this seems to happen to *other* tabs only while the PDF is downloading, and not once it's loaded. I don't see why other tabs should be affected in 7.0.1 / multiprocess at all. But it seems worse than the 6.0 series, not better.

I agree with you teor, loading PDFs in those security settings can be annoyingly slow, especially PDFs containing scans of books. Hopefully with FF59esr and their switch to Chromium's PDFium we wont get such problems (although it's written in C++ = memory unsafe).

Could be a while before that happens. And it seems Google has fixed some issues in that code and dependent libraries, but they never find them all.

comment:3 in reply to:  2 ; Changed 5 months ago by gk

Status: newneeds_information

Replying to teor:

Replying to cypherpunks:

Isn't this expected since JIT is disabled in those higher security settings? Or should there be a whitelist for anything pdf.js (at least for the Medium security setting)?

No, this seems to happen to *other* tabs only while the PDF is downloading, and not once it's loaded. I don't see why other tabs should be affected in 7.0.1 / multiprocess at all. But it seems worse than the 6.0 series, not better.

With "downloading" do you mean getting the external helper app dialog and then downloading the file to disk or do you mean just loading the file into your browser over the Internet? Do the two scenarios behave differently for you?

comment:4 in reply to:  3 Changed 5 months ago by teor

Status: needs_informationnew

Replying to gk:

Replying to teor:

Replying to cypherpunks:

Isn't this expected since JIT is disabled in those higher security settings? Or should there be a whitelist for anything pdf.js (at least for the Medium security setting)?

No, this seems to happen to *other* tabs only while the PDF is downloading, and not once it's loaded. I don't see why other tabs should be affected in 7.0.1 / multiprocess at all. But it seems worse than the 6.0 series, not better.

With "downloading" do you mean getting the external helper app dialog and then downloading the file to disk or do you mean just loading the file into your browser over the Internet? Do the two scenarios behave differently for you?

Yes. I only see the issue when loading the file into the embedded PDF viewer.

comment:5 in reply to:  2 Changed 5 months ago by gk

Keywords: tbb-security-slider added
Summary: Tor Browser rendering hangs when downloading large PDFsTor Browser rendering hangs when downloading large PDFs on higher security slider levels

Replying to teor:

Replying to cypherpunks:

Isn't this expected since JIT is disabled in those higher security settings? Or should there be a whitelist for anything pdf.js (at least for the Medium security setting)?

No, this seems to happen to *other* tabs only while the PDF is downloading, and not once it's loaded. I don't see why other tabs should be affected in 7.0.1 / multiprocess at all. But it seems worse than the 6.0 series, not better.

I think the cypherpunk is right in pointing to the JIT prefs. The PDF is not just download but the rendering is already starting once chunks of the pdf are available. And other tabs should be affected as the PDF viewer is basically blocking the web content process and in ESR 52 there are only two processes a chrome and a content one (e10s multi is not available in that series). And it is much worse than in the 6.x series because we had a bug in that which did not disable JIT despite what it claimed (see #21865).

I guess we could think about exempting the PDF viewer from the JIT restrictions.

comment:6 Changed 2 months ago by teor

I can confirm that this happens even if the tor process is no longer downloading PDFs.
In fact, it still happens even after the tabs containing the PDFs have been closed!

To reproduce:

  1. Go to http://www.mitsubishielectric.com.au/Air_Conditioning_User_Manuals.html
  2. Open a few of the PDFs (I tried about 10)
  3. Wait for some to load and start to render
  4. Close their tabs
  5. Try to open another site

It took a long time for the tabs and window to close, and I couldn't open any other sites, even after tor had stopped downloading anything. I had to restart the browser.

comment:7 Changed 2 months ago by cypherpunks

Summary: Tor Browser rendering hangs when downloading large PDFs on higher security slider levelsPDF.js overloads CPU when opening large PDFs on higher security slider levels

I had to restart the browser.

No, you hadn't. It's not a hang. You can wait until your tasks complete :) Enjoy the JIT-less world!

As mentioned above, it'll be replaced in ESR59 because of many issues, including

Warning: AcroForm/XFA is not supported  viewer.js:7221
Warning: Unimplemented widget field type "Btn", falling back to base field type. pdf.worker.js:3830

comment:8 Changed 7 weeks ago by cypherpunks

This is not an issue with JIT simply being too slow, or at least that's not the only issue. Extremely javascript-heavy webpages that are nearly unusable without JIT still do not result in this behavior, and it only applies to some PDF files, even ones which do not seem particularly complicated. Likewise, for PDF files which do not trigger this hang, the lack of JIT simply makes them render more slowly. As gk mentioned, the PDF viewer is blocking the web content process. My guess is that some behavior changed which results in some element in the file taking up way more CPU than it needs to, resulting in even simple PDF files hanging the process.

I would eat my hat if this were merely a case of "this is slow for big PDFs because no JIT".

comment:9 Changed 4 weeks ago by cypherpunks

According to Dave Townsend, there are no "plans to integrate PDFium at this point", so unless there's a big surprise FF59 will still be stuck with pdfjs :(

Note: See TracTickets for help on using tickets.