av9ash/GitBugs huggingface dataset:
Bug: Perma Late Beta browser/components/urlbar/tests/browser/browser_quickactions.js | The action is displayed - 1 == 2 - JS frame :: chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/ - when Gecko 111 switches to Late Beta 2023-02-24
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-01-31 16:07:24+00:00
Resolved: 2023-02-23 13:28:58+00:00

* [Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=a83c7c68e54553b4bd95e1170f5def39889ea045&selectedTaskRun=IzQXXkh8TH2r5_ZVORUpMQ.0)
* [How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)
* [Failure log](https://treeherder.mozilla.org/logviewer?job_id=404063929&repo=try&lineNumber=3041)
```task 2023-01-31T13:09:31.811Z] 13:09:31     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_quickactions.js | Expected placeholder l10n when search mode is inactive - {"args":{"name":"Google"},"id":"urlbar-placeholder-with-name"} deepEqual {"id":"urlbar-placeholder-with-name","args":{"name":"Google"}} - 
[task 2023-01-31T13:09:31.811Z] 13:09:31     INFO - Leaving test bound enter_search_mode_key
[task 2023-01-31T13:09:31.812Z] 13:09:31     INFO - Entering test bound test_disabled
[task 2023-01-31T13:09:31.812Z] 13:09:31     INFO - Awaiting for the urlbar panel to open
[task 2023-01-31T13:09:31.812Z] 13:09:31     INFO - Urlbar panel opened
[task 2023-01-31T13:09:31.813Z] 13:09:31     INFO - Buffered messages finished
[task 2023-01-31T13:09:31.813Z] 13:09:31     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_quickactions.js | The action is displayed - 1 == 2 - JS frame :: chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_quickactions.js :: test_disabled :: line 185
[task 2023-01-31T13:09:31.813Z] 13:09:31     INFO - Stack trace:
[task 2023-01-31T13:09:31.814Z] 13:09:31     INFO - chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_quickactions.js:test_disabled:185
[task 2023-01-31T13:09:31.814Z] 13:09:31     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_quickactions.js | There is no selected element. - true == true - 
[task 2023-01-31T13:09:31.815Z] 13:09:31     INFO - Not taking screenshot here: see the one that was previously logged```
Bug: An aggressive white flicker can be seen when changing themes
Status: NEW
Priority: --
Created: 2023-01-31 17:52:20+00:00
Resolved: 2024-04-05 14:23:17+00:00

**Note**
* When the user changes between themes or when he disables one, he will notice an aggressive white flicker.

**Found in**
* Beta v110.0b7

**Affected versions**
* Nightly v111.0a1
* Beta v110.0b7
* Release v109.0
* ESR v102.7.0esr

**Tested platforms**
* Affected platforms: Windows 10, Mac OS 11
* Unaffected platforms: -

**Steps to reproduce**
1. Launch browser,
2. load about:addons
3. select the Themes tab
4. Click the Enable/Disable button of the default themes (or any other)

**Expected result**
* No aggressive flicker is observed.

**Actual result**
* An aggressive flicker is observed.

**Regression range**
* Before Nightly builds from 2021-11-30, the flicxker was only observed on the top menu bar.
* First bad: Tested mozilla-central build: 2021-12-01 (verdict: b)
* Last good: Tested mozilla-central build: 2021-11-30 (verdict: g)
* Pushlog: could not be obtained as mozregression bisection coul;d not continue in autoland.

**Additional notes**
* This issue occurs more often when Disabling a theme than when enabling it.
* I chose to add the access keyword because the flicker might be especially bad for certain users.
Bug: Can no longer move toolbar icons to Overflow Menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-31 21:26:07+00:00
Resolved: 2023-02-02 17:37:24+00:00

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

Steps to reproduce:

Updated to Firefox 109.0 with existing profile


Actual results:

all my icons that used to be in the Overflow Menu had moved to the main toolbar.  The Overflow Menu button was missing, and I no longer had the option to move icons back to the overflow menu.  The only option shown is to pin/unpin an icon.

If I go into the Customize Toolbar settings, I can drag a built-in toolbar icon to the Overflow Menu box, but cannot drag any of my own icons to it.  Once a built-in icon has been added, the Overflow Menu shows up, but there is no way to add other icons.

I tested this in a fresh/new profile, and that does not let me add 3rd-party icons to the overflow menu either.


Expected results:

Moving to a newer release of Firefox should have kept the icons already in the Overflow Menu where they had been previously (not moving them to the main toolbar)

I should be able to send icons to the Overflow Menu from the toolbar.
Bug: Intermittent browser/components/places/tests/browser/browser_library_open_all_with_separator.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-01-31 21:32:03+00:00
Resolved: 2023-02-28 17:04:41+00:00

**Filed by:** csabou [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=404116770&repo=mozilla-beta
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GunsJ8pjTUK5iNF7nrMeHA/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2023-01-31T20:00:10.763Z] 20:00:10     INFO - TEST-PASS | browser/components/places/tests/browser/browser_library_open_all_with_separator.js | Downloads are hidden - true == true - 
[task 2023-01-31T20:00:10.763Z] 20:00:10     INFO - TEST-PASS | browser/components/places/tests/browser/browser_library_open_all_with_separator.js | Current view is shown - true == true - 
[task 2023-01-31T20:00:10.764Z] 20:00:10     INFO - Buffered messages finished
[task 2023-01-31T20:00:10.764Z] 20:00:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_library_open_all_with_separator.js | Test timed out - 
[task 2023-01-31T20:00:10.765Z] 20:00:10     INFO - Not taking screenshot here: see the one that was previously logged
[task 2023-01-31T20:00:10.765Z] 20:00:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_library_open_all_with_separator.js | Uncaught exception received from previously timed out test - popupshown listener on #placesContext not removed before the end of test
[task 2023-01-31T20:00:11.020Z] 20:00:11     INFO - GECKO(7808) | MEMORY STAT | vsize 2104543MB | vsizeMaxContiguous 65925512MB | residentFast 398MB | heapAllocated 128MB
[task 2023-01-31T20:00:11.022Z] 20:00:11     INFO - TEST-OK | browser/components/places/tests/browser/browser_library_open_all_with_separator.js | took 45362ms
[task 2023-01-31T20:00:11.033Z] 20:00:11     INFO - checking window state
[task 2023-01-31T20:00:11.033Z] 20:00:11     INFO - Not taking screenshot here: see the one that was previously logged
[task 2023-01-31T20:00:11.034Z] 20:00:11     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_library_open_all_with_separator.js | Found a Places:Organizer after previous test timed out - 
[task 2023-01-31T20:00:11.034Z] 20:00:11     INFO - GECKO(7808) | must wait for focus
[task 2023-01-31T20:00:11.046Z] 20:00:11     INFO - TEST-START | browser/components/places/tests/browser/browser_library_open_bookmark.js
```
Bug: Firefox installer fails to properly set ACLs on the installer directory
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-31 23:18:31+00:00
Resolved: 2024-05-30 18:04:55+00:00

I hesitate to even report this through this form, but I figured I'd let you folks sort it out and decide if it's important or not.

When installing Firefox, users are given the choice to decide where to install the browser. By default, it's a subdirectory of C:\Program Files\, but since we're given the option to install it where we want, we can choose C:\Mozilla Firefox\.  If we install to this location, we can monitor the software update process with Process Monitor to see if there's anything that might be exploitable for local privilege escalation with Crassus: https://github.com/vullabs/Crassus

Running this on a Process Monitor log of this update process shows:

C:\tmp>Crassus.exe firefox_update.PML
[18:09:09] Crassus v1.1.0
[18:09:09] Reading events file...
[18:09:09] Found 1,463,240 events...
[18:09:09] Searching events.............
[18:09:12] Found 290 privileged events of interest...
[18:09:12] Checking ACLs of events of interest...
[18:09:12] We can place the missing alibre design.exe in c:\mozilla firefox (System Integrity)
[18:09:12] We can place the missing geomagic design.exe in c:\mozilla firefox (System Integrity)
[18:09:12] We can write to: c:\mozilla firefox\updater.exe (High Integrity)
[18:09:12] We can write to: c:\mozilla firefox\uninstall\helper.exe (High Integrity)
[18:09:12] We can also rename: c:\mozilla firefox\uninstall to allow loading of our own c:\mozilla firefox\uninstall\helper.exe (High Integrity)
[18:09:12] We can write to: c:\mozilla firefox\accessiblehandler.dll (64-bit, High Integrity)
[18:09:12] We can write to: c:\mozilla firefox\accessiblemarshal.dll (64-bit, High Integrity)
[18:09:12] We can write to: c:\mozilla firefox\default-browser-agent.exe (High Integrity)
[18:09:12] Extracting DLL export functions...
[18:09:12] Finding AccessibleHandler.dll - No DLL Found
[18:09:12] Finding AccessibleMarshal.dll - No DLL Found
[18:09:12] Saving output...
[18:09:12] CSV Output stored in: results.csv
[18:09:12] Proxy DLL sources stored in: stubs
[18:09:12] All done


This makes it clear that we (as any unprivileged user) can replace, for example, updater.exe to an EXE of our choice.  And if our replaced EXE requests privileges via the Windows UAC, then this will probably go unnoticed as that would be the same behavior as the real updater.exe.  But perhaps more importantly, the entire Firefox application can be replaced with whatever we want.

This is really only important on multi-user systems where Firefox is installed to a non-default location.  So yeah, probably not too many vulnerable systems out there.

As for the "alibre design.exe" and "geomagic design.exe" EXE files that are checked for with SYSTEM privileges, this is both quite surprising, and also not 100% reproducible in my testing.  But when it does happen, it doesn't appear that they will be executed if they are present.  So perhaps not exploitable in a traditional Windows privilege escalation sense.  But perhaps worth at least investigating...
Bug: Tabs dumped when main windows exited whilst in private browsing
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2023-02-01 01:53:19+00:00
Resolved: 2024-01-05 16:51:31+00:00

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

Steps to reproduce:

Fedora 37
firefox-107.0.1-1.fc37.x86_64

1) open Firefox.   
2) Open several tabs
3) open two Private Windows
4) close the initial widows
5) close both private windows
6) reopen Firefox.  Previous tabs are not gone
7) say several bad words and write Bugzilla
Bug: The weather suggestion UI shows out-of-date info
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-01 02:23:54+00:00
Resolved: 2023-04-05 15:02:14+00:00

This is a regression due to the l10n cache change in bug 1811373. The weather UI ends up using out-of-date cached strings for the current temperature and high/low text. For example if the UI shows 20° as the current temperature and Firefox fetches a new suggestion with 19° as the current temperature, the UI will keep showing 20°.

By design, `L10nCache.ensure()` [doesn't recache a string if it's already cached](https://searchfox.org/mozilla-central/rev/02ff1234547a8097df4b07a0deb70dae49ac0d03/browser/components/urlbar/UrlbarUtils.sys.mjs#2541). The problem here is that we set `excludeArgsFromCacheKey` to true, which means as long as the string is cached *with any argument value*, then `ensure()` won't recache it. If the argument value changes -- e.g., from 20 to 19 -- too bad.
Bug: Bookmarks toolbar folder menu sometimes doesn't open
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-01 06:46:13+00:00
Resolved: 2023-06-23 08:19:16+00:00

Steps to reproduce:

1. open browser
2. enable bookmarks toolbar
3. create 6 folders in the bookmarks toolbar
4. open 2 tabs
5. try dragging and hovering the first tab into the second or third folder or dragging and hovering the second tab into the fifth or the sixth folder


Actual results:

The folder menu doesn't open


Expected results:

The folder menu should open allowing to quickly bookmark the tab
Bug: 404 not found displayed for Help at the target URLs for search interventions and tips cards
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-01 09:38:18+00:00
Resolved: 2023-09-01 13:31:17+00:00

**Found in**
* Firefox 110.0b8

**Affected versions**
* Nightly 111.0a1
* Beta 110.0b8
* RC 109.0.1

**Tested platforms**
* Affected platforms: Windows 10x64, macOS 10.12.6 and Ubuntu 18.4
* Unaffected platforms: none


**Steps to reproduce**
1. Type the refresh firefox or cache firefox string on the Address Bar
2. Hover the Help button on the intervention card
3. Click the Help button

**Expected result**
* Mozilla help support URLs should be opened

**Actual result**
* 404 not found displayed for Help at the target URLs for search interventions and tips

**Regression range**
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0e287637cb438c9591ffad4e7416b4e4e75088e3&tochange=ad6a4e59525c845b8d71b65c3471efc41a3aa7a1
* Regressed by: Bug 1803873
Bug: Users are enrolled in the "Window Modal vs. Tab Modal" experiment even if they don't have Firefox pinned to the taskbar
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-01 10:31:01+00:00
Resolved: 2023-02-07 15:26:36+00:00

**[Affected versions]:**
- Firefox Beta 110.0b8 - Build ID: 20230131190033

**[Affected Platforms]:**
- Windows 10 x64

**[Prerequisites]:**
- Firefox is not installed.
- Have the Firefox "[setup.exe](http://ftp.mozilla.org/pub/firefox/releases/110.0b8/win64/en-US/Firefox%20Setup%20110.0b8.exe)" downloaded to your PC.
- Have the "[user.js](https://drive.google.com/file/d/1CxnCpHB9VswWuEGpZ0jebNaQDznxF6DM/view?usp=share_link)" file saved to your PC.

**[Steps to reproduce]:**
1. Install Firefox using the "setup.exe" from prerequisites and uncheck the "Pin to taskbar" option from the install flow.
2. Create a new Firefox profile but do not open it.
3. Navigate to the profile folder and paste the "user.js" from the prerequisites.
4. Open the browser using the previously created profile and the "--first-startup" command.
5. Navigate to the "about:studies" page and observe the displayed studies.

**[Expected result]:**
- The "Window Modal vs. Tab Modal" experiment is not displayed.
    
**[Actual result]:**
- The "Window Modal vs. Tab Modal" experiment is displayed.

**[Additional Notes]:**
- Attached is a screen recording of the issue:
Bug: Save file dialog in Windows 10 looks messy...
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-01 12:27:28+00:00
Resolved: 2023-02-01 13:29:57+00:00

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

Steps to reproduce:

I want to download a file from a webserver and click on it,


Actual results:

The upcoming dialog "What should nightly do with this file?" looks bad because of a big black bar at the right side. See screenshot.


Expected results:

The dialog should look nice.
Bug: Add/Edit top site form's URL and custom screenshot URL form validation are broken
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-01 14:18:16+00:00
Resolved: 2023-07-30 21:20:46+00:00

STR

1. Open the new tab page.
2. Try to add a top site or edit an existing top site tile. It should open a form in a dialog.
3. Enter something arbitrary like "pqrst" in the URL field and click on the Add or Save button.

Expected result:

Form validation is performed and an error tooltip is displayed if the URL is not valid. The dialog should stay open to allow the user to enter the correct URL.

Actual result:

The dialog closes and a top site tile is added. It doesn't map to anything valid.
Bug: The image of the “Set to Default” modal from the treatment branches of the "Test Window modal vs Tab modal on about:welcome" experiment is not the correct one
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-01 14:32:29+00:00
Resolved: 2023-02-03 08:22:17+00:00

**[Affected versions]:**
- Firefox Beta 110.0b8 (Build ID: 20230131190033)

**[Affected Platforms]:**
- Windows 10 x64
- Windows 11 x64

**[Prerequisites]:**
- Have the latest version of Firefox Beta 110 installed and opened.
- Have the “nimbus.debug” and “devtools.chrome.enabled” prefs set to “true” in the “about:config” page.

**[Steps to reproduce]:**
1. Force enroll in the Treatment C branch of the experiment using the following link: about:studies?optin_slug=window-modal-vs-tab-modal&optin_branch=treatment-c&optin_collection=nimbus-preview
2. Focus the browser console and run the “Cc["@mozilla.org/browser/clh;1"].getService().wrappedJSObject.firstRunProfile = true; Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._maybeShowDefaultBrowserPrompt()” syntax.
3. Observe the first modal. 

**[Expected result]:**
- The “Set to Default” modal is correctly displayed and has the correct image.

**[Actual result]:**
- The “Set to Default” modal has the wrong image.

**[Notes]:**
- This issue is also reproducible in the Treatment A and B branches of the experiment.
- This issue is not reproducible on the Control branch of the experiment.
- Attached is a screenshot of the issue.
Bug: title bar mouse actions changed
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-01 14:39:19+00:00
Resolved: 2023-02-02 15:00:52+00:00

About the same time as the tab colors changed (finding the active tab is much easier, thanks for that), the desktop's title bar mouse actions are overridden.  With all other applications, my mouse actions are:
- left click: raise
- middle click: move to desktop, maximize, minimize, etc
- right click: toggle raise and lower

With a recent update, the actions are now:
- left click: raise
- middle click: nothing
- first right click: 
     Pin to Overflow Menu (gray/disabled)
     Remove from Toolbar (gray/disabled)
 [v]Menu Bar
     Bookmarks Toolbar  >
     Customize Toolbar...
- second right click (while first right click menu is visible):
     Move to Desktop   >
     Maximize
     (etc...)

A search for "title" in about:config returns nothing useful.  
Was this change from bug 1812289 ?
Please do not alter/trap mouse actions on title bar.
Bug: The “Choose Your Language” modal is not displayed in the treatment branches of the "Test Window modal vs Tab modal on about:welcome" experiment
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-01 14:39:35+00:00
Resolved: 2023-08-28 16:34:20+00:00

**[Affected versions]:**
- Firefox Beta 110.0b8 (Build ID: 20230131190033)

**[Affected Platforms]:**
- Windows 10 x64
- Windows 11 x64

**[Prerequisites]:**
- Have the latest version of Firefox Beta 110 installed and opened.
- Have the “nimbus.debug” and “devtools.chrome.enabled” prefs set to “true” in the “about:config” page.
- Have set a different OS language than the browser's one.

**[Steps to reproduce]:**
1. Force enroll in the Treatment C branch of the experiment using the following link: about:studies?optin_slug=window-modal-vs-tab-modal&optin_branch=treatment-c&optin_collection=nimbus-preview
2. Focus the browser console and run the “Cc["@mozilla.org/browser/clh;1"].getService().wrappedJSObject.firstRunProfile = true; Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._maybeShowDefaultBrowserPrompt()” syntax.
3. Click the “Skip this step” button from the first modal.
4. Observe the next modal displayed.

**[Expected result]:**
- The “Choose Your Language” modal is displayed.

**[Actual result]:**
- The “Import Data” modal is displayed.

**[Notes]:**
- This issue is also reproducible in the Treatment A and B branches of the experiment.
- This issue is not reproducible on the Control branch of the experiment.
- Attached is a screen recording of the issue.
Bug: The Download Mobile URL does not contain the experiment parameters when it is accessed from the treatment branches of the "Test Window modal vs Tab modal on about:welcome" experiment
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-01 14:42:23+00:00
Resolved: 2023-02-08 08:59:29+00:00

**[Affected versions]:**
- Firefox Beta 110.0b8 (Build ID: 20230131190033)

**[Affected Platforms]:**
- Windows 10 x64
- Windows 11 x64

**[Prerequisites]:**
- Have the latest version of Firefox Beta 110 installed and opened.
- Have the “nimbus.debug” and “devtools.chrome.enabled” prefs set to “true” in the “about:config” page.

**[Steps to reproduce]:**
1. Force enroll in the Treatment C branch of the experiment using the following link: about:studies?optin_slug=window-modal-vs-tab-modal&optin_branch=treatment-c&optin_collection=nimbus-preview
2. Focus the browser console and run the “Cc["@mozilla.org/browser/clh;1"].getService().wrappedJSObject.firstRunProfile = true; Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._maybeShowDefaultBrowserPrompt()” syntax.
3. Navigate through the Onboarding flow until the “Mobile” modal is shown.
4. Click the “Send yourself a download link instead” button.
5. Observe the URL’s parameters of the opened link.

**[Expected result]:**
- The URL contains a specific "utm_term "parameter for the experiment.

**[Actual result]:**
- The URL doesn’t contain a specific "utm_term" parameter for the experiment.

**[Notes]:**
- This issue is also reproducible in the Treatment A and B branches of the experiment.
- This issue is not reproducible on the Control branch of the experiment.
- Attached is a screen recording of the issue.
Bug: Bookmarks of "about:newtab" page slows down loading of places.sqlite file when "Open previous windows and tabs" is turned on
Status: NEW
Priority: P5
Created: 2023-02-01 17:12:13+00:00
Resolved: 2024-02-27 08:43:53+00:00

Steps to reproduce:

Step 1: use a new unedited profile
Step 2: bookmark a new tab (about:newtab) many times or import with a html file.
Step 3: Turn on the option "Open previous windows and tabs"
Step 4: close and restart the browser

The about:newtab bookmark from my exported HTML file:
<DT><A HREF="about:newtab" ADD_DATE="1514039844" LAST_MODIFIED="1514039844" ICON_URI="chrome://branding/content/icon32.png"></A>



Actual results:

If you bookmark a new tab (about:newtab) and turn on the option "Open previous windows and tabs" it will slow down the loading and closing of the places database.

While it is loading you can't add or delete bookmarks and the icons on the new tab page are blank.

The more newtab bookmarks there are the slower it gets.
Having 2.000 about:newtab bookmarks takes 1 second to load.
4.000 takes about 4 seconds to load
8.000 takes about 12 seconds to load
16.000 takes about 50 seconds to load

This bug does not exist is Firefox 108. it is new to 109.

If you turn off "Open previous windows and tabs" it will load instantly again.


Expected results:

When turning on "Open previous windows and tabs" it should not make any difference in loading the places database. Loading should not take longer than 1 second.

Attached is a bookmark html file with 8.000 "about:newtab" for testing.
Bug: PDFs are downloaded to the home folder despite choosing to "view" in the "ask" dialog
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-02-01 19:25:35+00:00
Resolved: 2025-02-11 13:40:36+00:00

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

Steps to reproduce:

Open a PDF in Firefox in the "always ask" dialog.


Actual results:

File is opened in Firefox but still downloaded to my home folder (Linux).


Expected results:

Just viewed the file WITHOUT persisting it on permanent storage (maybe downloaded to /tmp).