av9ash/GitBugs huggingface dataset:
Bug: Not able to import data from Opera/Vivaldi on first run migration
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-11-16 16:33:01+00:00
Resolved: 2022-12-21 13:26:18+00:00

**Found in**
* Nightly 109.0a1

**Affected versions**
* Nightly 109.0a1

**Tested platforms**
* Affected platforms: all
* Unaffected platforms: 

**Preconditions**
* Opera/Vivaldi are installed(stable version from Ubuntu apps or from the following link: https://www.opera.com/download, I downloaded .deb file) and has user data to import:
- browsing history
- saved bookmarks
- saved Logins and Passwords
- search bar history
- cookies
* Create an user.js file with the following prefs:
user_pref("browser.migrate.opera.enabled", true);
user_pref("browser.migrate.vivaldi.enabled",true);
* Remove the profiles folder from:
- MacOS: Library\Application Support\Firefox
- Windows: %appdata%\Mozilla
- Ubuntu: home/user/.mozilla

**Steps to reproduce**
1. Open Fx profile manager from terminal using -p -migration command
2. Create a new profile.
3.  Go to profiles folder and paste user.js to the new profile created above
4. Open Firefox with the profile created at step 2

**Expected result**
* Opera and Vivaldi browsers should be available on the first run migration

**Actual result**
* Opera, Vivaldi browsers are missing from the first run migration

**Regression range**
* Not a regression. New feature implementation

**Additional notes**
* Chrome browser is listed.
Bug: defaultEngineId does not support an _isAppProvided: false search engine
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-11-16 19:40:53+00:00
Resolved: 2022-12-12 14:05:02+00:00

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

Steps to reproduce:

Firefox used to allow configuring search engines via search.json.mozlz4, however on version 108.0b1 this no longer seems to work for non-builtin search engines (ones with _isAppProvided: false).

This seems related to the changeset 714274 (aac389dbe3cb61fb13d7a38332f941e594361e69)

Steps to reproduce:
1. Create a new Firefox profile
2. Add a new custom search engine to the profile (e.g. add the following to engines array:)
```
{
  "id":"582076c8-4739-4996-992c-41df0982d240",
  "_name":"HackerNews",
  "_isAppProvided":false,
  "_urls":[{"template":"https://hn.algolia.com/?q={searchTerms}"}],
  "_metaData":{"alias":"!hn","order":4}
}
```
3. Set the default search engine to the custom search engine in search settings page
4. Copy search.json.mozlz4 to a new Firefox profile


Actual results:

Observe that default search engine reverts to Google.


Expected results:

Expected default search engine to remain set to HackerNews.
Bug: sftp always download files instead of displaying them
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-11-16 19:47:41+00:00
Resolved: 2022-11-21 08:46:46+00:00

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

Steps to reproduce:

a) Use firefox with empty profile.
b) Enter an URL like sftp://mycomputer/home/user/test.html.

NOTE: Needs an host called mycomputer and the test.html file in the specified path accessible via ssh/sftp.



Actual results:

File is downloaded.

Until some version ago this simply displayed the website in the browser. Now since at least 5-10 versions it only downloads the file. That's rather annoying, as for downloading files via SSH there are better tools.


Expected results:

File should be displayed.

For file types which can be displayed in the browser (html, text, images, pdf) the browser should be used to display them instead of downloading. Or at least ask and and allow to display.

A related issue: When I enter an URL of an image in the browser it also downloads it instead of displaying. In this case it even gets correct mime-type via the HTTP headers which it doesn't for SFTP. I'm pretty sure this also worked in the past.
Bug: [mac][HCM] "Last Active" badge text is not readable on the Dark theme with Increase Contrast
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-11-16 22:02:49+00:00
Resolved: 2022-12-20 08:23:45+00:00

## STR:
1. Activate a High Contrast Mode of the macOS by checking `Increase Contrast` option under `System Preferences > Accessibility > Display > Display` and ensure the `Dark` mode is selected under the `System Preferences > General > Appearance`
1. Visit Firefox View at `about:firefoxview`
2. Ensure that `Tab Pickup` shows some tabs (from Sync)
3. Review the `Last active` badge on the first tab card

## Expected:
The badge text is easy to read and the color contrast provided for the text vs background combination is WCAG 2.1 AAA compliant (7:1 or higher)

## Actual:
The badge text is not possible to read, because the color contrast is 1:1 for light green text against white background.

## Notes:
The code affects all systems, but Windows 11 HCM is ignoring the light green color on HCM while macOS does not enforce it, thus the MacOS is most affected. I do not have access to a Linux build t

It looks like the issue is with the `background-color: #E3FFF3;` being hardcoded for the `.last-active-bagde` (thus the Fx theme cannot handle it by itself) and no HCM-specific style is provided in the cascade.

Tested on the most recent Nightly 109.0a1 (2022-11-16) (64-bit) on macOS v.12.6.1
Bug: Browser toolbox 'restore down' window position is not saved
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-17 02:46:08+00:00
Resolved: 2022-11-18 20:32:30+00:00

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

Steps to reproduce:

Open the Browser toolbox (ctrl-alt-shift-i)
Maximize the window if it's not already
Click the restore-down button
Move the window down from the top any other location
Quit the toolbox
Restart the toolbox


Actual results:

The restored-down window opens at the top of the screen


Expected results:

The restored-down window should have opened in the same place it was closed.

Happens on latest versions of developer, beta, and nightly but not on release.
Also happens in Troubleshoot mode.

Deleting the chrome_debugger_profile folder did not help.
Bug: Tabs telemetry appears to no longer be collected
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-11-17 03:02:33+00:00
Resolved: 2022-12-01 13:08:02+00:00

I'm seeing logs with:

> Sync.Telemetry  ERROR   Notification for engine tabs but it isn't current

So the telemetry module doesn't think the tab engine is currently syncing when it is - [see here](https://searchfox.org/mozilla-central/source/services/sync/modules/telemetry.js#641)

This message also causes an error log to be recorded. I haven't dug into the implications of this.
Bug: The download window should have a smaller minimum resizable width/height/size
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-11-17 07:14:17+00:00
Resolved: 2023-01-26 11:44:40+00:00

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

Steps to reproduce:

Click on the hamburger menu icon, select Downloads.  The window popup huge, needs the sizing ability to be added back to the window.


Actual results:

Cannot resize the Downloads window.


Expected results:

Ability to resize the window.
Bug: [Linux] The “Firefox Video” is not displayed on the “about:welcome” page
Status: NEW
Priority: P3
Created: 2022-11-17 07:47:12+00:00
Resolved: 2022-11-21 16:52:04+00:00

**[Affected versions]:**
- Firefox Nightly 109.0a1 (Build ID: 20221116182402)

**[Affected Platforms]:**
- Ubuntu 22.04 x64

**[Prerequisites]:**
- Have the latest version of Firefox Nightly 109.0a1 installed and opened.
- Have the “browser.aboutwelcome.screens” pref set to “[{"id":"VIDEO_ONBOARDING","content":{"position":"center","title":"Thanks for downloading Firefox!","subtitle":"You’re contributing to a more open and accessible internet","has_noodles":false,"secondary_button":{"label":"Skip video","action":{"navigate":true}},"video_container":{"video_url":"https://assets.mozilla.net/video/firefox-welcome/MozillaBetterTogether.mp4","action":{"navigate":true},"autoPlay":false}}},{"id":"AW_GRATITUDE","content":{"position":"split","split_narrow_bkg_position":"-228px","image_alt_text":{"string_id":"mr2022-onboarding-gratitude-image-alt"},"background":"url('chrome://activity-stream/content/data/content/assets/mr-gratitude.svg') var(--mr-secondary-position) no-repeat var(--mr-screen-background-color)","progress_bar":true,"logo":{},"title":{"string_id":"mr2022-onboarding-gratitude-title"},"subtitle":{"string_id":"mr2022-onboarding-gratitude-subtitle"},"primary_button":{"label":{"string_id":"mr2022-onboarding-gratitude-primary-button-label"},"action":{"type":"OPEN_FIREFOX_VIEW","navigate":true}},"secondary_button":{"label":{"string_id":"mr2022-onboarding-gratitude-secondary-button-label"},"action":{"navigate":true}}}}]” value on the “about:config” page.


**[Steps to reproduce]:**
1. Restart the browser and navigate to the “about:welcome” page.
2. Observe the intro screen of this page.

**[Expected result]:**
- A Firefox video is displayed that is loaded and ready to play.

**[Actual result]:**
- The Firefox video doesn’t show at all, and the “Video can’t be played because the file is corrupt” message is displayed.

**[Notes]:**
 - This issue is not reproducible on Windows 10 x64 and macOS.
 - Attached is a screenshot of the issue.
Bug: TPS - Error syncing tabs: tabEngine.getAllClients().find is not a function
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-11-17 09:36:32+00:00
Resolved: 2022-11-25 08:53:35+00:00

Opening this bug to track this error we are seeing when running the sync integration tests on firefox-ios.

https://storage.googleapis.com/mobile-reports/public/firefox-ios-M1/result_318/SyncIntegrationTests/results/index.html

It happens when we login on Nightly to check if tabs open on mobile are synced.

The error is:
CROSSWEAVE ERROR: [phase phase1] RunNextTestAction failed - TypeError: tabEngine.getAllClients().find is not a function(resource://tps/modules/tabs.jsm:72:49) JS Stack trace: Find@tabs.jsm:72:49

Please see complete log file attached if needed.

We need to narrow down when the error started to happen but it is between Nov 7th and Nov 15th.

Mark, are you aware of any changes that could be causing this? Thanks!
Bug: Address bar no longer retains URL highlight after switching tabs
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-11-17 09:58:47+00:00
Resolved: 2022-12-16 13:26:10+00:00

STR:
1. Click in the address bar to highlight the entire URL or manually select all.
2. Switch to a different tab and back again.

Expected:

The URL should still be highlighted for that tab.

Actual:

The address bar is focused but the URL is not highlighted.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=54bf7e90e341b37087d161b71e008a0f0b654375&tochange=ad7fa1c3acafff6e9d6d4d0e1804c1a08f2b8517

Regressed by Bug 1219775.
Bug: No previous Windows and Tabs displayed under "Restore only the ones you want" on Success page
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-11-17 10:04:59+00:00
Resolved: 2023-02-09 14:00:59+00:00

**Found in**
* Firefox 108.0b2

**Affected versions**
* Firefox 108.0b2
* Nightly 109.0a1
* Firefox 107.0

**Tested platforms**
* Windows 10
* macOS13 Ventura
* Ubuntu 22.04

**Preconditions**
* Firefox installed

**Steps to reproduce**
1. Launch Firefox
2. Open several windows with tabs 
3. Load in each tabs some random websites
4. Go to about:support
5. Click on "Refresh Firefox..." button and again "Refresh Firefox" in the pop-up that appears on screen
6. On the Success page, select "Restore only the ones you want"

**Expected result**
* Under "Restore only the ones you want" there should be the previous opened windows and corresponding tabs.

**Actual result**
*  Under "Restore only the ones you want" no previous windows and tabs are displayed.

**Regression range**

I checked manually the regression for this issue and noticed that the first affected Nightly build is from 17-10-2022 while the issue can not be reproduced in the previous build from 16-10-2022.
We searched through the pushlogs from this time range and a possible culprit might be Bug 1169529.
Maybe this might help when looking into this.

* Potentially regressed by: https://bugzilla.mozilla.org/show_bug.cgi?id=1169529
Bug: StatusPanel gets stuck open in an overLink state on some sites, like Twitter
Status: NEW
Priority: --
Created: 2022-11-17 11:47:30+00:00
Resolved: 2022-12-06 12:07:02+00:00

I've noticed this for a long time but it kinda became background noise so I never filed a bug until now. I'm sure it's not a recent regression in any case.

### STR
1. Go to https://twitter.com/Twitter
2. Find a tweet that has an image and mouse over the image - the status panel should show the URL for the image view while the image is hovered
3. Click on the image to open the big image view, and don't move the mouse to make sure you don't accidentally hover a link
4. The status panel should now be stuck open with the URL of the first page (https://twitter.com/Twitter)
5. Without mousing over any links, move the mouse out of the image area and click on the dim overlay to exit the image view
6. The status panel should now be stuck open with the URL of the image viewer (e.g. https://twitter.com/Twitter/status/whatever/photo/1)

### Expected
For steps 4 and 6, the mouse is not actually over a link, so the status panel should disappear on its own.

### Actual
For steps 4 and 6, the status panel stays open permanently until you mouse over a link, or you perform some navigation in the browser, or the window loses focus, etc.

The bug is definitely not restricted to Twitter - I've noticed it on other sites from time to time. But since it's so common/easy to reproduce on Twitter, it's the only example I can specifically remember. I think a lot of wordpress sites have the same problem when clicking images to open an image viewer overlay, but I can't think of a specific example.
Bug: Small artifact on the right side of Firefox View button once an item from the palette is dragged over tabs while in customize mode
Status: REOPENED
Priority: P3
Created: 2022-11-17 13:38:00+00:00
Resolved: 2023-01-16 17:56:37+00:00

**Found in**
* Firefox 108.0b2

**Affected versions**
* Firefox 108.0b2
* Nightly 109.0a1
* Release 107.0

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

**Preconditions**
* Have browser.tabs.firefox-view pref set as true if not already (it should be true by default)

**Steps to reproduce**
1. Go to More Tools-> Customize toolbar in the burger menu.
2. Drag any item over a tab

**Expected result**
* A small space is made for the item to fit after the Firefox View icon

**Actual result**
* A small space is made for the item to fit after the Firefox View icon by showing an ugly artifact. If the item is hovered near the right side of the Firefox View icon the blank space is created after it without any artifacts.

**Regression range**
* Not a regression range, it is something that also happens using an old Nightly build from 2022-05-10, close to when Firefox View feature was implemented.

**Additional notes**
* I'm not sure if this is intended as a notification for the users for them to know where the item will be placed, I think having a blank space just as it is when hovering over the Firefox View button itself would be enough.
Bug: Perma browser-chrome Customize failures e.g. on CustomizableUI.jsm when Gecko 109 merges to Beta on 2022-12-12
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-17 13:38:38+00:00
Resolved: 2022-11-19 00:38:04+00:00

[Tracking Requested - why for this release]:

* [Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&revision=39ebadcaf7ea950074c6e4c5e7d7d3ff89ef7713&group_state=expanded)
* [How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)
* **Failure logs:**
    * [TEST-UNEXPECTED-FAIL | browser/base/content/test/sync/browser_contextmenu_sendtab.js | Uncaught exception in test - at resource:///modules/CustomizableUI.jsm:1135 - TypeError: aPlacements is undefined](https://treeherder.mozilla.org/logviewer?job_id=396838127&repo=try&lineNumber=3697)
    * [TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_firefoxview_feature_callout_a11y.js | A promise chain failed to handle a rejection: aPlacements is undefined - stack: buildArea@resource:///modules/CustomizableUI.jsm:1135:22](https://treeherder.mozilla.org/logviewer?job_id=396838172&repo=try&lineNumber=11162)
    * [TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_UsageTelemetry_toolbars.js | Uncaught exception in test - at resource:///modules/CustomizableUI.jsm:4334 - Error: Area not yet restored](https://treeherder.mozilla.org/logviewer?job_id=396838173&repo=try&lineNumber=19208)
    * [TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_newwindow_focus.js | A promise chain failed to handle a rejection: aPlacements is undefined - stack: buildArea@resource:///modules/CustomizableUI.jsm:1135:22](https://treeherder.mozilla.org/logviewer?job_id=396838108&repo=try&lineNumber=9348)
    * [TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_1008559_anchor_undo_restore.js | Test timed out -](https://treeherder.mozilla.org/logviewer?job_id=396838019&repo=try&lineNumber=11998)
    * [TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_user_events.js | Cleanup function threw an exception - at resource:///modules/CustomizableUI.jsm:1135 - TypeError: aPlacements is undefined](https://treeherder.mozilla.org/logviewer?job_id=396838100&repo=try&lineNumber=31735)
    * all browser-chrome failures here: [push](https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=MRgWKptQSVyyZOyvFpjXlA.0&revision=39ebadcaf7ea950074c6e4c5e7d7d3ff89ef7713&searchStr=bc&group_state=expanded)

Mike, these seem triggered by Bug 1798896.
Can you take a look please?
Thank you.
Bug: Right click (secondary click) is not working anymore after update to 108.0b2
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-11-17 14:04:36+00:00
Resolved: 2022-11-17 14:12:15+00:00

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

Steps to reproduce:

Just updated firefox 108.0b2 (official) on ArchLinux x86-64.


Actual results:

Right click (aka secondary mouse button click) is not working. Sometimes when I do a secondary click, no menu is appearing, and right click works if I do a double click.


Expected results:

I saw there's an update to the animations. I can see a transition on the menu popup in the new firefox. That update must have broken the secondary mouse click.
Bug: You are currently on nightly update channel text is not correctly aligned inside the About Firefox Nightly window
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-17 14:10:23+00:00
Resolved: 2022-11-18 14:27:34+00:00

**Found in**
* 109.0a1 (2022-11-17)

**Affected versions**
* 109.0a1 (2022-11-17)

**Tested platforms**
* Affected platforms: Windows 10x64, Ubuntu 20.04, macOS 11
* Unaffected platforms: none



**Steps to reproduce**
1. Open the About Nightly window.
2. Observe the update channel text.

**Expected result**
* Text is correctly aligned.

**Actual result**
* Text is not correctly aligned.

**Regression range**
* Last good revision: 0f84b85f120f45fe6bad63d5e26b5ba4cd89f801
First bad revision: fd69d6b3aeb8e1e04334a0885f60966883a69c08
 Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f84b85f120f45fe6bad63d5e26b5ba4cd89f801&tochange=fd69d6b3aeb8e1e04334a0885f60966883a69c08 

**Additional notes**
* Attached a screenshot.
Bug: Screenshot occasionally saves file with extremely long filename
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-11-17 14:40:54+00:00
Resolved: 2024-12-14 01:53:20+00:00

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

Steps to reproduce:

This happened a few weeks ago and I don't recall which website it was. On a windows 11 PC. Browse to an offending website. Take screenshot. Save visible to desktop. 


Actual results:

Screenshot file appears on the desktop with very long filename. Try to delete, rename or move the file with windows explorer and it fails. File properties show an odd looking path. Sorry I don't have the details. Tried CMD to delete the file and it also failed. Rebooted PC with Linux live USB and was able to rm the offending file.


Expected results:

After saving the screenshot file to the desktop, delete and rename operations should work as expected.
Bug: Drop-down menus items with empty values have a smaller height compared to the ones that have values
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-17 15:37:42+00:00
Resolved: 2022-12-12 14:40:40+00:00

**Found in**
* 109.0a1 (2022-11-17)

**Affected versions**
* 109.0a1 (2022-11-17)

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



**Steps to reproduce**
1. Open Bugzilla and log in.
2. Open a random issue and click on Edit Bug.
3. Click on a random flag from `Bug flags` and hover over the options.

**Expected result**
* All options have the same height.

**Actual result**
* Empty value option has reduced height.

**Regression range**
* Last good revision: 0f84b85f120f45fe6bad63d5e26b5ba4cd89f801
First bad revision: fd69d6b3aeb8e1e04334a0885f60966883a69c08
 Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f84b85f120f45fe6bad63d5e26b5ba4cd89f801&tochange=fd69d6b3aeb8e1e04334a0885f60966883a69c08 
Possible regressor: bug 1799460.

**Additional notes**
* Attached a screen recording.