1884499 - PDF display: 2 tabs are sometimes opened

Status: NEW

(GeckoView :: PDF Viewer, defect)

Description

[Denis Müller [:Webworkr]]

User Agent: Mozilla/5.0 (Android 14; Mobile; rv:125.0) Gecko/125.0 Firefox/125.0

Steps to reproduce:

A PDF should be displayed in the browser.

Actual results:

The browser opens 2 tabs:

• 1 empty tab
• 1 tab with display of the PDF

Expected results:

The browser should only open the "PDF tab".

Comment 1

[Adina Petridean QA [:apetridean]]

Hi, thanks for reporting.

I was not able to reproduce the issue described on Firefox Nightly 125.0a1 with Samsung Galaxy S23 Ultra (Android 14).
In order to further look into the issue you're experiencing, could you please provide the following additional information?

• Details regarding the Device used
• A link to the website on which you encountered the issue;
• Video recording of the issue;

Thanks!

Comment 2

[Denis Müller [:Webworkr]]

• Samsung Galaxy A13 5G (SM-A136B)
• It does not affect any specific websites according to my observations so far.
• I am trying to create a screen video. My previous app has compatibility issues on Android 14 and I'm not quite familiar with the replacement software yet. Most recently, the videos were too large to upload (at least on GitHub). It will therefore still take some time with the video. I'll leave the info request open until then.

Comment 3

[Adina Petridean QA [:apetridean]]

Thank you.
I was unable to reproduce this issue on Firefox 125.0b4. I've tested it on Samsung Galaxy A13, Samsung Galaxy S9 (Android 8), Samsung Galaxy Z Fold 4 (Android 14), and Samsung Galaxy S23 Ultra (Android 14).
Could you please confirm if you're encountering the same issue on the latest Nightly build?

Comment 4

[Denis Müller [:Webworkr]]

The phenomenon currently only occurs in certain cases. I am currently observing two examples.
In my provider's webmailer, this is the case when I want to download the backup QR code for two-factor authentication (2FA), although I would first like to clarify whether the cause lies with the web hoster.

And here is a public example:
"https://www.presseportal.de/blaulicht/pm/66841/5752166".
If you click on the link "https://www.pd-h.polizei-nds.de/download/74582", two tabs open.

Comment 5

[Calixte Denizet (:calixte)]

:Webworkr, are you using nightly ? If yes, did you change the value of the pref browser.download.open_pdf_attachments_inline (which is true by default in Fenix) ?

Comment 6

[Denis Müller [:Webworkr]]

Yes, Nightly is in use.
I am not aware of having changed this setting. I wouldn't even know where to find it off the top of my head.

The phenomenon only occurs occasionally, apparently in certain constellations. There have been no indications so far as to what these are.

Comment 7

[Calixte Denizet (:calixte)]

You can open a tab with about:config in the address bar, then search for the above pref and tell us if it's true or false.

Comment 8

[Denis Müller [:Webworkr]]

I had already suspected something along these lines. As far as I know, I have not changed anything in the config. These should all be the default values.

Comment 9

[Denis Müller [:Webworkr]]

Attachment: Screenshot_20240410_173047_Firefox Nightly.jpg

about:config

Comment 10

[Denis Müller [:Webworkr]]

Is my example comprehensible or do you still need a proof?

Comment 11

[Calixte Denizet (:calixte)]

Is my example comprehensible or do you still need a proof?

Yes it's, thank you.

That said I'm able to reproduce the issue on a real Pixel 7 Pro device and nightly.
I wonder if it's because the returned header has the attachment as content-disposition.
The mentioned pref is true by default in GV and it's used here:
https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#295
I wonder if we create a new tab because it's an attachment and then instead of reusing this tab we just create a new one to render the pdf.
:olivia, would you have any idea ?

Comment 12

[Olivia Hall [:olivia]]

I wonder if we create a new tab because it's an attachment and then instead of reusing this tab we just create a new one to render the pdf.

Something like that makes sense to me and seems the best lead based on my testing as well! I noticed on Desktop the example seems to download and open. I kinda wonder if Android is trying to do the same behavior, but can't with the attachment?

Was able to reproduce in both GV and Fenix:

• Fenix - was able to reproduce on a Pixel 4a Android 14 using comment 4
  • (Originally, I noticed some interesting checking around attachment on the AC side around here, but this seems irrelevant since the bug also reproduced on GeckoView, but maybe interesting.)
• GeckoView - was able to reproduce on a Pixel 4a Android 14 using comment 4

I noticed also on Desktop using:

• https://www.presseportal.de/blaulicht/pm/66841/5752166 to click https://www.pd-h.polizei-nds.de/download/74582" shows the PDF and downloads it.
  • I do see a target="_blank" and rel="noopener"in the markup on this link:
  • <a target="_blank" class="uri-ext outbound" rel="noopener" href="https://www.presseportal.de/blaulicht/pm/66841/5728839">https://www.presseportal.de/blaulicht/pm/66841/5728839</a>
  • Saw content-disposition: attachment; filename=Fahrradcodierung_-registrierung.pdf and content-description: File Transfer
• In contrast, this example does not https://www.robertkaufman.com/quilting/quilts_patterns/intertwine/ to click https://www.robertkaufman.com/assets/pdf/Intertwine-2023KONACOTY.pdf does not. (Also, does not reproduce bug behavior in Android.)
  • <a target="_blank" href="/assets/pdf/Intertwine-2023KONACOTY.pdf" onclick="gtag([&quot;_trackEvent&quot;, &quot;Downloads Projects&quot;, &quot;More Info&quot;, &quot;Intertwine - Kona&amp;reg; Cotton, 01\/2023&quot;])">Download this pattern</a>
  • Manually adding rel="noopener" to this link didn't reproduce the behavior.
  • Saw content-disposition: inline; filename="Intertwine-2023KONACOTY.pdf" and content-description: File Transfer

Comment 13

[Denis Müller [:Webworkr]]

In the meantime, my provider has replied to me:

"We cannot reproduce this behavior with 'Desktop Firefox' and other browsers. We can also observe this with Nightly, but we assume that this is a bug in the browser, as no other browser - tested by us - behaves in this way."

(Answer translated into American English)

Comment 14

[Denis Müller [:Webworkr]]

I no longer notice this phenomenon.
Can anyone confirm this?

130.0a1 (Build #2016034623),
hg-d2cde533d949+
GV: 130.0a1-20240725093133
AS: 130.20240724050232