av9ash/GitBugs huggingface dataset:
Bug: .url extension Download leads to Arbitrary File Read
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-01-12 15:49:07+00:00
Resolved: 2025-02-24 11:35:51+00:00

Chromium Bug Reference: https://bugs.chromium.org/p/chromium/issues/detail?id=1307930

While visiting a webpage if the download initiate for  .lnk/ .local these file types are changed to .download by firefox. But i have found a way to download .url File while lead to Arbitrary File Read

Note: .local/ .lnk are already restricted and .url is missed

We can use Blob Method with type text to download the .url file without changing it to .download

FIREFOX VERSION : 108.0.2 (64-bit)

REPRODUCTION CASE:

.Url Download POC
1. Open the Below Attached HTML
2. You can See the .Url file Downloaded

.Url Download Arbitrary File Read POC
1. Open the Below Same Attached HTML
2. You can See the .URL File Downloaded
3. Upload the same file in the Upload Button
4. You can See the content of system.ini file

I have also attached the POC Video for your reference
Bug: Firefox Translations extension adds noticeable (>1s) delay to browser readiness at launch time
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2023-01-12 16:04:24+00:00
Resolved: 2023-01-31 14:39:07+00:00

This is especially noticeable when a content blocker is also enabled, as these will delay webpage load time until they are ready.

Steps to reproduce:

- Install uBlock Origin (from <https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/>)
- Install Firefox Translations (from <https://addons.mozilla.org/en-US/firefox/addon/firefox-translations/>)
    - I wouldn't know but it's possible the number of currently downloaded translations package influence -- I can't remember how many I have locally on my side, maybe ~5
- Open a simple webpage (i.e. <http://example.org/>)
- Check the setting _"Open previous windows and tabs"_ so that the browser opens the above webpage at next launch
- Quit Firefox
- Launch Firefox

Notice the >1s delay for the restored webpage to open compared to when Firefox Translations is disabled.

Two profiling sessions attached, one with Firefox Translations enabled, the other without Firefox Translations -- all else being the same.
Bug: Firefox Sync will just show "Connect Another Device" in the "Show tabs from other device" menu even though there are two devices and both synced
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-12 19:16:32+00:00
Resolved: 2023-01-27 16:58:23+00:00

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

Steps to reproduce:

Firefox Sync will just show "Connect Another Device" in the "Show tabs from other device" menu even though there are two devices and both synced. On the other device, the tabs show up fine, it's just broken in one direction.

1. Use Firefox sync with Firefox on Linux on both sides
2. Enable syncing open tabs on both sides
3. ???
4. Discover to find that even after tapping "Sync Now" in settings on both sides, one side just uselessly gives you a giant "Connect Another Device" button and not the actual tabs


Actual results:

Open tabs broken on one devivce, getting "Connect Another Device" popup even though there is another device. It works in the other direction/on the other of the two devices too (it shows the tabs of the bugged device flawlessly), so clearly at least the device on the other side understands there are two devices


Expected results:

I can see open tabs in both directions, at least after manually pressing "Sync Now" on each end
Bug: Intermittent browser/components/uitour/test/browser_UITour_observe.js | single tracking bug
Status: REOPENED
Priority: P5
Created: 2023-01-12 23:10:13+00:00
Resolved: 2025-02-17 07:20:10+00:00

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

---
```
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour_observe.js | The panel shouldn't be open - 
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour_observe.js | Menu button should know that the menu is closed - 
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - Done shared checks
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - finished tests in this file
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - Buffered messages finished
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - TEST-UNEXPECTED-FAIL | browser/components/uitour/test/browser_UITour_observe.js | A promise chain failed to handle a rejection: Message handler threw uncatchable exception - stack: (No stack available.)
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - Rejection date: Thu Jan 12 2023 22:21:27 GMT+0000 (Coordinated Universal Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.sys.mjs :: assertNoUncaughtRejections :: line 266
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - Stack trace:
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - resource://testing-common/PromiseTestUtils.sys.mjs:assertNoUncaughtRejections:266
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - chrome://mochikit/content/browser-test.js:nextTest:675
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - GECKO(16974) | MEMORY STAT | vsize 11603MB | residentFast 371MB | heapAllocated 220MB
[task 2023-01-12T22:21:29.844Z] 22:21:29     INFO - TEST-OK | browser/components/uitour/test/browser_UITour_observe.js | took 2453ms
[task 2023-01-12T22:21:29.866Z] 22:21:29     INFO - checking window state
[task 2023-01-12T22:21:29.889Z] 22:21:29     INFO - TEST-START | browser/components/uitour/test/browser_UITour_resetProfile.js
```
Bug: Tests in browser/base/content/test/tabs/browser.ini are no longer sorted alphabetically
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-12 23:21:13+00:00
Resolved: 2023-01-19 04:53:23+00:00

Small oversight in bug 1788953. https://hg.mozilla.org/mozilla-central/rev/7cda7550cf2bc3b88854d96c655521d7630d39dd#l2.2
Bug: Spotlight and friends' dismiss button lacks padding
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-01-13 00:40:13+00:00
Resolved: 2023-02-03 05:09:21+00:00

[Compared to the prototype](https://www.figma.com/file/k4DsV0Ehon1xyTf5DjmrIx/Spotlight-Modals?node-id=549%3A12145&t=nYPB4DeuZArroAoq-0), our dismiss buttons are missing padding. This also seems to indicate that they were intended to be 12px, though I suppose that seems too small, so maybe the designer was just working with a different scaling factor. Basically, the button is 32px and the X icon inside it is 12px. So you've got a 12px icon with 10px padding.
Bug: console.error: (new Error("Polling for changes failed: Unexpected content-type \"text/plain;charset=US-ASCII\".", "resource://services-settings/remote-settings.js", 334))
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-13 04:13:05+00:00
Resolved: 2023-11-06 21:09:35+00:00

I am testing C-C TB locally under Debian GNU/Linux.
Since December 2022, I have noticed the errors of the following form, during my local testing.

```
07:57.83 GECKO(6141) console.error: (new Error("Polling for changes failed: Unexpected content-type \"text/plain;charset=US-ASCII\".", "resource://services-settings/remote-settings.js", 334))
```
This is a relative newcomer. I have only observed it since December 2022. (not that I run mochitest often enough. Due to the long timeout during testing, I am discouraged to do so, and run it maybe once a month now.
Regarding long timeout there is a related entry, bug 1802401 comment 4.

Anyway, the "Polling for changes failed" comes from
the following line in C-C.
https://searchfox.org/comm-central/source/mozilla/services/settings/remote-settings.js#334

"Unexpected content-type" is thrown from the following line:
https://searchfox.org/comm-central/source/mozilla/services/settings/Utils.jsm#407

const ct = response.headers.get("Content-Type");
if (!is404FromCustomServer && (!ct || !ct.includes("application/json"))) {
  throw new Error(`Unexpected content-type "${ct}"`);

Comparing the code and the log suggests that whatever returns the header did not return "application/json" data, but "test/plain;charset=US-ASCII". This should be a clear enough hint.

I hope this information leads to the root cause and hopefully a solution.

I filed this for testing infrastructure because I suspect that the testing framework does not properly set the fake server data or something which C-C TB expects during testing.
If this is not the case, please feel free to change the component, etc.

I am attaching an excerpt from a local log where the errors were produced.
The output from the following command:
egrep -a "(Polling for changes failed|TEST_START|TEST_END)" /FF-NEW/log1520-mochitest.txt
"-a" was necessary since the log now spews out strange 8-bit characters which egrep under LC_ALL=C regards as binary data. So I tell egrep to regard the input as text file by using "-a".

I am a bit surprised that sometimes the error is recorded AFTER TEST_END and the next TEST_START is recorded.
Bug: Firefox suggest offers switching to a non-existent tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-13 08:36:35+00:00
Resolved: 2023-01-17 08:18:50+00:00

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

Steps to reproduce:

Started to type to display a link from history




Actual results:

Non-existent tab is shown and offered to switch to


Expected results:

Item from history is offered to be opened
Bug: PDF form content is not printed
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-13 09:53:51+00:00
Resolved: 2023-01-13 11:32:36+00:00

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

Steps to reproduce:

Just tired to fill out this form [1]. While FF displays what I have filled in, it won't print it. The text is not even visible in preview.

I am attaching the PDF file, which I saved, where 'Joe Doe' is stored.

Steps to Reproduce:
1. Open the attached PDF in FF (or download from [1])
2. Press print button
3. The preview won't contain the form text

[1]: https://www.fio.cz/docs/cz/FW8Ben_Fio.pdf


Actual results:

Form content is not printed



Expected results:

Form content is printed


Additional info:
After too much fiddling, it seems this might be some font issue which I might be missing. Via Master PDF editor, I was able to change the `F1` font to `Helvetica` an print it out. But I'd assumed that print should look the same as what I can see. Not sure ...
Bug: Bookmarked page “star” button color differs between generated and privileged themes and can be hard to see with some generated themes
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-01-13 12:35:50+00:00
Resolved: 2023-01-25 17:25:51+00:00

Description:
The address bar “star” button for bookmarked pages has a different color between some privileged and generated themes.
In the case of some of those generated themes this “star” button may also become very hard to see as the color almost matches the address bar background.

Affected themes:
- life-in-color—abstract-balanced-colorway
- life-in-color—cheers-balanced-colorway
- life-in-color—elemental-balanced-colorway
- life-in-color—foto-balanced-colorway
- life-in-color—graffiti-balanced-colorway
- life-in-color—lush-balanced-colorway

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Bookmark a page on both browsers
6. Observe the color difference of the “star” button between the privileged and generated themes
7. Observe that in the case of several generated themes the “star” button is barely visible against the address bar background

Actual:
1. Generated themes bookmarked page “star” button color is different from the ones used by the privileged theme.
2. In the case of several generated themes the “star” button is barely visible against the address bar background

Expected:
1. Generated themes bookmarked page “star” button color should be the same as the one used by the privileged theme.
2. There should be more contrast between the background color of the address bar and the bookmarked page “star” button on several generated themes so as the button is visible.
Bug: Bypassing Content Security Policy (CSP) through PHP function
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-13 14:10:43+00:00
Resolved: 2024-05-30 18:03:49+00:00

Content Security Policy (CSP) are set to prevent cross-site scripting (XSS) and other code injection attacks form untrusted sources, However, a specifically crafted PHP injection can be utilized to circumvent the policy. As a result, an attacker would be able to load malicious JavaScript on the website, completely compromising the content security policy.

REPRODUCTION CASE
1. Host the provided csp.php file using a PHP server by running the command: 'php -S localhost:8000'
2. Navigate to the hosted server URL 'http://localhost:8000/csp.php'

Here i have used `Content`-Security-Policy: default-src 'none'; script-src 'unsafe-inline';`, This specific policy is telling the browser to block all resources (default-src 'none') except scripts loaded from the current origin ('unsafe-inline'). This means that by default, the browser will block all resources such as images, stylesheets, and external scripts from loading, unless they are loaded from the same origin as the website. 

However, the above-hosted PHP code will read an external origin URL sends the contents to the client. This may pose a security risk if the file contains malicious code or if the URL points to a malicious website previously injected or stored by the attacker. It could lead to cross-site scripting (XSS) or other types of attack. It is important to validate the origin and the URL before using the readfile() function.
Bug: Loading URIs should be done with URI objects by default, rather than strings, to help avoid unnecessary parsing / fixup / allocations
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-01-13 14:13:29+00:00
Resolved: 2023-04-12 05:24:32+00:00

See [this profile](https://share.firefox.dev/3QDNwgu) from Florian in bug 1800596 comment 18.

I think one of the causes for this is that there is in fact no public DOM/docshell API that takes an nsIURI - both [BrowsingContext](https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/dom/chrome-webidl/BrowsingContext.webidl#300) and [nsIWebNavigation](https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/docshell/base/nsIWebNavigation.idl#286) implement this with string arguments.

This means that in practice, we end up doing a lot of repetitive conversions from string to URI, frequently via [URIFixup](https://searchfox.org/mozilla-central/source/docshell/base/URIFixup.sys.mjs) which is even more expensive because it has to cope with arbitrary (non-URL) input.

I think we should add a URI-based alternative on BrowsingContext and nsIWebNavigation, deprecate the other APIs, and gradually switch consumers over.

Nika/Marco, does this sound reasonable, and do you have naming suggestions for the new API? I think ideally we'd move the old API to `loadURIString` or something, but that may be tricky...
Bug: Possible Download of .url Files for Data Exfiltration
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-13 14:20:47+00:00
Resolved: 2024-05-30 18:03:51+00:00

In Firefox it has implemented a security measure to protect users by replacing the download of ".lnk" files with ".download" extension. However, there is another file extension that is considered to be more severe than ".lnk", which is the ".url" extension.
A ".url" file, also known as a URL shortcut, is a type of link file that points to a web page or other resource on the internet. These files can be created by the user or by an application, and can be used to quickly access a specific webpage. However, if a ".url" file is maliciously created by an attacker, it can contain a script or other code that will execute automatically when the file is opened. This can lead to the execution of malware, the stealing of personal information, or other malicious activity.

hence made a POC which uses this method by convincing the user to save and upload the saved file for data exfiltration.
Bug: [about:logins] Warning panel links cannot be focused by using Tab key
Status: NEW
Priority: P2
Created: 2023-01-13 15:08:11+00:00
Resolved: 2024-06-08 09:46:22+00:00

**Found in**
- Firefox 109.0

**Affected versions**
- Firefox 109.0
- Firefox 110.0a1

**Tested platforms**
- Affected platforms: macOS 11.7.2
- Unaffected platforms: Windows, Ubuntu

**Prerequisites**
- Have at least one breached site saved in the profile-- instructions on how to do this can be found [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1565326#c1)

**Steps to reproduce**
1.  Launch Firefox and go to "about:logins"
2. Press the "Tab" key until the "Learn more" or "Go to -website-" hyperlinks inside the warning banner are focused.

**Expected result**
- The hyperlinks can be focused.

**Actual result**
- The hyperlinks cannot be focused.

**Regression range**
- Will see for a regression. Seems that this was an issue way back in Firefox 70 as well. See Bug 1576175.

**Additional notes**
- The issue can be seen in the following [attachment](https://drive.google.com/file/d/1m_dMMWYYY2BAqzQp4seLfdl75LuZChhC/view?usp=share_link)
- By activating the "Use keyboard navigation to move focus between controls" in macOS settings will allow the user to select the links within the warning panel
Bug: .desktop file extension on Linux should be rewritten to .desktop.download to avoid users running local executables _if_ desktop files are executed by the user's file manager.
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-01-13 17:04:46+00:00
Resolved: 2024-05-30 18:03:56+00:00

Hi Team before starting this have a Look into the below issue description. in which it shows the shortcuts files are restricted and Changed to .download But the same for Linux are not prevented

https://bugs.chromium.org/p/chromium/issues/detail?id=1307930

https://bugs.chromium.org/p/chromium/issues/detail?id=1140417

.desktop is a Shortcut file in linux similar to .lnk in Windows which could have ability to invoke the executables

Tested in Latest Version of FireFox in Linux 5.7.0-kali1-amd64 (KERNEL)

REPRODUCTION CASE
1. Open the below attached html File in Firefox on linux
2. You can see the shortcut file is allowed and downloaded in linux without renaming

Impact: Lead to Executing Code 

I have added a POC HTML The resultant download file will invoke Calc when it is trying to execute
Bug: dark mode disabled itself
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-14 04:11:53+00:00
Resolved: 2023-02-21 02:15:20+00:00

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

Steps to reproduce:

On Windows 10 Professional, 64-bit, install Firefox version 108.0.2, 64-bit, set to dark mode settings. (Also have Thunderbird version 102.6.1, 64-bit, installed with dark mode settings.)  Confirm Firefox "About" screen clearly states, "Firefox is up to date."
In Windows 10 Professional, set personalization theme to display one specific photo for the desktop Background (jpg format); I did not save this photo as a Windows theme.
Open Firefox version 108.0.2, 64-bit, set dark mode.
In Windows 10 Pro personalization, change the theme from the selected on to display a saved "theme" [saved over a year ago] that is of a different single photo (jpg format), and close the personalization.
Confirm Windows 10 Pro immediately changed the theme.
Open Firefox.




Actual results:

Firefox disabled all previous dark mode settings.
Coincidentally, Thunderbird 106.6.1, 64-bit, also disabled all previous dark mode settings.
I could not readily locate Firefox settings to return to set Firefox back to the previous dark mode settings.


Expected results:

1) I expected the Firefox setting of dark mode to remain in dark mode; OR to 2) provide a message stating that dark mode was disabled and why (if it was intended by Firefox designers to disable the previously-set dark mode).  Any message should provide either a link or instructions telling me how to set Thunderbird "back" to dark mode.
Bug: Tab closes when trying to download attachment from Yahoo Mail.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-14 12:46:26+00:00
Resolved: 2023-03-17 00:12:41+00:00

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

Steps to reproduce:

Click to download single attachment in Yahoo Mail, either in regular tab or pinned tab.


Actual results:

After the Save dialog box opens, the Yahoo Mail tab closes after a short period of time (<60 seconds) (but the Dialog box stays open).

Tested pinned tab, regular tab, tab in container. 

Does not every single time, especially if tab just opened, but it does about 80-90% of the time.


Expected results:

The tab should not close.

This does not happen in Chrome.

This problem started a few versions ago but am only reporting now.
Bug: Webextension context menu item in the Sidebar menu looks strange
Status: NEW
Priority: P3
Created: 2023-01-14 13:48:09+00:00
Resolved: 2023-10-23 12:21:05+00:00

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



Actual results:

See attached image.


Expected results:

It should look like the other menu items.
Bug: Sync changes configurations on existing devices upon initial sync of new device
Status: NEW
Priority: P2
Created: 2023-01-14 22:29:51+00:00
Resolved: 2023-01-27 16:06:19+00:00

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

Steps to reproduce:

- I have an established sync account with a lot of privacy related changes, such as disabling firefox's password manager (or at least the offer to save passwords to it) and I have noscript installed.
- When I start using a new computer I set up firefox sync on it, to sync in those settings, and preferably the noscript whitelist I have built up over time.

(fyi. I have a rather old sync account by now, so there may be some kind of old state embedded in it that I don't know of.)


Actual results:

- The addons are installed and most settings are synced to the new computer, but some settings don't seem to be applied to the new computer (specifically I noted noscript whitelist and whether or not to query to save passwords weren't saved).
- Worse yet the settings that weren't applied seem to have been back-synced to all my other devices, wiping my noscript whitelist and the password setting. I don't know if anything else is affected.

(This has been consistent over my last 4 additions of desktop firefox instances to my sync account.)


Expected results:

The settings in my sync account should be applied to the new device. If they fail to apply to the new device that failure shouldn't destroy the data in my sync account.
Bug: Pop-up Bubbles No Longer Appear Over Bookmark Entries in Firefox Nightly 110.0a1 (2023-01-13) (64-bit)
Status: NEW
Priority: P3
Created: 2023-01-15 00:55:04+00:00
Resolved: 2023-02-09 14:57:52+00:00

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

Steps to reproduce:

Pressed Ctrl+Shift+D, then hovered my mouse cursor over an entry in the list.


Actual results:

Nothing happened.


Expected results:

A pop-up window should have appeared over the entry with the full text of that entry, including the portion that was too long to fit in the window.