av9ash/GitBugs huggingface dataset:
Bug: Ubuntu Snap Beta reports Stable version number
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-08-22 19:57:37+00:00
Resolved: 2022-08-23 23:53:11+00:00

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

Steps to reproduce:

I needed native messaging after upgrading Ubuntu from 21.10 to 22.04. I saw an article at omgubuntu that said it was fixed in beta, so I installed firefox using

snap install firefox channel=beta

The version that was installed (and has been working fine) has been 104.0b9-1. HOWEVER when I choose (hamburger)-->Help--> About Firefox, it shows a different number




Actual results:

$ snap info firefox
name:      firefox
summary:   Mozilla Firefox web browser
publisher: Mozilla✓
store-url: https://snapcraft.io/firefox
contact:   https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
license:   unset
description: |
  Firefox is a powerful, extensible web browser with support for modern web
  application technologies.
commands:
  - firefox
  - firefox.geckodriver
snap-id:      3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
tracking:     latest/beta
refresh-date: today at 14:08 CDT
channels:
  latest/stable:    103.0.2-1    2022-08-09 (1670) 171MB -
  latest/candidate: 104.0-3      2022-08-19 (1725) 185MB -
  latest/beta:      104.0b9-1    2022-08-22 (1738) 185MB -
  latest/edge:      105.0a1      2022-08-22 (1737) 182MB -
  esr/stable:       91.12.0esr-1 2022-07-26 (1588) 161MB -
  esr/candidate:    102.2.0esr-2 2022-08-22 (1739) 182MB -
  esr/beta:         ↑                                    
  esr/edge:         102.1.0esr-1 2022-07-26 (1592) 169MB -
installed:          104.0b9-1               (1738) 185MB -

[About Firefox]
Updates available at (mozilla url)
103.0.1 (64-bit) 



Expected results:

I expected to see version 104.0b9-1, the beta version I am running, according to snap, because Native Messaging works (and it didn't on the stable release). Instead Firefox itself is showing 103.0.1 (which is close to what snap stable says)
Bug: Hanging when navigating to URLs, using devtools, or downloading update.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-22 20:25:16+00:00
Resolved: 2022-09-05 06:48:28+00:00

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

Steps to reproduce:

Typing google.com in the address bar and hitting enter has no result.
Using the arrow button in the bar instead of Enter starts loading, but eventually ends in a "The connection has timed out" error.
Refreshing an already-open page does work, but sometimes shift-refresh is needed.

Sometimes video buffering hangs indefinitely and requires a page refresh.

After opening devtools with F12, the Network and Console panes remain empty for a long time, and console commands have no output.

When an update is available, after going to the "Help → About Nightly" window, the download stays at 0% for a long time. Restarting Firefox allows the download to finish, and then restarting again completes the update.

I ran mozregression; this was the last regression window output:
2022-08-22T15:36:16.293000: INFO : Narrowed integration regression window from [a3cd22f7, aa9a4f02] (4 builds) to [7696ca8c, aa9a4f02] (2 builds) (~1 steps left)
Bug: HCM Recently Closed focus color
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-08-22 20:46:44+00:00
Resolved: 2023-09-25 13:43:34+00:00

for MacOS, when the HCM colors are set up in the Firefox itself, the implementation on recently closed focus is confusing because the outline is visited link color and the underlying element doesnt carry any link text. While on mac OS links do not need to carry a link text style on Windows OS they do. Would be best just to be consistent and apply changes to both. 

Recommendation: Style all text inside each row with hyperlink text color (MozNativehyperlinktext), then the default behavior would be to have an outline with text color (WindowText)
Bug: Intermittent browser/components/urlbar/tests/browser/browser_quickactions.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2022-08-22 22:43:25+00:00
Resolved: 2022-10-10 06:39:50+00:00

**Filed by:** mlaza [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=388126986&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ZHGp9fyVSXCf1-klaT9x1w/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/ZHGp9fyVSXCf1-klaT9x1w/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2022-08-22T21:35:18.761Z] 21:35:18     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_quickactions.js | The command "themes" passed completed its test - true == true - 
[task 2022-08-22T21:35:18.761Z] 21:35:18     INFO - Leaving test bound test_pages
[task 2022-08-22T21:35:18.761Z] 21:35:18     INFO - Buffered messages finished
[task 2022-08-22T21:35:18.761Z] 21:35:18     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_quickactions.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-08-22T21:35:18.762Z] 21:35:18     INFO - GECKO(1540) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2022-08-22T21:35:18.762Z] 21:35:18     INFO - GECKO(1540) | MEMORY STAT | vsize 16012MB | residentFast 318MB | heapAllocated 149MB
[task 2022-08-22T21:35:18.763Z] 21:35:18     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_quickactions.js | took 46260ms
```
Bug: Intermittent browser/components/uitour/test/browser_UITour.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-08-23 05:44:03+00:00
Resolved: 2025-02-10 12:08:05+00:00

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

---
```
[task 2022-08-23T04:50:18.105Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | Element should not be null, when checking visibility - 
[task 2022-08-23T04:50:18.106Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | Highlight should be closed/hidden after UITour tab is closed - 
[task 2022-08-23T04:50:18.107Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | Element should not be null, when checking visibility - 
[task 2022-08-23T04:50:18.107Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | Tooltip should be closed/hidden after UITour tab is closed - 
[task 2022-08-23T04:50:18.108Z] 04:50:18     INFO - Buffered messages logged at 04:49:35
[task 2022-08-23T04:50:18.108Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | @noautohide on the menu panel should have been cleaned up - 
[task 2022-08-23T04:50:18.109Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | The panel shouldn't have @panelopen - 
[task 2022-08-23T04:50:18.110Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | The panel shouldn't be open - 
[task 2022-08-23T04:50:18.110Z] 04:50:18     INFO - TEST-PASS | browser/components/uitour/test/browser_UITour.js | Menu button should know that the menu is closed - 
[task 2022-08-23T04:50:18.111Z] 04:50:18     INFO - Done shared checks
[task 2022-08-23T04:50:18.112Z] 04:50:18     INFO - Starting test_unsecure_host_override
[task 2022-08-23T04:50:18.112Z] 04:50:18     INFO - Buffered messages finished
[task 2022-08-23T04:50:18.113Z] 04:50:18     INFO - TEST-UNEXPECTED-FAIL | browser/components/uitour/test/browser_UITour.js | Test timed out - 
[task 2022-08-23T04:50:18.253Z] 04:50:18     INFO - GECKO(5360) | MEMORY STAT | vsize 943MB | vsizeMaxContiguous 447MB | residentFast 213MB | heapAllocated 208MB
[task 2022-08-23T04:50:18.254Z] 04:50:18     INFO - TEST-OK | browser/components/uitour/test/browser_UITour.js | took 45247ms
[task 2022-08-23T04:50:18.255Z] 04:50:18     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-08-23T04:50:18.256Z] 04:50:18     INFO - TEST-UNEXPECTED-FAIL | browser/components/uitour/test/browser_UITour.js | Found a tab after previous test timed out: https://example.org/browser/browser/components/uitour/test/uitour.html - 
[task 2022-08-23T04:50:18.276Z] 04:50:18     INFO - checking window state
[task 2022-08-23T04:50:18.294Z] 04:50:18     INFO - TEST-START | browser/components/uitour/test/browser_UITour2.js
```
Bug: Blob downloads via <a /> no longer working
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-23 09:32:12+00:00
Resolved: 2022-08-23 14:22:27+00:00

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

Steps to reproduce:

At some point within the last week, I am no longer able to download files in Firefox Nightly that are generated on the client side. This sample code, taken from a popular StackOverflow answer, which works on previous versions of Firefox and in the current Chrome/Edge, is used quite widely on web pages to download content from a blob URL. I find websites like Photopea or WhatsApp, where files are generated in the client, are no longer able to save files. 

I can reproduce this on a fresh installation of Firefox Nightly on macOS. 

```
function saveAs(blob, fileName) {
	if (typeof navigator.msSaveOrOpenBlob !== 'undefined') {
		return navigator.msSaveOrOpenBlob(blob, fileName);
	} else if (typeof navigator.msSaveBlob !== 'undefined') {
		return navigator.msSaveBlob(blob, fileName);
	} else {
		var elem = window.document.createElement('a');
		elem.href = window.URL.createObjectURL(blob);
		elem.download = fileName;
		elem.style = 'display:none;opacity:0;color:transparent;';
		(document.body || document.documentElement).appendChild(elem);
		if (typeof elem.click === 'function') {
			elem.click();
		} else {
			elem.target = '_blank';
			elem.dispatchEvent(new MouseEvent('click', {
				view: window,
				bubbles: true,
				cancelable: true
			}));
		}
                URL.revokeObjectURL(blob);
	}
}

saveAs(new Blob(['Test file'], { mimeType: 'text/plain' }), 'test.txt')
```


Actual results:

No content is downloaded, and Firefox doesn't display any feedback to indicate a failed download. 


Expected results:

The file should be downloaded to disk, or, if the user needs to grant some permission, Firefox should prompt the user to permit downloads.
Bug: Fix onboarding link layout
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-23 12:27:35+00:00
Resolved: 2022-10-11 06:30:14+00:00

+++ This bug was initially created as a clone of Bug #1779219 +++

As per spec @ https://www.figma.com/file/o7FiykrKIyDBgsjEQUYDOr/Quick-actions-in-the-Awesomebar?node-id=7%3A2288
Bug: The "Colorways" modal for existing users is wrongly displayed if an expired theme is applied to the browser
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-08-23 12:29:55+00:00
Resolved: 2022-08-24 21:16:17+00:00

**[Affected versions]:**
- Firefox Beta 105.0a1
- Firefox Nightly 106.0a1 - Build ID: 20220822190304

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

**[Prerequisites]:**
- Have the following prefs in the "about:config" page:
 - "devtools.chrome.enabled" set to "true";
 - "browser.theme.colorway-closet" set to "false"
 - "browser.aboutwelcome.templateMR" set to "true";
- Have the "Browser Console" opened.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Change the system's time to 01/30/2022 and restart the browser.
3. Navigate to the "about:addons" page and select the "Themes" section.
4. Enable an old colorway theme (e.g. Cheese Puff)
5. Change the system time to present and restart the browser.
6. Focus the "Browser Console" and run the `Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog();` code.
7. Navigate through the Onboarding flow for the existing users and observe the displayed modals.

**[Expected result]:**
- The "Colorways" modal is not displayed.

**[Actual result]:**
- The "Colorways" modal is displayed in the Onboarding flow.

**[Additional Notes]:**
- Attached a screen recording of the issue.
Bug: The Upgrading Users modals does not have scroll bars when the browser is resized
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-23 12:54:18+00:00
Resolved: 2023-04-01 05:56:12+00:00

**[Affected versions]:**
- Firefox Nightly 106.0a1 - Build ID: 20220822190304

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

**[Prerequisites]:**
- Have the Firefox browser installed and opened.
- Have the “devtools.chrome.enabled” pref set to true.
- Have the Browser Console opened.(Ctrl+Shift+J)
- Have the “Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog();” syntax copied to clipboard.


**[Steps to reproduce]:**
1. Focus the browser console (Ctrl+Shift+J), paste the “Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog();” string, and press “Enter” key.
2. Modify the height by resizing the browser and observe the elements displayed on the browser’s page.

**[Expected result]:**
- The modals are correctly rendered and have a scroll bar when the browser is resized.

**[Actual result]:**
-  The modals do not have a scroll bar when the browser is resized and a part of the elements cannot be accessed.

**[Notes]:**
- This issue is not reproducible for new users.
- Attached is a screen recording of the issue.
Bug: localStorage out of sync among multiple tabs
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-08-23 15:59:34+00:00
Resolved: 2023-05-26 18:55:45+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15

Steps to reproduce:

While running Selenium test with Firefox 91 with dom.storage.next_gen enabled, localstorage read at unexpected time which results test failure.

Reproducible: occasionally occurs in Selenium test run but do not know the conditions to reproduce it manually

This issue is affecting multiple tests in our web application and we reported this issue in Bug 1751727 while using Firefox 78.3.1.  We now use Firefox 91.12 with dom.storage.next_gen enabled but still observed this issue.



Actual results:

In the test, there are two windows/tabs are opened for the same page of our web application.   When it saves some change, it would update its metadata in localstorage.  When we switch to the 2nd window, it retrieve the old/previous metadata.

I added a timestamp to show when it starts to retrieve the metadata from localstorage.  It turned out the 2nd window was retrieving metadata from localstorage before the saving event occurred.  I attached the following figure to show the logic flow and timing.


Expected results:

In the test, there are two windows/tabs are opened for the same page of our web application.   When it saves some change, it would update its metadata in localstorage.  When we switch to the 2nd window/tab, we retrieve the metadata from localstorage and expect it to be the updated one.
Bug: Fix SecurityError: Node.appendChild: Adopting nodes across docgroups in chrome documents is unsupported on about pages
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-08-23 16:01:39+00:00
Resolved: 2022-11-24 17:53:20+00:00

Screenshots component throws `SecurityError: Node.appendChild: Adopting nodes across docgroups in chrome documents is unsupported` on about pages. Screenshots should work as expected on both about and non about pages
Bug: [Colorway Closet] Changing between Soft/Balanced and Bold themes doesn't switch the modal styling to dark or light mode
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-23 17:51:19+00:00
Resolved: 2022-09-21 13:18:02+00:00

Seen today with the latest Nightly. Didn't work like this yesterday.

When I use the Colorway Closet from either Firefox View or Addons, and switch between light and bold intensity for any color, the modal itself doesn't get updated for light/dark mode.
Bug: [Colorway Closet - about:addons] CTA button label is inconsistent with Firefox View if an expired colorway is enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-23 18:43:31+00:00
Resolved: 2022-09-29 13:13:06+00:00

Currently, the "Try Colorways" and "Change Colorway" buttons label text in about:addons are determined by `BuiltInThemes.isMonochromaticTheme` ([searchfox](https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/toolkit/mozapps/extensions/content/aboutaddons.js#3702,3707-3709)). However, FireFox View uses `BuiltInThemes.isColorwayFromCurrentCollection` ([searchfox](https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/browser/components/firefoxview/colorways-card.mjs#85,89,122,149,166,168,181)). This results in the CTA button text being inconsistent between about:addons and Firefox View. 

about:addons will render "Change Colorway" if any colorway, be it expired or in the active collection, is enabled. On the other hand, Firefox View will only render "Change Colorway" if the active enabled theme is a colorway from the active collection. We should update about:addons accordingly to amend this inconsistency.

STR:
1. Enable an expired colorway (ex. "Cheers" or "Cheese Puff")
2. Go to about:addons and observe CTA button text is "Change Colorway"
3. Go to about:firefoxview and observe CTA button text is "Try Colorways"

Expected: both should be "Try Colorways"
Actual: both are not the same label text and should be consistent ("Try Colorways")
Bug: Fx-View Tab Pickup shows the "Turn on sync" error with a new profile instead of the first setup step
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-23 19:27:56+00:00
Resolved: 2022-09-22 09:20:04+00:00

Its expected that sync isn't configured initially and signing up / signing in to an FxA account will opt the user in to sync automatically, so we shouldn't show this error unless the user is signed in.
Bug: Folders Inside Folders In Bookmarks Bar Does Not Show
Status: NEW
Priority: P5
Created: 2022-08-23 19:53:50+00:00
Resolved: 2023-02-06 16:52:35+00:00

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

Steps to reproduce:

1. Be On The Latest Nightly Firefox Version
2. Have folders inside of your Bookmarks Bar
3. Have another folder inside of that folder. Example: Folder "Test" > Folder "Test 2"
4. Go inside of the folder "Test"
5. Hover your mouse over the nested folder "Test 2".



Actual results:

The contents inside of folder "Test 2" do not slide out or appear, so I am not able to go into those bookmarks inside of the "Test 2" Folder, which is a sub-folder of "Test".


Expected results:

The Folder inside of "Test" ("Test 2") should expand enabling me to view the bookmarks I have inside of the nested folder
Bug: Folders Inside Folders In Bookmarks Bar Does Not Show
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-23 19:55:05+00:00
Resolved: 2022-08-23 21:59:22+00:00

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

Steps to reproduce:

1. Be On The Latest Nightly Firefox Version
2. Have folders inside of your Bookmarks Bar
3. Have another folder inside of that folder. Example: Folder "Test" > Folder "Test 2"
4. Go inside of the folder "Test"
5. Hover your mouse over the nested folder "Test 2".



Actual results:

The contents inside of folder "Test 2" do not slide out or appear, so I am not able to go into those bookmarks inside of the "Test 2" Folder, which is a sub-folder of "Test".


Expected results:

The Folder inside of "Test" ("Test 2") should expand enabling me to view the bookmarks I have inside of the nested folder
Bug: Colorway Closet section on Firefox View page — For Light and Balanced themes, should use the light mode button coloring
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-08-23 20:35:51+00:00
Resolved: 2022-09-29 13:58:34+00:00

In Firefox View's colorway promo, if the user has chosen a Light or Balanced colorway, we should use the white on dark blue (light mode) button coloring.

The current dark mode button can look pretty garish against some of the light background colors.
Bug: AboutWelcome progress bar test fails for noninteger display scaling factors
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-08-23 21:04:18+00:00
Resolved: 2022-10-12 14:01:33+00:00

It's possible for the test [test_aboutwelcome_with_progress_bar](https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/browser/components/newtab/test/browser/browser_aboutwelcome_configurable_ui.js#390-460) to fail if display scaling factor is not an integer. I assume there aren't already any try configurations to test for different scaling factors, or else there would be intermittent failure reports.

Basically it's testing the computed style for `height: 6px`, but it's possible that the computed style is actually `height: 5.33px` or something like that. The progress indicator has no inner height, but rather [a 3px border](https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/browser/components/newtab/content-src/aboutwelcome/aboutwelcome.scss#1301). So, its height varies because the computed border width varies depending on the device pixels to CSS pixels ratio. (border is the only property with subpixel scaling)

That is Firefox's [border subpixel rounding](https://crisal.io/words/2020/06/13/rounding-borders.html) working as intended for 150% display scaling, but the tests don't account for it, so I had to delete them while I was debugging with that test file.

The trouble is it's impossible to know exactly how it's going to round, because it depends on the layout. You could check that it's within a range — for `border-width: 3px` on 2 sides, we should always get 7 > n > 5. But `test_element_styles` doesn't have a comparison option and that would be a bit complicated.

This isn't super important, but the only workarounds I know of are changing scaling factor or temporarily modifying/deleting the test. Changing the scaling factor on Windows 8 and 10 has some discouraging side effects that stick around until reboot (at least for me), so I tend to assiduously avoid it.
Bug: There's too much vertical space between the Tab Pickup and Recently Closed section when the first is collapsed
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2022-08-24 00:36:02+00:00
Resolved: 2022-08-25 11:30:57+00:00

As an artifact of the grid layout, when the Tab Pickup section is collapsed, the content below doesn't move up as expected and leaves too much space. 

Adding `grid-template-rows: masonry` to the `body > main` [grid layout](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/firefoxview.css#99) fixes this.