av9ash/GitBugs huggingface dataset:
Bug: Intermittent TV browser/components/search/test/browser/browser_search_telemetry_sources.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-01-25 23:31:01+00:00
Resolved: 2022-07-26 00:11:13+00:00

**Filed by:** nerli [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=365407491&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Gf5MTZvMTuKvOi2PGlAczA/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Gf5MTZvMTuKvOi2PGlAczA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2022-01-25T20:44:24.061Z] 20:44:24     INFO - TEST-PASS | browser/components/search/test/browser/browser_search_telemetry_sources.js | Should have matched browser.search.adclicks.webextension in scalars and expectedScalars - true == true - 
[task 2022-01-25T20:44:24.061Z] 20:44:24     INFO - TEST-PASS | browser/components/search/test/browser/browser_search_telemetry_sources.js | Should have matched browser.search.adclicks.unknown in scalars and expectedScalars - false == false - 
[task 2022-01-25T20:44:24.062Z] 20:44:24     INFO - Buffered messages logged at 20:44:22
[task 2022-01-25T20:44:24.062Z] 20:44:24     INFO - Leaving test bound test_source_webextension
[task 2022-01-25T20:44:24.062Z] 20:44:24     INFO - Buffered messages finished
[task 2022-01-25T20:44:24.063Z] 20:44:24     INFO - TEST-UNEXPECTED-FAIL | browser/components/search/test/browser/browser_search_telemetry_sources.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2022-01-25T20:44:24.063Z] 20:44:24     INFO - GECKO(3408) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2022-01-25T20:44:24.064Z] 20:44:24     INFO - GECKO(3408) | MEMORY STAT | vsize 7814MB | residentFast 275MB | heapAllocated 118MB
[task 2022-01-25T20:44:24.064Z] 20:44:24     INFO - TEST-OK | browser/components/search/test/browser/browser_search_telemetry_sources.js | took 51317ms
[task 2022-01-25T20:44:24.064Z] 20:44:24     INFO - checking window state
[task 2022-01-25T20:44:24.065Z] 20:44:24     INFO - GECKO(3408) | Completed ShutdownLeaks collections in process 3408
```
Bug: Browser console spam when favicon is not present
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-26 03:59:58+00:00
Resolved: 2022-01-26 10:40:12+00:00

STR:
1. Open Browser Console.
2. Go to <http://example.com/>.

Actual result:
```
GET http://example.com/favicon.ico
[HTTP/1.1 404 Not Found 118ms]

[Exception... "Favicon at "http://example.com/favicon.ico" failed to load: Not Found."  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource:///modules/FaviconLoader.jsm :: onStopRequest :: line 253"  data: no]
```

Expected result:
`FaviconLoader` should not log 404 Not Found errors.
Bug: [ 0day Vulnerability ] XSS at Mozilla Firefox Bookmarks
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-26 05:03:24+00:00
Resolved: 2024-09-16 06:26:57+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36

Steps to reproduce:

Hi,


I found an XSS vulnerability in Bookmarks in Mozilla Firefox Browser. I don't know if this will be 0day Vulnerability or not, until now my community and I are looking for practical scenarios so that it can have an impact on other Mozilla Firefox Browser users.

I should have reported this sooner to you so you can check it too.
Follow Me :)

Steps :
1. Open your Mozilla Firefox Browser

2. Add Bookmarks

3. Then add the url:
javascript:alert(document.domain)

4. Then open the victim's browser, see xss triggered in the victim's browser

5. At first I thought it was a cookie from myself, but when I checked on another website, it turned out to be a different cookie.


Actual results:

Impact of stored XSS attacks
If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. The attacker can carry out any of the actions that are applicable to the impact of reflected XSS vulnerabilities.


Reference :
https://www.youtube.com/watch?v=tTEethBKkRc


Expected results:

Supporting Report :
1. Video
Download Now :
https://drive.google.com/file/d/1PzT7Dmqn4XzGN68-mcVOBzRQJA-Vb56Z/view?usp=sharing


Thanks
Regards,


Aidil Arief
Secrash Academy
Bug: Security bug [ 0day Vulnerability ] XSS at Mozilla Firefox Bookmarks
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-26 05:09:51+00:00
Resolved: 2023-05-23 03:28:38+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
Firefox for Android

Steps to reproduce:

Hi,

I found an XSS vulnerability in Bookmarks in Mozilla Firefox Browser. I don't know if this will be 0day Vulnerability or not, until now my community and I are looking for practical scenarios so that it can have an impact on other Mozilla Firefox Browser users.

I should have reported this sooner to you so you can check it too.
Follow Me :)

Steps :

Open your Mozilla Firefox Browser

Add Bookmarks

Then add the url:
javascript:alert(document.domain)

Then open the victim's browser, see xss triggered in the victim's browser

At first I thought it was a cookie from myself, but when I checked on another website, it turned out to be a different cookie.


Actual results:

Impact of stored XSS attacks
If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. The attacker can carry out any of the actions that are applicable to the impact of reflected XSS vulnerabilities.

Reference :
https://www.youtube.com/watch?v=tTEethBKkRc


Expected results:

Supporting Report :

Video
Download Now :
https://drive.google.com/file/d/1PzT7Dmqn4XzGN68-mcVOBzRQJA-Vb56Z/view?usp=sharing
Thanks
Regards,


Aidil Arief
Secrash Academy
Bug: The "Google" string is briefly displayed in the placeholder text of the in-content search bar after the "New Tab" page is refreshed even if it is not the default search engine
Status: NEW
Priority: P3
Created: 2022-01-26 10:50:51+00:00
Resolved: 2023-06-06 08:48:36+00:00

**[Affected versions]:**
- Firefox Release 96.0.2 - Build ID: 20220119190439
- Firefox Beta 97.0b8 - Build ID: 20220125201015
- Firefox Nightly 98.0a1 - Build ID: 20220116095124

**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.6.2
- Linux Mint 20.2 x64

**[Prerequisites]:**
- Have a Firefox build installed.
- Have Bing set as the default search engine.

**[Steps to reproduce]:**
1. Open Firefox with the profile from prerequisites.
2. Open a "New Tab" and refresh it.
3. Observe the placeholder text from the in-content search bar.

**[Expected result]:**
- The "Search with Bing or enter address" placeholder text is displayed.
	
**[Actual result]:**
- The "Google" string is briefly displayed instead of the "Bing" one.

**[Notes]:**
- This issue is reproducible with all the search engines.
- This issue is not reproducible if a new tab is opened instead of refreshing the page.
- I have tried to find a regression window, but it seems that this issue is not reproducible with Mozregression builds.
- Attached a screen recording of the issue.
Bug: Temporary Geolocation permission is per-request, causing unexpected behavior of the permissions API (was: PermissionStatus.onchange not called when temporarily allowing geolocation request)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-26 15:12:55+00:00
Resolved: 2022-02-28 15:38:03+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36

Steps to reproduce:

First of all, I open this bug in the github repository of navigator geolocation API.
https://github.com/w3c/geolocation-api/issues/117

The point is that if I don´t click the remember my decision check box, the navigator geolocation API doesn´t react, it is like if the user handn´t do anything.



Actual results:

Results are that after select block or allow without clicking the remember my decision check box, the navigator geolocation API doesn´t detect it. I already opened this issue in this API repo as I referenced before but they told me this bug was related to Mozilla


Expected results:

The navigator geolocation API should detect when I click on any option without selecting the remember my decision check box
Bug: test_refresh_firefox.py uses SSWindowStateReady event to check that session is restored,
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-01-26 15:25:52+00:00
Resolved: 2022-07-12 12:22:37+00:00

test_refresh_firefox.py uses SSWindowStateReady event to check that session is restored, but then looks at currentURI to confirm that the right page is loaded. 

Trouble is that when SSWindowStateReady fire, due to the browser's being RemoteWebNavigation and may not have the correct currentURI yet, the test fail. We need to wait for currentURI to update, which happens in onLocationChange.
Bug: Download manager does not automatically open TSV files as per setting
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-01-26 15:30:05+00:00
Resolved: 2022-02-07 16:37:35+00:00

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

Steps to reproduce:

In Settings: Microsoft Excel is set as the application to use when I download a TSV file.
I frequently download such files.  Unfortunately the Download Manager ignores the 'Do this automatically for files like this from now on' setting which is ticked.
The dialogue reappears on every download and needs 'OK' to be clicked. 
This is on MacOS Monterey 12.1, and was already an issue in earlier versions.
This is in Firefox 96.0.2 (64-bit), UA Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0


Actual results:

The dialogue box pops up every time despite the setting, and it's necessary to click 'OK'.

Similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1416973


Expected results:

The download should occur and the file should open in MS Excel without any need for a button-push, as happens for example in Chrome. 

Thanks in advance for investigating.
Bug: Users can not be enrolled or unenrolled from Nimbus rollouts if studies are disabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-01-26 15:37:51+00:00
Resolved: 2022-01-28 09:48:04+00:00

**[Affected Versions]:**
- Firefox Beta 97.0b8 (Build ID: 20220125201015)
- Firefox Nightly 98.0a1 (Build ID: 20220126065618)

**[Affected Platforms]:**
- Windows 10
- macOS 11.6
- Linux Mint 20.2

**[Prerequisites]:**
- Have Remote Settings Devtools installed and set to the Stage environment.
- Have “nimbus.debug” set to “true” from “about:config”.
- Have a rollout launched to Stage (e.g the desktop “privatebrowsing” rollout from this [comment](https://github.com/mozilla/nimbus-shared/issues/183#issuecomment-1014761996)).
- Be enrolled in the rollout.

**[Steps to reproduce]:**
1. Go to “about:preferences#privacy” and untick “Allow Nightly to install and run studies”.
2. Use Remote Settings Devtools to change the environment to “Prod” (including clearing data and polling).
3. Restart the browser and observe the “about:studies” page.

**[Expected result]:**
- You are no longer enrolled in the rollout.

**[Actual result]:**
- You are still enrolled in the rollout.

**[Notes]:**
- The issue is also reproducible for enrolling in rollouts after the option is unchecked.
- If the option is then checked, users are unenrolled.
- Users are not unenrolled from active rollouts if the option is unchecked (without stopping the rollout or changing the environment).
- Attached is a recording of the issue.
Bug: Changes in PDF forms are not saved when overwriting an existing saved file from a loaded file:/// pdf.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-01-26 15:42:20+00:00
Resolved: 2022-04-11 10:35:13+00:00

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

Steps to reproduce:

open pdf file in FF that contains form fields
enter content to form fields
safe pdf file


Actual results:

pdf is not saving added content in form fields if the pdf file does already exist
example: 
save pdf first time = content in forms will be saved
save pdf again and FF promts to overwrite existing file = content will not be safed!
(if saving with a new filname = content will be saved)


Expected results:

added forms content should be saved when overwriting an existing pdf file
Bug: [Windows] "Always open" triggers auto-execute for .exe files
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-01-26 16:42:39+00:00
Resolved: 2024-10-30 00:16:11+00:00

##### [Description:]
On Windows, when adding the .exe extension with "Always Open" it will trigger executing the executable.

##### [Environment:]
97.0b8
98.0a1 2022-01-26

##### [Steps:]
1. New profile.
2. Load https://archive.mozilla.org/pub/firefox/candidates/96.0.1-candidates/build1/win64/en-US/
3. Click on an .exe
4. After download is complete, right click in the Download Pannel and set "Always Open Similar Files"
5. Click again on an .exe from the https://archive.mozilla.org/pub/firefox/candidates/96.0.1-candidates/build1/win64/en-US/

##### [Actual Result:]
Exe file is added to the Applications with always ask, but it behaves as auto-open. "Always Open Similar files" remains checked for the .exe filetype.

##### [Expected Result:]
I don't believe we should let .exe files autoexecute on Windows

##### [Note:]
The icon for the "always ask" that is added on "Always Open .. " is an action icon, not the "always ask" icon - subject we are touching on in bug 1740841 and also in https://bugzilla.mozilla.org/show_bug.cgi?id=1742693#c7
Bug: Session Restore screen appears after launching Firefox 3 or 4 times.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-26 20:38:38+00:00
Resolved: 2022-01-27 17:35:29+00:00

**Affected platforms:**
Windows10 64 bit, (happens on one of my windows10 machines, probably because of Antivirus?)
 
**Affected versions:**
Latest Nightly 98  
Latest Beta 97.0b8
Latest Release 96.0.2

**Steps to reproduce:**

1- Launch Firefox with a new profile in profile manager
2- Close firefox
3- Launch firefox with the same profile
4- Close firefox
5- Launch firefox with the same profile
6- Close firefox
7- Launch firefox with the same profile

**Expected Results**:
Firefox new tab page should show up

**Actual:**
I get the Restore session screen:

Sorry. We’re having trouble getting your pages back.
We are having trouble restoring your last browsing session. Select Restore Session to try again.
  [restore] [New session]


**Note:** (if applicable)
sometimes it takes 3 times of open and close, sometimes it takes 4 times open and close in order for the restore screen to appear.
not sure why it kicks the session restore if just the new tab page should appear.
the only thing i can think of is the antivirus (cisco AMP)

**Severity Suggestion:**
Would suggest S3, im really not sure why it does that on one of my Windows10 machines and on the other one it works perfectly.
Bug: Firefox crashed when deleting bookmarklet
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-26 21:10:18+00:00
Resolved: 2022-02-02 15:47:50+00:00

I added the bookmarklet linked from https://tomcritchlow.com/2022/01/26/electric-tables (ctrl-f for `+ Electric Tables` to see exact JS). I added it to the bookmarks sidebar, tried out a few sites, and then right clicked -> delete bookmark. Firefox crashed upon deletion - after restart it did appear to have deleted it.

I'm not impacted by this bug (as I just wanted to try out the nifty doodad), so feel free to reassign/close/etc - thanks!

---

Maybe Fission related. (DOMFissionEnabled=1)


Crash report: https://crash-stats.mozilla.org/report/index/7ec7d7f0-453a-4c10-a553-4580b0220126

MOZ_CRASH Reason: ```MOZ_RELEASE_ASSERT(!gCallingListeners)```

Top 10 frames of crashing thread:
```
0 libxul.so <name omitted> 
1 libxul.so <name omitted> 
2 libxul.so <name omitted> 
3 libxul.so <name omitted> 
4 libxul.so <name omitted> 
5 libxul.so <name omitted> 
6 libxul.so js::Call /usr/src/debug/firefox-96.0-1.fc35.x86_64/js/src/vm/Interpreter.cpp:552
7 libxul.so <name omitted> 
8 libxul.so <name omitted> 
9 None @0x00001ef815deb9cf 
```
Bug: Disable (or nerf) some UITour APIs in Private Browsing Windows, to avoid showing a surprising "You're signed in" message in private window at Firefox Accounts website
Status: NEW
Priority: --
Created: 2022-01-26 22:31:49+00:00
Resolved: 2022-04-07 15:04:49+00:00

STR:
1. In a fresh Firefox profile, visit https://www.mozilla.org/en-US/firefox/accounts/
--> Notice you get page content that indicates you're not signed in.

2. Now sign in to Firefox (Sign in in Tools or Hamburger menu), or switch to your regular browsing profile where you are signed in, and visit https://www.mozilla.org/en-US/firefox/accounts/ again.
--> Notice that you get page content that indicates you are signed in (literally "You're signed in to Firefox")

3. Now, open a private window (ctrl+shift+p) and visit https://www.mozilla.org/en-US/firefox/accounts/ again.

ACTUAL RESULTS:
Page content that knows that I'm signed in to Firefox.

EXPECTED RESULTS:
Since I'm in a brand-new private window, I would not expect any websites (including mozilla.org) to know any information about me being signed in to anything.


NOTES:
I've been told this differential-rendering of https://www.mozilla.org/en-US/firefox/accounts/ is actually using the UITours API, which is whitelisted to only a few Mozilla domains (and the API in question only reports *that you are signed in to the browser*, and nothing more).   So it's unlikely that this is any actual risk / privacy leakage here.

Nonetheless, this **gives the appearance** of a privacy bug.   To a user, the "You're signed in" message here makes it seem like Firefox might be co-mingling cookies between the regular browsing session and the private browsing session.

We should avoid giving that appearance to avoid needlessly startling users.  One way of doing this might be to nerf any login-state-relevant pieces of this API in Private Browsing mode; not sure if that would break anything or if there are any better approaches to addressing this.
Bug: Colorway change my Windows, left the top of the screen with a peach colored haze that will not go away even thought I clicked use original theme.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-01-27 07:01:21+00:00
Resolved: 2022-02-18 20:02:43+00:00

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

Steps to reproduce:

After update it change the theme for Firefox, I click no use original theme.  That theme stayed in Windows.
Bug: [MSIX] App doesn't start after installing
Status: NEW
Priority: --
Created: 2022-01-27 07:33:14+00:00
Resolved: 2022-02-14 22:01:26+00:00

We have a few reports from Microsoft Store from users noting that they were not able to start Firefox upon installing. 

-  T* : opens and closes have to install me it infuriates nahui
- A****c: does not work after downloading it 
- M***: The browser is good, but the version from the store does not start

I wonder if there's something wrong with a certain version, but it seems that they're all on a different version (from 95-96.0.2). I will look into more information in the meantime.
Bug: company website - 2nd & 3rd menu options can't be selected, others can - works in Chrome and Safari
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-01-27 12:00:40+00:00
Resolved: 2022-02-10 17:08:04+00:00

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

Steps to reproduce:

entered logon info on Firefox to go to company home page, tried to click on menu options #2 and #3 (different times) and get just arrow cursor instead of the hand cursor to activate the option choice.


Actual results:

Menu options #1, 4-6 will indicate as actionable with cursor changing to Hand but #2 and 3 won't change cursor from arrow to a hand.



Expected results:

menu options #2 & 3 should have been able to be select-able (they are select-able / actionable in Chrome and Safari).   They were working before last update.
Bug: When a tab is unloaded with a Firefox in need of restart and it displays about:restartrequired, still print the url that used to be in this tab
Status: NEW
Priority: --
Created: 2022-01-27 12:31:09+00:00
Resolved: 2024-04-16 11:33:37+00:00

Bug opened as a follow-up of https://bugzilla.mozilla.org/show_bug.cgi?id=1751366.

When a tab is unloaded after the new recent features but that Firefox is in need of a restart, in private windows it result in a situation where we get `about:restartrequired` tab shown, and the url bar is empty, therefore losing the url that used to be in the url bar.

The url should stay visible/accessible so that the user can bookmark or copy/paste the tab.
Bug: [meta] Unintentional collection of user-edited search engine values
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2022-01-27 13:56:31+00:00
Resolved: 2022-03-15 15:27:14+00:00

We discovered that we have been unintentionally receiving unwanted data in some of our search telemetry for Firefox Desktop, Firefox for Android (Fenix), and Focus for Android. Although the situation in which this occurs is rare, we believe it is important to do a full assessment and take action. This bug tracks those efforts.

#### Cause
In order to allow attribution of search by our partners, each partner assigns Firefox one or  more “search codes”. This search code appears in the URL as an HTTP query parameter. Firefox Telemetry reports “search code” counts in order to help us ensure that the correct codes are being sent. This helps us detect defects as well as search engine “hijacking” by malware. We discovered some instances in which we believe, if a user (typically accidentally) edited that part of the URL, then the contents of that field were sent back in Telemetry. For instance, if the search code was “firefox” and the user pasted an email address “example@example.com” into that part of the URL this was reported as the search code “fireexample@example.comfox”.

Note that search codes are not search queries (i.e. what you searched for). Unless edited as above, they do not include any unique or identifying information.   

#### Impact
Our investigation found that the unwanted data was rare – a maximum of 0.0013% of recorded events on Firefox Desktop, 0.0005% on Firefox for Android, and 0.0057% on Firefox Focus for Android. This matches our expectations given that the conditions described above are difficult to trigger. Firefox on iOS and Focus on iOS have a different implementation of the telemetry and are unaffected.

#### Mitigation Plan
In Firefox 96.0.3 we will be pushing a fix that limits collecting codes to a known list. This will still allow us to investigate potential search hijacking by malware by targeting specific values but will stop the unwanted collection of data. We have also started removing all submitted values not on the known list when the data is received by our telemetry servers. We will additionally remove all unknown values from existing data, which we expect to be completed by the end of February.

The update for clients landed on Nightly on January 25. Updates will start shipping January 27 on Release and ESR channels:
* Firefox Desktop (Bug 1751746)
* Firefox for Android, Firefox Focus (Bug 1751920)

In addition, we will be disabling telemetry collection for this value entirely on older Firefox versions back to Firefox 83, which is the earliest version where that change can be made with remote configuration. We encourage people with versions of Firefox older than 96.0.3 to update their version of Firefox.