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

Status: RESOLVED FIXED

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

Description

[sarsenyev]

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.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 2

[Andrew Overholt [:overholt]]

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

[Allen Maxwell]

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

Issue should repro after flashing build 20130225070200 and applying revertNightly.sh

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this possibly related to Bug 803568?  The fix for that, a simple nullptr check never made it into B2G, I think.

Comment 5

[Brendan Dahl [:bdahl]]

Attachment: 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.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

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

[Alex Keybl [:akeybl]]

We discussed in triage, this only occurs when zooming down to the "3-character level". Not a common user scenario, not a blocker.

Comment 8

[Andrew Overholt [:overholt]]

(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.

Comment 9

[sarsenyev]

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

Comment 10

[sarsenyev]

Reference to Comment #9
Test case ID:4927
https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=4927
UCID:pdfviewer-007

Comment 11

[sarsenyev]

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.

Comment 12

[John Hammink]

Escalating.  Crash....bad.

Comment 13

[Wayne Chang [:wchang]]

Triage - blocking base on crash description.

Comment 14

[Alex Keybl [:akeybl]]

No new info since comment 7, so not a blocker.

Comment 15

[Leo]

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

Comment 16

[John Hammink]

In addition to comment #15, we're seeing this on nearly every testrun.   Re-nomming.

Comment 17

[Alex Keybl [:akeybl]]

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.

Comment 19

[Jack Liu]

it's important to end user, mark leo?, it's bad experience if crash while review pdf file.

Comment 20

[Dietrich Ayala (:dietrich)]

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.

Comment 21

[Viga]

(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

[Jack Liu]

Dears, please try to avoid the crash, can you limit zooming in a range?

Comment 23

[Joe Cheng [:jcheng] (please needinfo)]

Brendan, comment 22 sound like an idea. what do you think? thanks

Comment 24

[Preeti Raghunath(:Preeti)]

minus as it is not a blocker.

Comment 25

[Viga]

(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.

Comment 26

[Jack Liu]

What's blocker except crash problem?

Since PDF is popular document type, especially on network, can pdf viewer makes users feeling better?

Comment 27

[Brendan Dahl [:bdahl]]

(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.

Comment 28

[Preeti Raghunath(:Preeti)]

Brendan,

What will it take to cap by canvas size?

Is it a feature enhancement?

Comment 29

[Jack Liu]

Dear experts, is there a solution?

Comment 30

[Andrew Overholt [:overholt]]

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.

Comment 31

[Preeti Raghunath(:Preeti)]

Bill,

This is a memory issue. Please take a look at the same.

Comment 32

[Brendan Dahl [:bdahl]]

We have a fix upstream, it is waiting on review then we will update Gaia.

Comment 33

[Jason Smith [:jsmith]]

Point of clarification - this is OOM, not a crash.

Comment 34

[Mike Lee [:mlee]]

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.

Comment 35

[Jason Smith [:jsmith]]

I'm going to assume you didn't mean to wipe away the memshrink whiteboard

Comment 36

[Mike Lee [:mlee]]

Updating Target Milestone for FxOS Perf koi+'s.

Comment 37

[Jason Smith [:jsmith]]

Should be fixed by the landing of the dependency. Can we confirm?

Comment 38

[sarsenyev]

Attachment: 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

Comment 39

[Jason Smith [:jsmith]]

Sounds like we can close this as fixed then. The scrolling issue you are describing is tracked in bug 902088.