av9ash/GitBugs huggingface dataset:
Bug: [Colorway Closet] Expiry pill is misaligned
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-07-19 18:21:10+00:00
Resolved: 2022-08-16 13:47:07+00:00

Per UX feedback:
- The vertical alignment of the pill compared to the collection title is off
- It's offset too far to the left when it wraps on the next line

It looks like we might want to tweak the text size and the inner padding of the pill as well.
Bug: [Colorway Closet] Too much white space at the bottom of modal.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-07-19 18:44:06+00:00
Resolved: 2022-08-30 13:59:45+00:00

UX design review mentioned that there is too much white space at the bottom of the closet modal at a larger screen size.

In the XXL mockup, it looks to be that the bottom of the "set colorway" is approx ~189px from the bottom of the modal.
Bug: Intermittent browser/components/customizableui/test/browser_947914_button_zoomOut.js | Uncaught exception in test - undefined - timed out after 50 tries.
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-07-19 18:59:07+00:00
Resolved: 2022-07-27 18:35:12+00:00

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

---
```
[task 2022-07-19T18:46:31.857Z] 18:46:31     INFO - TEST-PASS | browser/components/customizableui/test/browser_947914_button_zoomOut.js | Zoom out button exists in Panel Menu - 
[task 2022-07-19T18:46:31.858Z] 18:46:31     INFO - Buffered messages finished
[task 2022-07-19T18:46:31.859Z] 18:46:31     INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_947914_button_zoomOut.js | Uncaught exception in test - undefined - timed out after 50 tries.
[task 2022-07-19T18:46:31.863Z] 18:46:31     INFO - Leaving test bound 
[task 2022-07-19T18:46:31.864Z] 18:46:31     INFO - GECKO(1646) | MEMORY STAT | vsize 20984329MB | residentFast 1720MB
[task 2022-07-19T18:46:31.865Z] 18:46:31     INFO - TEST-OK | browser/components/customizableui/test/browser_947914_button_zoomOut.js | took 5551ms
[task 2022-07-19T18:46:31.866Z] 18:46:31     INFO - checking window state
[task 2022-07-19T18:46:31.867Z] 18:46:31     INFO - TEST-START | browser/components/customizableui/test/browser_947914_button_zoomReset.js
```
Bug: "Unhandled error: TypeError: can't access property "documentURI", doc is null" error in JS, sometimes with notification "Whoa! Firefox Screenshots went haywire", if you take a screenshot from context menu in video doc background area
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-07-19 21:40:49+00:00
Resolved: 2024-05-16 18:06:26+00:00

STR:
1. Directly view some video, e.g. load this screencast that I posted on GitHub:
https://user-images.githubusercontent.com/426803/179851098-88c9110a-7ff6-49c3-9e25-607963eed17c.webm
2. Right-click the background area (outside the video)
3. Choose "Take a screenshot" from the context menu.
4. Repeat steps 2 and 3 several times.

ACTUAL RESULTS:
* No screenshot is taken.
* Each time you choose "Take a screenshot", this appears in your Web Console (if you have devtools open):
```
Unhandled error: TypeError: can't access property "documentURI", doc is null
    assertIsBlankDocument moz-extension://83b5bab2-1871-46d9-a25b-613a456e74a0/assertIsBlankDocument.js:12
    ui moz-extension://83b5bab2-1871-46d9-a25b-613a456e74a0/selector/ui.js:101
    catcher moz-extension://83b5bab2-1871-46d9-a25b-613a456e74a0/catcher.js:59
 undefined
```
* Some of the time (maybe every 2-3 attempts), I get a system notification saying "Whoa! Firefox Screenshots went haywire" (see attached image)

EXPECTED RESULTS:
Either the screenshot operation should succeed, or we shouldn't show it as an available option, or we should show a more user-friendly notification about why it failed & what the user should do (e.g. they can right-click the actual video and choose "Take Snapshot" if they want, and that seems to work)
Bug: The unable to connect page is not displayed when DNS points to a valid but inexistent address
Status: NEW
Priority: P5
Created: 2022-07-20 13:45:04+00:00
Resolved: 2022-09-06 15:06:09+00:00

**Found in**
* Fx104.0a1

**Affected versions**
* Fx104.0a1

**Affected platforms**
* Windows 10

**Preconditions**
Have a keyword set in your OS hosts file like:
::1 cognizantsoftvision

**Steps to reproduce**
1. Launch Firefox.
2. Set *browser.fixup.dns_first_for_single_words* to true.
3. Open a new tab and type in *cognizantsoftvision* and hit enter.


**Expected result**
* Error page is displayed.

**Actual result**
* A search is performed.

**Regression range**
* This is not a regression.

**Additional notes**
* Please see the discussion in bug 1778655#c3, the last paragraph for more details and context.
* Upon further discussion this might be something related to the localhost redirect, but warants more investigation as the expected result is not reached (the error page).
Bug: A phrase in the connection error page is not bolded as per documentation specs
Status: VERIFIED
Priority: P4
Resolution: FIXED
Created: 2022-07-20 14:23:49+00:00
Resolved: 2022-08-04 12:14:24+00:00

**Found in**
* Fx104.0a1

**Affected versions**
* Fx104.0a1

**Affected platforms**
* Windows 10

**Steps to reproduce**
1. Launch Firefox.
2. Navigate to http://cnn .
3. Inspect the error page.

**Expected result**
* The phrase "If you entered the right address, you can:" is bolded.

**Actual result**
* The phrase is not bolded.

**Regression range**
* Not a regression.

**Additional notes**
* The issue does not occur on Ubuntu 20.04 or macOS.
* Please note that in [figma documentation](https://www.figma.com/file/tcLAFl4pzPbXDvEUzfVTaP/Disable-alternate-fixup-in-the-Address-Bar?node-id=2%3A83) the phrase appears bolded and the difference between OSs is not mentioned.
Bug: open tab next to current do not seem to work properly
Status: UNCONFIRMED
Priority: --
Created: 2022-07-20 19:45:57+00:00
Resolved: 2024-02-27 08:49:45+00:00

Steps to reproduce:

Firefox 91.11.0 ESR - win x64 https://ftp.mozilla.org/pub/firefox/releases/91.11.0esr/win64/

open about:config page:

browser.tabs.insertRelatedAfterCurrent = true


Actual results:

the tab is opened at the end 


Expected results:

the tab should be open after the active one
Bug: "Delete cookies and site data when Firefox is closed" setting does not persist
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-21 01:09:22+00:00
Resolved: 2022-07-21 15:04:17+00:00

Steps to reproduce:

Open Firefox and got to "about:preferences#privacy"
Check box for "Delete cookies and site data when Firefox is closed"
Restart Firefox
Go back to "about:preferences#privacy"
Notice "Delete cookies and site data when Firefox is closed" option is unchecked


Actual results:

"Delete cookies and site data when Firefox is closed" option resets to disabled after Firefox is restarted.


Expected results:

"Delete cookies and site data when Firefox is closed" option should persist between restarts when enabled.
Bug: Intermittent [TV] browser/components/newtab/test/browser/browser_asrouter_bug1761522.js | Cleanup function threw an exception - OperationError: Could not remove the non-empty directory at C:\Users\task_165836448695152\AppData\Local\Temp\tmp9tefw1jo.mozr
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-07-21 04:35:47+00:00
Resolved: 2022-08-16 15:38:17+00:00

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

---
```
INFO - TEST-PASS | browser/components/newtab/test/browser/browser_asrouter_bug1761522.js | asrouter.ftl content matches expected - "asrouter-test-string = Test Test Test\n" == "asrouter-test-string = Test Test Test\n" - 
[task 2022-07-21T03:04:44.564Z] 03:04:44     INFO - Leaving test bound test_asrouter
[task 2022-07-21T03:04:44.564Z] 03:04:44     INFO - Buffered messages finished
[task 2022-07-21T03:04:44.565Z] 03:04:44     INFO - TEST-UNEXPECTED-FAIL | browser/components/newtab/test/browser/browser_asrouter_bug1761522.js | Cleanup function threw an exception - OperationError: Could not remove the non-empty directory at C:\Users\task_165836448695152\AppData\Local\Temp\tmp9tefw1jo.mozrunner\settings\main\ms-language-packs.
[task 2022-07-21T03:04:44.565Z] 03:04:44     INFO - Specify the `recursive: true` option to mitigate this error
[task 2022-07-21T03:04:44.566Z] 03:04:44     INFO - GECKO(5604) | MEMORY STAT | vsize 2112465MB | vsizeMaxContiguous 65213088MB | residentFast 330MB | heapAllocated 153MB
[task 2022-07-21T03:04:44.566Z] 03:04:44     INFO - TEST-OK | browser/components/newtab/test/browser/browser_asrouter_bug1761522.js | took 143ms
```
Bug: FF loses tabs of normal window when closing private window last
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-21 09:14:24+00:00
Resolved: 2022-10-14 12:17:06+00:00

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

Steps to reproduce:

Having both opened: One session in normal mode, one in private mode. FF is configured to start with the last session (Common > Start > Check for "Open prior tabs and windows". Startpage is configured to 3 custom addresses. There are several tabs opened which are not in the startpage. Closing the regular window before the private. Closing the private. Start FF again in normal mode (regular start).
This behaviour is not only in the recent FF version. Not tested on any mobile, desktop only.


Actual results:

FF starts with the 3 custom addresses but overrides the "start with the last session"


Expected results:

All tabs should be re-opened instead of only the ones from from the start page if this checkbox is checked. Perhaps add remark to labeling. Or add another checkbox or bool-switch to let user choose the desired behaviour.
Bug: Gmail is blank.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-21 09:43:53+00:00
Resolved: 2022-07-21 11:15:40+00:00

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

Steps to reproduce:

I opened Gmail landing page.


Actual results:

Gmail is blank. Source code shows nothing. Can't use the page. Gdoc loads on Firefox. Gmail loads on every other browser. What are they messing with Firefox? It's ridiculous.


Expected results:

Gmail should load. 
Or I should quit using Firefox?
Bug: Barcode is incorrectly rendered in PDF viewer
Status: NEW
Priority: --
Created: 2022-07-21 12:29:50+00:00
Resolved: 2025-02-04 14:12:46+00:00

**Found in**

Firefox 103.0

**Affected versions**

Firefox 103.0
Firefox 104.0a1

**Affected platforms**

Windows 10
macOS 12.0
Ubuntu 20

**Steps to reproduce**

Launch Firefox
Go to https://pdf.ninja/interactiveform_enabled.pdf and scroll to the second page

**Expected result**

The barcode lines are visible

**Actual result**

The barcode lines are replaced by a string of "0"

**Regression range**

Will see for a regression
Bug: Glean default search engine data is reporting errors when submitting an empty submission URL
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-07-21 14:19:35+00:00
Resolved: 2022-08-22 13:19:17+00:00

Missed a case in bug 1775312. Specifically for private search engine's submission url, it's still being set to an invalid URL [here](https://searchfox.org/mozilla-central/rev/a352cc827575823676717d53766c39710b54201a/toolkit/components/search/SearchService.sys.mjs#2919):

```js
    if (info.defaultPrivateSearchEngineData) {
      Glean.searchEnginePrivate.displayName.set(
        info.defaultPrivateSearchEngineData.name
      );
      Glean.searchEnginePrivate.loadPath.set(
        info.defaultPrivateSearchEngineData.loadPath
      );
      Glean.searchEnginePrivate.submissionUrl.set(
        info.defaultPrivateSearchEngineData.submissionURL ?? "blank:"
      );
      Glean.searchEnginePrivate.verified.set(
        info.defaultPrivateSearchEngineData.origin
      );
    } else {
      Glean.searchEnginePrivate.displayName.set("");
      Glean.searchEnginePrivate.loadPath.set("");
      Glean.searchEnginePrivate.submissionUrl.set(""); // <= HERE
      Glean.searchEnginePrivate.verified.set("");
    }
```

I shoulda caught it in review. Whoops!
Bug: Remove Duckduckgo  from default search engines for private windows because it allows Microsoft trackers
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-07-21 20:10:29+00:00
Resolved: 2024-04-15 12:20:15+00:00

According to mulitple reliable tech news sources, it is clearly known to public that Duckduckgo allows Microsoft trackers and it is against privacy and Mozilla's mission. Please consider removing it from default search engines for private windows. Thank you very much.
Bug: Crash [@ mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest] or [@ mozilla::dom::ExternalHelperAppParent::RecvOnDataRequest]
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-22 08:42:24+00:00
Resolved: 2023-01-17 04:51:16+00:00

In experimental IPC fuzzing, we found the following crash on mozilla-central revision 375d42ba2f83+:

    =================================================================
    ==2126==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fffd24f7256 bp 0x7fffffdc3390 sp 0x7fffffdc3370 T0)
        #0 0x7fffd24f7256 in mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest(nsTString<char> const&) uriloader/exthandler/ExternalHelperAppParent.cpp:115:24
        #1 0x7fffd2565544 in mozilla::dom::PExternalHelperAppParent::OnMessageReceived(IPC::Message const&) objdir-ff-asan-oldc/ipc/ipdl/PExternalHelperAppParent.cpp:195:52
        #2 0x7fffdfabb716 in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) objdir-ff-asan-oldc/ipc/ipdl/PContentParent.cpp:6615:32
        #3 0x7fffd19d7ce3 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) ipc/glue/MessageChannel.cpp:1749:25
        [...]
        #22 0x7fffeafd14de in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:5942:8



The issue here is that methods in `ExternalHelperAppParent` lack checks for `Init` being called prior to other methods, so `mListener` ends up being `nullptr`. Adding those checks should be straightforward. Keeping bug s-s because parent bug is still s-s.
Bug: Firefox uBlock Origin issue: cannot open any websites, 100% single CPU core use
Status: RESOLVED
Priority: --
Resolution: INACTIVE
Created: 2022-07-22 10:12:06+00:00
Resolved: 2022-09-02 15:31:46+00:00

Steps to reproduce:

Two friends of mine have had the same issue: after upgrading to Firefox 102.x their installations became totally unusable: Firefox starts, and then one CPU core becomes 100% busy at which point you cannot open any websites as they all seem to freeze.

At the same time you still could open `about:preferences` and `about:addons`. As for the latter when disabling add-ons there's a considerable delay, almost a dozen of seconds. Disabling uBlock Origin has fixed the issue momentarily, at which point I deleted the add-on, installed it again and then Firefox started working as brand new.

I wonder if it's a known issue and if it's already been addressed/fixed.

Unfortunately I cannot provide any more information, since I've fixed the affected profiles and there's no way to debug the issue further.

Still in my opinion it should have never happened because people were basically left with 100% broken Firefox installations and, if not for me, both would have abandoned Firefox. As a non-IT person it's impossible to figure it all out. Thankfully I'm an IT specialist, so it took me a minute to fix both PCs.

As for PCs: they are totally unrelated, one is Windows 10 64, another one Windows 8.1 64 with all updates installed, running Firefox 102.0 x86-64.

Again, I now cannot follow up because one profile is fixed permanently and the second one for which I actually made a backup (so that the issue can be debugged) is not accessible (a remote PC with no remote access).

If Mozilla developers are interested, next week I can probably fetch the second profile and send it to the interested parties privately via email.
Bug: Improper tab-to-search entries for some strings followed by dot
Status: NEW
Priority: P3
Created: 2022-07-22 12:43:55+00:00
Resolved: 2024-04-08 15:26:53+00:00

**Found in**
* Nightly 104.0a1 2022-07-21

**Affected versions**
* all

**Affected platforms**
* all

**Steps to reproduce**
1. Type `amazon` in address bar - `Amazon` tab-to-search is shown on the second row
2. Type `amazon.` - `Google` tab-to-search is shown on the second row
3. Type `amazon.c` in address bar - `Amazon` tab-to-search is shown on the second row
4. Repeat with `bing.`, `baidu.`, `youtube.`, `meme.`, `blog.`, `support.` and make sure the domain is not autofilled

**Expected result**
* Google tab-to-search shouldn't be offered for another search engines domains
* No tab-to-search entry for other strings followed by dot

**Actual result**
* Google tab-to-search entry is displayed in the second row on the address bar panel. The typed string is deleted when the tab-to-search entry is selected by Tab or mouse click.

**Regression range**
* First bad: 2021-06-23
* Last good: 2021-06-22
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95970359b68e4d468d903493f36471838502a088&tochange=1f8cbba9a51a930e1f81bd0f711faf057529e4d1
* mozregression couldn't bisect further than this

**Additional notes**
* This is not reproducible for `duckduckgo.` and `wikipedia.` strings
Bug: Pocket newtab collections and recent saves conflict
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-22 15:55:52+00:00
Resolved: 2022-07-23 09:18:09+00:00

If a collection card grid is displayed, and recent saves is on, we end up with a recent saves in the collection grid AND the regular grid.

This is because collection card grid uses the generic card grid with some modified props, but recent saves prop was built into the base card grid.

This should instead be a prop passed to the card grid of choice inside discoverty stream base.

Probably not a huge issue because I don't see us using collection card grid any time soon, but should be fixed. It is an easy fix, and while collection card grid exists in code, it should be left in a not broken state.
Bug: newtab package.json requires old node and npm versions (10.23.*, 6.14.10) and has package version conflicts
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-07-22 19:21:53+00:00
Resolved: 2023-05-05 15:54:39+00:00

We have an [engines configuration in package.json](https://searchfox.org/mozilla-central/rev/3f1856fc5adc6b1662e5388c67e33fa322c5b323/browser/components/newtab/package.json#64-69) which requires an old version of node. If you use `mach npm` and `mach node` [as instructed by the docs](https://firefox-source-docs.mozilla.org/browser/components/newtab/docs/index.html) there are module version problems. The npm install step produces this error: 

```
pm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: 'activity-streams@1.14.3',
npm WARN EBADENGINE   required: {
npm WARN EBADENGINE     firefox: '>=45.0 <=*',
npm WARN EBADENGINE     '//': 'when changing node versions, also edit .nvmrc',
npm WARN EBADENGINE     node: '10.23.*',
npm WARN EBADENGINE     npm: '6.14.10'
npm WARN EBADENGINE   },
npm WARN EBADENGINE   current: { node: 'v16.0.0', npm: '7.10.0' }
npm WARN EBADENGINE }
```
And the `npm run bundle` step fails. I think we need to update that package.json with the same versions that `mach` is using (and ideally find a way to tie the 2 together).
Bug: When mass selecting history with shift+click, your position down the page decreases dramatically.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-22 21:21:40+00:00
Resolved: 2022-08-04 14:25:20+00:00

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

Steps to reproduce:

In order to replicate this, for me at least, all you need to do is go in to the manage history tab and scroll down a few dozen entries. From there, you just hold shift and click. 


Actual results:

In my experience, I can be down 300 entries or more, but as soon as I press anything I am shot up nearly to the top and only select about 20 entries or so.


Expected results:

I expect that it would select the entry I actually clicked. I think that if you click any entry that the "Name, URL, Tags" organization tab would appear over it will act as null and re-select your previous selected entry. Tested this a few times and it has been 100% consistent, so I believe it's the cause.
Bug: screenshot zoomed/cropped when resistFingerprinting enabled
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-07-23 05:44:38+00:00
Resolved: 2024-06-25 09:12:12+00:00

Steps to reproduce:

test performed on macOS 12.x on a retina display
start with clean profile
enable privacy.resistFingerprinting
visit https://www.mozilla.org/en-US/
scroll to bottom of page to make sure all elements loaded/rendered
take full screenshot


Actual results:

saved screenshot is zoomed/cropped


Expected results:

should match the screenshot with privacy.resistFingerprinting disabled (attached)
Bug: Download filename missing extension
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-23 12:09:12+00:00
Resolved: 2022-07-24 06:53:49+00:00

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

Steps to reproduce:

From Firefox on Windows 10, open the (Apache Friends)[1] homepage, then download the Windows version of XAMPP. The download URL is `https://downloadsapachefriends.global.ssl.fastly.net/8.1.6/xampp-windows-x64-8.1.6-0-VS16-installer.exe?from_af=true`.

The download’s MIME type is technically incorrect: `application/x-msdos-application`

[1]: https://www.apachefriends.org/


Actual results:

The download produces a file named `xampp-windows-x64-8.1.6-0-VS16-installer`.


Expected results:

The download should produce a file named `xampp-windows-x64-8.1.6-0-VS16-installer.exe`.