av9ash/GitBugs huggingface dataset:
Bug: problems buying with ebay
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-01-28 09:03:59+00:00
Resolved: 2021-02-08 09:47:58+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

login to ebay
collecting two products to buy
fill in the data to pay



Actual results:

the prcedure stops
it is impossible to pay the products


Expected results:

after fill in the paying data you should be able to pay and buy the products

after a call with ebay to solve the problem (checking all login data and all settings, reset the account and so on) they told me, it must be a problem of the actual browser
Bug: Search engines broken since update
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-01-28 11:22:55+00:00
Resolved: 2021-01-28 17:42:58+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

On the last Update on my arch linux machines the behavior of the search engines change drastically


Actual results:

Since the last update the layout of the search engines in the address bar change together with the behavior.
When I enter just the keyword of the search engine in the address bar and hit enter I'll get the search result of my standard search engine for the keyword. If I type just the keyword+space and enter nothing happens.
Often on searches the search string is not correctly forwarded to the search engine.


Expected results:

Before the update I could fast go to the webpage of the search engines by just typing the keyword in the address bar and hit enter.
Furthermore, I could search for every simple string (without special characters) with all search engines not matter if OpenSearch or Plugin.
I would like to get that behavior back.
Bug: CTRL-left clicking on links now opens the pages to the LEFT of the page i reside in, which is extremely confusing
Status: NEW
Priority: --
Created: 2021-01-28 13:39:08+00:00
Resolved: 2021-04-23 09:57:55+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Up to the previous versions , when i CTRL-left click on a link, the new page opens the link to the RIGHT of the link i was on, which is natural and logical. 
In the new version it opens all links in new tabs to the LEFT of the tab Iam on and it is not logical and extremely confusing to work with. 
Please revert back to the old so new tabs open to the RIGHT. 


Actual results:

In the new version it opens all links in new tabs to the LEFT of the tab Iam on and it is not logical and extremely confusing to work with. 


Expected results:

Tabs should open AFTER the tab you stand in not before.
Bug: Scroll tabs/Open a new tab/list all tabs toolbar buttons are not keyboard accessible.
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2021-01-28 14:40:16+00:00
Resolved: 2023-06-02 15:21:01+00:00

Not really Proton specific but perhaps can be addressed as part of this work. Right now these 3 buttons are not keyboard accessible. Keyboard focus switches from tabs in the tab bar straight into the navigation toolbar.
Bug: Simplify Recently Closed Tabs and Recently Closed Windows subviews
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-01-28 15:16:54+00:00
Resolved: 2021-04-19 16:28:54+00:00

This is something that can ship pre-Proton, so it can happen immediately, and doesn't need to be behind a pref.

The Recently Closed Tabs and Recently Closed Windows subviews are dynamically generated. They have their "showing" event handlers set up here:

https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/browser/components/customizableui/CustomizableWidgets.jsm#125-133

and the actual work of filling them with items is here:

https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/browser/components/customizableui/CustomizableWidgets.jsm#158-194

There are some utilities and abstractions in browser/components/sessionstore/RecentlyClosedTabsAndWindowsMenuUtils.jsm that will likely need some slight modification.

The structures (I'm combining them here since they're so similar, but they remain two separate submenus) should be:
```
Recently Closed Tabs/Windows <header>
<separator>
<list of recently closed tabs/windows>
<separator>
Reopen All Tabs/Windows
```

What we need to do:

1. Remove the keyboard shortcut indicator on the first item in both subviews. This can be done by removing [these lines](https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/browser/components/sessionstore/RecentlyClosedTabsAndWindowsMenuUtils.jsm#224-229), and then I think we can also then get rid of [this](https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/browser/components/customizableui/CustomizableWidgets.jsm#182)
2. Turn the "Restore All Tabs" and "Restore All Windows" footer into a normal toolbarbutton subview item
3. Rename "Restore All Tabs" to "Reopen All Tabs"
4. Rename "Restore All Windows" to "Reopen All Windows"

One thing we need to figure out with UX is whether or not we're going to change the limit on how many recently closed tabs / windows to show - that list can get quite long. Do we limit the number to show, or do we make the list a fixed maximum height with a scrollbar? Or something else entirely?

Remember when updating strings to ensure that they're not re-used elsewhere - if so, double-check that the propagated change is acceptable with UX, or create a new string just for the menu.

Also remember that if you're updating a string, you still have to update the ID of it so that our localizers know to re-translate.
Bug: The "Recommended by Pocket" section is no longer displayed on the latest Firefox Nightly for new profiles until a restart is made
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-01-28 15:41:12+00:00
Resolved: 2021-02-12 21:44:21+00:00

**[Notes]:**
- This issue is reproducible only on new Firefox profiles.

**[Affected versions]:**
- Firefox Nightly 87.0a1 - Build ID: 20210128094617

**[Affected Platforms]:**
- Windows 10 x64
- Mac 10.15
- Linux Mint 20

**[Prerequisites]:**
- Have a new Firefox profile with the "browser.search.region" pref set to "US" in the "about:config" page:

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites and open a "New Tab".
2. Observed the displayed sections.

**[Expected result]:**
- The following sections are displayed:
	- In-content Search Bar
	- Top Sites
	- Recommended by Pocket
	- Highlights
	
**[Actual result]:**
- The "Recommended by Pocket" section is not displayed.

**[Regression Window]:**
- Considering the fact that this issue is not reproducible withe the Firefox Nightly build from 2021/01/ using the Mozregression tool I have managed to find the following regresion window:
 7:58.85 INFO: Last good revision: fe38d0f74425a27d23677eee7624777fa6ff9f25
 7:58.85 INFO: First bad revision: cf9e8638462a2e1583d4aa16bc216db1263cbc4a
 7:58.85 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fe38d0f74425a27d23677eee7624777fa6ff9f25&tochange=cf9e8638462a2e1583d4aa16bc216db1263cbc4a

From the pushlog it seems that Bug 1688220 has caused this behavior.

**[Additional Notes]:**
- This issue is no longer reproducible after a browser restart.
- Attached a screenshot of the issue.

@Dao, could you please take a look over this issue?
Bug: in the version 85.0, all PDFs that are visualized in Firefox,  are being printedwith an extra blank page.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-01-28 15:42:00+00:00
Resolved: 2021-02-01 15:37:11+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

 1) in an application, open an PDF that are visualized by the visualization PDF application. 
2) It appears to be ok, with normal number of pages. 
3) when I send it to the printer, it prints an extra blank page.


Actual results:

In the version 85.0, all PDFs that are visualized in Firefox,  are being printed with an extra blank page.


Expected results:

The pdf  must be printed as equal as the visualization.
Bug: uTorrent does not start from Firefox
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-01-28 15:48:33+00:00
Resolved: 2021-06-11 13:20:53+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Op: Win10 / 64 Prof Hungarian

When you click on a torrent link on a page opened in Firefox 83 (and above), the first window pops up, but the second one (in which uTorrent would come) is no longer. Nothing happens. Specifically, the entry is C: \ ProgramData \ Microsoft \ Windows \ WER \ ReportArchive \ AppCrash_uTorrent.exe....

If I revert to Firefox 82 or 78.7esr, the error will not occur.


Actual results:

The AppCrash_uTorrent.exe.... file content (detail)

Version=1
EventType=APPCRASH
EventTime=132514113181691389
ReportType=2
Consent=1
UploadTime=132514113186483172
ReportStatus=268566528
ReportIdentifier=07355647-c212-4b0e-91a0-3dd7956bc690
IntegratorReportIdentifier=10c00438-a71d-473e-ba54-b8bbd81a5853
Wow64Host=34404
Wow64Guest=332
NsAppName=uTorrent.exe
OriginalFilename=uTorrent.exe
AppSessionGuid=0000042c-0001-0109-64bf-18c1e1c8d601
TargetAppId=W:00062755a277cb4b44beba16cb5e10ff61fd00000904!000076cb0def3ee130f4bddb6893acbcd6a7284f336b!uTorrent.exe
TargetAppVer=2011//05//17:23:16:24!66ca5!uTorrent.exe
BootId=4294967295
ServiceSplit=1991664696
TargetAsId=649
IsFatal=1
EtwNonCollectReason=1
Response.BucketId=0b0cd1a4574901376287add72124d472
Response.BucketTable=1
Response.LegacyBucketId=1335226954024277106
Response.type=4
Sig[0].Name=Alkalmazásnév
Sig[0].Value=uTorrent.exe
Sig[1].Name=Alkalmazásverzió
Sig[1].Value=2.2.1.25302
Sig[2].Name=Alkalmazás időbélyegzője
Sig[2].Value=4dd301c8
Sig[3].Name=Hiba – modul neve
Sig[3].Value=GDI32.dll
Sig[4].Name=Hiba – modul verziója
Sig[4].Value=10.0.19041.546
Sig[5].Name=Hiba – modul időbélyegzője
Sig[5].Value=9a24d4df
Sig[6].Name=Kivételkód
Sig[6].Value=c000041d
Sig[7].Name=Kivétel – eltolás
Sig[7].Value=00005d67
DynamicSig[1].Name=Operációs rendszer verziója
DynamicSig[1].Value=10.0.19042.2.0.0.256.48
DynamicSig[2].Name=Területibeállítás-azonosító
DynamicSig[2].Value=1038
DynamicSig[22].Name=További információk 1
DynamicSig[22].Value=3a7c
DynamicSig[23].Name=További információk 2
DynamicSig[23].Value=3a7c073b83bf0a1c7b91447f2e388728
DynamicSig[24].Name=További információk 3
DynamicSig[24].Value=4a49
DynamicSig[25].Name=További információk 4
DynamicSig[25].Value=4a493bf1a049937d1c049b83b07fde31
UI[2]=C:\Program Files (x86)\uTorrent\uTorrent.exe
LoadedModule[0]=C:\Program Files (x86)\uTorrent\uTorrent.exe
LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\System32\KERNEL32.DLL
LoadedModule[3]=C:\Windows\System32\KERNELBASE.dll


Expected results:

If I choose not to download uTorrent but to download the torrent file, it works fine with all versions of Firefox.
Bug: Fix Zoom controls styling in the Proton AppMenu
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-01-28 17:25:07+00:00
Resolved: 2021-04-21 12:50:27+00:00

Currently, the Zoom controls in the Proton AppMenu have:

1. Unusual start-side indentation
2. No icons for the +, - and fullscreen controls
3. A ring and shading around the zoom level that we'd like to remove.

Work to do:

1. Re-use the existing icon assets for now. This might involve re-jigging some of the CSS I added in bug 1688744 to allow for icons on some toolbaritems.
2. Remove the ring and shading around the zoom level display.
3. Eliminate the start-side padding of the toolbaritem.

This work _should_ be self-contained to the Proton AppMenu, and should not impact the currently shipping AppMenu.
Bug: Firefox 85 Bookmark -- New Entries Broken
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-01-28 18:03:03+00:00
Resolved: 2021-06-04 04:16:53+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

There are multiple issues with the "new" bookmarks implementation in Firefox 85, all of which were imposed as defaults on users (rather than being offered as options). In the order of annoyance/nonworkability:

(1) The "Other Bookmarks" subsystem interferes with all existing management of bookmarks through folders. What's worse is that it can only be "hidden," not eliminated.

(2) New bookmarks are now placed at the top of the entire bookmarks list, instead of at the bottom where they've always been (and belong). This forces existing bookmark folders to a different location (farther down) when using the bookmarks menu item, slowing down use of existing bookmarks and folders (and sometimes hiding those folders if the list is long and/or using a different screen resolution).

(3) Despite having all known favicons settings turned off, new bookmarks are importing favicons

Steps to reproduce:  Very simply, "upgrade to Firefox 85 and you get ALL OF THESE."


Actual results:

Established (as in "established since single-digit version numbers") means for managing and using bookmarks no longer work. There appears to be no functional advantage to the new system.


Expected results:

Nothing. Any changes should have been made optional, and there need to be clear directions for reversing mere "interface" changes (such as "how to ensure that new bookmarks go to the bottom of the list," which is no doubt a single entry buried somewhere in about:config).
Bug: Bookmarks Toolbar feature 'Only Show on new Tab' is not working
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-01-28 18:06:42+00:00
Resolved: 2021-02-01 17:19:35+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Create a new bookmark in the toolbar if your don't have any
Right click on the space between the address bar and the buttons on the right
Select 'Bookmarks toolbar' -> 'Only Show on new Tab'
Create new tab
Bookmark toolbar is not showing up


Actual results:

Bookmark toolbar is not showing up when 'Only Show on new Tab' is selected


Expected results:

When creating new tab with 'Only Show on new Tab' select, a bookmark toolbar should show up when creating new tab
Bug: Honor pref values when displaying bookmarks toolbar in Skeleton UI
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-01-28 19:24:54+00:00
Resolved: 2021-02-10 22:35:09+00:00

We should honor the values for `browser.toolbars.bookmarks.2h2020` and `browser.toolbars.bookmarks.visibility` to correctly show the margins in the skeleton UI
Bug: Visible passwords are not re-masked if computer goes into screen saver mode
Status: NEW
Priority: P3
Created: 2021-01-28 20:17:15+00:00
Resolved: 2021-01-28 21:09:01+00:00

This bug is related to [Bug 1680534](https://bugzilla.mozilla.org/show_bug.cgi?id=1680534). I have only reproduced this behavior on Mac, haven't tried Windows or Linux.

STR:
1. Change lock screen timeout to less than 5 minutes
1. Have a login in `about:logins`
1. View saved login password by activating the eye icon. If the OS re-authentication/primary password prompt **does not appear**, restart Firefox to clear the authentication timer
1. Enter OS password or primary password
1. Set a timer for 5+ minutes
1. After timer has expired, unlock your computer to view Firefox

If you have a local Firefox, here's STR that is a bit quicker:

1. In your local repo, [navigate to AboutLoginsParent and change the value for AUTH_TIMEOUT_MS](https://searchfox.org/mozilla-central/rev/4f07d49f1c7a823da07e3a231ac87c6435c8fd58/browser/components/aboutlogins/AboutLoginsParent.jsm#233-234)
2. The quickest screen saver/screen lockout timer on Mac is 30 seconds, so setting `AUTH_TIMEOUT_MS` to ~45 seconds or so will be much quicker than waiting 5 minutes.
3. Follow the previous STR

Expected result:
- Password is re-masked

Actual result:
- Password is unmasked

It seems as if the re-mask timer doesn't behave as expected if Mac goes into screen saver mode. I have no idea why this would be happening off the top of my head.
Bug: bad position of confirmation dialog when removing all logins
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-01-28 21:21:23+00:00
Resolved: 2021-02-22 16:57:06+00:00

STR:

1. open about:logins
2. menu icon -> Remove All Logins

Expected:

The confirmation dialog is in the middle of the Firefox window.

Actual:

The confirmation dialog is located _somewhere_.

Tested in Firefox 85 and Firefox Nightly on macOS 11.1.
Bug: 'Modify' button in newtab devtools isn't sending messages
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-01-28 21:42:13+00:00
Resolved: 2021-02-08 21:52:25+00:00

the `router.sendMessage()` function got broken by a refactor - this patch fixes to `Modify` button to use the refactored `routeCFRMessage()`.
Bug: Unable to load certain sites after 85.0 upgrade
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-01-29 04:35:26+00:00
Resolved: 2021-02-22 11:25:59+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

opened these sites:
https://www.newyorker.com/news/our-columnists/a-bold-proposal-to-ease-child-poverty-is-the-essence-of-bidenomics
https://www.wired.com/story/worrisome-new-coronavirus-strains-are-emerging-why-now/?mbid=social_tw_sci&utm_brand=wired-science&utm_medium=social&utm_social-type=owned&utm_source=twitter
https://newrepublic.com/article/161084/republican-retreat-governance-voter-suppression


Actual results:

received blank page, after momentarily seeing the page (able to open in another browser & I'm not at any kind of view limit)


Expected results:

should have seen pages listed above
Bug: Update existing users' references to old http mailto: provider links
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-01-29 11:55:48+00:00
Resolved: 2021-02-16 21:56:21+00:00

We now have some infrastructure to update protocol handlers, cf. https://searchfox.org/mozilla-central/rev/f9ad45c76ba50bdee54bebd14e6625ae14d4d085/uriloader/exthandler/HandlerService.js#235 .

We should use it to migrate any "old" http entries to the new https ones added in the deps in bug 1526890. This should fix the concern raised by Yahoo Japan in https://groups.google.com/u/1/g/firefox-dev/c/ZOxTG-hwPQQ .

I expect we should leave removed entries that are still in people's profiles (where there is no HTTPS equivalent) alone.
Bug: [Win] No attribution or dltoken data on a clean environment when downloading from https://www-demo3.allizom.org/en-US/firefox
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-01-29 12:41:32+00:00
Resolved: 2021-02-03 14:28:59+00:00

*Affected versions*
* 86.0b3 (20210128185743)


*Affected platforms*
* Windows 7x64
* Windows 10x64

*Preconditions*
* The Firefox browser is uninstalled, all the registries and all the appdata are removed.

*Steps to reproduce*
1. Go to https://www-demo3.allizom.org/en-US/firefox/.
2. Click on the Download Firefox button.
3. Install and open Firefox and about:telemetry.
4. Search for `dltoken` or `attribution` and observe the strings.


*Expected result*
* The attribution data and download token strings are displayed.

*Actual result*
* No strings are displayed neither for `dltoken` or `attribution` data.

*Regression range*
* This is reproducible on https://www-demo3.allizom.org/en-US/firefox/ site which is used for testing [PI-896](https://jira.mozilla.com/browse/PI-896)

*Notes*
* Another thing worth mentioning is that there is no attribution data displayed in about:telemetry#environment-data-tab_settings.
* Attached a screenshot.
* We consider this an S2 because we cannot test [PI-896](https://jira.mozilla.com/browse/PI-896) without the download token ID.
Bug: Wayland pipewire screensharing broken since Firefox 85 in Sway
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-01-29 13:52:17+00:00
Resolved: 2021-01-29 16:19:23+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Upgraded to Firefox 85


Actual results:

The (blank) menu entry for sharing the screen with pipewire disappear leaving no option left.


Expected results:

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1675764 there should be a new entry to screen share with pipewire
Bug: Cards Saved to Pocket redirect to 404 page when accessed from the Highlight section
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-01-29 15:16:37+00:00
Resolved: 2021-02-01 15:10:11+00:00

**[Affected versions]:**
- Firefox Nightly 87.0a1, BuildID 20210129095945
- Firefox Beta 86.0b3, BuildID 20210128185743
- Firefox Release 85.0, BuildID 20210118153634
- Firefox Release 84.0.2, BuildID 20210105180113

**[Affected Platforms]:**
- Windows 10
- macOS 10.15
- Linux Mint 20

**[Prerequisites]:**
- Have a new Firefox profile.
- You are logged in a Pocket account.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to a page with an article (eg. https://en.wikipedia.org/wiki/Egyptian_language).
3. Save the article to Pocket and open a new tab.
4. Refresh the page and click the saved card Pocket.
5. Observe the page the link redirects to.

**[Expected results]:**
- The card redirects to the correct location on the getpocket.com website.

**[Actual results]:**
- The card redirects to a 404 page on the getpocket.com website.

**[Notes]:**
- The issue is reproducible with any link that is Saved to Pocket from the Highlights section.
- The page in my case redirects to https://getpocket.com/my-list/read/6741005 which results in a 404, while https://getpocket.com/read/6741005 redirects me to the correct page.
- When hovering the card the following link is displayed https://getpocket.com/read/6741005?src=fx_new_tab
- Attached a screen recording of the issue.


@thecount, could you please take a look at this?
Bug: All loaded tabs reloading on startup or restart (profile-related)
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-01-29 15:50:21+00:00
Resolved: 2023-03-31 04:12:18+00:00

My ASAN nightly (which I use to run a specific profile) has been (for several days) reloading all loaded tabs on restarts for updates (and shutdown and then start with no update).

No tabs were in the process of loading.   No obvious crash was seen 

It's possible it was a shutdown-timeout (especially as it's ASAN), but some of the restarts I hadn't been running very long.  

Reloading all loaded tabs adversely affects startup time, can cause tabs to timeout or hang while loading (facebook), and can really hurt performance.

Note: this did *not* happen in a new profile in a quick test.
Bug: Open PDF in Nightly doesn't preserve original URL
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-01-29 16:50:20+00:00
Resolved: 2022-03-18 19:31:20+00:00

Steps to Reproduce: 

1. Visit a PDF URL: https://www.apple.com/privacy/docs/A_Day_in_the_Life_of_Your_Data.pdf 
2. Click "Open in Nightly" when asked if you want to download or save. 
3. Read PDF
4. Copy URL. 

Expected: A sharable URL that points to the original resource:  https://www.apple.com/privacy/docs/A_Day_in_the_Life_of_Your_Data.pdf  

Actual: A file:// URL pointing to my downloads folder. (file:///Users/mgaudet/Downloads/A_Day_in_the_Life_of_Your_Data.pdf) 

Other browsers: 

* Safari has the expected behaviour
* Edge Beta does too. 

I am on macOS, Firefox Nightly 87.0a1 (2021-01-29

(Guessed at component? Maybe ought to be Firefox :: File Handling? )