av9ash/GitBugs huggingface dataset:
Bug: when restoring my session, one of the windows corrupts and becomes a single "undefined" tab
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-21 21:16:58+00:00
Resolved: 2023-12-04 12:23:24+00:00

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

Steps to reproduce:

enabled automatic session restore
2. have LOT of tabs (this may not be necessary actually, but it could contribute to the problem. The affected window was the largest of the 3 both times it happened)
2.5 in one of the cases where this issue happened, I was switching between Firefox profiles and may have accidentally closed the window as it was loading from disk. This was only the case for one of the 2 times, however.
3. close Firefox through "Exit" in the main menu (hamburger menu button on the right) or its corresponding keyboard shortcut (control + shift + Q)



Actual results:

data loss! That's what happened!
An entire window, probably 50+ tabs (I am one of those tab hoarding types...), was lost. You had one job, session restore!
If not for browsing history I'd have to start from scratch, at least with that window.


Expected results:

session restore should have restored ALL tabs and windows from previous session. In case of failure, Firefox should maintain a snapshot of the most recently closed session (maybe two, depending on the size). In a sense, automatic backups of the session. On the upside, I've learned a lesson: always keep a somewhat recent backup of my profile in case of Firefox being stupid. Or use Vivaldi.
Bug: Edit and Zoom combined buttons' label are not centered when the items are in the overflow panel
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-21 21:30:16+00:00
Resolved: 2022-12-01 20:29:14+00:00

STR:
1. Latest Nightly
2. Open the customize page
3. Move the Edit and Zoom controls to the overflow menu
4. Exit customize mode and open the overflow panel

See how the Copy, Paste, and zoom percentage are not centered
Bug: File MIME type is overwritten by OS-level settings
Status: NEW
Priority: P3
Created: 2022-11-21 23:43:22+00:00
Resolved: 2022-11-25 14:26:19+00:00

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

Steps to reproduce:

1. Create a form with a file input
2. Select a CSV file from your computer
3. Programmatically read the file's MIME in JavaScript (`File.type`)

OS: Windows 10
Firefox 100: Error
Chrome 107: OK


Actual results:

While working on a project for a client, they came across a bug we could not reproduce. It turned out the MIME type of a file provided in an upload input was being overwritten by OS settings.

The file type in question is a CSV file. On my test Windows machine, I did not have Excel or any Microsoft Office apps installed. The client however, did.

While my .csv files were returned as `text/csv` consistently, theirs returned `application/vnd.ms-excel`.

These files were tested and confirmed to be real CSV files and not just renamed Excel files.


Expected results:

Common filetypes like CSV should be reliably set to their "natural" MIME type, and not allow the OS to overwrite it if software has been set to the default handler for that file type.

I can fully understand that some filetypes might be obscure and this allows to get more reliable information, but some MIME types should be safe from this behaviour if they are common enough. Other browsers like Chrome do not trigger this issue and seemingly parse the "natural" MIME type regardless of OS settings.
Bug: The Persist Search tip is inconsistently displayed on the address bar
Status: RESOLVED
Priority: P3
Resolution: INVALID
Created: 2022-11-22 10:35:46+00:00
Resolved: 2024-09-11 15:30:02+00:00

**Found in**
* Fx108.0b4

**Affected versions**
* Fx 108.0b4

**Affected platforms**
* Windows 10
* Ubuntu 22.04
* macOS

**Preconditions**
New profile.

**Steps to reproduce**
1. Launch Firefox.
2. Go to about:config and set *browser.urlbar.showSearchTerms.featureGate* to true.
3. Open a new tab (Search Tip is displayed - **NOT** persist search tip).
4. Perform a search using the address bar.
**Expected result**
* Persist search tip is displayed as this is the first time search terms are persisted in the session.
**Actual result**
* Persist search tip is not displayed.

5. Open a new tab and perform another search.

6. With the tab where the search was made in the foreground, perform a restart.
**Expected result**
* Persist search tip is displayed .
**Actual result**
* Persist search tip is not intially displayed on the foreground tab, only when switching back to another tab where a search was made.


**Regression range**
* I'm not sure if this is a regression, as nothing new was added to the build.

**Additional notes**
* This issue started occurring Tuesday, on the same build where in the previous day everything worked accordingly (persist search tip was displayed on the search from step 4). 
* This issue only occurs on beta. Nightly works as expected on the same machine (only the persist search tip is displayed.
Bug: Session recovery loses windows converted to tabs
Status: NEW
Priority: --
Created: 2022-11-22 18:51:25+00:00
Resolved: 2022-12-12 21:10:27+00:00

In Firefox 107 and Nightly, but not in (some) earlier versions, if you open two new windows, move the second window to be a tab in the first window, shut down Firefox, and restart it, with the 'Open previous windows and tabs' preference selected, the second tab (ex window) will be gone. From manual inspection, it appears that the window-to-tab tab doesn't make it into the sessionstore-backups/recovery.jsonlz4 file in my profile.

(I am on Fedora 36 x86-64 Linux under X, but I expect that this is generic.)

I believe that this worked in Firefox 106, but I only noticed the issue recently so I can't be entirely sure. My knowledge of mozregression usage isn't sufficient for me to bisect this, since it (presumably) requires two runs of the same Firefox to test properly.
Bug: Make element picker for screenshot capture keyboard accessible
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-11-22 19:32:14+00:00
Resolved: 2024-05-13 19:29:56+00:00

One of the way to indicate the rectangle we want to capture on a page is to use the "element" selector. This lets the user hover over elements on the page, highlighted with an outline to provide the box coordinates to capture. 

Its not clear how to make this UX keyboard accessible. Perhaps we'd need an alternate affordance like a select menu with a list of element targets (the list would be filtered to candidates with a minimum height/width etc.)
Bug: Uneven margins between the tab pickup header and its contents vs. the recently closed header and its contents
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-11-22 21:39:11+00:00
Resolved: 2023-01-30 11:17:34+00:00

The `#collapsible-tabs-container` element has 0.5em top margin, whereas the setup-step cards in the tab pickup have 0 top margin. This disparity is most apparent when there are 0 recently closed tabs - so you have borders around each container. 

I think the recently-closed-tabs treatment is probably correct in this case so we just need to add the same `margin-block-start: 0.5em` property to the [`.setup-step` rule](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/firefoxview.css#456-459)
Bug: When Internal Explorer or EdgeHTML Edge is selected in the new migrator, refer to "Favorites" instead of "Bookmarks" in the resources list
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-11-22 22:18:29+00:00
Resolved: 2023-03-30 03:15:33+00:00

Internet Explorer and EdgeHTML Edge used the term "Favorites" rather than "Bookmarks". We should try to preserve that terminology in the migrator if these are the browsers that people are migrating from.

We already do this for the existing XUL migration dialog. This bug is to make sure we also do this for our new dialog.
Bug: downloader faulting and corruption
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-23 04:17:54+00:00
Resolved: 2023-01-20 16:46:16+00:00

Steps to reproduce:

Download from gog.com. A combination of .bin files and .exe on Windows 64 bit and Firefox 64bit. In batches of 5 simultaneous downloads.

This has been happening on all versions of Firefox all throughout 2022


Actual results:

Downloads creates a .part file (temporary cache) and the final output file. The completed download creates one of three outcomes:-

1) creates the final file with name preserved and cache removed (perfect)
2) creates the final file but adds (1) to the end of the file name even though a similar file does not exist (wrong)
3) leaves the download in the .part cache file and does not write to final file.


Expected results:

Write the data to the final output file. Preserve the original file name. Delete .part cache file
Bug: Get wrong MIME type on Firefox@KylinOS
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-23 08:01:27+00:00
Resolved: 2023-04-27 03:33:42+00:00

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

Steps to reproduce:

My website provides a file uploader to the users, and only Excel file (xlsx) is allowed to be uploaded. So I try to check the MIME type of uploaded file and limit it to "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" which is listed on MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types). This works well on most browsers and os, but failed on Firefox, OS is Kylin V10.
FireFox version: Firefox for ubuntu 52.3.0, 64bit
OS version:  Kylin V10, arm64


Actual results:

By uploading a file with format '.xlsx', Firefox reports the file.raw.type is 'application/wps-office.xlsx'


Expected results:

By uploading a file with format '.xlsx', Firefox reports the file.raw.type is 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
Bug: Synchronization of tabs in disconnected device
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-11-23 09:06:06+00:00
Resolved: 2022-11-29 21:42:27+00:00

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Firefox for Android

Steps to reproduce:

I am logged in to Firefox on my laptop and on my cell phone. Everything is fine. I was able to open/use tabs on any one of the devices mentioned. But one day, I did factory reset to my cell phone. Before factory reset, some tabs were open in Firefox in my cell phone. After resetting, I reinstalled firefox. Then in my firefox account, three devices were listed. Two cell phones with same name and one laptop. I disconnect old device (same device which I reset).  

Now the problem/bug is, whenever, I sync in my cell phone, it shows old tabs (opened in my cell phone before resetting). And currently, they are not opened in my cell phone (after resetting). 


Actual results:

 Whenever, I sync in my cell phone, it shows old tabs (opened in my cell phone before resetting of my cell phone). And currently, they are not opened in my cell phone (after resetting). 

I am unable to close these opened (shown) tabs. If I close them, they appear again after every sync.


Expected results:

Tabs opened in my cell phone before resetting of my cell phone must be closed if I close them.
Bug: gitlab Next link is partially overlapped in portrait
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-11-23 11:28:35+00:00
Resolved: 2022-11-23 19:18:01+00:00

User Agent: Mozilla/5.0 (Android 12; Mobile; rv:109.0) Gecko/109.0 Firefox/109.0
Firefox for Android

Steps to reproduce:

Go to https://gitlab.freedesktop.org/xorg/xserver/-/issues
in Firefox Nightly for Android.

Move to bottom of webpage.


Actual results:

Check that "Next" button is partially overlapped by "Show 20 items".


Expected results:

Don't overlap.
Bug: [Experiment] The users can be enrolled in the “Onboarding Welcome Video Experiment” even if they prefer reduced motion
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-11-23 13:12:46+00:00
Resolved: 2022-12-09 18:55:24+00:00

**[Affected versions]:**
- Firefox Beta 108.0b5 - Build ID: 20221122190120

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

**[Prerequisites]:**
- Have the Firefox Beta 108.0b5 browser installed.
- Have this [user.js](https://drive.google.com/file/d/13v9G4ujXA51LztHONfoVj5-rz76_MqNj/view?usp=share_link) saved on your computer.
- Have the “Show animations on Windows” set to Off in OS settings.

**[Steps to reproduce]:**
1. Open the browser using the -p --first-startup and create a new profile.
2. Copy and paste the user.js file from prerequisites on the Profile Folder.
3. Open the Firefox profile from prerequisites.
4. Navigate to the “about:studies” page.
5. Observe the listed studies.

**[Expected result]:**
- The “Onboarding Welcome Video Experiment” experiment is not displayed on the “about:studies” page.

**[Actual result]:**
- The “Onboarding Welcome Video Experiment” experiment is displayed on the “about:studies” page.

**[Notes]:**
- The “userPrefersReducedMotion” is recognized as true in the ASRouter devtool.
- Attached is a screen recording of the issue.
Bug: No borders for the bookmarks folder drop-down
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-11-23 13:36:24+00:00
Resolved: 2023-08-09 16:35:27+00:00

**Found in**
* Firefox 108.0b5

**Affected versions**
* Nightly 109.0a1
* Firefox 108.0b5

**Tested platforms**
* Affected platforms: Windows 7, Windows 8.1
* Unaffected platforms: macOS 11.7, Ubuntu 20.04, Windows 10

**Preconditions**
* set the Bookmarks Toolbar to Always Show.

**Steps to reproduce**
1. On the Bookmarks Toolbar - create a New Folder.
2. Click on the folder and observe the dropdown.

**Expected result**
* The dropdown's borders should be properly displayed.

**Actual result**
* The dropdown's borders are not visible at all on Beta 108 and are lacking the shadow on Nightly 109.0a1.

**Regression range**
* Found commit message:
Bug 1793359 - Simplify bookmarks popup placement. r=Itiel,dao,mak
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=05f17b2551cb8583002fa405a8982ca5c8166be2&tochange=c92eaa4cd353e2c5f9445d7fdb5ef5503adf949f

**Additional notes**
* Beta 108 is more affected than Nightly 109.0a1 where the landing of Bug 1796940 made the borders visible even if the shadow is still missing.
Bug: Search bar can't be resized from its max value to its min value from one action
Status: NEW
Priority: --
Created: 2022-11-23 13:46:24+00:00
Resolved: 2023-01-03 16:33:35+00:00

**Found in**
* Firefox 108.0b5

**Affected versions**
* Firefox 108.0b5
* Latest Nightly 109.0a1

**Unaffected versions**
* Firefox 107.0 RC

**Tested platforms**
* Affected platforms: Windows 10, macOS 11.6, Ubuntu 22.04
* Unaffected platforms:  N/A

**Preconditions**
* Have the Search Bar enabled in the right side of the URL bar.
* Remove the separator from the right side the URL bar.

**Steps to reproduce**
1. Place the cursor between URL bar and Search Bar
2. Click and drag from right to left the in order to resize the Search Bar (and URL bar)

**Expected result**
* The Search Bar can be resized from max to min length from one action

**Actual result**
* The Search Bar can only be resized from max to min length after using more then one action.

**Regression range**
* First bad: fde57ffc3be69783c38c9abaf96d673d683e7e15
* Last good: a9df937f88903ab2d7ecd4a977273fd500aeca2b
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a9df937f88903ab2d7ecd4a977273fd500aeca2b&tochange=fde57ffc3be69783c38c9abaf96d673d683e7e15
* Potentially regressed by: Bug 1794630 - Improve splitters for browser chrome use cases.

**Additional notes**
* Gif showing the issue is attached.
Bug: Unable to resize search bar after restore browser sizemode
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-23 15:04:43+00:00
Resolved: 2022-11-23 15:05:55+00:00

Another steps to reproduce:
1. Add search bar in toolbar from about:preferences#search

2. Maximize the browser
3. Drag the splitter to make the search bar as wide as possible

4. Restore browser sizemode
5. Attempt to resize the search bar by dragging the splitter

Actual results:
The search bar cannot be resized at all.
Screencast: https://youtu.be/OYMaAHLabvQ

Expected results:
The search bar can be resized.
Bug: Unnecessary white space is displayed under the progress bar on the Onboarding modals at different zoom levels
Status: NEW
Priority: P3
Created: 2022-11-23 15:05:26+00:00
Resolved: 2022-11-28 16:37:53+00:00

**Found in**
* 108.0b5

**Affected versions**
* 109.0a1
* 108.0b5
* 107.0


**Tested platforms**
* Affected platforms: Win 10, macOS 10.15, Ubuntu 21.04


**Steps to reproduce**
1. Lunch Firefox
2. Navigate to the "about:welcome" page.
3. Decrease and increase the zoom level.
4. Observe the progress bar.


**Expected result**
* There is no white space displayed under the progress bar. The progress bar should be sticking to the bottom of the modal no matter the zoom level.

**Actual result**
* An unnecessary white space is displayed under the progress bar at different zoom levels.

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

**Additional notes**
* The zoom levels on which this issue occurs differ from one display to another.
* Please observe the issue in the attachment.
Bug: Overflow tab arrow is still displayed for a moment after Firefox switches to Fullscreen
Status: NEW
Priority: --
Created: 2022-11-23 15:14:25+00:00
Resolved: 2022-11-23 15:14:25+00:00

**Found in**
* Firefox 108.0b5

**Affected versions**
* Firefox 108.0b5
* Latest Nightly 109.0a1
* Firefox 107.0 RC

**Tested platforms**
* Affected platforms: macOS 11.6
* Unaffected platforms: Windows 10, Ubuntu 22.04

**Steps to reproduce**
1. Have the Firefox open in a relative small size (not entire screen)
2. Open enough tabs until the overflow tab arrows are visible
3. Click the fullscreen button (green button next to close, minimize | full screen button from Application Menu | any method)

**Expected result**
* The overflow tab arrow is gone from the tab bar before the animation of fullscreen finishes

**Actual result**
* The arrow is still shown for 1 second after Firefox has switched to fullscreen.

**Regression range**
* Not a regression since this has been an issue since 72.0a1, older builds will close when switching to full screen

**Additional notes**
* Screencast showing the issue is attached.
Bug: text in menuitem from extension with icon at start shifted, not verticaly aligned with other menu items
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-11-23 15:25:58+00:00
Resolved: 2022-12-14 08:16:05+00:00

Firefox 109.0a1 20221123094429 on Windows 8.1 with the Multi Accounts Container extension 8.0.7 installed

The context menuitem for the Multi Accounts Container extension has its text horizontally shifted, possibly because it uses an icon for it.

Regression from bug 1801844?

PS: There is less vertical space between menu items, not sure if this is desired.
Bug: style of download dialog regressed
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-11-23 21:26:37+00:00
Resolved: 2023-07-01 11:42:24+00:00

Bug 1801339 regressed the style of the download dialog. Please see the attached screenshot.

STR:

1. Make sure you have Firefox configured to always ask for DMG files
2. Download a DMG file from https://archive.mozilla.org/pub/firefox/nightly/2022/11/2022-11-23-09-44-29-mozilla-central/
3. See the dialog.
Bug: open/save dialog is too wide for long file names
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-24 03:01:03+00:00
Resolved: 2022-11-24 17:26:40+00:00

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

Steps to reproduce:

Open (or save) a file with a long file name


Actual results:

The open/save dialog includes the full file name and is stretched extremely wide with very long file names


Expected results:

The dialog width should be smaller and the file name should be truncated.

mozregression output:

7:06.42 INFO: No more integration revisions, bisection finished.
 7:06.42 INFO: Last good revision: e63a07f26954b74c53db790288de6cdbc08280cb
 7:06.42 INFO: First bad revision: 8390e1d55a65db3a7605d49b37a226df55001344
 7:06.42 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e63a07f26954b74c53db790288de6cdbc08280cb&tochange=8390e1d55a65db3a7605d49b37a226df55001344
Bug: Sidebar context menu: "Open Link in New Tab" does nothing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-24 03:44:55+00:00
Resolved: 2022-11-24 04:33:45+00:00

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

Steps to reproduce:

1. Install Tab Stash from: https://addons.mozilla.org/en-US/firefox/addon/tab-stash/
2. Open the Tab Stash sidebar.
3. Either save a tab into the stash, or open a new tab and navigate to a page. (The important thing is to get Tab Stash show a link in the sidebar UI—doesn't matter where in the UI the link is shown.)
4. Right-click on the link in the Tab Stash UI and choose "Open Link in New Tab".


Actual results:

The link (either stashed or unstashed, doesn't matter) should open in a new tab.


Expected results:

Nothing. No tab is opened, and no errors are shown in the extension developer console.
Bug: firefox --screenshot fails on macOS Ventura
Status: NEW
Priority: --
Created: 2022-11-24 04:08:21+00:00
Resolved: 2022-11-28 20:11:03+00:00

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

Steps to reproduce:

On the Terminal command line input

/Applications/Firefox.app/Contents/MacOS/firefox -screenshot https://www.mozilla.org/en-GB/

or

/Applications/Firefox.app/Contents/MacOS/firefox --screenshot https://www.mozilla.org/en-GB/


Actual results:

produced output:

*** You are running in headless mode.
[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt

Then the application seemingly hangs until I press the Enter key, where I get the shell back. However, ps ax shows a firefox process is still running until manual kill.


Expected results:

a screenshot of the web page should have been generated and stored in a file at a convenient location
Bug: [Experiment] The “Try Colorways” modal from the “Firefox View” page is not triggered after clicking the “Choose colorway” button from the Colorways Reminder CFR
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2022-11-25 11:06:00+00:00
Resolved: 2022-12-01 20:26:30+00:00

**[Affected versions]:**
- Firefox Beta 108.0b5 (Build ID: 20221122190120)

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

**[Prerequisites]:**
- Have the latest version of Firefox Beta 108 installed and opened.
- Have the channel pref set to “release”.
- Have the “nimbus.debug” pref set to true in the “about:config” page.


**[Steps to reproduce]:**
1. Force enroll in the Treatment A branch of the experiment using the following link: about:studies?optin_slug=colorways-expiring-fx108&optin_branch=treatment-a&optin_collection=nimbus-preview
2. Change the system date to 2 days in the future.
3. Restart the browser, open and close 3 tabs.
4. Unfocus the Address bar and don’t interact with the Firefox View CFR.
5. Navigate to Firefox View tab and dismiss the “Firefox View Callout” messages.
6. Change the system date to 29th December 2022 and restart the browser.
7. Navigate to a website (e.g. cats.com).
8. Click the “Choose colorway” button from the Colorway Reminder CFR.
9. Observe what happens.

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

**[Actual result]:**
- The “Firefox View” page is focused, and the “Try Colorways” modal doesn’t open.

**[Notes]:**
- This issue is also reproducible in the Treatment B, C, and D branches of the experiment.
- Attached is a screen recording of the issue.