1891737 - Account recovery key creation leads to a blank page after pressing “Download and continue”

Status: NEW

(GeckoView :: PDF Viewer, defect)

Description

[Jonathan Almeida [:jonalmeida]]

FxA version:

• 1.281.2

Prerequisites:

• Have no Account Recovery key set up;

Steps to reproduce:

1. Access FxA Settings through “Manage account” button from the 3 dots button - Account;
2. Tap on “Create” to start the Account recovery key process;
3. Enter the password for the account from prerequisites;
4. Tap on “Download and continue”
5. Observe behavior;

Expected result:

• Recovery key is downloaded and user is taken to add a hint for ease of access;

Actual result:

• Tapping “Download and continue” takes the user to a blank page;

Notes:

• Issue does NOT reproduce if user accesses FxA settings through URL directly;
• Recovery key pdf file is NOT downloaded;
• Email is received;
• Pressing the back button displays the Hint page;
• On some devices the flow exists after pressing “Download and continue”
• See the attached media;

Comment 1

[Jonathan Almeida [:jonalmeida]]

Attachment: Screenshot_20240401_143443.png

Copied over from FXA-9384 and I'll include my comment from there, over here as well:

If you reproduce this same flow by visiting accounts.firefox.com with a normal tab (no Custom Tab chrome), then the PDF viewer works, but the blob download is still not triggered from the new window request. I suspect there are two symptoms (of the same bug?):

1. The Android engine needs to support blob downloads for blob:https://accounts.firefox.com/{UUID} type URIs.
2. PdfJS should render in a Custom Tab.

---

I've moved this bug into GeckoView::PDfViewer initially because that not working seems like a core part of the problem. If that would work, the PDF download button would surely show up at least. Feel free to move it around though if this is the wrong assumption.

Comment 2

[Olivia Hall [:olivia]]

Thanks for the report!

You know this reminds me of bug 1884499. (It could just be that I saw that yesterday and it is on my mind more than a true relation.)
In bug 1884499, Android presumably isn't handling a content-disposition: attachment; correctly. On Desktop, this flow downloads the PDF and opens the PDF. On Android, in that case, it is still opening, but opening a new about:blank tab as well (assuming when it tried to download). The opening of about:blank seems especially reminiscent.

Do you know what content-disposition is set on the blob, if any?

1. The Android engine needs to support blob downloads for blob:https://accounts.firefox.com/{UUID} type URIs.

So, I think we do have this mechanism, but it possibly isn't connected or else something else is going on specific to PDFs. So, the deep click context menu does support blob: URLS based on this. And AFAIK, I think the PDF stream uses blobs internally as well, so some level of support is there.

I made a simple SVG blob test to try to figure out more. Downloading an SVG via a blob seems to work as expected.

Could you make a plain HTML sample that simulates the blob Download and continue is sending? That might help narrow down to the right layer. I also wonder if the root issue could just be the PDF viewer not supporting custom tabs as well.

2. PdfJS should render in a Custom Tab.

I think we have parallel bugs of bug 1809149 and bug 1842558 tracking that. We should probably prioritize one of them. It also does the about:blank display similar to this bug

Comment 3

[Olivia Hall [:olivia]]

Attachment: blob_svg_download.html

Generic blob click to download and deep click context menu SVG test. (Not sure why Android doesn't display it in a viewer, but it appears valid on Desktop using inkscape to view and downloads as expected on Android.)

Edit: Appears Android doesn't have in-built SVG support. I was able to open the downloaded SVG file in Canva on Android.

Comment 4

[Olivia Hall [:olivia]]

Hi :calixte,

Could you offer some additional insight, especially with PDFs and custom tabs?

Comment 5

[Jonathan Almeida [:jonalmeida]]

(In reply to Olivia Hall [:olivia] from comment #2)

Thanks for the report!

You know this reminds me of bug 1884499. (It could just be that I saw that yesterday and it is on my mind more than a true relation.)
In bug 1884499, Android presumably isn't handling a content-disposition: attachment; correctly. On Desktop, this flow downloads the PDF and opens the PDF. On Android, in that case, it is still opening, but opening a new about:blank tab as well (assuming when it tried to download). The opening of about:blank seems especially reminiscent.

This might be related! See below about the new window location.href bit.

Do you know what content-disposition is set on the blob, if any?

To our knowledge, there is no content-disposition that is set on the application side and the file-saver package that is used also doesn't recommend setting this if the file is created from the client side web app (which is what we are doing here).

1. The Android engine needs to support blob downloads for blob:https://accounts.firefox.com/{UUID} type URIs.

So, I think we do have this mechanism, but it possibly isn't connected or else something else is going on specific to PDFs. So, the deep click context menu does support blob: URLS based on this. And AFAIK, I think the PDF stream uses blobs internally as well, so some level of support is there.

I made a simple SVG blob test to try to figure out more. Downloading an SVG via a blob seems to work as expected.

Could you make a plain HTML sample that simulates the blob Download and continue is sending? That might help narrow down to the right layer. I also wonder if the root issue could just be the PDF viewer not supporting custom tabs as well.

I haven't figured out how to do this yet that accurately simulates it for you yet, but if it helps, from the code in FxA, we generating the blob and using saveAs from the file-saver package to set the location.href (or a new window location.href) to the blob URI.

NI please if there is any more information I can provide, thanks Olivia!

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:calu, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Olivia Hall [:olivia]]

Forgot to set a ni!

Hi :calixte,

Could you offer some additional insight, especially with PDFs and custom tabs?

Comment 8

[Olivia Hall [:olivia]]

Attachment: blob_pdf_download.html

Working example of a blob PDF download. Still looking for a simplified exact STR example.

Comment 9

[Olivia Hall [:olivia]]

Attachment: orange.pdf

Comment 10

[Olivia Hall [:olivia]]

Attachment: blob_pdf_download.html

Comment 11

[Olivia Hall [:olivia]]

Managed to make a working blob PDF example. Haven't narrowed down what is happening in the primary issue, but the working version might help narrow down the root cause.

Comment 12

[Jonathan Almeida [:jonalmeida]]

No longer using a Custom Tab for accounts.firefox.com will remove problems like this that we've seen under bug 1856770. Let's block on that one and raise the meta severity.

Comment 13

[Jonathan Almeida [:jonalmeida]]

I found this older issue (bug 1553790) that seems to suggest that we never had window.open links for blobs ever working in GV.

Nevermind, maybe we can close it because it does work now as noted it comment 0 report: "Issue does NOT reproduce if user accesses FxA settings through URL directly;"