885287 - [PDF Viewer] Application cannot open large files(30MB).

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::PDF Viewer, defect)

Description

[Leo]

STR:
  1. Open browser and try accessing large PDF file (size ~ 30mb).

Expected:
  PDF viewer will be opened and the File should be displayed properly.

Actual:
  PDF Viewer is opened but the file is not displayed by the application.

Comment 1

[Leo]

This seems like a memory limitation of target.
When tested with a 26MB pdf file, free memory became under 5MB and PDF viewer app's memory usage was up to 190MB.
In this memory status, app can't be running correctly.
I think PDF viewer app's implementation is not optimized with memory.

Jason, Please add your comments.

Comment 2

[Jason Smith [:jsmith]]

Probably the same problem as bug 876906. I agree - it's probably a memory usage issue.

Comment 3

[Leo]

Here the issue raised and the issue marked as duplicate seems to be two different issues. The duplicate issue is about a crash due to OOM.

Here, the issue is when opening files of large size (~30mb), the PDF viewer displays a white page, without any crash.

The pdf file used for testing is http://www.etsi.org/deliver/etsi_ts/151000_151099/15101001/10.03.00_60/ts_15101001v100300p.pdf or search for "ETSI TS 151" in google and open a link. 

Please let know your response.

Comment 4

[Leo]

... please try version V10.03.

Old versions seems to be small files.

Comment 5

[Jason Smith [:jsmith]]

We might want to wait for bug 876906 to land anyways. Brendan is going to update the pdf.js to the latest code available, which may or may not fix this bug. I'll reopen and mark this dependent on bug 876906.

Comment 6

[Leo]

The same problem is present with this document also http://www.etsi.org/deliver/etsi_ts/151000_151099/15101001/04.03.00_60/ts_15101001v040300p.pdf. In this case, the file size is ~14mb.

Comment 8

[Scoobidiver (away)]

(In reply to Jason Smith [:jsmith] from comment #5)
> We might want to wait for bug 876906 to land anyways.
It won't be uplifted to b2g18.

Marking as blocking leo based on bug 899451. Feel free to mark bug 876906 as leo+ instead.

Comment 9

[Kai-Chih Hu [:khu]]

[Triaged on 8/7] Marked qawanted, and let's conclude under what kinds of situation, we will have problems. So far, we are not really cleared to know when we will have this issue.

Comment 10

[Jason Smith [:jsmith]]

(In reply to khu from comment #9)
> [Triaged on 8/7] Marked qawanted, and let's conclude under what kinds of
> situation, we will have problems. So far, we are not really cleared to know
> when we will have this issue.

I think the title actually clarifies that quite well. It's with large PDF files (~30 MB). What I think we need to know instead is what the product requirements are for size of PDFs we need to support.

Comment 11

[Natalya Kot [:nkot]]

Have retested this issue on more recent (8/07) Leo build,
got the following results:

1) 894 KB (bug 876906) - the file loads successfully, the user is able to scroll up/down w/o any issues
http://www.irs.gov/pub/irs-pdf/fw2.pdf 
 
2) 2.17 MB (bug 902088) - the file can be downloaded, it took about 5 min to fully download it, I did not hit, did not try too hard though to repro this bug when scrolling up/down results in exiting the file due to OOM event
http://www.telefonica.com/es/about_telefonica/pdf/informes/2009/Telefonica_IA09_Esp.pdf

3) 14.3 MB (this bug, comment 6) - the bug still reproduces, the PDF viewer displays a white page, without any crash, looks like it is loading but it goes extremely slow, the progress bar shows about 30% after of 10 min being loaded
http://www.etsi.org/deliver/etsi_ts/151000_151099/15101001/04.03.00_60/ts_15101001v040300p.pdf

mclemmons also was helping to test it, 
- got a 5 MB pdf to load successfully
http://www.minotnd.org/pdf/engineering/sanitary%20sewer/24x36_ntrunk.pdf
- tried download of 33 MB PDF and got the white screen for the bug 885287
http://www.minotnd.org/pdf/engineering/sanitary%20sewer/Preliminary%20Engineering%20Report%20Puppy%20Dog%20Sewer%20System.pdf

Build info:
Firmware: v08o
Build ID: 20130807071207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/11bb1b0eefff
Gaia: 60ca81600a080dae33058b0692ecaa213556c926
Platform Version: 18.1

Comment 12

[Wayne Chang [:wchang]]

Triage - Partner will not consider this blocking and will not take this patch. Leaving Moz triage to decide.

Comment 13

[Andrew Overholt [:overholt]]

Without hard product requirements, this seems like not a blocker.

Product, we'd still love to hear about specific requirements here like acceptable PDF size.

Comment 14

[Peter Dolanjski [:pdol]]

It would be nice to support up to a size like 20MB, but I'd like to understand what would be involved in that.  The work involved may not be worth the return.  Any thoughts on what would be required to optimize the PDF viewer for larger file sizes?

Not sure who to NI for pdf viewer.

Comment 15

[Jason Smith [:jsmith]]

Brendan would be a good person to ask.

Comment 16

[Brendan Dahl [:bdahl]]

(In reply to Peter Dolanjski [:pdol] from comment #14)
> Any thoughts on what would be required to optimize the
> PDF viewer for larger file sizes?

There are a number of things we could do, but I don't think there will be one magic bullet. Just loading pdf.js takes up quite a bit of space and then we have the pdf in memory and must decompress the various streams. The biggest gains could probably come from less aggressively caching things in pdf.js.

In general reducing memory use in pdf.js had been tough since firefox doesn't have a great way of profiling memory.

Comment 17

[Nicholas Nethercote [inactive]]

> - tried download of 33 MB PDF and got the white screen for the bug 885287
> http://www.minotnd.org/pdf/engineering/sanitary%20sewer/
> Preliminary%20Engineering%20Report%20Puppy%20Dog%20Sewer%20System.pdf

Please note that different PDF documents use different PDF features, and so comparing random documents isn't always meaningful. For example, this PDF is a scanned document and so is likely to see big improvements from bug 959925.

Comment 18

[Nicholas Nethercote [inactive]]

I'm going to close this, because pdf.js's memory consumption has improved a lot. If you still have problems with particular documents, please open one bug per document -- different documents have different characteristics, and lumping multiple documents into a single bug just leads to confusion. Thanks.