av9ash/GitBugs huggingface dataset:
Bug: The Last Active tab from Firefox View does not update the title for Youtube pages if different videos are reached in the same tab without switching away from it
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-09-28 12:36:48+00:00
Resolved: 2022-11-04 13:05:09+00:00

**Found in**
* 106.0b5 (2022-09-28) 

**Affected versions**
* Firefox Nightly 107.0a1 
* Beta 106.0b5

**Affected platforms**
* all

**Steps to reproduce**
1. On Machine A Sign in with an FxA account and Reach Firefox View.
2. On Machine B Sign in with the same FxA account and reach Youtube.com
3. On Machine B search for Cooking and Select any video from the list.
4. Click Sync Now on both devices from the FxA panel.
5. On Machine B select a different video from the Suggestions on the Right.
6. Click Sync Now on both devices from the FxA panel.

**Expected result**
* The Subsuquent videos from Machine B have different page titles and they should update for Machine A Firefox view Tab pickups section (Last Active)
**Actual result**
* The Youtube page titles do not update in the Firefox View Tab pickups section on Machine A.

* Please note that if the user clicks any other Tab or Firefox View and then back to the Youtube tab on Machine B after syncing again it will imediatelly update the title for the Last Active tab in the Firefox View of Machine A.
Bug: The Firefox View url "about:firefoxview" is case sensitive
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2022-09-28 14:44:16+00:00
Resolved: 2022-10-11 15:14:01+00:00

**Found in**
* 106.0b5 (2022-09-28) 

**Affected versions**
* Firefox Nightly 107.0a1 
* Beta 106.0b5

**Affected platforms**
* all

**Steps to reproduce**
1. Set any other color from the Change Colorway menu.
2. Reach about:firefoxview in  a new tab.
3. Reach about:FirefoxView in a second tab.

**Expected result**
* The about:firefoxview url should not be case sensitive and it should redirect to the same page.
* The about:FirefoxView url should be replaced with the default "Search with google" text and the page background color should be the one set in the Colorway menu.

**Actual result**
* The about:firefoxview url text is replaced with Search with google and the Background color remains the one set in the Colorway menu.
* The about:FirefoxView url text remains inside the urlbar and the page background color is white as if the user was redirected to a different page.
Bug: Intermittent browser/components/search/test/browser/browser_searchbar_keyboard_navigation.js | single tracking bug
Status: REOPENED
Priority: P5
Created: 2022-09-28 15:38:43+00:00
Resolved: 2025-02-24 07:10:17+00:00

**Filed by:** ncsoregi [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=391665494&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/b5My4FZFT8u3O6tosBkOMA/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/b5My4FZFT8u3O6tosBkOMA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2022-09-28T11:13:08.979Z] 11:13:08     INFO - TEST-PASS | browser/components/search/test/browser/browser_searchbar_keyboard_navigation.js | the textfield value should be unmodified - 
[task 2022-09-28T11:13:08.979Z] 11:13:08     INFO - Buffered messages finished
[task 2022-09-28T11:13:08.980Z] 11:13:08     INFO - TEST-UNEXPECTED-FAIL | browser/components/search/test/browser/browser_searchbar_keyboard_navigation.js | first suggestion should be selected - Got -1, expected +0
[task 2022-09-28T11:13:08.980Z] 11:13:08     INFO - Stack trace:
[task 2022-09-28T11:13:08.981Z] 11:13:08     INFO - chrome://mochikit/content/browser-test.js:test_is:1485
[task 2022-09-28T11:13:08.981Z] 11:13:08     INFO - chrome://mochitests/content/browser/browser/components/search/test/browser/browser_searchbar_keyboard_navigation.js:test_tab_and_arrows:496
[task 2022-09-28T11:13:08.981Z] 11:13:08     INFO - chrome://mochikit/content/browser-test.js:handleTask:1045
[task 2022-09-28T11:13:08.981Z] 11:13:08     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1117
[task 2022-09-28T11:13:08.981Z] 11:13:08     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-09-28T11:13:08.982Z] 11:13:08     INFO - TEST-UNEXPECTED-FAIL | browser/components/search/test/browser/browser_searchbar_keyboard_navigation.js | the textfield value should have changed - Got "foo", expected "foo1"
[task 2022-09-28T11:13:08.983Z] 11:13:08     INFO - Stack trace:
[task 2022-09-28T11:13:08.983Z] 11:13:08     INFO - chrome://mochikit/content/browser-test.js:test_is:1485
[task 2022-09-28T11:13:08.983Z] 11:13:08     INFO - chrome://mochitests/content/browser/browser/components/search/test/browser/browser_searchbar_keyboard_navigation.js:test_tab_and_arrows:497
[task 2022-09-28T11:13:08.983Z] 11:13:08     INFO - chrome://mochikit/content/browser-test.js:handleTask:1045
[task 2022-09-28T11:13:08.983Z] 11:13:08     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1117
[task 2022-09-28T11:13:08.984Z] 11:13:08     INFO - Not taking screenshot here: see the one that was previously logged
```
Bug: Sidebar width is no longer restored after restart
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-28 20:20:56+00:00
Resolved: 2022-10-21 13:38:37+00:00

## STR

1. Start from a clean profile (or at least a profile with only one window)
  * You may need to enable "Open previous windows and tabs", unsure...
2. Open a sidebar, such as bookmarks (View -> Sidebars -> Bookmarks)
3. Change the sidebar width (to some non-default value you'll recognise) by dragging the splitter
4. Restart Firefox

## ER

The custom sidebar width should be restored after Firefox restart when the window opens.

## AR

The default sidebar width is used instead.

## Notes

The correct custom width _is_ being loaded and set as a `width` attribute on `sidebar-box`, but this is perhaps being ignored with the modern flexbox mode...?
Bug: Top of tabs not clickable
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-09-29 03:02:50+00:00
Resolved: 2022-10-11 12:15:18+00:00

When I scroll to the top of the screen such that my mouse is prevented from going any further by the edge of the screen, then I click. I would expect that given that my mouse is directly on a tab, that it would select the tab. Yet, nothing happens if I left click, or even if I right click. This leads me to believe that there might be a 1px dead space that overlays the tabs. This is problematic because I use the "stopped by the edge" technique with a touchpad to ensure accuracy. In a real life scenario, this bug causes about 50% of my attempts to change tabs to fail.

I tried to eliminate my system and WM (XFCE) as the cause of the problem prior to filing the bug report. I tried about every combination possible of settings/themes, and nothing seems to change. I have tried Chrome and Vivaldi, with neither having the same issue. 

Here's some more information:
-> Titlebar is disabled.
-> Size of tabs doesn't fix problem.
-> Have tried safe mode and reinstalling to no avail.
-> Screen resolution set in xrandr is accurate to the size of my screen.
-> This happens in maximized and also full screen (F11)
Bug: Intermittent browser/modules/test/browser/browser_PageActions_contextMenus.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-09-29 04:21:33+00:00
Resolved: 2023-06-30 12:02:17+00:00

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

---
```
INFO - TEST-PASS | browser/modules/test/browser/browser_PageActions_contextMenus.js | [["pageAction",null,{"addonId":"dd1fe44517dcda2316bb1664b663e5903834fd72@temporary-addon","action":"manage"}],["pageAction",null,{"addonId":"dd1fe44517dcda2316bb1664b663e5903834fd72@temporary-addon","action":"manage"}],["pageAction","accepted",{"addonId":"dd1fe44517dcda2316bb1664b663e5903834fd72@temporary-addon","action":"uninstall"}]] deepEqual [["pageAction",null,{"addonId":"dd1fe44517dcda2316bb1664b663e5903834fd72@temporary-addon","action":"manage"}],["pageAction",null,{"addonId":"dd1fe44517dcda2316bb1664b663e5903834fd72@temporary-addon","action":"manage"}],["pageAction","accepted",{"addonId":"dd1fe44517dcda2316bb1664b663e5903834fd72@temporary-addon","action":"uninstall"}]] - 
[task 2022-09-29T04:04:13.337Z] 04:04:13     INFO - Buffered messages finished
[task 2022-09-29T04:04:13.338Z] 04:04:13     INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_PageActions_contextMenus.js | A promise chain failed to handle a rejection: store error: OpenAttemptedDuringTransaction(ThreadId(66)) - stack: (No stack available.)
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - Rejection date: Thu Sep 29 2022 04:04:12 GMT+0000 (Coordinated Universal Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.jsm :: assertNoUncaughtRejections :: line 270
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - Stack trace:
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - resource://testing-common/PromiseTestUtils.jsm:assertNoUncaughtRejections:270
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - chrome://mochikit/content/browser-test.js:handleTask:1073
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - Leaving test bound contextMenu
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - Entering test bound contextMenuOnSeparator
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - Waiting for main page action button to have non-0 size
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - Waiting for main page action panel to be open
[task 2022-09-29T04:04:13.339Z] 04:04:13     INFO - promisePageActionViewChildrenVisible waiting for a child node to be visible
```
Bug: Firefox view page is no longer displayed when clicked after accessing the homepage button while on the Firefox view page
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-09-29 11:55:58+00:00
Resolved: 2022-10-03 11:23:05+00:00

**Found in**
* 106.0b5 (20220927185813)

**Affected versions**
* 106.0b5 (20220927185813)
* 107.0a1 (20220929014928)





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

**Preconditions**
* Have the Home Page button added to the toolbar.

**Steps to reproduce**
1. Open the Firefox View page by clicking the Pinned icon.
2. Click on the Home button from the toolbar. 
3. Click on the Firefox view button.

**Expected result**
*  The Firefox View page is displayed.

**Actual result**
* Nothing happens. 

**Regression range**
* Not a regression. I can reproduce the issue starting with bug 1762903 when the Firefox view tab was implemented.
 
**Additional notes**
* Attached a screen recording.
* Clicking the Back arrow, will display the Firefox View page. Also restarting the browser or moving the Firefox View button to another part of the browser (e.g toolbar) will make it function again.
Bug: The urlbar-handoff telemetry is not correctly recorded in private browsing mode
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-09-29 11:57:12+00:00
Resolved: 2023-02-21 16:15:50+00:00

**Found in**
* Fx 107.0a1

**Affected versions**
* Fx 107.0a1
* Fx 106.0b5
* Fx 105.0.1

**Affected platforms**
* Windows 10
* Ubuntu 20
* macOS

**Steps to reproduce**
1. Launch Firefox.
2. Open a Private Browsing window.
3. Click the websearch bar type a word and hit enter.
4. Go to about:telemetry -> Raw JSON -> Raw Data and check for the search_counts under keyed.histogram

**Expected result**
* There is an 'urlbar-handoff' telemetry ping recorded.

**Actual result**
* Only a 'urlbar' telemetry ping is recorded.

**Regression range**
* This is not a recent regression. Will look into a regression range ASAP.
Bug: Address bar Search Engine placeholder is not correctly displayed in private browsing
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-29 12:03:16+00:00
Resolved: 2023-02-08 12:06:14+00:00

**Found in**
* Fx 106.0a1

**Affected versions**
* Fx 107.0a1
* Fx 106.0b5

**Affected platforms**
* Ubuntu 20
* Windows 10
* macOS

**Pre-conditions**
browser.search.separatePrivateDefault.ui.enabled set to true
Have a PB window opened in a previous session at least once.

**Steps to reproduce**
1. Launch FF.
4. Go to about:preferences#search.
4. Change the search engine for PB to be different from the one used in the regular version.
5. Open a PB window and check the address bar.

**Expected result**
Search Engine set for PBM is correctly displayed in the placeholder.

**Actual result**
The address bar displays the wrong placeholder.

**Regression range**
N/A
Bug: Login pop-up Windows are being picked up as the last active tab in Firefox View
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-09-29 12:14:37+00:00
Resolved: 2022-10-06 13:26:26+00:00

**Found in**
* 106.0b5 (2022-09-28) 

**Affected versions**
* Firefox Nightly 107.0a1 
* Beta 106.0b5

**Affected platforms**
* all

**Steps to reproduce**
1. Sign in on Both Machines A and B.
2. Reach Firefox View on Machine A.
3. Reach pinterest.com on Machine B and select Login with Facebook in order to open the pop up window.
4. Sync on both devices.
5. Select the Last Active "facebook" page from the Tab Pickup section in Firefox View on Machine A.
6. Sign in to Facebook with a valid account.

**Expected result**
* Pop-up windows should not be displayed in the Tab pickup section.
* Only The Pinterest tab should be displayed in the Tab pickup section.

**Actual result**
* The Log in pop up window is displayed as the last active tab.
* The user can select the Last Active tab on Machine A and reach the facebook login page.
* Logging in to Facebook will immediately close the tab.
* Clicking on the Last Active Tab again from the Firefox View page will open and close a new tab immediately.
Bug: The default search engine changed prompt is displayed even when the previous engine is still available
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-29 12:19:41+00:00
Resolved: 2022-10-19 15:39:16+00:00

The prompt we have for displaying information about a user's default engine being removed can also be displayed if the application default is changed - even if the original engine is still available.

This leads to a confusing message. For now, we'll add a check to see if the engine still exists or not before displaying.
Bug: Set and Continue button rapidly moves up and down when changing colors on the Choose the color what inspires you screen
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-29 13:23:36+00:00
Resolved: 2022-10-11 13:39:56+00:00

**Found in**
* 106.0b5 (20220927185813)

**Affected versions**
* 106.0b5 (20220927185813)
* 107.0a1 (20220929014928)





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

**Steps to reproduce**
1. Open about:welcome page.
2. Select the `Skip this step` option until the `Choose the color that inspires you` is displayed.
3. Change the colors and observe the `Set and continue` button.

**Expected result**
*  The colors are changed and no visual issues occur.

**Actual result**
* `Set and continue` button rapidly changes position.
 
**Additional notes**
* Attached a screen recording.
* On Ubuntu 20.04 and macOS 11 the issue is intermittent. On Windows, the issues happen almost anytime when changing colors.
Bug: `About Firefox Nightly` dialog size changes(flickers) when rendering is complete.
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-29 16:22:54+00:00
Resolved: 2022-10-21 13:44:14+00:00

Steps to reproduce:
1. Help > About Nightly

Actual results:
`About Firefox Nightly` dialog flickers.


Before landing Bug 1756450:
Dialog size changes are small.

After landing Bug 1756450:
It will appear smaller. After that, it becomes larger. BUG!
It is reproduced each time the dialog is displayed.

After landing Bug 1792337:
It will appear large. After that, it becomes smaller. BUG!
It is reproduced each time the dialog is displayed.

Expected results:
Flickering should be minimized as much as possible.
Bug: Fail to restore display columns in Library
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-29 17:50:20+00:00
Resolved: 2022-10-26 12:33:49+00:00

Steps to Reproduce:
```
1. Open Library
2. Right click on column header
3. Select `Most Recent Visit` to show the column
4. Close Library

5. Open Library
6. Right click on column header
7. Select `Most Recent Visit` to hide the column
8. Close Library

9. Open Library again
10. Right click on column header
11. Select `Most Recent Visit` to show the column
12. Close Library

13. Open Library
```

Actual Results:
The column `Most Recent Visit` dose not show. i.e, Fail to restore display columns.


Expected Results:
The column `Most Recent Visit` show show.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=de2452d764b9b813d15b0913de65b5cfa6b94956&tochange=fb5a1a49ca4a4681b91a545ce49bbb7ca15bbe8c
Bug: Vertical scrollbar is not present when about:preferences is horizontally constrained
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-29 19:14:22+00:00
Resolved: 2022-10-21 12:51:25+00:00

When the about:preferences#privacy page is resized to about 859px wide, the vertical scrollbar disappears off the side of the window. [This appears to be due to the .pane-container's width being set to the --main-pane-width.](https://searchfox.org/mozilla-central/rev/f0ffbdcf82000a8ecab13954f6618797e37c6173/browser/themes/shared/preferences/preferences.css#57) Replacing width with max-width allows the vertical scrollbar to remain visible on the window regardless of the window's width.

According to mozregression, this appears to be a regression from Bug 1790307, https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b95ae2249c9b0a3a0340b2b799675c6b10821910&tochange=fd57a3ea2b88fd2969fc1cf7e2c41cffff0d084d
Bug: In Firefox Preferences "Data Collection and Use" section, one "learn more" label is misaligned (should be baseline-aligned)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-09-29 20:42:01+00:00
Resolved: 2024-08-08 11:14:42+00:00

STR:
1. Visit Firefox Preferences (`about:preferences`)
2. Use Preferences' search field to find "data collection" (or just manually click/scroll to the data collection section in Privacy & Security)
3. Look at the "Learn more" links.

ACTUAL RESULTS:
The first checkbox's "Learn More" link (next to `Allow Nightly to send technical and interaction data to Mozilla`) is a bit lower than the rest of the line. See attached screenshot.

EXPECTED RESULTS:
Properly/consistently aligned "Learn More" links.
Bug: [documentation] Update documentation about secure bug handling
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2022-09-30 07:48:23+00:00
Resolved: 2023-03-23 21:21:09+00:00

Bugzilla should hide the relationship between security and non-security bugs for quite a while now. Our documentation still cautions people not to link them, when in fact it could be beneficial for posterity.

Let's fix the documentation.
Bug: Change engine telemetry is not recorded if default engine is changed during startup as a result of pending configuration or other changes.
Status: NEW
Priority: P3
Created: 2022-09-30 07:53:03+00:00
Resolved: 2025-01-30 17:30:00+00:00

**Found in**
* 107.0a1 

**Affected versions**
* 107.0a1 , 106.0b

**Tested platforms**
* Affected platforms: Windows 10, Mac 11, Ubuntu 22.04


**Steps to reproduce**
1. Launch FF.
2. Set region to BE (restart)
3. Set default engine to ebay.
4. Set region to RO (restart)

**Expected result**
* Default search engine is set to google (default for RO) since ebay is not available anymore for the new region
* Change engine telemetry is recorded

**Actual result**
* Default search engine is set to google (default for RO) since ebay is not available anymore for the new region
* Change engine telemetry is not recorded
Bug: browser.search.separatePrivateDefault.ui.enabled is reset @ every startup
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-30 07:56:47+00:00
Resolved: 2022-10-26 01:38:57+00:00

**Found in**
* 107.0a1

**Affected versions**
* 107.0a1, 106.0b6

**Tested platforms**
* Affected platforms: Windows 10, Ubuntu 22.04, Mac 11

**Steps to reproduce**
1. Launch FF.
2. Go to about:config
3. browser.search.separatePrivateDefault.ui.enabled to true
4. Restart browser and check the value for browser.search.separatePrivateDefault.ui.enabled.

**Expected result**
* browser.search.separatePrivateDefault.ui.enabled is true

**Actual result**
* browser.search.separatePrivateDefault.ui.enabled is false
Bug: UX: add an option for downloads to go into /tmp that people can actually find
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-09-30 08:43:42+00:00
Resolved: 2022-10-08 22:02:51+00:00

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

Steps to reproduce:

In response to https://bugzilla.mozilla.org/show_bug.cgi?id=1738574 it seems some option was added in some way for downloads that are set to open with a program (rather than "save to file") go back into some /tmp folder again. However, in Settings > Files and Preferences > Downloads there is no obvious way to do so. Even worse, about:config also doesn't show any useful setting when I search for "downlods". This here mentions an option: https://github.com/mozilla/policy-templates/blob/master/README.md#startdownloadsintempdirectory but when I manually add an about:config entry browser.downloads.start_downloads_in_tmp_dir with boolean set to true, this doesn't actually seem to do anything.


Actual results:

1. I tried to use the supposedly added option to have downloads opened with a program go to /tmp again since I find it way more intuitive


Expected results:

I am able to find such an option despite it supposedly being available now. This was not the case, I can't find it.
Bug: [Linux] The progress bar of the “Tab Pickup” callout message is not read by a screen reader software
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-09-30 09:47:13+00:00
Resolved: 2024-04-25 18:51:52+00:00

**[Affected versions]:**
- Firefox Beta 106.0b6 - Build ID: 20220929195234
- Firefox Nightly 107.0a1 - Build ID: 20220929214556

**[Affected Platforms]:**
- Linux Mint 20.2 x64
- Linux Mint 20.3 x64

**[Prerequisites]:**
- Have a screen reader software installed and opened (e.g.: Orca).

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Navigate on the firefox View page and click the “See what’s new” button to trigger the “Tab Pickup” callout message.

**[Expected result]:**
- The progress bar from the “Tab Pickup” callout message is successfully read by the screen reader.

**[Actual result]:**
- The progress bar from the “Tab Pickup” callout message is read as “level bar”.

**[Notes]:**
- This issue is reproducible also on “Recently Closed” and “Colorways” callout messages.
- This issue is not reproducible on Windows and macOS.
- Attached a screen recording of the issue [here](https://drive.google.com/file/d/1uSTA3rUWDNq7NSOIeYvMGkYxy8Bpl1Ya/view?usp=sharing).