av9ash/GitBugs huggingface dataset:
Bug: Intermittent browser/components/urlbar/tests/browser/browser_glean_telemetry_abandonment_interaction_persisted_search_terms_enabled.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INVALID
Created: 2023-01-04 07:48:22+00:00
Resolved: 2023-01-25 20:13:45+00:00

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

---
```
[task 2023-01-04T06:42:33.164Z] 06:42:33     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_glean_telemetry_abandonment_interaction_persisted_search_terms_enabled.js | interaction is correct - "persisted_search_terms_refined" == "persisted_search_terms_refined" - 
[task 2023-01-04T06:42:33.164Z] 06:42:33     INFO - Buffered messages logged at 06:41:02
[task 2023-01-04T06:42:33.165Z] 06:42:33     INFO - Awaiting for the urlbar panel to open
[task 2023-01-04T06:42:33.166Z] 06:42:33     INFO - Urlbar panel opened
[task 2023-01-04T06:42:33.166Z] 06:42:33     INFO - Buffered messages finished
[task 2023-01-04T06:42:33.166Z] 06:42:33     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_glean_telemetry_abandonment_interaction_persisted_search_terms_enabled.js | Test timed out - 
[task 2023-01-04T06:42:33.290Z] 06:42:33     INFO - GECKO(18452) | MEMORY STAT | vsize 130552305MB | residentFast 1348MB
[task 2023-01-04T06:42:33.294Z] 06:42:33     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_glean_telemetry_abandonment_interaction_persisted_search_terms_enabled.js | took 120598ms
```
Bug: Zoom on pdf.js freezes linux with OOM
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-04 13:23:32+00:00
Resolved: 2023-01-31 12:00:15+00:00

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

Steps to reproduce:

open a pdf, zoom in. Specially when Ctrl+2fingerScroll (i guess more ram allocation before garbage collection). 



Actual results:

freezes system. sometimes it recovers to a Gah report after ~20 hours.


Expected results:

Zooms in. or errors in less than a minute?
Bug: Update icon has a black border
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-04 14:28:15+00:00
Resolved: 2023-01-04 14:32:35+00:00

See the attached screenshot

The icon uses 2 `circle` https://searchfox.org/mozilla-central/rev/8a4f55bc09ffc5c25dcb4586c51ae4a9fee77b4c/browser/themes/shared/icons/notification-fill-12.svg#4-7
```
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12" width="12" height="12" fill-opacity="context-fill-opacity">
  <circle fill="context-stroke" cx="6" cy="6" r="4"/>
  <circle fill="context-fill" cx="6" cy="6" r="3"/>
</svg>
```

As there is no `stroke` attribute set in CSS for the first `circle`, and given the change from Bug 1807479, the fill color defaults to `black`, hence the unwanted "border".
Bug: #editBMPanel_locationRow does not work in "Edit This Bookmark"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-04 15:46:30+00:00
Resolved: 2023-01-04 17:25:41+00:00

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

Steps to reproduce:

1) Open about:config and search toolkit.legacyUserProfileCustomizations.stylesheets. Set to true.
2) Close Firefox.
3) Create a directory called chrome inside the Profile folder of Firefox.
4) In a text editor, save the following content as userChrome.css file into the Profile\Chrome folder of Firefox.

#editBMPanel_locationRow { visibility: visible !important; }

5) Run Firefox again.
6) Press the CTRL+D key twice (or click the star icon in adress-bar).



Actual results:

The URL field can't displayed in the "Edit This Bookmark" pop-up menu.


Expected results:

As Firefox 108.x and previous versions, URL should displayed in the "Edit This Bookmark" pop-up menu.
Bug: Right-click menu appears behind bookmarks in folder
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-04 22:24:30+00:00
Resolved: 2023-01-05 16:04:37+00:00

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

Steps to reproduce:

* Create folder of bookmarks
* Open folder to view dropdown
* Right-click on a contained bookmark 


Actual results:

Right-click menu appears behind dropdown


Expected results:

Right-click menu appears in front of dropdown
Bug: Address flicker in the urlbar placeholder
Status: NEW
Priority: P3
Created: 2023-01-05 05:32:48+00:00
Resolved: 2023-01-05 17:03:02+00:00

This is a follow up to bug 1801456 comment 33:

(In reply to :Gijs (he/him) from comment #33)
> (In reply to Eemeli Aro [:eemeli] from comment #28)
> > Some thoughts on this, at a few different layers of abstraction:
> > 
> > 1. I'm pretty sure that one right fix in this case would have been to remove [this line](https://searchfox.org/mozilla-central/rev/a44deb21744de6269329b05461c55488a147f95e/browser/base/content/navigator-toolbox.inc.xhtml#337), and to rely on `BrowserSearch.initPlaceHolder()` set the l10n id. This would keep the entry field blank until we've at least tried to look for an engine name, which normally happens before the first paint.
> 
> Mark/Drew, can we file a follow-up bug for this and/or some other work to make the address bar placeholder more resilient to l10n being async in this case? Off-hand that seems like it would put this type of issue to bed more thoroughly - the distinction between comment #30 and comment #32 is, I suspect, to do with whether the `de` translation has all the newest nightly strings translated or not...
Bug: On the macOS, pinned tabs cannot be saved after the window is closed
Status: NEW
Priority: P3
Created: 2023-01-05 11:42:17+00:00
Resolved: 2023-09-19 14:56:13+00:00

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

Steps to reproduce:

1. Open firefox on the macOS

2. Open any page, such as https://www.mozilla.org

3. Right click the tab to set the pinned tab

4. Click the window close icon in the upper left corner to close the browser window

5. Right click firefox on the taskbar to exit the browser

6. Reopen the firefox browser


Actual results:

It is found that the previously set pinned tab is missing


Expected results:

The set pinned tab is reopened
Bug: Trying to unblock the TestDllBlocklist_UserBlocked.dll makes other blocked dll's names to be incorrectly parsed/displayed and active
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-01-05 15:14:18+00:00
Resolved: 2023-01-17 10:17:25+00:00

**Found in**
* Firefox 110.0a1 (BuildId:20230105092304)

**Affected versions**
* Firefox 110.0a1 (BuildId:20230105092304)

**Tested platforms**
* Affected platforms: All Windows .
* Unaffected platforms: macOS & Ubuntu.

**Preconditions**
* Have Google Drive for desktop installed (https://www.google.com/drive/download/) or TortoiseGit (https://tortoisegit.org/) installed.

**Steps to reproduce**
1.  Access the about:third-party page.
2. Hit CTRL + O.
3. Close the File Explorer and refresh the about:third-party page.
4. Block the drivefsext.dll or the TortoiseOverlays.dll.
5. Click on "Restart Nightly now" when prompted.
6. Unblock the TestDllBlocklist_UserBlocked.dll. 
7. Click on "Restart Nightly now" when prompted.
8. Hit CTRL + O & access the Google drive location (if the drivefsext.dll  was blocked) or a file where a git repository was initialized (if the TortoiseOverlays.dll was blocked).
9. Close the File Explorer and refresh the about:third-party page.

**Expected result**
* Step 8: The dll which was blocked in step 4 is successfully blocked (the overlay is not displayed on files for that particular service).
* Step 9: The dll's name is successfully displayed inside the about:third-party page.

**Actual result**
* Step 8: The dll which was blocked in step 4 is not actually blocked (the overlay is displayed on files for that particular service).
* Step 9: The dll's name is not parsed correctly.

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

**Additional Notes**
Copying the raw data to clipboard from the about:third-party page gives me the following output when this issue is reproduced:

 `"blocked": [
    "TestDllBlocklist_UserBlocked.dll",
    "\u0000rivefsext.dll"
  ]`
Bug: Limit session store writes to once per hour when the user is idle
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-05 15:25:28+00:00
Resolved: 2023-01-31 10:33:39+00:00

Bug 1305950 tried to do this, but started treating the user as idle after 180'000s (50 hours), when according to the comment it meant to do it after 3 minutes: https://searchfox.org/mozilla-central/rev/f9f59140398bc4d04d840e8217c04e0d7eafafb9/browser/components/sessionstore/SessionSaver.jsm#373

This is because the nsIUserIdleService API takes times in seconds, rather than milliseconds.
Bug: _getVisibleTabs() may return tab instead of array
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-05 15:56:02+00:00
Resolved: 2023-01-18 10:43:46+00:00

Consumers of `_getVisibleTabs()` expect it to return an array, e.g. they use `.length` and such.

However, it may return a tab instead of an array: https://searchfox.org/mozilla-central/rev/d6a131ceb435c03ccab2592578f6e2ebf12c1644/browser/base/content/tabbrowser-tabs.js#1201-1208

```js
    _getVisibleTabs() {
      // Cannot access gBrowser before it's initialized.
      if (!gBrowser) {
        return this.allTabs[0];
      }

      return gBrowser.visibleTabs;
    }
```

Unless I'm missing something, `gBrowser.tabContainer.allTabs[0]` is a tab, not an array.

Seems a regression from https://phabricator.services.mozilla.com/D32855, since previously it was https://searchfox.org/mozilla-central/rev/f1d137eff50a5dfa45fc93def1e91cb4e3c34214/browser/base/content/tabbrowser.xml#269-278

```xml
      <method name="_getVisibleTabs">
        <body><![CDATA[
          // Cannot access gBrowser before it's initialized.
          if (!gBrowser) {
            return [ this.firstElementChild ];
          }

          return gBrowser.visibleTabs;
        ]]></body>
      </method>
```

I don't know if it causes problems in practice, though.

Also, I'm not sure it makes sense to only return the 1st tab, nor why `gBrowser` is needed at all. Why not let `gBrowser.visibleTabs` redirect to `gBrowser.tabContainer._getVisibleTabs()` instead of the other way around, and cache `_visibleTabs` in `gBrowser.tabContainer`?
Bug: The "Blocked by Nightly" icon is displayed if unblocking a dll and refreshing the about:third-party page without restarting Firefox
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-01-05 15:58:04+00:00
Resolved: 2023-01-17 10:17:25+00:00

**Found in**
* Firefox 110.0a1 (BuildId:20230105092304)

**Affected versions**
* Firefox 110.0a1 (BuildId:20230105092304)

**Tested platforms**
* Affected platforms: All Windows.
* Unaffected platforms: macOS & Ubuntu.

**Preconditions**
* Have Google Drive for desktop (https://www.google.com/drive/download/) or TortoiseGit (https://tortoisegit.org/) installed.

**Steps to reproduce**
1. Access the about:third-party page.
2. Hit CTRL + O.
3. Close the File Explorer and refresh the about:third-party page.
4. Block the drivefsext.dll or the TortoiseOverlays.dll.
5. Click on "Restart Nightly now" when prompted.
6. Unblock the dll which was blocked in step 4.
7. Click on "Restart later" when prompted.
8. Refresh the about:third-party page.

**Expected result**
* The "white minus" icon ("Block this module") is displayed for that particular dll.

**Actual result**
* The warning.svg icon ("Blocked by Nightly") is displayed.

**Regression range**
* This is not a regression.
Bug: Firefox does not save anything ("Save as" not working in Flatpak version) [SOLVED]
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-01-05 18:01:43+00:00
Resolved: 2023-02-01 18:56:21+00:00

Steps to reproduce:

I launch the browser, open the page and try to download the file / save the image "Save as..."

My system:
Devuan 4 chimaera (last update)
Firefox 108.0.1 | Flathub version


Actual results:

Nothing happens


Expected results:

A menu opens to select the folder to download / starts downloading in the download list
Bug: Bookmarks manager shows duplicate tags in the input field
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-01-05 18:30:29+00:00
Resolved: 2023-02-21 12:34:30+00:00

**Steps to Reproduce**:
1. In `about:config`, set `browser.bookmarks.editDialog.delayedApply.enabled` to `true`.
2. Open the hamburger menu, then navigate to Bookmarks -> Manage bookmarks.
3. From the Library window, select a bookmark or multiple bookmarks.
4. In the Tags field, enter a string with duplicate tags, e.g. `a, a, b`.
5. Press ENTER.

**Expected Result**:
The duplicate `a` tag disappears from the input field.

**Actual Result**:
The duplicate `a` tag is persisted in the input field (but not in the database).
Bug: In permanent PBM with a tab pinned, Fx closes without confirmation
Status: NEW
Priority: --
Created: 2023-01-05 18:47:05+00:00
Resolved: 2023-01-24 13:46:01+00:00

Steps to reproduce:

I still hope one day we can have a "warnOnQuit" setting that always, without conditions, prevent Firefox to quit when accidentally hitting the button at the top right or anything else, but knowing that's not how it work, I play by the rules by adding "warnOnClose" and having always 2 empty tabs open as a safety.
Recently, I realized this wasn't enough, and identified one specific reproducible bug that could cause the quit to happen:

Set the browser to "always run in privacy mode"
In about:config set browser.warnOnQuit to true
In about:config set browser.warnOnClose to true
Open a tab to have 2 of them
Experiment 1: try to press the X on the window to close
Pin 1 or both of the tabs
Experiment 2: try to press the  X on the window to close

I think other conditions could prevent the confirmation to happen, but I wasn't able to identify them (and reproduce them).

Note: tested on Firefox 102 ESR


Actual results:

Experiment 1: Firefox should display a warning and not close unless confirmation is given
Experiment 2: Firefox close without warning or confirmation


Expected results:

When all conditions are reunited, Firefox should never close without giving a warning and requiring a confirmation
Bug: When hovering over bookmarks folders in folders then moving to other bookmarks folders at the top level, the first folders' contents were still shown sometimes in 110.0a1 20230105092304
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-05 22:24:43+00:00
Resolved: 2023-01-10 21:49:33+00:00

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

Steps to reproduce:

I started Firefox 110.0a1 20230105092304 on Wayland in Plasma 5.26.4 in a Fedora 37 KDE Plasma installation. I had previously enabled the menu bar. I selected Bookmarks in the menu bar. I moved the cursor over various bookmarks folders and folders in those folders. I moved the cursor over other bookmarks folders at the top level of the bookmarks menu.


Actual results:

When hovering over bookmarks folders in folders then moving to other bookmarks folders at the top level, the first folders' contents were still shown sometimes in 110.0a1 20230105092304. Multiple overlapping bookmarks folders were sometimes shown as a result. This problem also happened with 110.0a1 20230105092304 on XWayland in Plasma and on Wayland and XWayland in GNOME 43.2.

This problem didn't happen with 110.0 2023-1-4 on Wayland in Plasma. I ran mozregression --good 2023-1-4 --bad 2023-1-5 --persist /tmp/mozregression -p ~/.mozilla/firefox/z8d4nvrc.default-nightly

The first bad change was 47c002d3637247e71ee901f32421deaecc9d8ea3 Bug 1805414 - Remove nsMenuFrame and nsMenuParent.

10:24.10 INFO: Narrowed integration regression window from [2ff86d7e, 47c002d3] (3 builds) to [0c989b2b, 47c002d3] (2 builds) (~1 steps left)
10:24.10 INFO: No more integration revisions, bisection finished.
10:24.10 INFO: Last good revision: 0c989b2bcd7882a9e7106e7879ab8933c2e09071
10:24.10 INFO: First bad revision: 47c002d3637247e71ee901f32421deaecc9d8ea3
10:24.10 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0c989b2bcd7882a9e7106e7879ab8933c2e09071&tochange=47c002d3637247e71ee901f32421deaecc9d8ea3



Expected results:

When hovering over bookmarks folders in folders then moving to other bookmarks folders at the top level, the first folders' contents should have disappeared. The second bookmarks folders' contents should have been shown without overlapping with the first menu.
Bug: Horizontal menu separators are not the same color when using the generated themes as when using privileged themes
Status: VERIFIED
Priority: P5
Resolution: FIXED
Created: 2023-01-06 09:28:59+00:00
Resolved: 2023-01-25 08:12:31+00:00

Description:
Horizontal menu separators are gray when using generated themes as opposed to colored in the theme accent color when using privileged themes.

Affected areas:
- Hamburger menu and sub-menus
- Unified Extensions Button panel
- “List all tabs” button panel (far right downward facing arrow button)
- “Site information” panel (lock icon left of URL or “Nightly/Firefox” box left of URL when on privileged pages such as about:addons)
- “Protections” panel (shield icon left of URL)
- Downloads panel

NOTE: Panel outline color is consistent between the generated and privileged themes.

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Access the above mentioned affected areas and observe the difference between the horizontal menu separator colors when using the generated/privileged themes

Actual:
Generated themes horizontal menu separators are gray and don’t use the theme accent color as in the case of the privileged themes

Expected:
Horizontal menu separators for the generated themes should be the same color as for the privileged themes.
Bug: Privileged page “Nightly/Firefox” site information box colors differ between generated and privileged themes
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-06 09:52:08+00:00
Resolved: 2023-01-13 17:51:02+00:00

Description:
The “Nightly/Firefox” site information box found at the left of the address bar when on privileged pages such as about:addons is of a different background color when using generated themes as opposed to privileged themes.
The “Nightly/Firefox” box font color is also different between the themes.

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Access about:addons and observe the difference in background color and font color of the “Nightly/Firefox” site information box at the left of the address bar between the generated and privileged theme

Actual:
Generated theme “Nightly/Firefox” site information box background color and font color are different from the ones used by privileged theme.

Expected:
“Nightly/Firefox” site information box background color and font color should be the same for both generated and privileged themes.
Bug: Address bar button icons highlight on hover is not the same color when using the generated themes as when using privileged themes
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-06 10:15:26+00:00
Resolved: 2023-01-13 17:52:36+00:00

Description:
Address bar button icons highlight on hovering the mouse cursor over them is of different colors when using generated themes as opposed to privileged themes.

Affected button icons:
-  “Site information” button icon (lock icon left of URL)
-  “Protections” button icon (shield icon left of URL)
- “Bookmark this page” button icon (star icon right side of address bar)

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Access https://www.wikipedia.org/, start hovering over the mentioned affected button icons and observe the difference in highlight color between the generated and privileged themes

*NOTE* that in the case of the privileged themes the icon color also changes on hovering over it while in the case of the generated theme the icon remains the same color regardless of being hovered over or not.

Actual:
Generated theme highlight on hover colors are different from the ones used by the privileged theme. Also the privileged themes icon color changes on hovering over it while in the case of the generated theme the icon remains the same color regardless of being hovered over or not.

Expected:
Generated theme address bar button icons highlight on hover should use the same colors as in the case of the privileged theme.
Also the generated theme address button icon should change color on hover as in the case of the privileged theme.
Bug: Menu item highlight on hover is not the same color when using the generated themes as when using privileged themes
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-06 10:45:23+00:00
Resolved: 2023-01-13 17:52:27+00:00

Description:
Menu items highlight on hovering the mouse cursor over them is of different colors when using generated themes as opposed to privileged themes. Highlight is gray on generated themes and colored using the accent color on privileged themes.

Affected areas:
- Hamburger menu and sub-menus
- Unified Extensions Button panel
- “List all tabs” button panel (far right downward facing arrow button)
- “Site information” panel (lock icon left of URL or “Nightly/Firefox” box left of URL when on privileged pages such as about:addons)
- “Protections” panel (shield icon left of URL)
- Downloads panel

See the attached video for more details. Note that the privileged theme is on the left and the generated theme is on the right in the video attachment.

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Access the above mentioned affected areas and observe the difference between the highlight of menu items when hovering over them while using the generated/privileged themes

Actual:
Generated themes menu items highlight on hover colors are different from the ones used by the privileged theme.

Expected:
Generated theme menu items highlight on hover should use the same colors as in the case of the privileged theme.