av9ash/GitBugs huggingface dataset:
Bug: [NIGHTLY 134.0a1] If there is a tab group, when pinning a tab (outside of a group) it always goes into the first tab group
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2024-10-29 16:31:36+00:00
Resolved: 2025-01-07 15:07:34+00:00

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

Steps to reproduce:

1. Set browser.tabs.groups.enabled to true in about:config on Nightly 134.0a1
2. Create a tab group
3. Attempt to pin another tab OUTSIDE of that group, where it will then be put in the tab group instead of at the beginning of the tab bar (outsside the group)


Actual results:

The tab you are attempting to pin goes into the very first tab group


Expected results:

The tab you are attempting to pin should be pinned outside of a tab group, unless it is ALREADY within a tab group, or is dragged to a tab group.
Bug: Close Firefox View with the "Esc" key
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-10-29 16:57:26+00:00
Resolved: 2024-11-13 12:18:04+00:00

Steps to reproduce:

* Open Firefox View
* Press `Esc`


Actual results:

Nothing.


Expected results:

Firefox View should be closed.
Bug: Remove the extra padding on the right of the hamburger menu in the vertical mode
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2024-10-29 17:12:54+00:00
Resolved: 2024-10-29 18:56:20+00:00

The padding between the edge of the window and the hamburger menu in the vertical mode is too large. 
It should be identical to the padding between the two elements in the horizontal mode.
Bug: message "zut l'onglet a planté" s'affiche aléatoirement lors d'ouverture d'un nouvel onglet
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-10-29 17:17:07+00:00
Resolved: 2024-11-13 10:25:36+00:00

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

Steps to reproduce:

ouverture de firefox puis ouverture d'un nouvel onglet puis une recherche quelconque dans cet onglet et le message "zut l'onglet a plante"


Actual results:

message "zut l'onglet a plante


Expected results:

une page web correspondant à ma demande aurait du s'ouvrir
Bug: about:welcome screens do not reflow at 400% zoom
Status: NEW
Priority: P2
Created: 2024-10-29 18:32:30+00:00
Resolved: 2025-03-03 18:05:10+00:00

## Prerequisites:

Found in Nightly 133.0a1 (2024-10-28)(64-bit)
Increase zoom in browser to 400%

## STR:

1. Open `about:welcome` from the URL bar
2. Navigate through the `about:welcome` wizard with 400% zoom on in the browser.

## Expected/Actual:

> Avoiding the need to scroll in the direction of reading in order to reveal lines that are cut off by the viewport is important, because such scrolling significantly increases the effort required to read. It is also important that content is not hidden off-screen. For example, zooming into a vertically scrolling page should not cause content to be hidden to one side. ([Intent - WCAG 1.4.10 Reflow](https://www.w3.org/WAI/WCAG21/Understanding/reflow.html#intent))

Once the user has enabled their browser to zoom up to 400%, a horizontal scroll bar is required to continue reading and to access some buttons throughout the `about:welcome` wizard. 

Content should be reflowed so that it all appears and is accessible through vertical scrolling
Bug: [Dev Tools] Make Attribution parameters editable
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-10-29 18:49:52+00:00
Resolved: 2024-10-30 09:33:40+00:00

In Fx132  code change in [D221443](https://phabricator.services.mozilla.com/D221443) made about:asrouter#devtools-targeting -> Attribution parameters non editable. Scope of this bug is to land one line fix to bring back editable
Bug: Drag and drop tab to create group creates multiple colour changes
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-10-29 20:03:49+00:00
Resolved: 2024-11-27 10:34:42+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**

Drag 1 tab over another tab slowly in the tab strip to trigger tab group creation

**Expected behavior [What should have happened?]:**

When tab group creation is triggered, a coloured highlight based on an auto-assigned tab group colour show appear over tab 1 and tab 2

**Actual behavior [What actually happened?]:**

As you drag tab 1 over tab 2 the selected tab group colour changes multiple times as you move the tab

See screen recording
Bug: Moving a tab to a group should activate the group's window
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-10-29 20:46:29+00:00
Resolved: 2025-02-10 15:32:24+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**

1. Open 1 window (window 1) and create a tab group
2. Open a second window (window 2) and open a new tab
3. Move the new tab to the group in window 1 via right click and "add tab to group"

**Expected behavior [What should have happened?]:**
window 1 becomes the active window and tab inside group is in focus

**Actual behavior [What actually happened?]:**

Tab disappears from window 2 (no feedback of where it went to)
Bug: Try to reduce flickering / flashing opt-in UI when switching between tabs with RC sidebar tool open
Status: NEW
Priority: P3
Created: 2024-10-30 00:41:39+00:00
Resolved: 2025-02-21 16:08:32+00:00

Working on https://phabricator.services.mozilla.com/D226075 for Bug 1925408, I can see flickering in the opt-in UI whenever I switch tabs with the RC tool open. It's possible that Bug 1927956 will help, but the issue is most likely due to the way we load the UI with fluent + react. 

Attached an image of how the RC looks before the opt-in illustration and text are fully loaded in. It's brief, yet noticeable enough to be distracting, especially after quickly navigating through several tabs.
Bug: Improve responsive design of integrated RC
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-10-30 01:13:00+00:00
Resolved: 2025-01-11 09:22:54+00:00

With WIP changes like https://phabricator.services.mozilla.com/D226075, the RC UI doesn't look quite right with different sidebar sizes. The feedback I received so far includes:

Recommendations panel
- letter grade should be below product image

Settings panel
- font-size for the toggle descriptions (not labels) are the same size as the labels, when they should be smaller
- toggles are "sticking out" with the min sidebar width size. We might have to adjust how we "group" the elements for the panel

Empty states:
- with larger / max width, illustration, description, and CTA button should be centered. Illustration should maintain its original size
- with the min width, illustration should be slightly smaller

Bonus:
- loading state boxes should be rounded (no sharp corners)
- loading state boxes are slightly bigger than they should be (no scroll must be needed to see all of them)

We also have a new Figma spec for the layout with different sidebar widths: https://www.figma.com/design/GnCtw7DmPtlSEIfjatHtSI/Review-Checker-in-sidebar?node-id=12309-117085&node-type=frame&m=dev
Bug: The warning dialog stacks 2-3 times after pasting content from Google Docs to web pages or Google docs
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-10-30 07:54:35+00:00
Resolved: 2025-02-20 07:32:09+00:00

**Found in**
* 134.0a1 (2024-10-29)

**Affected versions**
* 134.0a1 (2024-10-29)








    


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


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
* run the DLP agent in CMD using: .\content_analysis_sdk_agent.exe --user --toblock=.*mysecret* --towarn=.warn. --delays=3  (this also reproduces with `--towarn=.awarnb.*)


**Steps to reproduce**
1. Create a Gdoc containing the `warningwarning` string and copy it.
2. Paste the string in another Google Doc or a webpage.
3. Observe the behavior.



**Expected result** 
* The warning dialog is only shown once.


**Actual result**
* The warning dialog is stacked 3 times.

**Regression range**
* The stacked issue happens after bug 1915351.

**Additional notes**
* Attached a screen recording.
Bug: With pinned tabs, after opening tab group, this group's tabs' layout in tab bar is moved to left
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-10-30 07:54:56+00:00
Resolved: 2025-01-31 13:52:24+00:00

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

Steps to reproduce:

I opened and closed different tabs, moved some tabs from and to groups.  Then I clicked on tab group to show its tabs.


Actual results:

Tab group's tabs' layout in tab bar was moved to left, over other tabs.


Expected results:

Tabs should have been displayed on the right side after group's name.
Bug: 133.0b1 - Randomly Freezes when changing tabs, its not usable
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-10-30 09:48:32+00:00
Resolved: 2024-11-05 12:37:38+00:00

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

Steps to reproduce:

I launched browser and opened a new tab! Ofc 


Actual results:

Firefox is not responding!


Expected results:

Idk, not freeze!
Bug: Tab groups hairline should extend across the entire group when reordering/adding new tabs
Status: NEW
Priority: P3
Created: 2024-10-30 09:56:41+00:00
Resolved: 2025-01-15 16:28:41+00:00

From bug 1926359: Ideally the line should cover the whole group, but I don't know that we can do this given our use of display:contents. As it stands the line will extend under dragged tabs themselves, but left or right from those there can be gaps in the line.
Bug: [Experiment] The Firefox title and logo overlap with the Pocket stories on certain zoom levels using the variantB layout
Status: NEW
Priority: --
Created: 2024-10-30 11:43:29+00:00
Resolved: 2024-10-30 11:43:29+00:00

**[Affected versions]:**
- Firefox Nightly 134.0a1 (Build ID 20241029155057)
- Firefox Beta 133.0b1 (Build ID 20241028142722)
- Firefox Release 132.0 (Build ID 20241021175835)

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

**[Prerequisites]:**
- Have the "browser.newtabpage.activity-stream.newtabLayouts.variant-a" pref set to true.
- Have the "browser.search.region" pref set to "US".

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Open a new tab and zoom in to 190%.
3. Scroll down and observe the Firefox logo.

**[Expected result]:**
- All page icons are scaled correctly according to the zoom level.

**[Actual result]:**
- The Firefox title is displayed below the story cards.

**[Notes]:**
- Depending on the screen size, the title/logo overlaps with the cards on the following zoom levels:
	- 1920x1080p - 150-160%, 190-210%, 250-260%, 420-500%
	- 2560x1440p - 190-220%, 250-290%, 330-360%
	- 3072x1920 (macbook retina display) - 150%, 200%, 400-500%
- Attached a screen recording of the issue:
Bug: Content analysis notification is displayed two times when the connection to the agent cannot be established
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-10-30 13:29:28+00:00
Resolved: 2025-03-03 14:44:30+00:00

**Found in**
* 134.0a1 (2024-10-29)

**Affected versions**
* 134.0a1 (2024-10-29)








    


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


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
* DLP Agent is not running


**Steps to reproduce**
1. Paste a string to a random webpage.



**Expected result** 
* The notification is only shown once.


**Actual result**
* The notification is displayed 2 times.

**Regression range**
* The issue happens after bug 1915351.

**Additional notes**
* Attached a screen recording.
Bug: Use the account uid for all merge warnings
Status: NEW
Priority: P2
Created: 2024-10-30 13:48:06+00:00
Resolved: 2024-10-30 13:48:06+00:00

We store a hash copy of the user's email when logging in so we know whether to show a merge warning later. This is fragile because the user may change their email, thus showing a false positive. We should move to using the (hashed) uid instead.
Bug: 'send yourself a download link' link is marked up as a button
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-10-30 16:44:23+00:00
Resolved: 2025-01-17 12:33:19+00:00

## Prerequisites:

Found in Nightly 134.0a1 (2024-10-29)(64-bit)

## STR:

1. Open `about:welcome` from URL bar
2. Click the blue 'Save and Continue' button
3. Click the gray 'Skip this step' button
4. The multiple device screen will appear. Right click the 'send yourself a download link' link and observe the code in Dev Tools

## Expected/Actual:

`<a role="button" tabindex="0" data-l10n-name="download-label">send yourself a download link.</a>`

Since this is a link and not a button, `role="button"` should be removed. This should be marked up as a link with `<a href="">`
Bug: Notification dot from the received tab is misaligned
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-10-30 16:47:03+00:00
Resolved: 2025-02-21 23:06:56+00:00

**Found in**
* 133.0b1

**Affected versions**
* 134.0a1
* 133.0b1
* 132.0

**Preconditions**
* Have a FxA account and be signed into Sync on 2 profiles 

**Tested platforms**
* Affected platforms: Ubuntu 22.04, Windows 11
* Unaffected platforms: macOS 13.6 / 14.7 

**Steps to reproduce**
1. Open a random webpage with the first profile from prerequisites
2. Right click on the tab and use the “Sent Tab to Device” option to send the tab to the second profile 
3. Observe the notification dot from the received tab on the second profile 

**Expected result**
*  The notification dot from the received tab is centered under the site favicon

**Actual result**
*  The notification dot from the received tab is slightly offset to the left of the site favicon

**Regression range**
* Mozregression points to bug 1902083

**Additional notes**
* See the attached ss
* The issue is more visible on Ubuntu than on Windows
* Not reproducing on macOS
Bug: Always showing default search engine icon next to address confuses site identity and is not relevant to the current site
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-30 18:02:01+00:00
Resolved: 2024-11-01 16:48:25+00:00

STR:
1. Set `browser.urlbar.scotchBonnet.enableOverride = true`.
2. Make sure the default search engine is Google. 
3. Visit a non-Google site like mozilla.org.

Expected:
Everything in the address bar relates to the current site, especially the icon closest to the address.

Actual:
The icon closest to the address shows a Google logo but the current website is something else which could lead to confusion.

The area to the left of the address is normally reserved for website identity and security. A user unfamiliar with how the unified search button works could mistake the current site as a Google property based on the icon, even users who are familiar with it could subconsciously make a false association. This confusion is more likely with Google since it uses the same icon across a variety of different services. It doesn't help that the icon is the most colorful and eye-catching part of the stock navigation toolbar.

The address bar is normally reserved for contextual information or actions that relate to the current site when in an unmodified state. The default search engine does not satisfy this criteria and introduces clutter into an area that already suffers from too much information. This has lead to security labels being hidden (Bug 1925332) and the minimum window width being increased for vertical tabs (Bug 1923080).

Chrome only shows the Google logo in the site identity area when the address is modified (non-URL) to indicate it will perform a search, this avoids clutter, ensures it is contextually relevant and not confused with site identity. Similarly, Fenix only shows the unified search button when the address bar is focused which largely avoids the issue.

Another thing to consider is the visual impact of such prominent branding. Showing the Google logo on every site (more than Chrome!) makes the browser feel more like a property of Google or is being powered by Google in more ways than just search. Even though the default search engine can be easily changed, it may give a bad first impression for those switching from Chrome intending to avoid Google.
Bug: Tabs from other devices panel does not display all tabs from synced mobile devices
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-10-30 18:37:31+00:00
Resolved: 2024-11-09 09:39:07+00:00

**Prerequisites**
Note - the issue is reproducible in Firefox View release with a synced mobile device (View does not display all synced tabs from a mobile device.) 
 
1. In Nightly, sign in to Mozilla account and pair a mobile device with more than 25 tabs open.  
2. Activate sidebar experiment and sync tabs. 

**Expected result** 
1. Tabs from other devices sections in Account menu, Firefox View, and the new sidebar display all open mobile tabs, regardless of their number. 

**Actual result**
1. Only the most recent 25 tabs show in the new sidebar and Fx View. 
2. If mobile device has inactive tabs (not reloaded in for 14 days), they will not be displayed in the sidebar and Fx View. 
3. The full list of tabs is displayed in Accounts menu (and in the old sidebar if you flip the experiment off).
Bug: Update desktop oauth flows to the newly agreed mechanisms
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-10-30 18:49:33+00:00
Resolved: 2024-11-05 19:33:05+00:00

We previously got information about the services to enable and the sync engine selections in the oauth_login message. We determined that this caused us to lose that information in scenarios where the verification happens in a different session (eg, a browser restart).

Therefore, we agreed that the service information should come in the `login` message, even though this message comes before we are verified. Because verification might happen in a different browser session, we need to persist these selections. Which brings us to the final complication - when verifying in a different session, we *also* get a `login` message during that flow - but this flow has also lost the session information. Therefore, we need to make sure these persisted engines survive multiple `login` messages but also keep the data from the single message which has the information we need.
Bug: Removing tabs from a tab group places tabs in reverse order.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-10-30 18:51:34+00:00
Resolved: 2024-12-05 12:43:30+00:00

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

Steps to reproduce:

When selecting 'Ungroup tabs' or 'Remove from group', tabs are placed in reverse order.  



Expected results:

Ungrouped tabs should retain their previous order.
Bug: Keeping a private window open will break session restore
Status: NEW
Priority: P2
Created: 2024-10-30 18:55:54+00:00
Resolved: 2024-11-19 21:10:11+00:00

I closed all my regular Firefox windows except for a private window, and then reopened a regular Firefox window, but session restore did not occur. Under the history tab, I don't see the option to `restore previous session` either. 

Steps to reproduce:
1. Have a regular Firefox window and a private Firefox window open
2. Enable `open previous windows and tabs`
3. Close the regular Firefox window
4. Reopen a regular Firefox window

Expected result: The regular Firefox window that's opened should contain tabs from the previous session 
Actual result: The regular Firefox window opens with the homepage
Bug: 9.51% tresize (Linux) regression on Mon October 21 2024
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-10-30 19:52:31+00:00
Resolved: 2024-11-07 00:22:40+00:00

Perfherder has detected a talos performance regression from push [42d3134758c767b29889b2a3184fc869cc184d63](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=42d3134758c767b29889b2a3184fc869cc184d63). 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)** |  
|--|--|--|--|--| 
| [10%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,4767341,1,1)  | [tresize](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tresize)  | linux1804-64-shippable-qr | e10s fission stylo webrender-sw | 20.64 -> 22.60 | 
### Improvements:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)** |  
|--|--|--|--|--| 
| [7%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,109827,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | windows11-64-shippable-qr | e10s fission stylo webrender-sw | 1.79 -> 1.67 | 
| [6%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,4774898,1,1)  | [tart](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tart)  | macosx1015-64-shippable-qr | e10s fission stylo webrender-sw | 1.78 -> 1.67 | 
| [5%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&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.84 -> 1.75 | 


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=2610), 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 2610`

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 aglavic@mozilla.com.
Bug: New Tab uses Pocket Image Proxy to fetch Unified Ads API images
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-10-30 20:27:23+00:00
Resolved: 2024-10-30 20:36:49+00:00

New Tab on Nightly 134.0a1 (2024-10-30) passes images fetched from Unified Ads API through the Pocket Image Proxy. That is, the image URL `https://ads-img.mozilla.org/v/images?image_data=foo` is turned into `https://img-getpocket.cdn.mozilla.net/296x148/filters:format(jpeg):quality(60):no_upscale():strip_exif()/https%3A%2F%2Fads-img.mozilla.org%2Fv1%2Fimages%3Fimage_data%3Dfoo` before fetching.

While this is unnecessary for all images served by Unified Ads API (Unified API already anonymizes user requests), it has the additional undesired effect of cropping images for Medium Rectangle ads. See attached screenshot for how medium rectangle ads are currentlu displayed in New Tab vs how they should be displayed.