av9ash/GitBugs huggingface dataset:
Bug: Can't reorder tab groups on tab strip
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-22 17:19:48+00:00
Resolved: 2024-10-22 17:28:19+00:00

Steps to reproduce

1. Create a tab group via drag and drop (or context menu)
2. Add several new tabs to the right of it outside the group
3. Click and hold on tab group label and drag it to the other side of the new tabs

Expected
Tab group is dragged to another position on the tab strip (move to right side of new tabs)

Actual
Drags the entire window. Can't drag tab group label to another position
Bug: "Remove from group" moves tab into another group
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-10-22 17:49:26+00:00
Resolved: 2024-12-05 12:45:35+00:00

Steps to reproduce

1. Create 2 tab groups with 2+ tabs in each group and make sure these groups are next to each other in the tab strip
2. Right-click on a tab inside the group on the left (group 1) and select "Remove from Group"

Expected:
Tab is moved out of the group to the left end of the group

[Group 1 - tab 1] **[Removed tab]** [Group 2 - tab 1, tab 2]

Actual:
Tab is moved into the other group (group 2) that directly to the right of it

[Group 1 - tab 1][Group 2 -  **[Removed tab]** ,tab 1, tab 2]
Bug: The "save visible" / "save full page" panel is mostly invisible now that the z-index of the content area changed vs. the toolbox
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-22 17:59:37+00:00
Resolved: 2024-11-11 08:08:58+00:00

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

Steps to reproduce:

1. Right click on the page
2. Click "Take Screenshot"


Actual results:

Something went wrong at the top right corner.
https://i.imgur.com/SC8urQg.png

I guess it is a dialog with buttons, allowing users to screenshot the entire page?
> https://support.mozilla.org/en-US/kb/take-screenshots-firefox


Expected results:

Display the dialog correctly.
Bug: Group label covers tab when dragging a tab
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-10-22 18:13:23+00:00
Resolved: 2025-01-08 12:15:44+00:00

Steps to reproduce:

1. Create 2 tab groups with 2+ tabs inside each
2. Drag a tab from one group to the other

Expected:
Labels don't overlap with tabs 
Tab group hairline doesn't follow the tab once it's moved out of the group

Actual: 

Tab group label overlaps with tab when moving a tab between groups
Tab group hairline follows tab when moved out of the group

See screen recording for reference
Bug: In the about:newtab "wireframe" rendering, the pocket stories' gray-placeholder-image-box ends up looking like a large dark/light/dark flicker instead of a smooth handoff to the actual thumnail-images
Status: NEW
Priority: P3
Created: 2024-10-22 18:29:42+00:00
Resolved: 2024-10-28 21:15:43+00:00

STR:
1. In Firefox preferences, choose "Website Appearance: Dark" (optional; just makes this a bit easier to see, for me at least).
2. Open a new window with Ctrl+N.
3. As the new window opens, carefully watch the lower half of the new-tab-page (where pocket suggested stories will appear).  Even better, capture a screencast or a profile and watch it back in slow-motion.

ACTUAL RESULTS:
A. At first, the new window is fully dark.
B. Then, there's a brief "wireframe" rendering, in which the pocket suggested stories section has a light-gray "thumbnail-image placeholder" in each story.
C. Then when we swap from the wireframe to the actual grid-of-stories, the light-gray "thumbnail-image placeholders" all disappear entirely, so the dark background color is now showing.
D. Then, the actual thumbnail image appears (sometimes gradually fading in).

EXPECTED RESULT:
No such light-gray "thumbnail-image placeholder" in phase "B".
Or, if we want to keep that placeholder, we should make there be a less-jarring handoff from that placeholder to the eventual thumbnail-image (possibly by darkening the gray color, or keeping the placeholder in-place until we show the thumbnail, or something else)


NOTES:
The actual-results A,B,C,D progression feels like a "dark/LIGHT/dark/gradual-fade-in", with the "dark/LIGHT/dark" part feeling particularly jarring.  The light-gray-thumbnail image is responsible for most of that, so that's what I'm focusing on here.

I think the light-gray box here is meant to be a placeholder for the actual/eventual thumbnail image -- and to-that-end, it's probably intended to *reduce* the perception of flickering/stuff-popping-into-existence? But in practice it gives the opposite outcome right now, because it disappears (in actual-results-step-C) for some time before the image shows up -- there's no smooth hand-off from the placeholder to the actual-image.  So that's why this ends up feeling like a weird brief-misrendering-flicker, rather than feeling like the graceful placeholder that it's meant to be.
Bug: Can't drag tab to left of tab group
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2024-10-22 18:36:47+00:00
Resolved: 2025-01-29 19:22:49+00:00

Steps to reproduce:

1. Create a new tab group with 1+ tabs (position of the group should be in the far left of tab strip)
2. Click + icon to create a new tab to the right of the group
3. Drag New tab to the start of the tab strip (far left)

Expected
Tab is moved to the left of the tab group

Actual
Tab is moved inside the tab group (can't move past the group)

See screen recording for reference
Bug: No animation when dragging a tab over other tabs in a tab group
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-10-22 18:48:44+00:00
Resolved: 2024-11-20 09:10:50+00:00

Steps to reproduce

Create a tab group with 1+ tabs inside
Open several new tabs outside the tab group
Drag a tab into the tab group

Expected
There is a sliding animation when you drag a tab inside a tab group (same as when you move a tab when not in a group)

Actual
No sliding animation when moving a tab inside a group 

See screen recording
Bug: Graphics in HCM Night Sky need color changes
Status: NEW
Priority: P2
Created: 2024-10-22 19:07:55+00:00
Resolved: 2024-11-14 02:51:19+00:00

## Prerequisites:

Found in Nightly 133.0a1 (2024-10-21)(64-bit)

Turn on Night Sky High Contrast mode on your device ([steps to do so here](https://firefox-source-docs.mozilla.org/accessible/ColorsAndHighContrastMode.html#operating-system-high-contrast-mode-os-hcm))

## STR:

1. Open `about:welcome` from the URL bar
2. Observe the graphic on the left hand side of the first 3 screens

## Actual:

The yellow background colors (on Windows 11 Night Sky) appear to be the same as the yellow for form controls. That yellow has semantic meaning, so using it in large swaths in the image can be confusing. Also, the brightness of the yellow may be a bit overwhelming for people with photosensitivity, particularly against the black background.
- Consider replacing the yellow (button text) with black (canvas color) and black with white (canvas text).
Bug: Import Browser Data: Combobox needs additional markup
Status: NEW
Priority: P1
Created: 2024-10-22 20:34:39+00:00
Resolved: 2025-03-03 18:05:35+00:00

## Prerequisites:

Found in Nightly 133.0a1 (2024-10-21)(64-bit)

## STR:

1. Open `about:welcome` from the URL bar
2. Click the 'Save and Continue' button to go to the next screen
3. When the Import Browser Data screen appears, right click on the combobox and select 'Inspect (Q)' from the context menu

## Expected:

The `<button>` element should have `role=combobox` added and [follow the combobox ARIA pattern](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/#wai-ariaroles,states,andproperties)
Bug: Pressing "Escape" to revert to loaded address in address bar doesn't work
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-22 22:00:27+00:00
Resolved: 2024-11-28 11:50:29+00:00


Steps to reproduce:

1. Go to any page on the web
2. Do Control-L
3. Do Control-X
4. Press "Escape"
5. Press "Escape"

What happens:

The address bar is blank.

Expected result:

The address bar should contain the address present in Step 2 above.

Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
41:00.73 INFO: Narrowed integration regression window from [91c817b5, ba91ce2c] (3 builds) to [91c817b5, fdd8368c] (2 builds) (~1 steps left)
41:00.73 INFO: No more integration revisions, bisection finished.
41:00.73 INFO: Last good revision: 91c817b56f6154e2ebf610207242ba18c735af09
41:00.73 INFO: First bad revision: fdd8368ccabfe9d0a48c95891bbdb2f27e177886
41:00.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=91c817b56f6154e2ebf610207242ba18c735af09&tochange=fdd8368ccabfe9d0a48c95891bbdb2f27e177886
Bug: Intermittent browser/base/content/test/tabPrompts/browser_contentOrigins.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-10-23 07:15:05+00:00
Resolved: 2025-01-13 12:06:00+00:00

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

---
```
[task 2024-10-23T05:43:20.458Z] 05:43:20     INFO - TEST-START | browser/base/content/test/tabPrompts/browser_contentOrigins.js
[task 2024-10-23T05:43:25.395Z] 05:43:25     INFO - GECKO(5932) | console.error: "Prompter: internal dialogs not available in this context. Falling back to window prompt."
[task 2024-10-23T05:43:25.840Z] 05:43:25     INFO - GECKO(5932) | MEMORY STAT | vsize 2112495MB | vsizeMaxContiguous 65938513MB | residentFast 316MB | heapAllocated 134MB
[task 2024-10-23T05:43:25.841Z] 05:43:25     INFO - TEST-OK | browser/base/content/test/tabPrompts/browser_contentOrigins.js | took 5383ms
[task 2024-10-23T05:43:25.857Z] 05:43:25     INFO - checking window state
[task 2024-10-23T05:43:25.858Z] 05:43:25     INFO - TEST-INFO | started process screenshot
[task 2024-10-23T05:43:25.988Z] 05:43:25     INFO - TEST-INFO | screenshot: exit 0
[task 2024-10-23T05:43:25.989Z] 05:43:25     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabPrompts/browser_contentOrigins.js | Found an unexpected unknown window with document URI: chrome://global/content/commonDialog.xhtml and title: Authentication Required - Firefox Nightly at the end of test run - 
[task 2024-10-23T05:43:25.990Z] 05:43:25     INFO - GECKO(5932) | must wait for focus
[task 2024-10-23T05:43:25.991Z] 05:43:25     INFO - TEST-START | browser/base/content/test/tabPrompts/browser_multiplePrompts.js
```
Bug: Firefox crashes when opening certain PDF files.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-10-23 08:48:53+00:00
Resolved: 2024-10-23 21:08:58+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
Firefox for Android

Steps to reproduce:

Open Firefox.
Navigate to a website with a PDF link (e.g., a government form).
Click on the PDF link to open it.


Actual results:

Firefox crashes immediately upon attempting to open the PDF file, and the browser restarts.


Expected results:

The PDF file should open within the Firefox PDF viewer without crashing the browser.
Bug: JavaScript errors are reported in the console on certain websites.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-23 09:09:20+00:00
Resolved: 2024-10-23 09:58:33+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
Firefox for Android

Steps to reproduce:

Open Firefox.
Navigate to a specific website (e.g., a web app).
Open the JavaScript console (F12 or Ctrl+Shift+K).


Actual results:

Multiple JavaScript errors are displayed in the console, affecting site functionality.


Expected results:

No JavaScript errors should be displayed, and the website should function correctly.
Bug: Settings keyboard shortcut does not work
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-23 10:36:09+00:00
Resolved: 2024-10-24 10:28:45+00:00

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

Steps to reproduce:

On Mac, using the keyboard shortcut to access settings (Command+,) no longer works after updating to version 132.0b9.
Steps to Reproduce:
1. Open Firefox on Mac
2. Use keyboard shortcut for settings (Command+,)


Actual results:

Nothing - settings do not open and must be accessed by typing about preferences in the search bar.


Expected results:

Settings open automatically once the shortcut is used.
Bug: 4.42 - 3.89% tart / tart (Windows) regression on Fri October 4 2024
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-10-23 12:14:03+00:00
Resolved: 2024-10-24 01:33:25+00:00

Perfherder has detected a talos performance regression from push [0ce46cb64bf09bfa7f0edd1340f7d7166fbbf8ec](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=0ce46cb64bf09bfa7f0edd1340f7d7166fbbf8ec). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)** |  
|--|--|--|--|--| 
| [4%](https://treeherder.mozilla.org/perfherder/graphs?timerange=2592000&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.80 -> 1.88 | 
| [4%](https://treeherder.mozilla.org/perfherder/graphs?timerange=2592000&series=autoland,86450,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender | 1.80 -> 1.87 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=2508), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the patch(es) may be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run all of these tests on try with `./mach try perf --alert 2508`

The following [documentation link](https://firefox-source-docs.mozilla.org/testing/perfdocs/mach-try-perf.html#running-alert-tests) provides more information about this command.

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).

If you have any questions, please do not hesitate to reach out to bacasandrei@mozilla.com.
Bug: [Experiment] The "Keep bookmarks toolbar open?" message is not triggered in the treatment-b branch
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-23 12:43:48+00:00
Resolved: 2024-10-24 12:16:37+00:00

**[Notes]:**
- The message is NOT triggered even if a new tab is opened.
- The message is triggered only if the Bookmark Toolbar is set to "Always Show". However, the experiment targets only users that have the default option, to show only on new tabs. If the "Always Show" option is enabled by the users, the message will be triggered next time the page is visited. 

**[Affected versions]:**
- Firefox Nightly 133.0a1 - Build ID: 20241022213158
- Firefox RC 132.0 - Build ID: 20241021175835

**[Affected Platforms]:**
- Windows 10
- macOS 13.4
- Linux Mint 20.1

**[Prerequisites]:**
- Have following prefs set:
  - nimbus.debug = true

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to the following custom link to force enroll in the treatment-a of the experiment: `about:studies?optin_slug=recommend-bookmark-toolbar-existing-user&optin_branch=treatment-b&optin_collection=nimbus-preview`.
3. Close the tab.
4. Navigate 3 times any website that should trigger the message (eg: https://x.com).
5. Observe the behavior. 

**[Expected result]:**
- The message is triggered after the website is opened a third time.
OR
- The message is triggered after opening a new tab.

**[Actual result]:**
- No message is triggered.

**[Additional Notes]:**
- Attached is a screen recording of the issue.
Bug: With new sidebar enabled, opening private windows always have the sidebar expanded.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-23 17:30:59+00:00
Resolved: 2024-11-20 08:48:58+00:00

* With the new sidebar enabled (with or without vertical tabs)
* Open a new private window
* The private window always opens with the sidebar expanded.

[This was noted on connect as well](https://connect.mozilla.org/t5/discussions/firefox-sidebar-and-vertical-tabs-try-them-out-in-nightly/m-p/75122/highlight/true#M28877).
Bug: Additional Tabs not loading in background while working on an existing tab
Status: UNCONFIRMED
Priority: --
Created: 2024-10-23 18:23:18+00:00
Resolved: 2024-12-27 14:58:02+00:00

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

Steps to reproduce:

If I open my whereby account, for example https://whereby.com/myAccountURL with a middle click or simply force it to open in another tab, but I do NOT visit that new tab, instead I stay on the current one. On Google Chrome the new tab ends up loading without problems. Here on Firefox it basically freezes the loading process until I actually click on the new tab, forcing me to have to go to the other tab and wait till it loads and then I can continue working on my previous tab.

I do it like this because when am meeting with my development team I simply open the tab and am ready. Now I am forced to open the tab, go to it, stay there and wait till the page loads, and then go back to the previous tab I was in.


Actual results:

The new tabs do not load in the background. Like the web workers or any other technology in whereby.com is not letting the tab load till I have that tab active.


Expected results:

It should load in the background when opened, without me having to go to that new tab. if I open a link in a new tab it should simply open.

I do have the following config settings in TRUE


browser.search.context.loadInBackground	true	
browser.tabs.loadInBackground	true	
services.sync.prefs.sync.browser.tabs.loadInBackground true

And I have checked others to make sure they are true:


browser.search.context.loadInBackground	true	
browser.tabs.loadBookmarksInBackground	true	
browser.tabs.loadDivertedInBackground	true	
dom.timeout.background_budget_regeneration_rate	1000	
dom.timeout.background_throttling_max_budget	1500	
dom.workers.background_throttling	false


I am using the SNAP version of Firefox on Ubuntu 24.10
Bug: With Sidebar Revamp feature enabled the border around content is lighter than usual
Status: NEW
Priority: P2
Created: 2024-10-23 18:25:28+00:00
Resolved: 2024-11-01 12:43:47+00:00

This is a visual regression when sidebar.revamp = true and using the System theme, the border around content is ligher, and it is a bright element of a generally dark toolbox. With System theme it used to be threeDShadow, that is a quite dark color.
With Dark theme it is slightly darker than in the screenshot and it's the same with revamp true or false, so I imagine the regression is only affecting System theme.

Emilio said on Slack:
> With the system theme, you use ThreeDShadow without sidebar.revamp, and rgba(255, 255, 255, .3) with sidebar.revamp (edited) 
> don't have context on why we want to use different color with and without revamp enabled
> And yeah agreed that a darker border would generally suffice
> Maybe just unconditionally just using rgba(0, 0, 0, .3)? We don't ever have a fully black toolbar with system themes so that seems reasonable?

I think we should at least clarify the difference with and without revamp.
Bug: Tabs unable to move to another monitor on top Discord
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-23 19:13:04+00:00
Resolved: 2024-11-11 16:20:49+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Copy of Bug 1417276 that was closed as "resolved," when the issue is still there as described.

Steps to reproduce:

I had Discord open on another monitor maximized and tried moving a tab from one monitor on top of where discord is located.

I have not been able to replicate it with other application open.


Actual results:

The tab stayed put in the current window and did not move over to the other monitor.


Expected results:

The tab should have moved to the other monitor.
Bug: For a pinned tab in vertical tabs sidebar, clicking the tab steals keyboard focus
Status: NEW
Priority: P2
Created: 2024-10-23 20:25:51+00:00
Resolved: 2024-10-31 21:38:27+00:00

I have the sidebar tabs enabled and have pinned gmail. It appears when I click the pinned tab it steals keyboard focus so the usual gmail keyboard shortcuts stop working. I have to click back inside the main browser area to move keyboard focus back.
Bug: Tab tooltips / previews don't work when the "update available" popup is visible
Status: NEW
Priority: P3
Created: 2024-10-23 23:29:08+00:00
Resolved: 2024-10-29 15:55:58+00:00

When hovering over a tab, there is no tooltip or preview shown if the "update available" doorhanger popup is visible.

STR:
1. Be negligent on updates (i.e. have a pending update waiting).
2. Have the "update available" popup showing.
3. Have tab hover previews enabled.
4. Hover the mouse cursor over a tab. Nothing is shown, so you cannot determine the tab title via hover until dismissing the "update available" popup.
Bug: Tool's icons in the sidebar should have 'icon' color.
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-10-24 08:36:27+00:00
Resolved: 2024-11-28 09:28:03+00:00

Tool's icons in the sidebar don't have the correct color. Right now, they are black. Could we change them to the same icon color that we are using in the toolbar for all other icons? Thank you!
Bug: Dropping a pinned tab over the tab area will result in a moving animation of the pinned tab
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-10-24 11:28:40+00:00
Resolved: 2024-12-06 02:23:50+00:00

**Found in**
* 133.0a1 (2024-10-23)

**Affected versions**
* 133.0a1 (2024-10-23)
* 132.0







    


**Tested platforms**
* Affected platforms: Windows 10, macOS 12, Ubuntu 24
* Unaffected platforms: none



**Steps to reproduce**
1. Pin a tab.
2. Drag and drop the pinned tab over other tabs.

****Expected result****
* Nothing happens.

**Actual result**
* The pinned tab has an animation returning to the position.



**Regression range**
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0d847aebe581db1b61e50e88f6f17c5edbb47425&tochange=5248d1af290fd5c94b8b3d4eaeae5ac659c6b81b. 
I am not sure if bug 1921762 is the regressor. Please change it if this is not correct. Thank you!

**Additional notes**
* Attached a screen recording.
Bug: getTabTooltip should cache value of pid pref
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-10-24 11:44:23+00:00
Resolved: 2024-10-25 04:15:40+00:00

In the [profile]( https://share.firefox.dev/3Uner34) in bug 1923363 I'm seeing a ton of markers for pref reads of `browser.tabs.tooltipsShowPidAndActiveness` which appear to be coming from https://searchfox.org/mozilla-central/rev/dca2603d55b5b39d3b8ab8e93c08b42563f5aad8/browser/components/tabbrowser/content/tabbrowser.js#6179-6184 .

That pref read should be cached instead of running once for each tab and its tooltip. In the list-all-tabs code that getter gets called for each tab, cf. https://searchfox.org/mozilla-central/rev/dca2603d55b5b39d3b8ab8e93c08b42563f5aad8/browser/components/tabbrowser/TabsList.sys.mjs#358 .