av9ash/GitBugs huggingface dataset:
Bug: Private browsing site data displayed in regular manage site data dialog
Status: NEW
Priority: P3
Created: 2023-12-05 19:47:42+00:00
Resolved: 2024-01-17 21:02:36+00:00

I've just tested Bug 1817596 again, but with `youtube.com` instead. Even though I've only browsed in private browsing `youtube.com` shows up in "Manage Cookies and Site Data".
It could be that since we now enable Cache API in private browsing (Bug 1835300) we show PBM data in the Site Data Manager too.

Though I'm worried that we might be leaking private browsing data into normal browsing buckets. Have we potentially regressed Bug 1814733?

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

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

Steps to reproduce:

1. (in normal mode) I check cookies: settings-> cookies and site data ->  manage data ->  (specifically "arkadium.com") and it is not there.
2. open a new private window
3. go to arkadium.com (I'm not sure it matters, but I play "classic solitaire"
4. Close the private window
5. (Back in normal mode) check cookies: settings-> cookies and site data ->  manage data ->  (specifically "arkadium.com") and it >is< there.


Actual results:

A website visited in private mode places cookies in normal mode.


Expected results:

Cookies, in private mode, should not appear in normal mode.
Bug: Error: Key key_undoCloseTab of menuitem [title of closed tab here] could not be found
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-12-05 20:12:47+00:00
Resolved: 2024-11-26 11:24:58+00:00

STR:

1. Open a tab, e.g. example.com
2. Close that tab
3. Click on the History > Recently Closed Tabs menu.
4. Look at the global Browser Console.

Expected:
- No error messages

Actual:

- "Key key_undoCloseTab of menuitem [title of closed tab here] could not be found menu.js:295:21"
- menu.js permalink: https://searchfox.org/mozilla-central/rev/413b88689f3ca2a30b3c49465730c0e7d40f9188/toolkit/content/widgets/menu.js#295

It looks like the key is specified at https://searchfox.org/mozilla-central/rev/413b88689f3ca2a30b3c49465730c0e7d40f9188/browser/components/sessionstore/RecentlyClosedTabsAndWindowsMenuUtils.sys.mjs#316 (as part of bug 1692522, "Temporarily re-introduce keyboard shortcut display in Recently Closed Win/Tab submenu").

... but the patch to bug 1833416 removed the "key_undoCloseTab" key, and renamed it to "key_restoreLastClosedTabOrWindowOrSession".

To solve this, either the patch from bug 1692522 should be undone (if the display is no longer needed), or the code should be adjusted to use the new key id instead.
Bug: URL domain highlighting doesn't work when making changes to the URL without entering it, closing the tab and reopening it
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-12-05 22:57:23+00:00
Resolved: 2023-12-12 20:34:45+00:00

STR:
1. Open a few tabs
2. In one of these tabs open any url with some text after the `/`, like https://friends.walla.co.il/login
3. Edit the url by removing the last `n`, don't press Enter
4. Type `n` again (so the url would be the same as the one mentioned in step 2), still don't press Enter
5. Close the URL popup by pressing Esc or clicking an empty space on the page
6. Ctrl + W
7. Ctrl + Shift + T

AR:
The URL on the reopened tab is without domain highlighting

ER:
Should be with.

I think there could be other STRs (and I think I encountered those), this is just an example I saw in the wild.
Bug: aboutwelcome code missing eslint config overrides
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-12-06 00:51:46+00:00
Resolved: 2023-12-11 21:05:20+00:00

The one I initially noticed is [over here](https://searchfox.org/mozilla-release/rev/d3b6e6e03804ac37e1fde02a3a470f4715d56eb3/.eslintrc.js#560-570) - we need to add the aboutwelcome directory to the files array. I didn't take a close look, but probably there are some other overrides in there that apply to newtab but should also apply to aboutwelcome, or there might be some that apply to specific files that were moved to aboutwelcome.
Bug: Popups and menus lost all vertical separators in nightly
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-12-06 01:13:30+00:00
Resolved: 2023-12-06 17:06:44+00:00

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

Steps to reproduce:

Open the hamburger menu or the padlock or the shield icon

See that all the grey and orange underlines are gone


Actual results:

All the grey and orange underlines are gone


Expected results:

They should be present
Bug: After Migrating from Firefox account to Mozilla Account all my Synced Bookmark lost
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-12-06 04:46:12+00:00
Resolved: 2023-12-11 15:14:39+00:00

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

Steps to reproduce:

Last Night,  1 time Firefox Broken and quit and reopened, but while reopening all my synced data lost in the bookmark. 

#Need online assistant to troubleshoot and recover it in my mac. 


Actual results:

Bookmark sync not happening from my account. 

#Need online assistant to troubleshoot and recover it in my mac. 


Expected results:

All the bookmark should have retained from sync database.

#Need online assistant to troubleshoot and recover it in my mac.
Bug: Data field changes from 2024 to Dec 31 1969 when trying to print PDF
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-12-06 04:49:38+00:00
Resolved: 2023-12-20 11:48:28+00:00

Attach (recommended) or Link to PDF file here:
https://www.fidelity.com/bin-public/060_www_fidelity_com/documents/participnot.pdf

Steps to reproduce the problem:
1. Type any date into date field at bottom
2. Select Print at top

What is the expected behavior? (add screenshot)
Prints with date entered

What went wrong? (add screenshot)
Prints with 12 31 1969 in date field

Works in Chrome's pdf viewer
Bug: Empty alert-bar shown after Firefox Accounts login
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-12-06 07:48:15+00:00
Resolved: 2023-12-20 16:07:07+00:00

1. Fresh install of latest stable on macOS.
2. Settings > Sync > Log in (my account is actively used on other devices, only syncing Bookmarks).

Actual:

A confusing empty green message bar is shown at the top of the page.
Additionally, the message bar is sticky as I scroll down. 

Console shows:

```
"Failed to fetch client info for client ID sync. Encountered unexpected error, 400."
```
Bug: slow startup with system themes
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-12-06 09:33:30+00:00
Resolved: 2024-01-19 21:32:14+00:00

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

Steps to reproduce:

I selected dark or light theme. I reloaded Firefox. 


Actual results:

I could see that the startup is longer with the 2 system themes than with any other theme. I can see also the skeleton while loading the system themes (and not with the other ones). You can see that in my short video attached.


Expected results:

The startup should be faster (as you can see in my video).
Bug: [Experiment] Users cannot enroll in the “Ask User to Set Default PDF Handler” experiment due to unmatched targeting
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-12-06 12:44:00+00:00
Resolved: 2023-12-07 07:55:11+00:00

**[Notes]:**
 - According to the targeting of the [Experimenter ticket](https://experimenter.services.mozilla.com/nimbus/set-default-pdf-handler-rollout/summary), the experiment should target users having a default PDF handler other than the current Firefox installation.

**[Affected versions]:**
- Firefox Release 120.0.1 - Build ID: 20231129155202
- Firefox Beta 121.0b7 - Build ID: 20231204092159 (Release channel)

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

**[Prerequisites]:**
 - Have a new Firefox profile created and opened.
 - Have this “[user.js](https://drive.google.com/file/d/1CBhS2FxWttekfmkHRjvZMIFV-ed6zYiQ/view?usp=sharing)” file saved on your computer.
 - Have a different browser than Firefox set as the default PDF handler.

**[Steps to reproduce]:**
1. Navigate to the “about:support” page and paste the “user.js” file into the User Profile.
2. Restart the browser (Ctrl/Cmd + Shift + J and Ctrl/Cmd + Option + R).
3. Navigate to the “about:studies” page.
4. Observe the displayed experiments in the “Active Studies” section.

**[Expected result]:**
 - The users are successfully enrolled in the “Ask User to Set Default PDF Handler” experiment and the experiment is displayed as active in the “about:studies” page.

**[Actual result]:**
- Users cannot enroll in the “Ask User to Set Default PDF Handler” experiment due to unmatched targeting 

**[Additional Notes]:**
- This issue is reproducible on both branches of the experiment.
- Attaching a screen recording of the issue [here](https://drive.google.com/file/d/1HpYuqw5dBfvM66r3umEVI6WWGTH5WzOm/view?usp=sharing).
Bug: Firefox View History list stutters if there are lots of websites when accessed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-12-06 13:27:52+00:00
Resolved: 2024-01-19 16:08:16+00:00

**Found in**
- Firefox 122.0a1

**Affected versions**
- Firefox 122.0a1

**Tested platforms**
- Affected platforms: macOS 14.1.2, Windows 11, Ubuntu 22.04

**Preconditions**
- Have browser.firefox-view.virtual-list.enabled set to true
- Have a large number of history websites

**Steps to reproduce**
1. Launch Firefox and access Firefox View
2. Select History

**Expected result**
- The History list is smoothly presented

**Actual result**
- The History list stutters 

**Additional notes**
- The issue can be seen in the [following attachment](https://drive.google.com/file/d/1smA_-JfgW-k5ytxEZZgcfENMg5wGODDM/view?usp=sharing)
- This is reproducible most of the times, just go back and forth between History and other sections of Firefox View
- This issue does not reproduce with browser.firefox-view.virtual-list.enabled set to false
Bug: The Left border from the Review Checker Sidebar is displayed inside of the Shopping sidebar on Ubuntu
Status: NEW
Priority: --
Created: 2023-12-06 13:43:18+00:00
Resolved: 2024-01-19 15:37:43+00:00

**Found in**
* Nightly 122.0a1 (2023-12-06)

**Affected versions**
* Nightly 122.0a1 (2023-12-06) 
* Beta 121.0b7

**Affected platforms**
* Ubuntu

**Preconditions:**
Set the browser.shopping.experience2023.enabled - TRUE
Set the browser.shopping.experience2023.optedIn - 1

**Steps to reproduce**
1. Reach any product details page on amazon.com

**Expected result**
* The Left border line should be at the edge of the Shopping sidebar.

**Actual result**
* The Shopping sidebar extends a bit further than the border line.

**Regression range**
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6c39c0a033931984dbff5dd92897e596f298010b&tochange=9f7e052804fcfd0fd05e590530ea79520680bb7b
Bug: Firefox View longer searched terms will overflow the message box
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-12-06 14:12:07+00:00
Resolved: 2024-01-03 17:03:13+00:00

**Found in**
- Firefox 122.0a1

**Affected versions**
- Firefox 122.0a1

**Tested platforms**
- Affected platforms: macOS 14.1.2, Windows 11, Ubuntu 22.04

**Preconditions**
- Have browser.firefox-view.search.enabled set to true

**Steps to reproduce**
1. Launch Firefox and access Firefox View
2. Open any of the sections available besides Open Tabs
3. Focus search and type any word/website
4. Copy the typed word and paste it multiple times inside search
5. Look at the "No results for ..." message in the page

**Expected result**
- The searched string is kept inside the message box

**Actual result**
- The searched string will overflow the message box

**Additional notes**
- The issue can be seen in the attachment
- Strangely enough, if a website link is pasted multiple times, it will not behave the same as a manually typed string
- The issue is not reproducible in Open Tabs
Bug: Restored overlapped windows might not run their _delayedStartup routines until foregrounded.
Status: NEW
Priority: P3
Created: 2023-12-06 14:22:51+00:00
Resolved: 2023-12-19 17:31:47+00:00

In https://bugzilla.mozilla.org/show_bug.cgi?id=1783521#c13, I noticed that if many windows are restored simultaneously such that they overlap, then (at least on my Windows 10 system), some of those windows never fire the `MozAfterPaint` event, which is what's used to kick off `_delayedStartup`.

We might want to go through `_delayedStartup` to make sure there's nothing critical that _needs_ to have executed, even if the window has never come to the foreground. If it turns out that there is a need for those things, we might want to have the MozAfterPaint event handler race with an idle callback to give background windows a chance to run this routine too.

I'm only putting this in Session Restore because Session Restore is really the only place I can think of where a user might cause several windows to all open at the same time, overlapping one another. This might also make sense placed in Firefox :: General.
Bug: Syncing Doesn't Work Between Devices
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-12-06 14:58:26+00:00
Resolved: 2023-12-07 22:31:20+00:00

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

Steps to reproduce:

Bookmarked a website on my Windows 11 laptop.


Actual results:

The new bookmark didn't show up on my Android phone or Windows 10 PC.


Expected results:

Bookmarks should sync seamlessly and automatically between devices.
Bug: Clear search query "X" can't be selected via keyboard navigation in Firefox View
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2023-12-06 15:29:14+00:00
Resolved: 2023-12-07 21:50:10+00:00

**Found in**
- Firefox 122.0a1

**Affected versions**
- Firefox 122.0a1

**Tested platforms**
- Affected platforms: macOS 14.1.2, Windows 11, Ubuntu 22.04

**Preconditions**
- Have browser.firefox-view.search.enabled set to true

**Steps to reproduce**
1. Launch Firefox and access Firefox View
2. Access any section and focus on search
3. Input anything and press tab / shift+tab to get the focus on X (clear query)

**Expected result**
- "X" can be selected via keyboard inputs

**Actual result**
- "X" is skipped when pressing tab/ shift+tab

**Additional notes**
- The issue can be seen in the [following attachment](https://drive.google.com/file/d/1W5u6u3qnkwWE-Fz_RvZpbj_U7m8556vA/view?usp=sharing)
Bug: the surface displayed probe overcounts in some cases
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-12-06 16:31:24+00:00
Resolved: 2024-01-12 11:43:24+00:00

Summary

In certain cases, we have discovered counting errors in the probe that records events when the shopping sidebar is displayed in desktop Firefox (`glean.shopping.surfaceDisplayed`). These bugs go back to 119.

We are recording extra incorrect events in the following cases:
- **tab switches**
  - page is displayed with sidebar visible
  - user switches tabs
  - user then switches back to the page (without reloading the page)
  - an extra event is incorrectly recorded
- **page loaded in background**
  - page is loaded in a background tab
  - an event is incorrectly recorded immediately, before the user sees the tab
- **user opts in**
  - page is displayed with onboarding shown in the sidebar
  - event is recorded
  - user opts in, displaying review checker content
  - event is incorrectly recorded again
- **user opts out, then back in**
  - page is displayed with sidebar in opted-in state with review checker content
  - event is correctly recorded
  - user hides the sidebar by clicking "hide review checker" in sidebar settings component
  - user re-displays the sidebar by clicking the urlbar button
  - event is incorrectly recorded twice

We are correctly recording events in the following cases:

(note, all of these assume the page is loaded in a foregrounded tab)

- page is loaded by entering URL or clicking a link
- page is loaded from session restore
- page is displayed from hitting back/forward buttons
- page is reloaded by the user manually
- page was displayed with sidebar hidden, then the user clicked the urlbar button to show the sidebar
- page was displayed with sidebar visible, then the user closes the sidebar and reopens the sidebar
  - accurate if user has not opted in, so onboarding card is shown, and closes the sidebar using the X in the header, the "not now" link in the onboarding card, or the urlbar button
  - accurate if the user has opted in and closes the sidebar using the X in the header, but not in the case where the user opts out using the "hide review checker" button in the settings component
- page was displayed with sidebar hidden, then sidebar was made visible by another FF component
  - or by flipping prefs in about:config in a different window
  - or by nimbus activating the shopping feature for the first time
  - (note for future, this is not done now) or by a messaging system callout
Bug: Size of the review checker sidebar should be remembered after closing sidebar and restarting browser
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-12-06 16:39:59+00:00
Resolved: 2024-01-19 16:06:17+00:00

**Found in**
* Nightly 122.0a1 (2023-12-06)

**Affected versions**
* Nightly 122.0a1

**Affected platforms**
* All

**Preconditions:**
Set the browser.shopping.experience2023.enabled - **true**
Set the browser.shopping.experience2023.optedIn - **1**

**Steps to reproduce**
1. Reach [this](https://www.amazon.com/PlayStation-Console-Marvels-Spider-Man-Bundle-5/dp/B0CKZGY5B6/ref=sr_1_1?crid=3B5Z45IER18WU&keywords=ps5&qid=1701879249&sprefix=ps5%252Caps%252C295&sr=8-1) amazon product page. (or any other)
2. Resize the Review Checker sidebar to a random size.
3. Close the Review Checker sidebar.
4. Restart browser.
5. Go to a Amazon product page and re-open the Review Checker sidebar.

**Expected result**
* The size of the Review Checker sidebar should not reset to default.

**Actual result**
* The size of the Review Checker sidebar is re-set to default.

**Notes**
* This does not occur if you only resize and close/reopen the sidebar. (without restarting)

**Regression range**
* I'll be back with a regression range ASAP.
Bug: Adding/changing the hash causes a page load when browser.urlbar.trimHttps = true
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-12-06 16:41:59+00:00
Resolved: 2024-05-24 19:58:52+00:00

**Steps to reproduce**:
1. Ensure `browser.urlbar.trimHttps = true` (default in Nightly).
2. Open https://www.example.com/#hello
3. Change the hash from `#hello` to `#world` and press `Return`.

**Expectation**:
Hash should change without causing a page reload.

**Actual**:
Hash change causes a page reload.
Bug: Container are opened in private window
Status: NEW
Priority: --
Created: 2023-12-06 16:56:00+00:00
Resolved: 2024-05-03 09:51:03+00:00

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

Steps to reproduce:

I'm unable to reproduce this bug, a similar bug is reported here https://github.com/chronakis/firefox-sticky-window-containers/issues/17 but I'm using this extension https://addons.mozilla.org/it/firefox/addon/multi-account-containers/ and this behaviour started randomly in the last firefox release.

As background of this bug report, I have customized regedit values in past to open links in a private window of firefox to improve my privacy, this is an example: https://support.mozilla.org/en-US/questions/1242740 .

Anyway, this is a random bug, for example I have a pinned containerized tab for github in my normal browsing window, then opening a github link from another program it has been opened in the same container but in private window. This mean I'm not logged in there, but it's quite strange see the container in a private window considering that the extension is not supposed working there. 




Actual results:

Seems to me there is some mixing behaviour but I'm not able to investigate more, now I have some links opened in container inside a private windows which means they are container but they don't share data with the same containers in the normal window.


Expected results:

Links should be opened in private window without container and stuff, like in previous firefox versions. 
I don't know if it's a bug or a misexplained feature, to me it's confusing and strange onestly.
Bug: Firefox ignores the option to ask where to save PDFs when using default settings
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-12-07 00:46:47+00:00
Resolved: 2023-12-12 16:06:11+00:00

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

Steps to reproduce:

1. Use default settings on the "Applications" box in "Files and Applications".
2. Enable the option "Always ask you where to save files."
3. Download a PDF.


Actual results:

Firefox saved on the Downloads folder, ignoring the option to ask where I want to save.


Expected results:

The same thing that happens when you download other files: It asks where to save them.

For this to work, I had to change how Firefox handles PDFs to "Always ask." The problem with this option is that now it will ask even when I want to open a PDF. The issue I'm having is specific to when I download them.
Bug: Clear-icon in the search field in Firefox View is not accessible
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-12-07 01:44:43+00:00
Resolved: 2023-12-13 16:35:23+00:00

[The control](https://searchfox.org/mozilla-central/rev/16526d690cccc9c60cacf09cc08e2c3041ef884e/browser/components/firefoxview/fxview-search-textbox.mjs#70-75) lacks role and cannot be focused with a keyboard.
Bug: Review Checker is slightly resizing each time when switching tabs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-12-07 09:29:39+00:00
Resolved: 2024-01-19 16:11:55+00:00

**Found in**
* 122.0a1 (2023-12-06)


**Affected versions**

* 122.0a1 (2023-12-06)
* 121.0b7








**Tested platforms**
* Affected platforms: Windows 11, macOS 12, Ubuntu 20
* Unaffected platforms:  none


**Preconditions**
* browser.shopping.experience2023.enabled: true

**Steps to reproduce**
1. Open some random Amazon products in different tabs.
2. Switch tabs and observe the Review Checker.



**Expected result** 
* The Review Checker has a fixed size.

**Actual result**
* The Review Checker size is slightly changed each time a new tab is selected.




**Regression**
* Mozregression pointed to: bug 1858462 - Make shopping sidebar resizable











**Additional notes**
* Attached a screen recording.
Bug: [Search Preferences] For users with the search bar disabled, "Show search suggestions" should be unchecked when either browser.search.suggest.enabled or browser.urlbar.suggest.searches are false
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-12-07 11:39:16+00:00
Resolved: 2024-01-03 17:12:37+00:00

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

I had the search suggestions main pref enabled but the one for address bar disabled. After bug 1852045 this leads to an inconsistency in about:preferences#search where search suggestions seem to be enabled, but they're really disabled for the address bar, see the attached screenshot.
Bug: Unable to Highlight a single URL text from a PDF file
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-12-07 11:50:04+00:00
Resolved: 2024-03-05 08:14:48+00:00

**Found in**
* Nightly 122.0a1 (2023-12-07)

**Affected versions**
* Nightly 122.0a1 (2023-12-07) 

**Affected platforms**
* ALL

**Steps to reproduce**
1. Open a PDF with multiple links. (Attached file)
2. Enable the Highlight tool.
3. Highlight just one word or Row with a link.

**Expected result**
* Users should be able to highlight just one word or row of text even if its a Link.

**Actual result**
* Trying to highlight just one word, will highlight everything down to that area.

**Regression range**
Not Applicable