av9ash/GitBugs huggingface dataset:
Bug: UrlbarValueFormatter generates confusing console logs in tests when resizing window
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-12-04 21:39:31+00:00
Resolved: 2022-12-07 09:46:58+00:00

[See here for a frequent example](https://treeherder.mozilla.org/logviewer?job_id=398507779&repo=autoland&lineNumber=7135-7138).

The code path for this issue goes like this:
1. The [browser test](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/tests/browser/browser_feature_callout_resize.js) resizes the window, which apparently can happen while the urlbar input is valueless
2. Resizing invokes [UrlbarValueFormatter's resize handler](https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/browser/components/urlbar/UrlbarValueFormatter.sys.mjs#491)
3. This calls _ensureFormattedHostVisible with no metadata argument after 100ms,
4. which [calls _getUrlMetaData](https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/browser/components/urlbar/UrlbarValueFormatter.sys.mjs#105),
5. which [calls Services.uriFixup.getFixupURIInfo](https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/browser/components/urlbar/UrlbarValueFormatter.sys.mjs#149-152) (passing the input value, which is undefined at this point),
6. which [explicitly throws if no url is passed](https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/docshell/base/URIFixup.sys.mjs#301-306).
7. Although the exception is technically handled by the trycatch block in _getUrlMetaData, that apparently doesn't prevent it from being logged (I'm assuming but don't actually know if that's expected behavior in general).

Idk exactly why the input value is undefined — looking at the [context of the test](https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/browser/components/firefoxview/tests/browser/browser_feature_callout_resize.js#32-48), it seems like at every point when the window is resized the urlbar input value should be `about:firefoxview`. But clearly I'm missing something. I thought maybe it was the cleanup function, which does call resizeTo on the window after the Firefox View tab is closed up. But that should happen after the whole test file is finished, which doesn't match with the test logs I've been seeing.

In any case, I think there's a pretty simple fix here to just return before calling `Services.uriFixup.getFixupURIInfo` if the url is null.
Bug: Glitches are displayed when dragging a pinned normal tile over another one while only Sponsored tiles via Pocket are displayed
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-12-05 10:23:25+00:00
Resolved: 2023-06-07 13:38:14+00:00

**[Affected versions]:**
- Nightly 109.01a
- Beta 108.0b7

**[Affected Platforms]:**
- Mac 12.4
- Windows 10 x64
- Linux Mint 20

**[Steps to reproduce]:**
1. Open the Nightly browser.
2. Pin all the tiles.
3. Enable Sponsored tiles via Pocket.
4. Drag and drop the 4th tile over the 3th tile.
5. Observe the behavior.
6. Drag and drop the 4th pinned tile over the first one.
7. Observe the behavior.

**[Expected result]:**
Step 5: The tiles are switched between them and both remain pinned.
Step 7: The tiles are switched between them and both remain pinned.

**[Actual result]:**
Step 5: The dragged and dropped pinned tile disappears and an empty tile is displayed.
Step 7: The dragged and dropped pinned tile disappears, multiple empty tiles are displayed, and the other tiles move their position.


**[Notes]:**
- The tiles are correctly displayed if the new tab page is refreshed.
- The issue is not reproducible if there are NO sponsored tiles displayed.
- The issue is not reproducible if Sponsored tiles via Contile are displayed. 
- Attached is a screen recording of the issue.
Bug: Shift + Click on any link while in private window opens the link inside a new private window but groups it with the other "normal windows" inside the taskbar
Status: NEW
Priority: P3
Created: 2022-12-05 11:26:33+00:00
Resolved: 2022-12-12 10:41:04+00:00

**Found in**
* Firefox 108.0b9 (BuildId:20221201192006)

**Affected versions**
* Firefox 109.0a1 (BuildId:20221204094021)
* Firefox 108.0b9 (BuildId:20221201192006)
* Firefox 107.0.1 (BuildId:20221128144904)

**Unaffected versions**
* Firefox 102.5.0esr (BuildId:20221107191025)

**Tested platforms**
* Affected platforms: Windows 10 64bit
* Unaffected platforms: MacOS 11 & Ubuntu 22.04 

**Steps to reproduce**
1. Launch Firefox and open a new private window.
2. Access the following [link](https://de.wikipedia.org/wiki/Eminem) 
3. Shift + Click on any link.

**Expected result**
* The link opens inside a new private window which is grouped alongside with the other private windows.

**Actual result**
* The link opens inside a new private window but is grouped with the "normal browsing" windows.

**Regression range**
* I don't think that this is a regression.
Bug: Shift + Click on the "Open a new tab" button ( + button)  while in private window opens the tab inside a new private window but groups it with the other "normal windows" inside the taskbar
Status: NEW
Priority: P3
Created: 2022-12-05 12:19:42+00:00
Resolved: 2022-12-12 10:44:17+00:00

**Found in**
* Firefox 108.0b9 (BuildId:20221201192006)

**Affected versions**
* Firefox 109.0a1 (BuildId:20221204094021)
* Firefox 108.0b9 (BuildId:20221201192006)
* Firefox 107.0.1 (BuildId:20221128144904)

**Unaffected versions**
* Firefox 102.5.0esr (BuildId:20221107191025)

**Tested platforms**
* Affected platforms: Windows 10 64bit
* Unaffected platforms: MacOS 11 & Ubuntu 22.04 

**Steps to reproduce**
1. Launch Firefox and open a new private window.
2. Shift + Click on the "Open a new tab" button ( + ).

**Expected result**
* The tab opens inside a new private window which is grouped alongside with the other private windows.

**Actual result**
* The tab opens inside a new private window but is grouped with the "normal browsing" windows.

**Regression range**
* I don't think that this is a regression.
Bug: Failed download when saving the page at dailymail.co.uk
Status: NEW
Priority: P3
Created: 2022-12-05 12:48:04+00:00
Resolved: 2023-02-14 15:51:49+00:00

**Environment:**

Operating System: Ubuntu 20.4 LTS x6
Firefox version: Firefox Nightly 109.0a1 (2022-12-05) (64-bit)/ FIrefox Release 107.0.1





**Steps to reproduce:**
1. Navigate to: https://www.dailymail.co.uk/news/article-11491263/California-reparations-committee-recommend-handing-223-200-descendant-slaves.html
2. Left-Click on the browser menu (top right-hand side- three vertical lines).
3. Click on the "Save page as" option.
4. Select a location and left-click on "Save"
5. Observe the result.





**Expected Behavior:**
The page is saved.

**Actual Behavior:**
The download fails with a message in the download section of the page, but the page is saved and can be opened.

**Notes:**
- Reproducible on most pages.
- Reproducible regardless of the status of ETP.
- Reproducible in PRIVATE Mode as well.
- Reproducible with CTRL+S and with Right-Click-> "Save page as" option.
Bug: [FxView] Links from the recently closed tabs are not correctly arranged if they have different time
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-12-05 13:20:02+00:00
Resolved: 2022-12-09 11:05:51+00:00

**Found in**
* 109.0a1 (20221204094021)

**Affected versions**
* 109.0a1 (20221204094021)

**Tested platforms**
* Affected platforms: Windows 10x64, Ubuntu 20.04, macOS 11
* Unaffected platforms: none





**Steps to reproduce**
1. Open Firefox and some random web pages inside new tabs.
2. Close some tabs with a least a 1-minute difference.
3. Open Firefox View and observe the links from the Recently closed area.

**Expected result**
* All the closed tabs links are correctly arranged.

**Actual result**
* The links are arranged based on the time string.

**Regression range**
* Last good revision: 649c190f6c292f2038bad0d99267ff0fefe18194
First bad revision: 47632dabdc1f68f2a88b072a11f41441d5ea482a
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=649c190f6c292f2038bad0d99267ff0fefe18194&tochange=47632dabdc1f68f2a88b072a11f41441d5ea482a

**Additional notes**
* Attached a screenshot.
Bug: [FxView] Recently closed windows from the App Menu > History does not work after Firefox View was opened in a new window and the window is closed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-12-05 14:36:12+00:00
Resolved: 2023-01-13 09:55:39+00:00

**Found in**
* 109.0a1 (20221204094021)

**Affected versions**
* 109.0a1 (20221204094021)
* 108.0b9	
* 107.0.1

**Tested platforms**
* Affected platforms: Windows 10x64, Ubuntu 20.04, macOS 11
* Unaffected platforms: none





**Steps to reproduce**
1. Open Firefox and another new window.
2. Click the Firefox View button in the new window and close the window from the X button.
3. Open App Menu > History and click on the Recently closed Windows option.

**Expected result**
* The Recently Closed windows are displayed.

**Actual result**
* Nothing happens.

**Regression range**
* Last good revision: 4a17392e12c8d25a57b2085d647fad57a7fc82af
 6:00.33 INFO: First bad revision: 41e7f8ab19366809bb850d8622a15bab66f1984a
 6:00.33 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4a17392e12c8d25a57b2085d647fad57a7fc82af&tochange=41e7f8ab19366809bb850d8622a15bab66f1984a
Potential regressor: bug 1787979 

**Additional notes**
* Attached a screen recording.
* Recently Closed tabs and the Back button does not work either after the Recently closed windows button was clicked.
* Closing and reopening Firefox Browser fixes the issue. Restarting Firefox does not.
* S2 because the user is not able to restore the previously closed windows or tabs from the History Menu after following the above steps.
Bug: The "Colorway Reminder" CFR message is triggered even if less than 14 days have passed since the "CFR_FIREFOX_VIEW" message was displayed but only if the "Try it" button from the "CFR_FIREFOX_VIEW" message was clicked
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-12-05 15:13:09+00:00
Resolved: 2022-12-05 21:47:02+00:00

*[Notes]:**
- This issue is reproducible only if the "Try it" button from the "CFR_FIREFOX_VIEW" message was clicked. 
- If the "CFR_FIREFOX_VIEW" message was dismissed by clicking the "Not now" button or by pressing the "Esc" key, the "Colorway Reminder" CFR message is triggered only if 14 days have passed since the "CFR_FIREFOX_VIEW" message was displayed.

**[Affected versions]:**
- Firefox Beta 108.0b9 - Build ID: 20221201192006

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.6
- ubuntu 20.04 x64

**[Prerequisites]:**
- Have a new Firefox profile with the "nimbus.debug" pref set to "true" in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to "about:studies?optin_slug=colorways-expiring-fx108&optin_branch=treatment-a&optin_collection=nimbus-preview".
3. Change the system date to 2 days in the future.
4. Open and close 3 tabs.
5. Click the "Try it" button from the "CFR_FIREFOX_VIEW" message.
6. Change the system time to 19th or 20th December 2022.
7. Navigate to a website (e.g. cats.com).
8. Observe the behavior.

**[Expected result]:**
- The "Colorway Reminder" CFR message is **NOT** triggered considering that less than 14 days have passed since the "CFR_FIREFOX_VIEW" message was displayed.

**[Actual result]:**
- The "Colorway Reminder" CFR message is triggered.

**[Additional Notes]:**
- According to the [documentation](https://mozilla-hub.atlassian.net/wiki/spaces/FPS/pages/12492140/Colorways+Expiring+-Fx+108) the "Colorway Reminder" CFR message should be triggered only if 2 weeks have passed since the "CFR_FIREFOX_VIEW" message was displayed.
- Attached a screen recording of the issue.
Bug: The “Try Colorways” modal is not displayed by clicking the “Choose Colorway” button from the “Colorway Reminder” CFR message if the browser was closed and reopened
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-12-05 16:17:38+00:00
Resolved: 2023-01-09 14:34:05+00:00

**[Affected versions]:**
- Firefox Beta 108.0b9 - Build ID: 20221201192006

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

**[Prerequisites]:**
- Have a new Firefox profile with the "nimbus.debug" pref set to "true" in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to "about:studies?optin_slug=colorways-expiring-fx108&optin_branch=treatment-a&optin_collection=nimbus-preview".
3. Close the browser.
4. Change the system date to 2 days in the future and reopen the browser using the same profile as before.
5. Open and close 3 tabs.
6. Click the "Try it" button from the "CFR_FIREFOX_VIEW" message and dismiss the “Welcome Spotlight”.
7. Close the browser.
8. Change the system time to 22nd December 2022 and reopen the browser using the same profile as before.
9. Navigate to a website (e.g. cats.com) and click the “Choose colorway” button.
8. Observe the behavior.

**[Expected result]:**
 - The “Firefox View” page is displayed and the “Try Colorways” modal is focused.

**[Actual result]:**
- The “Firefox View” page is focused, but the “Try Colorways” modal is not displayed.

**[Notes]:**
- This issue is also reproducible when restarting the browser after the system time was changed.
 - Attaching [here](https://drive.google.com/file/d/1sSk1OafassFEvXf10xWgOhpJ9aAeOaM1/view?usp=sharing) a screen recording of the issue.
Bug: Two white lines are displayed on the progress bar of the “about:welcome” page when there are six screens
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-12-05 17:07:31+00:00
Resolved: 2022-12-09 12:55:19+00:00

**[Affected versions]:**
- Firefox Nightly 109.0a1 (Build ID: 20221204094021)

**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.7.1
- Ubuntu 22.04 x64

**[Prerequisites]:**
- Have the latest version of the Firefox Nightly build installed and opened.
- Have the Firefox browser not pinned to the Taskbar and not set as default.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to the "about:welcome" page.
3. Navigate through the "Onboarding" screens until the last screen is displayed.
4. Observe the progress bar.

**[Expected result]:**
 - The progress bar is correctly displayed.

**[Actual result]:**
 - Two unnecessary lines are displayed on the progress bar.

**[Regression Window]:**
- The issue is not reproducible with older Nightly 109.0a1 builds. Considering this using mozregression tools I have found the regression range. Here are the results:
 Last good revision: 2af51023c5830f0a6d57c1d07de92727b85af599
 First bad revision: cdf07ffca6205f336682391ffd8d349ea4935f65
 Pushlog: [link](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2af51023c5830f0a6d57c1d07de92727b85af599&tochange=cdf07ffca6205f336682391ffd8d349ea4935f65)

From this pushlog it seems that Bug 1794702 may have introduced this behavior.

**[Notes]:**
- This issue is not reproducible when the Onboarding contains 5 screens.
- Attached is a screenshot of the issue.
Bug: Error when UrlbarTokenizer logs the query context
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-12-05 17:22:41+00:00
Resolved: 2022-12-22 13:53:16+00:00

When urlbar logging is enabled, the message logged [here](https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/browser/components/urlbar/UrlbarTokenizer.sys.mjs#241) fails and the logger logs this internal error:

```
Exception trying to format object for log message: TypeError: cyclic object value(resource://gre/modules/Log.sys.mjs:640:19) JS Stack trace: format@sys.mjs:640:19
formatText@sys.mjs:569:44
format@sys.mjs:587:12
append@sys.mjs:719:31
log@sys.mjs:377:16
getLoggerWithMessagePrefix/proxy.log@sys.mjs:506:18
info@sys.mjs:391:10
tokenize@sys.mjs:241:17
startQuery@sys.mjs:231:26
startQuery@sys.mjs:133:24
startQuery@sys.mjs:1487:52
autoOpen@sys.mjs:496:20
_on_mousedown@sys.mjs:3193:21
handleEvent@sys.mjs:500:23
```

STR:

1. Set `browser.urlbar.loglevel` to `Info`
2. Click in the urlbar and start typing

This might have been regressed by adding the view to the query context in bug 1800810. I didn't verify.
Bug: stop implicitly pinning to taskbar on windows 8/10/11
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-12-05 18:46:49+00:00
Resolved: 2023-01-12 15:27:32+00:00

mkaply sent me a report from a user that claimed Firefox was pinning itself to the Windows taskbar while it was not running. I suspect what's happening here is that we're hitting [this line of code](https://searchfox.org/mozilla-central/rev/2ad13433da20a0749e1e9a10ec0ab49b987c2c8e/browser/installer/windows/nsis/shared.nsh#1301) while running updates -- which always pins to taskbar for Windows 8 and up. This code has been around for quite awhile, but until bug 1771951 was fixed it would not have done anything on Windows 10 & 11.

We ought to remove this, as we've certainly decided at this point that pinning without explicit user consent is a no-go.

(I'm not actually certain this will fix the reported issue, but it sure seems likely.)
Bug: The weather suggestion can flicker and pop in
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-12-05 19:22:08+00:00
Resolved: 2023-02-04 01:19:28+00:00

STR

1. If weather suggestions are already disabled (and they're currently disabled by default), skip to the next step. Otherwise disable them and open a new window
2. Click in the urlbar to show top sites
3. Enable weather suggestions and make sure a suggestion is successfully prefetched
4. Click in the urlbar again

There's flickering in the view: First the top sites are shown without the weather suggestion, and then the weather suggestion pops in. It will keep happening in the window for as long as it's open, weather suggestions are enabled, and the top sites don't change.

The problem is that the view's cached top-sites context is created in step 2 and it's never invalidated or recached. That's because [the recache logic only checks the first result after a search finishes](https://searchfox.org/mozilla-central/rev/2ad13433da20a0749e1e9a10ec0ab49b987c2c8e/browser/components/urlbar/UrlbarView.sys.mjs#2805-2812), which is a problem because now we're showing results in the top sites context that aren't actually top sites, namely the weather suggestion. We should instead check for the presence of a top site result anywhere in the results list.
Bug: Auto-downloaded PDF getting deleted after exiting Private Mode
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-12-05 22:42:30+00:00
Resolved: 2022-12-06 15:04:13+00:00

Steps to reproduce:

On Arch Linux, in a fresh profile on Firefox Developer Edition (108.0b9):

1) Open New Private Window
2) Visit url https://libgen.is
3) Enter the search term "Free software free society"
4) Click on [2] on any of the search results OR visit https://libgen.rocks/ads.php?md5=861C055B960E7F36D95164CAB34E0E97
5) Click on GET (might open an advertisement first) OR visit https://libgen.rocks/get.php?md5=861c055b960e7f36d95164cab34e0e97&key=WHE1T8517PQKXNIO


Actual results:

Firefoxe showed in the Downloads popup that it was downloading the PDF. Once downloaded the PDF was automatically opened in the PDF viewer of Firefox.

So far, good. Now, look in the Downloads folder of your PC. The PDF file would be there. Not in a temporary directory but in Downloads folder. By default, a user expects the file would stay if a file exists in the Downloader folder, even if the browser is closed. 

Now. Close the Private Window. The PDF file in the Downloads folder would be deleted automatically!


Expected results:

Expected: the file should not have been deleted.

If Firefox wants to maintain status-quo than the user can at least be warned that Downloaded files would be auto-deleted after Private browsing session is closed.

Better approach would be to warn the user as well as to NOT download the PDf in the default Downloads folder but in a temporary location, so that the user never gets confused that they had a file they had downloaded once and now they cannot find it.
Bug: Storybook launch should enable context properties
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-12-06 00:02:04+00:00
Resolved: 2024-02-19 19:19:36+00:00

When storybook was running from package.json we had some extra flags that we'd send to `./mach run` to enable context properties. That should be re-enabled. Adding a setpref flag to the mach command [1] should do it

`--setpref svg.context-properties.content.enabled=true'`

[1] https://searchfox.org/mozilla-central/rev/2ad13433da20a0749e1e9a10ec0ab49b987c2c8e/browser/components/storybook/mach_commands.py#31
Bug: favicon not reseting when changing tab to about:newtab with newtab to Blank Page
Status: VERIFIED
Priority: P5
Resolution: FIXED
Created: 2022-12-06 00:11:17+00:00
Resolved: 2024-09-02 05:20:06+00:00

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

Steps to reproduce:

1. Go to settings and change New Tab to Blank Page(I don't know if this is necessary)
2. Open a new tab and go to www.google.com
3. Change that tab location to about:newtab



Actual results:

The favicon(small icon in the tab) is the www.google.com one.


Expected results:

The favicon(small icon in the tab) is the about:newtab one (Firefox logo).
Bug: Google translate code stopped working Dec. 5th, 2022, versioni 88.0; Linux, Ubuntu 64 bit; same code works in Chromium, Opera and worked up till today in Firefox.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-12-06 03:56:21+00:00
Resolved: 2022-12-06 08:43:04+00:00

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

Steps to reproduce:

There were no changes, here is the code

<p>Translate:
<div id="google_translate_element"></div>
<script type="text/javascript">
function googleTranslateElementInit() {
  new google.translate.TranslateElement({pageLanguage: 'en'}, 'google_translate_element');
}
</script>

<script type="text/javascript" src="https://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script>




Actual results:

The word "Translate" appears, but not the drop-down box with translate options.  The same page DOES work on Chromium and Opera, and was working on Firefox until around 3 p.m. Dec. 5th.

There were no coding changes. The feature just stopped working. On another machine, the functionality was there (from the previous day), but when I refreshed the page, the same thing happened!


Expected results:

The Translate options box should appear

User-agent:
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0
Bug: [FxView] Firefox View page is updated only after a refresh while it’s being opened and Forget about this site option is used
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-12-06 13:18:47+00:00
Resolved: 2023-01-19 11:54:05+00:00

**Found in**
* 109.0a1 (20221206034609)

**Affected versions**
* 109.0a1 (20221206034609)
* 108.0
* 107.0.1

**Tested platforms**
* Affected platforms: Windows 10x64, Ubuntu 20.04, macOS 11
* Unaffected platforms: none





**Steps to reproduce**
1. Open Firefox and open a random webpage (e.g Facebook) in a new tab and then close the tab.
2. Open Firefox View.
3. Open History and select the Forget about this site option for the Facebook page.

**Expected result**
* Facebook page is no longer displayed in Firefox View.

**Actual result**
* Facebook page is displayed in Firefox View.

**Regression range**
* I will search for one ASAP.

**Additional notes**
* Attached a screen recording.
* Clicking the page inside Firefox View will make the link disappear. Clicking to dismiss the page inside Firefox View does nothing.
* Refreshing the page fixes the issue.