1868205 - Figure out how to deal with content:// URLs referring to PDFs

Status: NEW

(GeckoView :: PDF Viewer, task)

Description

[Marco Castelluccio [:marco]]

Given we are using blobs, when restoring a Fenix session the tabs with PDFs opened from the local filesystem can't be restored.

Comment 1

[Calixte Denizet (:calixte)]

STR:

• open a pdf from Files app
• kill fenix
• open fenix

The last tab is reopen with the content:// uri, but it leads to a 404.
It's because the access to the uri has been granted for a specific uid/pid.
So we're in a similar case where we reopen a firefox with a tab containing a blob url.
There are at least 3 solutions:

• let things as they are.
• auto-close tab with content:// uri which leads to a 404
• before killing Fenix (if we've the possibility to know that Fenix will be killed (because of the user or because of not-enough-memory)), we could save the pdf in a place we know and then reopen it when opening Fenix: the main drawback is that it'll lead to increase memory use.

Comment 2

[Titouan Thibaud [:titouan]]

I guess we can start with the second option (auto-close tab with content:// uri which leads to a 404), and start a broader discussion with the Product and UX teams to propose a better way of handling this situation? 

We may want to ask the user if they want to save a PDF that has just been opened for example? In the case of a receipt for a purchase, the user may think the PDF is stored on his device because it's been opened, and only find out later, when they need it, that it was not. How will we protect the users from those mistakes?

Comment 3

[Rahul Sainani [:rsainani]]

Should this be in pdf component?

Comment 4

[Titouan Thibaud [:titouan]]

Yes, thanks for flagging this. I'm moving it to GeckoView:PDF