1045918 - [B2G][PDF Viewer] Pressing the 'X' icon in the upper left corner does not close the PDF Viewer

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Martin Shuman [:Marty]]

Attachment: logcat-PDF.txt

Description:
Clicking the 'X' button in the upper left corner of the PDF viewer does not close the app.  Has no functionality.


Repro Steps:
1) Update a Flame to 20140729000201
2) Download and open a PDF file
3) Press the 'X' icon to close the PDF viewer

Actual:
The PDF Viewer does not close.


Expected:
The PDF Viewer closes properly.

Environmental Variables:
Device: Flame 2.0 (319MB)
Build ID: 20140729000201
Gaia: b11775fcbfe076a3fc560c2041f5b2fe1b345009
Gecko: 86b56e101512
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Keywords: PDF, Exit, Download, Browser

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/4069/
See attached: video clip (URL), logcat

Comment 1

[Martin Shuman [:Marty]]

This issue DOES occur on Flame 2.1 (319MB), Buri 2.1, and Buri 2.0.
The PDF Viewer does not close.

Environmental Variables:
Device: Flame Master (319MB)
Build ID: 20140728040209
Gaia: 295967a0b824a355ae9d57fb08f3632ed2ad18dd
Gecko: a4dcfbebcb58
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Buri Master
Build ID: 20140728073003
Gaia: 295967a0b824a355ae9d57fb08f3632ed2ad18dd
Gecko: d77f6a96ff96
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140728000238
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

---------------------------------------------------------------------------------------------------

This issue does NOT occur on Flame 2.0 (512MB).
The PDF Viewer closes properly.

Environmental Variables:
Device: Flame 2.0 (319MB)
Build ID: 20140729000201
Gaia: b11775fcbfe076a3fc560c2041f5b2fe1b345009
Gecko: 86b56e101512
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-----------------------------------------------------------------------------------------------------

The default PDF Viewer was not included in 1.4

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Nominating to block, this is a severe functional issue with pdf viewer in 319MB memory.

Comment 3

[Jason Smith [:jsmith]]

Blocking for being a bad functional bug with the PDF viewer.

Can we more details of exactly what happens on 1.4 here? I don't understand comment 1.

Comment 4

[Peter Bylenga [:PBylenga]]

I did some investigation yesterday on the 1.4 behavior when you tap on a pdf link it downloads to the download manager.  Then we you try to open it in download manager it states that it can't find an app that can open that type of file.

William Hsu opened a bug to track it for 1.4.

https://bugzilla.mozilla.org/show_bug.cgi?id=1046531

Comment 5

[Joshua Mitchell (Inactive)]

comment 4 addressed the QA-Wanted tag

Comment 6

[Manuel Casas Barrado [:mancas]]

I've been taking a look at this bug and after a few tries I think the reason why the app is not closing, is because a lack of memory. This behaviour could be caused by the pdf js app when trying to load the whole document at the same time. After a few seconds, the application crashes and  it can't send events.

So it seems to be a problem of performance rather than an app error. What's your thought?

Comment 7

[Kai-Chih Hu [:khu]]

Thinker, can you take a look on this bug? Thanks!

Comment 8

[Thinker Li [:sinker]]

(In reply to Manuel Casas Barrado [:mancas] from comment #6)
> I've been taking a look at this bug and after a few tries I think the reason
> why the app is not closing, is because a lack of memory. This behaviour
> could be caused by the pdf js app when trying to load the whole document at
> the same time. After a few seconds, the application crashes and  it can't
> send events.
> 
> So it seems to be a problem of performance rather than an app error. What's
> your thought?

I don't really understand.  We usually, in normal, switch to the homescreen if the foreground app is crash.  It does not depend on any event from app processes.  It relies on the signal sent by the kernel.  The attached logcat log is incomplete.  Could you provide a complete log and run |adb shell b2g-ps| while the pdfjs is hanging?

Comment 9

[Jason Smith [:jsmith]]

Can we try bisecting this against 2.0 builds only to see if we find the regression range here?

Comment 10

[Chris Kreinbring [:CKreinbring]]

Note: For the Last Working builds, any attempts to load a PDF end with a Unable to Open error page and an option to delete the PDF.

Regression window
Last working
BuildID: 20140608101635
Gaia: 2e5636e852a9354a5f8072b179cf16f72647cfd6
Gecko: 8bd92dc9ef59
Platform Version: 32.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

First broken
BuildID: 20140608183936
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 5f46ba7c1a82
Platform Version: 32.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Working Gaia / Broken Gecko = No repro
Gaia: 2e5636e852a9354a5f8072b179cf16f72647cfd6
Gecko: 5f46ba7c1a82
Broken Gaia / Working Gecko = Repro
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 8bd92dc9ef59
Gaia push log: https://github.com/mozilla-b2g/gaia/compare/2e5636e852a9354a5f8072b179cf16f72647cfd6...12af93123c5db55212d51fe235d39f21209a1eaa


B2G-inbound
Last working
BuildID: 20140607193134
Gaia: 5475755df9d5e16a221eb628b963172fc996f95f
Gecko: f64e4b6c3593
Platform Version: 32.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

First broken
BuildID: 20140608001934
Gaia: 4099f6dc3ed6388507c4613b2d53183da21b106b
Gecko: a85db90b6e37
Platform Version: 32.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Working Gaia / Broken Gecko = No repro
Gaia: 5475755df9d5e16a221eb628b963172fc996f95f
Gecko: a85db90b6e37
Broken Gaia / Working Gecko = Repro
Gaia: 4099f6dc3ed6388507c4613b2d53183da21b106b
Gecko: f64e4b6c3593
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/5475755df9d5e16a221eb628b963172fc996f95f...4099f6dc3ed6388507c4613b2d53183da21b106b

Comment 11

[Joshua Mitchell (Inactive)]

Broken by bug 1009780 ?  Aus - can you take a look?

Comment 12

[Aus Lacroix [:aus]]

Could you guys also explain to me how this is a regression? We didn't support opening PDFs that were downloaded before so this is a new feature AFAIK. :)

We do have to create a URL from the Blob so that's possibly using some extra memory but it should be very minimal.

Could I get a complete logcat here as well? (as asked by thinker in comment #8)

I honestly don't think I'll have any time to actively investigate this until next week.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Ghislain Aus Lacroix [:aus] from comment #12)
> Could you guys also explain to me how this is a regression? We didn't
> support opening PDFs that were downloaded before so this is a new feature
> AFAIK. :)

Fair point. Agree this sounds more like a new feature bug.

> 
> We do have to create a URL from the Blob so that's possibly using some extra
> memory but it should be very minimal.
> 
> Could I get a complete logcat here as well? (as asked by thinker in comment
> #8)

Flagging qawanted to get a longer logcat.

> 
> I honestly don't think I'll have any time to actively investigate this until
> next week.

That's fine. I'm moving this over to System under the assumption that this is a download manager bug.

Comment 14

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Attachment: pdf viewer logcat.txt

Comment 15

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I let the logcat above run for quite a bit after reproducing the issue so I hope it has the information that was left out before.
The results of running 'adb shell b2g-ps' after reproducing the issue are pasted below.

APPLICATION      USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
b2g              root      289   1     270304 79716 ffffffff b6f0d63c S /system/b2g/b2g
(Nuwa)           root      602   289   54816  5116  ffffffff b6f0d63c S /system/b2g/b2g
Homescreen       u0_a1152  1152  602   74676  10132 ffffffff b6f0d63c S /system/b2g/b2g
PDF Viewer       u0_a2221  2221  602   153080 51352 ffffffff b6f0d63c S /system/b2g/b2g
(Preallocated a  u0_a2261  2261  602   60712  12528 ffffffff b6f0d63c S /system/b2g/b2g

Comment 16

[Aus Lacroix [:aus]]

Going to have a look at this early next week.

Comment 17

[Aus Lacroix [:aus]]

Going to have a look at this today!

Comment 18

[Aus Lacroix [:aus]]

This is WFM on both 2.1 and 2.0 (v123 base image) with 319M Flame. It's quite possible that other fixes have enabled this to work cleanly.

Comment 19

[Cody Roesch [:croesch]]

In the latest 2.1 Nightly build for Flame, the X is working correctly and closes out of the .Pdf.

Environmental Variables:
Device: Flame Master
BuildID: 20140818040201
Gaia: aa8aace12d65956dd9525da5dac66e0d3b28597f
Gecko: 0aaa2d3d15cc
Version: 34.0a1 (Master) 
Firmware Version: v123

Comment 20

[Cody Roesch [:croesch]]

I did notice that in the latest Flame 2.1 Engineering build that the header and X button to close the .Pdf is missing though. Is this going to be fixed soon since nightly is fixed? Or is this a new bug?

Comment 21

[Jason Smith [:jsmith]]

(In reply to Cody Roesch [:croesch] from comment #20)
> I did notice that in the latest Flame 2.1 Engineering build that the header
> and X button to close the .Pdf is missing though. Is this going to be fixed
> soon since nightly is fixed? Or is this a new bug?

I would suggest filing a new bug for this issue you are seeing.

Comment 22

[Aus Lacroix [:aus]]

From my understanding, it's normal for the 'X' button to be gone. It's part of all the Haida work that's being done for 2.1.