Closed Bug 885287 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED WORKSFORME
blocking-b2g -

People

(Reporter: leo.bugzilla.gaia, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [TD-47901] [leo-triage])

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.
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.
Flags: needinfo?(jsmith)
Whiteboard: [TD-47901]
Probably the same problem as bug 876906. I agree - it's probably a memory usage issue.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jsmith)
Resolution: --- → DUPLICATE
Duplicate of bug: 876906
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.
Flags: needinfo?(jsmith)
... please try version V10.03.

Old versions seems to be small files.
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.
Status: RESOLVED → REOPENED
Depends on: 876906
Flags: needinfo?(jsmith)
Resolution: DUPLICATE → ---
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.
Duplicate of this bug: 900798
Blocks: 899451
(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.
blocking-b2g: --- → leo?
[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.
Keywords: qawanted
(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.
Flags: needinfo?(ffos-product)
QA Contact: sparsons
Blocks: 902088
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
Keywords: qawanted
Triage - Partner will not consider this blocking and will not take this patch. Leaving Moz triage to decide.
Whiteboard: [TD-47901] → [TD-47901] [leo-triage]
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.
blocking-b2g: leo? → -
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.
Flags: needinfo?(ffos-product) → needinfo?
Brendan would be a good person to ask.
Flags: needinfo?
Flags: needinfo?(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.
Flags: needinfo?(bdahl)
> - 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.
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.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.