938235 - Designs for PDF.js on fennec

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Arun Balachandran Ganesan [:abc]]

Attachment: PDF-js (draft for front-end).pdf

Design for MVP of PDF.js

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Some comments on the MVP:
* The initial flow is confusing me a bit. I see "open and view a PDF link" which leads to "Save PDF under menu options" and this then starts a PDF download. I was assuming that these were two different ways to get to a PDF resource:
  1. Tap a PDF link on a webpage
  2. Create a PDF from a normal webpage and then open it via downloads

* The minimal vertical scrubber is likely non-trival to implement. We have a similar request in bug 708765 for all webpages.
* We don't support a system of resource constraint warnings for any other web content. I'm not sure this should be part of the MVP. It could be part of a more general system.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

"mfinkle!" (recall guy at summit) I have taken Abc's ux design and worked out some basic UI for a first round/MVP version of this and wanted to get your thoughts on it too. In particular, I wanted to know what you thought of the side scrubber that I have here which functions similar to that of iOS's contacts scroller that allows for quick scrolling down long lists. I feel this works well for long .PDF scanning whereby the orange outline can indicate what page you started on, and the space left can be used to double as a page preview type of deal.

http://cl.ly/image/2p3c2A3r3a1k

please note, final 2 screens on the right are alternative treatments of the page number.

Comment 3

[Ian Barlow (:ibarlow)]

(In reply to Mark Finkle (:mfinkle) from comment #1)
> Some comments on the MVP:
> I was assuming that these were two different ways to get to a PDF
> resource:
>   1. Tap a PDF link on a webpage
>   2. Create a PDF from a normal webpage and then open it via downloads

Arun, I think this is what we agreed on as well. Is page 3 part of an older set of flows perhaps?

> * We don't support a system of resource constraint warnings for any other
> web content. I'm not sure this should be part of the MVP. It could be part
> of a more general system.

It strikes me that of anything a user can explicitly download, a PDF has the most potential to be larger than expected. Not giving people a chance to back out of a large download while their battery is low (or they are on an expensive data plan) seems pretty bad to me.

Comment 4

[Arun Balachandran Ganesan [:abc]]

(In reply to Ian Barlow (:ibarlow) from comment #3)
> (In reply to Mark Finkle (:mfinkle) from comment #1)
> > Some comments on the MVP:
> > I was assuming that these were two different ways to get to a PDF
> > resource:
> >   1. Tap a PDF link on a webpage
> >   2. Create a PDF from a normal webpage and then open it via downloads
> 
> Arun, I think this is what we agreed on as well. Is page 3 part of an older
> set of flows perhaps?

:mfinkle, ibarlow:

Yes, correct. I'll update the wireframes accordingly. Additionally, (as per page 4) under resource constraints  (like being in 3G), we would like to allow user to download the PDF in background later and open it from Under Downloads.

 
> > * We don't support a system of resource constraint warnings for any other
> > web content. I'm not sure this should be part of the MVP. It could be part
> > of a more general system.
> 
> It strikes me that of anything a user can explicitly download, a PDF has the
> most potential to be larger than expected. Not giving people a chance to
> back out of a large download while their battery is low (or they are on an
> expensive data plan) seems pretty bad to me.

Comment 5

[Yury Delendik (:yury)]

Few notes that can affect the design:
1) PDF.js has partial download of the PDF, downloads only what's needed for display of the certain page. (Example at http://mozilla.github.io/pdf.js/web/viewer.html#disableAutoFetch=true ) A loading indicator might be useless or lie.

2) Generating of a page thumbnail takes about the same amount of time/CPU as generating the whole page. There is no low resolution previews in a PDF document. So it will be nice to minimize amount thumb operations.

3) Often PDF documents provide document outline/content/bookmarks. It will be nice to expose that instead of thumbs.

4) Text selection and search operations are not demonstrated in the attachment 831661 [details]. Are these good features to have on the mobile devices?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Yury Delendik (:yury) from comment #5)
> Few notes that can affect the design:

Thanks Yury. Very useful information.

> 4) Text selection and search operations are not demonstrated in the
> attachment 831661 [details]. Are these good features to have on the mobile
> devices?

They are useful, and we already support those features in web content and in the Reader content. I would expect them to work in the PDF content too.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Anthony Lam from comment #2)
> "mfinkle!" (recall guy at summit) I have taken Abc's ux design and worked
> out some basic UI for a first round/MVP version of this and wanted to get
> your thoughts on it too. In particular, I wanted to know what you thought of
> the side scrubber that I have here which functions similar to that of iOS's
> contacts scroller that allows for quick scrolling down long lists. I feel
> this works well for long .PDF scanning whereby the orange outline can
> indicate what page you started on, and the space left can be used to double
> as a page preview type of deal.

Hi Anthony. My concerns with the scrubber center around the implementation difficulty, regardless of the nuances of the design. We need to determine if this scrubber is part of PDF.js or part of Fennec's normal panning system. Once we decide on that part, we need to figure out how to implement the foundation, the details themselves on the scrubber concept. Once we get past that we can work on the nuances of various different designs.

Given the way the page number is coupled to the PDF content, I'm thinking that we should handle this in PDF.js but I don't know how Fennec's panning system will work against us.

Yury can chime in about how PDF.js handles scrolling pages. Based on his insights in comment 5 (items #1 and #3), I'm thinking that PDF.js wants to control the panning/scrolling. If so, then we would need to make Fennec defer to the viewer, which is not hard to do using touch events.

Comment 8

[Yury Delendik (:yury)]

(In reply to Mark Finkle (:mfinkle) from comment #7)
> Yury can chime in about how PDF.js handles scrolling pages. Based on his
> insights in comment 5 (items #1 and #3), I'm thinking that PDF.js wants to
> control the panning/scrolling.

Desktop version of the PDF.js creates pages placeholder and defers scrolling/panning of the document to the browsers. PDF.js will paint and add the canvas once page is visible. Also there is a cache of 20 canvases to reduce amount of memory used by the document.

Zooming is different, we need to re-paint the canvas to display text in better quality. You may check http://mozilla.github.io/pdf.js/web/viewer.html, when you zoom in there are a second when we CSS-zoom the page and then re-paint -- we use only CSS zooming on the B2G 1.2. We can do we same for the Android if performance will be an issue.

Comment 9

[Wesley Johnston (:wesj)]

Attachment: pdfjs.xpi

WIP Extension. This is a hacked up version of the b2g app/desktop extension (which are remarkably similar. yay web!).

1.) I removed all of the b2g UI, as well as 
2.) attempting to disable tab thumbnails (although our mockups kinda want them).
3.) We're awful at iframe panning, unlike b2g, so this pans the main content.
4.) I also severely yanked back the rendering cache to three pages, which isn't as bad as I'd thought (after some small fixes in viewer.js).
5.) I commented out all the text layer code since it wasn't working well with our text selection anyway. I also killed the printing and fullscreen bits for now.

I tried to implement a CSS transform zoom, but performance was pretty awful. I may give it another shot. Oh, and this occasionally OOMs or something... we get graphical corruption all over, even in our native ui bits, and eventually freeze (no crash though!... sometimes)

I'm starting to feel like this is doable though. At least on higher end devices. Especially if we just go with a "reader" route. And I've got a better feel for pdf.js at this point. :)

Comment 10

[Ian Barlow (:ibarlow)]

Just a couple comments so far Wes -- I installed this and tried opening http://mzl.la/fx-design-values -- It opened the PDF, but seemed to crop the pages (perhaps because the doc has multiple page sizes?) and then it sent me into a crash loop... PDF looked nice while it was open though :)

Comment 11

[Caspy7]

Can I ask for a status update on this? (It's been two years.)
What's holding this back?

Comment 12

[Richard Newman [:rnewman]]

(In reply to Caspy7 from comment #11)
> Can I ask for a status update on this? (It's been two years.)
> What's holding this back?

My guess is that we have lots of other stuff on the pile right now.

Comment 13

[Felix Kraus]

I cannot believe that there ist still no inline pdf viewer for firefox on android. Seems like i have to spam my download folder with garbage for another 3 years...

Comment 14

[Manuel Reimer]

FYI: I've created an extension to make PDF.js work on Android:
https://addons.mozilla.org/en-US/android/addon/android-pdf-js/

This is stock PDF.js with a patch added, which allows zoom with pinch gestures.
Code and support:
https://github.com/M-Reimer/android-pdf-js

Comment 15

[sedrubal]

This issue is still relevant for the new Firefox for Android (fenix) browser.

Comment 16

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.