av9ash/GitBugs huggingface dataset:
Bug: Intermittent uriloader/exthandler/tests/mochitest/browser_extension_correction.js | Downloaded file should match somefile - Got "somefile(1)", expected "somefile"
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-10-26 03:16:08+00:00
Resolved: 2022-07-26 00:15:53+00:00

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

---
```
[task 2021-10-26T03:01:40.999Z] 03:01:40     INFO - TEST-PASS | uriloader/exthandler/tests/mochitest/browser_extension_correction.js | Downloaded file should match somefile - 
[task 2021-10-26T03:01:40.999Z] 03:01:40     INFO - Checking binary/octet-stream
[task 2021-10-26T03:01:41.000Z] 03:01:41     INFO - Download changed!
[task 2021-10-26T03:01:41.000Z] 03:01:41     INFO - Download changed!
[task 2021-10-26T03:01:41.001Z] 03:01:41     INFO - Download succeeded or errored
[task 2021-10-26T03:01:41.002Z] 03:01:41     INFO - Buffered messages finished
[task 2021-10-26T03:01:41.003Z] 03:01:41     INFO - TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_extension_correction.js | Downloaded file should match somefile - Got "somefile(1)", expected "somefile"
```
Bug: [MSIX] Beta installed from MS Store is named FirefoxBeta
Status: NEW
Priority: --
Created: 2021-10-26 07:17:40+00:00
Resolved: 2022-02-18 17:45:09+00:00

**Affected versions**
- Firefox 94.0b9 MSIX

**Affected platforms**
- Windows 11

**Steps to reproduce**
1. Install Firefox Beta
2. Open Start and search for Firefox

**Expected result**
- Firefox is named "Firefox Beta"

**Actual result**
- Firefox is named "FirefoxBeta"

**Regression range**
- The issue is related to Bug 1736659

**Additional notes**
- The issue can be seen in the attachment
Bug: [MacOS] "Show you how" text is not centered inside the button
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-10-26 07:29:35+00:00
Resolved: 2021-11-26 11:33:35+00:00

**Affected versions**
* 95.0a1 (2021-10-24)

**Affected platforms**
* MacOS 10.15

**Steps to reproduce**
1. Open Firefox with a new profile.
2. Open multiple tabs.
3. Quit firefox.
4. Reopen firefox with the profile from step 1.

**Expected result**
* Infobar is shown and the "Show you how" text is aligned in the center of the button.

**Actual Result**
* Infobar is shown and the "Show you how" text is not aligned in the center of the button.

**Regression range**

* last good build: https://hg.mozilla.org/mozilla-central/rev/ef7b596bb385f46280eb1492009bf8fb541e17db
* first bad build: https://hg.mozilla.org/mozilla-central/rev/3cf700ab977a298e19a00f1ec66d14939766955b

* Here is the regression range: "https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ef7b596bb385f46280eb1492009bf8fb541e17db&tochange=3cf700ab977a298e19a00f1ec66d14939766955b"


**Additional notes**
* Only the nightly version is affected by this issue.
Bug: [Experiment] The Firefox logo icon is wrongly displayed instead of the "umbrella" one on the "emotive-pin-firefox-modal" from the "Treatment B" branch
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-10-26 09:13:16+00:00
Resolved: 2022-04-19 18:59:03+00:00

**[Affected versions]:**
- Firefox Release 93.0 - Build ID: 20210927210923
- Firefox Beta 94.0 - Build ID: 20211025220926

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

**[Prerequisites]:**
- Have a Firefox profile older than 28 days.
- Have this [user.js](https://drive.google.com/file/d/1W7JYZPsxuTUfU6mp19cY3WFdGp6LF030/view?usp=sharing) file saved to your PC.
- Have at least 1 URL accessed in the last 13 days.
- The Firefox browser is not pinned to the taskbar.

**[Steps to reproduce]:**
1. Navigate to the profile folder from prerequisites and paste the "user.js" file.
2. Open the browser with the profile from prerequisites.
3. Observe the icon from the "Pin to taskbar" modal.

**[Expected result]:**
- An "umbrella" icon is displayed in the top part of the modal.
 
**[Actual result]:**
- The Firefox logo is displayed instead.

**[Notes]:**
- Attached a screenshot of the issue.
Bug: Cancel/ Add buttons are moved when Edit this site is opened
Status: NEW
Priority: P3
Created: 2021-10-26 11:26:40+00:00
Resolved: 2024-09-23 22:03:58+00:00

*Affected versions*
* 95.0a1 (20211020093007)
* 94.0 (20211025220926)

*Affected platforms*
* Windows 10 x64
* macOS 10.15
* Ubuntu 21.04



*Steps to reproduce*
1. Open Firefox and click on `Edit this site` from the Top Sites section.
2. Observe the new window Cancel/ Add buttons.







*Expected result*
* Panel is opened as expected.


*Actual result*
* Cancel/ Add buttons are moved and resized when the window is opened.

*Regression range*
* From what I saw this started with bug 1613705. After this bug, the Cancel button is slighty moved when the window is opened. This is harder to be seen.

* Then after bug 1727321, the Add button is moving as well.







*Notes*
* Attached a screen recording.
Bug: Edit this site button remains selected if Esc is used to close it's corresponding window
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-10-26 11:52:40+00:00
Resolved: 2024-01-18 21:42:55+00:00

*Affected versions*
* 95.0a1 (20211020093007)
* 94.0 (20211025220926)
* 93.0 (20210927210923)
* 91.2.0esr (20210927140538)
* 78.15.0esr (20210927121355)

*Affected platforms*
* Windows 10 x64
* macOS 10.15
* Ubuntu 21.04



*Steps to reproduce*
1. Open Firefox and click on `Edit this site` from the Top Sites section.
2. Hit Esc key.







*Expected result*
* Edit this site button is not displayed if not hovered.


*Actual result*
* Edit this site button remains in the selected state.

*Regression range*
* I don’t think this is a regression, the Edit this site button remains selected on Nightly 69.0a1(2019-05-31) when the functionality to exit with Esc key was added.






*Notes*
* Attached a screen recording.
* This can be reproduced if the `Edit this site button` is dragged. Same on `Open Menu button`
Bug: Personalize new tab toggles and checkbox are not so visible with dark theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-10-26 12:26:42+00:00
Resolved: 2021-10-26 15:17:14+00:00

*Affected versions*
* 95.0a1 (20211020093007)
* 94.0 (20211025220926)


*Affected platforms*
* Windows 10 x64
* macOS 10.15
* Ubuntu 21.04

*Preconditions*
* Dark theme

*Steps to reproduce*
1. Open Firefox and click on the `Personalize new tab` button.
2. Observe the checkbox and the toggles.







*Expected result*
* The checkbox and toggles are visible.


*Actual result*
* Toggles and checkbox are not so visible.

*Regression range*
* Last good revision: 462b8ab0d119d85c044a1332446b609786fcabc7
First bad revision: 4d1d81ae7b7edc5668d65b6927d907feab8d0e21
 Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=462b8ab0d119d85c044a1332446b609786fcabc7&tochange=4d1d81ae7b7edc5668d65b6927d907feab8d0e21








*Notes*
* Attached a screenshot.
Bug: Aero Glass Effect on Windows 7 looks more white than it should on the Firefox Window.
Status: NEW
Priority: --
Created: 2021-10-26 14:46:32+00:00
Resolved: 2021-10-29 20:16:55+00:00

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

Steps to reproduce:

Opening Firefox on Windows 7 Build 7601 (may also happen in other builds), with Aero Glass enabled.


Actual results:

On the Firefox window, the top bar looks more white than it should (also near the sides there is a cut between the improperly shown area and the properly shown area


Expected results:

The zone with Aero Glass effect on the Firefox window should not have a different tone than the one set by the Aero Glass theme in Windows 7.
Bug: Intermittent browser/components/sessionstore/test/browser_broadcast.js | sessionStorage data has been merged correctly to prevent data loss - Got "browser_broadcast.js-initial-value-1635251560725", expected "on-tab-close-racy"
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-10-26 15:10:24+00:00
Resolved: 2021-11-29 06:07:17+00:00

**Filed by:** archaeopteryx [at] coole-files.de
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=356060620&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/aJTRbhVXR1O84NscLIZQew/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2021-10-26T12:32:45.571Z] 12:32:45     INFO - TEST-PASS | browser/components/sessionstore/test/browser_broadcast.js | sessionStorage data has not been overwritten - 
[task 2021-10-26T12:32:45.572Z] 12:32:45     INFO - Leaving test bound flush_on_settabstate
[task 2021-10-26T12:32:45.573Z] 12:32:45     INFO - Entering test bound flush_on_tabclose_racy
[task 2021-10-26T12:32:45.574Z] 12:32:45     INFO - Buffered messages finished
[task 2021-10-26T12:32:45.575Z] 12:32:45     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_broadcast.js | sessionStorage data has been merged correctly to prevent data loss - Got "browser_broadcast.js-initial-value-1635251560725", expected "on-tab-close-racy"
[task 2021-10-26T12:32:45.576Z] 12:32:45     INFO - Stack trace:
[task 2021-10-26T12:32:45.577Z] 12:32:45     INFO - chrome://mochikit/content/browser-test.js:test_is:1364
[task 2021-10-26T12:32:45.578Z] 12:32:45     INFO - chrome://mochitests/content/browser/browser/components/sessionstore/test/browser_broadcast.js:flush_on_tabclose_racy:137
[task 2021-10-26T12:32:45.579Z] 12:32:45     INFO - Leaving test bound flush_on_tabclose_racy
```
Bug: Search engines of a same session present in pages 'about:preferences#search' and 'about:support' are not synchronized, neither are the search engines of a session of troubleshoot mode
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-10-26 15:49:43+00:00
Resolved: 2021-10-29 12:31:04+00:00

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

Steps to reproduce:

No manual modifications made in session of troubleshoot mode.

1. Select an interface language for the profile default-release that differs from the application build language;
2. In 'about:preferences#search' page, remove some search engines from the group, so that the resulting situation matches the one illustrated in attachment;
3. Switch to a session of troubleshoot mode and inspect the search engines present in the 'about:preferences#search' page. Make a note of it;
4. Reopen the profile default-release and select the interface language matching the application build language;
5. In 'about:preferences#search' page, inspect the list of present search engines;
6. Open the 'about:support' page.


Actual results:

- The lists of search engines exhibited at steps 5. and 3. are identical.
- The list of add-ons reported at step 6. are not synchronized with the ones at step 2.



Expected results:

- The lists of search engines exhibited at steps 5. and 2. to be synchronized and therefore identical.
- The add-ons reported in step 6. to be synchronized with the ones present at step 2.
Bug: "Save To Pocket" panel is empty when launched from overflow menu
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-10-26 18:55:12+00:00
Resolved: 2021-11-19 07:30:45+00:00

The "Save To Pocket" button sits in an overflow panel in the main toolbar. It is now completely empty for me on a M1 Macbook Air.

This does not reproduce on a clean profile.

Bisecting gets to the following range, at which point all builds start crashing on startup:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c11d60ea8989f78f258f4e30a968a779af737436&tochange=06d659a9bb93bf87ed51070d6a861e6e60bff6d7

This contains: https://bugzilla.mozilla.org/show_bug.cgi?id=1693582

Which seems highly relevant.
Bug: Inaccurate claims
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-10-26 22:39:19+00:00
Resolved: 2021-10-27 21:55:44+00:00

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

Steps to reproduce:

Firefox markets and profiles itself as the privacy browser, and have in the past expressed approval for the idea of default settings being relevant for respecting privacy.

At the same time, there are tons of types of telemetry on by default, and the documents now list that a number of technical solutions for tracking the user, even down to transparent pixels.

This is trojan horse-level misrepresentation. People, including me, expect descriptions to be accurate, and when they find out about things like the aforementioned, all credibility is blown out of the water.


Actual results:

In short, there is no privacy by default. There also is no overview of _ALL_ data transmissions done behind the scenes, and the 2000 or so settings in the about:config have no documentation. 


Expected results:

In order to stay credible - or even used (by e.g. me) - the following changes have to take place: 

1. All tracking, telemetry, profiling, product pushing, experiment participations must be off by default
2. There needs to be a settings page with every single setting that pertains to anything relating to the above
3. The about:config-list needs a clear, unambiguous, and fully disclosing definition next to it

Until the above is instated, any claims about being a privacy-oriented browser are false marketing. Unbelievably disappointed.
Bug: No longer ask me "What should Nightly do with this file?" when click on ".zip", ".tar.gz", ".tar.bz2", ".msix" link
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-10-27 00:08:16+00:00
Resolved: 2021-10-27 12:19:12+00:00

Steps to reproduce:
0. Start Nightly95.0a1 with new pofile
1. Open https://ftp.mozilla.org/pub/firefox/nightly/2021/10/2021-10-26-09-03-55-mozilla-central/
2. Click on `firefox-95.0a1.en-US.win64.zip`

Actual results:
No the helper dialog popup.
Start download automatically.

Expected results:
A helper dialog "What should Nightly do with this file?" should pop up to let you choose whether to open or download the file.


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=216de3cdebc9db25336b56380f23a20252d7e555&tochange=3de56e38f3c87f33a1e7849701edb3c62bc472a5
Bug: Download "could not be saved, because an unknown error occurred." in nightly
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-10-27 00:28:41+00:00
Resolved: 2021-12-10 05:59:49+00:00

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

Steps to reproduce:

Open a website and click on a link which tries to download a file.


Actual results:

Error message with " could not be saved, because an unknown error occurred. Try saving to a different location." appears, see attached screenshot "download-not-working.png"


Expected results:

Ask if I want to save or open the download.

I tested this problem with mozregression, and it said that it was caused by https://phabricator.services.mozilla.com/D129398 and indeed, if I disable "browser.download.improvements_to_download_panel", it's working again as before, so it's related to that setting now being enabled by default.
Bug: No longer ask me "Would you like to save this file?" when click on ".exe", ".mar", ".msix" link
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-10-27 01:15:01+00:00
Resolved: 2021-10-27 12:18:58+00:00

Steps to reproduce:
0. Start Nightly95.0a1 with new pofile
1. Open https://ftp.mozilla.org/pub/firefox/nightly/2021/10/2021-10-26-09-03-55-mozilla-central/
2. Click on Firefox Installer.en-US.exe

Actual results:
No the helper dialog popup.
Start download automatically.

Expected results:
A dialog "Would you like to save this file?" should pop up to let you choose whether to save or cancel.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=216de3cdebc9db25336b56380f23a20252d7e555&tochange=3de56e38f3c87f33a1e7849701edb3c62bc472a5
Bug: It is too easy for users, especially new users, to press F12 rather than F11
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-10-27 03:13:37+00:00
Resolved: 2021-10-29 13:03:18+00:00

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

Steps to reproduce:

I wished to make a website fullscreen. I misremembered F11 (which does indeed produce fullscreen) as F12 or else I hit F12 when I meant to press F11. 


Actual results:

A load of developer stuff comes up. Were I a less technical and/or new Firefox user, I would be considerably theown by this and I would wonder how to get rid of that stuff. I might even think that something had gone wrong with my browser.


Expected results:

The developer stuff needs to be remapped to another key, surely. Shift-F12 perhaps - and with unmodified F11 set to do nothing? I am surprised there is no extant bug report about this matter (and indeed surprised that the situation with Firefox, in this respect, is as it is; if Firefox wants to keep new users, then it should not scare them off with the developer console stuff).
Bug: Visible delay/lag in fluent translation of context menuitems
Status: NEW
Priority: P3
Created: 2021-10-27 04:30:39+00:00
Resolved: 2024-07-23 16:56:56+00:00

Maybe this should belong in Localization Infrastructure and Tools, I'm not really sure what the genesis of the problem is.

It's kind of hard to describe so see the attachment.

STR:
- Open 5-10 tabs.
- Multiselect some of them.
- Right click one of the multiselected tabs.
- Context menuitems like "Move Tabs", "Close Tabs", "Send x Tabs to Device" are of plural form.
- Now, without changing the multiselection, right click one of the non-multiselected tabs.
- The context menu opens again. Now those context menuitems that were previously plural are singular. But the labels change _after_ the context menu has visible opened. I checked and the setting of l10n attributes or IDs happens on popupshowing. So those attributes are changed before the popup is visually displayed. But the labels themselves, the visual text you see, are not shown until after the popup is displayed.
- Repeat so you can see it happens every time.

For that reason I think the problem is simply that l10n is slow to update the label. Because the popup is only going to wait until javascript execution on popupshowing is finished. But setting `l10n-id` or `l10n-attrs` finishes without a hitch before the label has changed.

That is, complete translation (of the text content, value, tooltiptext or whatever attribute) does not block the javascript method call that initiated the translation. Whether it's `document.l10n.setAttributes` or just `el.setAttribute("l10n-id", "something")`, there's naturally gonna be some time in between the setting of the l10n attribute and fluent setting the final target attribute or content with the actual localized text.

Which is unavoidable obviously and I'm not saying that stuff should be blocking, but it seems to be slower than ideal. Also, I don't think it has always been like this. I only noticed it a couple months ago and I had been closely working with that context menu for months before that since I made several autoconfig scripts that add new submenus and menuitems (also with dynamic plural forms) to that menu.

Back then the problem did not seem to exist. My custom menuitems still adjust plurality without any visible lag, because they always set label attribute directly instead of using fluent, as compatible strings didn't exist for me to repurpose. So I just mean that I was messing with the context menu in the same way to test my own scripts, doing exactly what I do in the animation, alternating between plural and singular rapidly. And I never noticed a lag in the built-in menuitems until a couple months ago. So that's why I assume there doesn't need to be a lag, there must be some way it can be sped up enough that it happens before the first paint
Bug: Flicker when changing rows inside Personalize new tab window
Status: NEW
Priority: --
Created: 2021-10-27 07:26:29+00:00
Resolved: 2024-01-19 17:30:52+00:00

*Affected versions*
* 95.0a1 (20211026214417)
* 94.0 (20211025220926)
* 93.0 (20210927210923)
* 91.2.0esr (20210927140538)


*Affected platforms*
* Windows 10 x64
* Ubuntu 21.04



*Steps to reproduce*
1. Open Firefox and click on `Edit this site` from the Top Sites section.
2. Use the keyboard to change rows.







*Expected result*
* Rows are changed as expected with no visual glitches.


*Actual result*
* Small flicker can be seen.

*Regression range*
* Not a regression, reproducible after bug 1703941.








*Notes*
* Attached a screen recording.
* The issue can be reproduced while using the mouse to change rows as well but with the mouse is more intermittent.
Bug: Selections are pushed out by the checkmark in the dropdown found in "Personalize new tab" when zoomed
Status: NEW
Priority: --
Created: 2021-10-27 07:33:23+00:00
Resolved: 2021-11-24 00:17:40+00:00

**Affected versions**
- Firefox 94.0
- Firefox 95.0a1

**Affected platforms**
- macOS 10.15 & 12.0.1

**Steps to reproduce**
1. Launch Firefox
2. Zoom the new tab page to >200%
3. Click the gear to personalize the new tab page
4. Select the dropdown for the number of rows found in "Shortcuts"

**Expected result**
- The selections are centered in the dropdown

**Actual result**
- Depending on the zooming levels, the selections are pushed out by the checkmark

**Regression range**
- Will see for a regression

**Additional notes**
- The issue can be seen in the attachment
- Only macOS seems to have the checkmark selection in the dropdown.
Bug: Potentially misspelled Telemetry Scalars
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-10-27 11:04:05+00:00
Resolved: 2021-11-03 15:27:34+00:00

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

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1737868#c3 specifically ```browser.ui.interaction.pinned_overflow-menu - Unknown scalar.```

Googling the error brings a bunch of identical hits. Looking into Scalars.yaml, it looks like pinned_overflow_menu is misspelled or being misrecorded.
Bug: 'New Window' option appears alongside 'New private window' in Proton hamburger menu when browser.privatebrowsing.autostart is true
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2021-10-27 11:45:58+00:00
Resolved: 2022-07-27 17:06:40+00:00

In the legacy File menu and in right-click context menus, 'New Window' related options are hidden when 'Always use private browsing mode' is ticked in about:preferences#privacy and instead only private window options are visible. 

Additionally, the 'New private window' command in the Proton hamburger menu has 'Ctrl+Shift+P' as the shortcut, whereas in the legacy File menu it is 'Ctrl+N' (both shortcuts work however).

When in private browsing only mode, only the 'New private window' item should be available in the Proton hamburger menu, and the displayed shortcut should be 'Ctrl+N'
Bug: About Firefox window appears in top left for an instant before moving to the center
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-10-27 14:54:27+00:00
Resolved: 2023-06-02 15:22:28+00:00

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

Steps to reproduce:

Opened up Firefox -> About Firefox menu


Actual results:

The popup appears misplaced in top-right for a split second.


Expected results:

It should have a consistent location (e.g. in center to where it moves almost immediately anyways)
Bug: Lockwise freezes when opening
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-10-27 19:14:14+00:00
Resolved: 2022-04-05 09:49:29+00:00

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

Steps to reproduce:

Open the lockwise.


Actual results:

Lockwise freezes when opening. It takes around 1 minute to appear logins. System config is Intel i5 with 8gb RAM.


Expected results:

Lockwise should load all logins instantly.