[B2G][PDF][PDF viewer]: PDF file crashes when zoom in or zoom out

RESOLVED FIXED in Firefox OS v1.2

Status

Firefox OS
Gaia::PDF Viewer
P1
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: sarsenyev, Assigned: bdahl)

Tracking

(Blocks: 1 bug, {perf})

unspecified
1.2 C4(Nov8)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:koi+, b2g18+ wontfix, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.2 fixed)

Details

(Whiteboard: [c=memory p= s= u=1.2] [MemShrink:P2] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
When you are trying to zoom in PDF file, you’re tapping “+” button until the PDF file crashes and brings back to the browser.

Repro Steps:
1) Updated to Unagi Build ID: 20130225070200 
2) From "Home Screen" go to "Browser"
3) Go to http://apps.irs.gov/app/picklist/list/formsInstructions.html
4) Select the PDF File to open it in “PDF Viewer”
5) Using the Magnifying Glass with the "+" zoom in on the PDF File in  increments until fully zoomed in

Expected:
PDF file is fully zoomed in

Actual:
PDF file is crashes

Repro frequency:
(5/5, 100%, on 2 devices)

Environmental  Variables:
Unagi Build ID: 20130225070200
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/effe37a77f18
Gaia: bb633c6f2deb829b2f3d5b9e7bac7fa24467d02a

Notes:
UCID: suite-pdfviewer-006
https://moztrap.mozilla.org/runtests/run/859/env/305/?pagenumber=1&pagesize=20&sortfield=order&sortdirection=asc&filter-id=4929
Q Analysts Test Team Priority Rating: Pri 2
This issue occurs in the landscape and portrait views.

Updated

5 years ago
Severity: normal → critical
blocking-b2g: --- → tef?
Keywords: crash
Whiteboard: [b2g-crash]
Given that up to 99% zoom seems to work without crashing can we put in a temporary fix to fake out the 100% by capping it at 95%? Would take an uplift to v1.0.1 with that fix if tested and working and can look for a full fix in later versions.
Assignee: nobody → bdahl
blocking-b2g: tef? → tef+
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → wontfix
FWIW I can't reproduce this with a 2013-02-18 build (build ID 20130219070200, git commit edaca00b1eb) on Unagi (somehow I'm on the beta channel now).

Comment 3

5 years ago
revertNightly.sh from tchung is required after flashing to get Nightly channel.

Issue should repro after flashing build 20130225070200 and applying revertNightly.sh
Is this possibly related to Bug 803568?  The fix for that, a simple nullptr check never made it into B2G, I think.
(Assignee)

Comment 5

5 years ago
Created attachment 719115 [details]
log output

I've attached the log output during the crash.  Seems we're running out of memory, though I'm not sure what all is relevant here.

Capping the zoom at 100% won't work for all pdfs since they can be an arbitrary size.  We could try to cap at a certain canvas size, but I'm not really sure what this limit should be.  I could attempt to find it by trial and error but I'd rather get some feedback on a sane limit from someone who knows more about the limits.
Hard to get a sane limit, when faxes are coming in at 8k+ in size.  I don't have the up to date phone - can somebody try just loading http://www.primariahd.ro/fisiere/module_fisiere/4191/Dispoz%20ordinara%20SEPTEMBRIE.pdf and see what happens?

Comment 7

5 years ago
We discussed in triage, this only occurs when zooming down to the "3-character level". Not a common user scenario, not a blocker.
blocking-b2g: tef+ → -
tracking-b2g18: --- → +
(In reply to Milan Sreckovic [:milan] from comment #6)
> Hard to get a sane limit, when faxes are coming in at 8k+ in size.  I don't
> have the up to date phone - can somebody try just loading
> http://www.primariahd.ro/fisiere/module_fisiere/4191/
> Dispoz%20ordinara%20SEPTEMBRIE.pdf and see what happens?

Eventually I get a white page with a seemingly-continuous spinner.
(Reporter)

Updated

5 years ago
Summary: [B2G][PDF][PDF viewer]: PDF file crashes when zoom in to maximum. → [B2G][PDF][PDF viewer]: PDF file crashes when zoom in or zoom out
(Reporter)

Comment 9

5 years ago
Unagi Build ID: 20130225070200
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b
Gaia: 5691a16fff8e1403c75ed9d6f3a443b7e58198c6

On Test Run 5.1
Now, the PDF crashes even when you are trying to zoom out.
Steps to reproduce:
Tap on Magnifying glass "+" 12 times and then keep taping on magnifying glass "-"
 
Actual result:
PDF file crashes.
It's reproduced 3/5 times

Updated

5 years ago
Whiteboard: [b2g-crash] → [b2g-crash] testrun 5.1
(Reporter)

Comment 11

5 years ago
Environmental  Variables:
Unagi Build ID: 20130404070204
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e43e65ec89d2
Gaia: daea430624ec02f8d36a12d581fc4a3278c27cb7

This issue still reproduces on "Unagi" device.

Updated

5 years ago
Whiteboard: [b2g-crash] testrun 5.1 → [b2g-crash] testrun 5.1 inarirun1

Updated

5 years ago
Whiteboard: [b2g-crash] testrun 5.1 inarirun1 → [b2g-crash] testrun 5.1 inarirun1, leorun3

Comment 12

5 years ago
Escalating.  Crash....bad.
blocking-b2g: - → leo?
Triage - blocking base on crash description.
blocking-b2g: leo? → leo+
No new info since comment 7, so not a blocker.
blocking-b2g: leo+ → -

Comment 15

5 years ago
This issue seems like the OOM issue stated in bug 885287 and bug 876906. Request to block on this considering the problem with OOM.

Updated

5 years ago
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3 → [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4

Comment 16

5 years ago
In addition to comment #15, we're seeing this on nearly every testrun.   Re-nomming.
blocking-b2g: - → leo?

Updated

5 years ago
Priority: -- → P1
Target Milestone: --- → 1.1 QE5
This is not a common user scenario. QA is running into this because they are stress testing uncommon user scenarios. Same blocker decision as with all previous triage sessions.
blocking-b2g: leo? → -
Target Milestone: 1.1 QE5 → ---

Updated

5 years ago
Target Milestone: --- → 1.1 QE4 (15jul)

Updated

5 years ago
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4 → [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4

Updated

5 years ago
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4 → [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun

Updated

5 years ago
Duplicate of this bug: 897381

Comment 19

5 years ago
it's important to end user, mark leo?, it's bad experience if crash while review pdf file.
blocking-b2g: - → leo?
We absolutely should fix this bug. However, we're not holding back the release for it. Please see https://etherpad.mozilla.org/b2g-triage-exceptions for reasons to block on a particular bug.
blocking-b2g: leo? → -

Comment 21

5 years ago
(In reply to Dietrich Ayala (:dietrich) from comment #20)
> We absolutely should fix this bug. However, we're not holding back the
> release for it. Please see
> https://etherpad.mozilla.org/b2g-triage-exceptions for reasons to block on a
> particular bug.

Should Block:
.Top Crashes

When I enlarge the pdf doc for a better view, it just disappears. You can imagine how annoyed
end user is. And for this point of view, this feature isn't usable, and even feature incomplete.

Comment 22

5 years ago
Dears, please try to avoid the crash, can you limit zooming in a range?
blocking-b2g: - → leo?
Brendan, comment 22 sound like an idea. what do you think? thanks
Flags: needinfo?(bdahl)
minus as it is not a blocker.
blocking-b2g: leo? → -

Comment 25

5 years ago
(In reply to Preeti Raghunath(:Preeti) from comment #24)
> minus as it is not a blocker.

Hi Preeti, as an user to reading some funny doc. When I drag and enlarge to the doc. It just disappears.
What do you think?

I think can we add some simple mechanism to avoid killing itself? 
When no more memory can be applied, enlarge(zoom in) doesn't response.

Updated

5 years ago
Flags: needinfo?(praghunath)

Comment 26

5 years ago
What's blocker except crash problem?

Since PDF is popular document type, especially on network, can pdf viewer makes users feeling better?
blocking-b2g: - → leo?
(Assignee)

Comment 27

5 years ago
(In reply to Joe Cheng [:jcheng] from comment #23)
> Brendan, comment 22 sound like an idea. what do you think? thanks

As mentioned above in comment #5 it would be better to cap by canvas size.
Flags: needinfo?(bdahl)
Brendan,

What will it take to cap by canvas size?

Is it a feature enhancement?
Flags: needinfo?(bdahl)

Comment 29

5 years ago
Dear experts, is there a solution?
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun → [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1
We discussed this again during triage today.  We again agreed that this is important to fix but it's well past the time when we can do something for 1.1.  I'm moving this to a 1.2 nomination.
blocking-b2g: leo? → koi?
(Assignee)

Updated

5 years ago
Flags: needinfo?(bdahl)
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1 → [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727
Bill,

This is a memory issue. Please take a look at the same.
Flags: needinfo?(praghunath) → needinfo?(bwalker)
(Assignee)

Comment 32

5 years ago
We have a fix upstream, it is waiting on review then we will update Gaia.
Flags: needinfo?(bwalker)
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727 → [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2
Point of clarification - this is OOM, not a crash.
Keywords: crash → perf
Whiteboard: [b2g-crash] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2 → [MemShrink] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2

Comment 34

5 years ago
koi+ per (In reply to Brendan Dahl [:bdahl] from comment #32)
> We have a fix upstream, it is waiting on review then we will update Gaia.
Status: NEW → ASSIGNED
blocking-b2g: koi? → koi+
Target Milestone: 1.1 QE4 (15jul) → ---

Updated

5 years ago
Whiteboard: [MemShrink] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2 → [MemShrink:P2] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2
Blocks: 881974
Whiteboard: [MemShrink:P2] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2 → testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2
I'm going to assume you didn't mean to wipe away the memshrink whiteboard
Whiteboard: testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2 → [MemShrink:P2] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2
(Assignee)

Updated

5 years ago
Depends on: 929059

Comment 36

5 years ago
Updating Target Milestone for FxOS Perf koi+'s.
Target Milestone: --- → 1.2 C4(Nov8)

Updated

5 years ago
Whiteboard: [MemShrink:P2] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2 → [c=memory p= s= u=1.2] [MemShrink:P2] testrun 5.1 inarirun1, leorun3, leorun4, retest_leorun4, email_and_pdf_leorun, burirun1, [pdfjs-f-fixed-upstream]https://github.com/mozilla/pdf.js/pull/3727, burirun2
Should be fixed by the landing of the dependency. Can we confirm?
Keywords: qawanted
(Reporter)

Updated

5 years ago
QA Contact: sarsenyev
(Reporter)

Comment 38

5 years ago
Created attachment 826020 [details]
log111txt.txt

After the fix is landed on 929059, the issue doesn't reproduce anymore on MOZ and COM RIL 1.2, no out memory issue when zooming in or zooming out, although the out memory issue appears when scrolling pages, see the logcat

Device: Buri v1.2 
BuildID: 20131101004000
Gaia: e717aec947571f5daf923c040a82f9f0719bb526
Gecko: 54de309e18a9
Version: 26.0
Firmware Version:US_20131015
(Reporter)

Updated

5 years ago
Keywords: qawanted
Sounds like we can close this as fixed then. The scrolling issue you are describing is tracked in bug 902088.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
status-b2g18: affected → wontfix
status-b2g-v1.2: --- → fixed
You need to log in before you can comment on or make changes to this bug.