av9ash/GitBugs huggingface dataset:
Bug: The blue focus ring around the "Save visible" button only shows three sides
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-03-03 18:22:37+00:00
Resolved: 2023-03-15 12:49:45+00:00

This bug is regression from bug 1799211. I bisected the regression to this pushlog:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d234e727ef2860ff52044b65313f1e22dffd0c0c&tochange=18ac09635451fa4e2fd11a45d98d88cefa158d42

### Steps to reproduce

1. Set `screenshots.browser.component.enabled` pref = `true`.
2. Load any web page.
3. Open the content menu's "Take Screenshot" menu item.

### Expected result

The screenshot menu ("Save visible | Save full page") has a blue focus ring around all four sides of the "Save visible" button.

### Actual result

The screenshot menu ("Save visible | Save full page") has a blue focus ring around "Save visible" button, but only on three sides. See the attached "Save visible" screenshot.

Is this the intended design? I expected the blue focus ring would have four sides surrounding the "Save visible" button. If I press the Tab key, the focus ring moves the "Save full page" button and _does_ have four sides. See the attached "Save full page" screenshot.

I can reproduce on Windows and macOS.
Bug: Transition about:newtab/about:home/about:welcome to remote page actor instead of legacy RemotePageManager
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-03 18:46:03+00:00
Resolved: 2023-03-03 19:36:55+00:00

bug 1614713 moved all consumers of RemotePageManager off of RemotePageManager, and into actor classes that extend RemotePageChild or RemotePageParent.

... all except one! about:newtab/about:home/about:welcome is still holding out on the old infrastructure.

At the moment, this is part of what's requiring us to instantiate a `BrowserTab` actor for each and every page load. I'm addressing that part in bug 1718082, but I'm using a stopgap solution by moving the forced initialization of RPM into the privileged about content process and into the existing ASRouter actor. I haven't tried to touch all the messaging infrastructure itself.

I _think_ it should be reasonably straightforward to:

1. make the ASRouter actor pair inherit from RemotePageChild/Parent
2. switch the 3 or so messages that it sends over the message port to use the "normal" RPM infrastructure for this instead
3. then remove the legacy RemotePageManager code entirely.

This bug is here to do that work. :-)
Bug: swipe-to-navigation indicator cannot be disabled
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-03 20:48:43+00:00
Resolved: 2023-03-31 07:09:09+00:00

Hi there!

With a combination of 1799563 and 1773057 it appears there's now no way to disable the swipe-to-navigation indicator without also disabling swiping gestures altogether. Previously, using `browser.history_swipe_animation.disabled=true` and `widget.disable-swipe-tracker=false` would allow swipes without the indicator.

1773057 notes `widget.disable-swipe-tracker` as a replacement, but this entirely disables the swiping gesture.

As a macOS user, the behaviour of the UI deviates from the platform native display; I can understand adding the UI for users to assist them with swiping, but I don't need an indicator (either it worked and the page loads, or it didn't; there's implicit UI). It would be great if the `browser.history_swipe_animation.disabled` pref could be restored.
Bug: Incorrect kerning in PDF rendered in Firefox but not Okular.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-03 23:02:06+00:00
Resolved: 2023-03-03 23:36:36+00:00

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

Steps to reproduce:

I downloaded https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/stage_codes.pdf


Actual results:

The text is incorrectly placed when rendered by Firefox yet not by Okular. The screenshot attached to this initial submission demonstrates this.


Expected results:

See the relevant screenshot.
Bug: Backout documentation changes to Metrics.yaml
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-03-04 09:21:00+00:00
Resolved: 2023-03-07 04:47:12+00:00

Bug 1815699 has landed some documentation changes to Metrics.yaml, but the glean event telemetry changes from that patch didn't land, thus Metrics.yaml should have not been touched.

The main problem is it introduced a "quicksuggest" result, but glean event telemetry doesn't return such a thing, it would indeed be confusing to return a quicksuggest type without saying what it is.
Bug: TAIL_SUGGESTION group should not be returned as "suggest"
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-03-04 09:27:34+00:00
Resolved: 2023-03-13 13:53:04+00:00

TAIL_SUGGESTION group is a search engine group, as such it should be in the `search_suggest group`, not in the `suggest` group.
Bug: Intermittently, the editbookmark dialogue won't appear when the star button is clicked
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-04 17:46:11+00:00
Resolved: 2023-04-03 11:59:49+00:00

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

Steps to reproduce:

Click the bookmark button of a tab in an affected window.


Actual results:

Once a window is affected, all tabs in that window are affected. Moving them to a new window doesn't resolve the problem.

The browser console prints the following error upon clicking the bookmark button:

```Uncaught (in promise) TypeError: can't access property "type", dialogInfo is null
    makeNewStateObject chrome://browser/content/places/editBookmark.js:662
    initPanel chrome://browser/content/places/editBookmark.js:430
editBookmark.js:662:11```


Expected results:

Judging by the error and the history of `editBookmark.js`, I think the regressor is Bug 1812083. After the issue manifests, if I set `browser.bookmarks.editDialog.delayedApply.enabled` to false, I can move the tabs to a new window to resolve the issue without restarting the browser.

I haven't run mozregression since this can't be reproduced at will.
Bug: Reload button rapidly flips between Reload and Stop states on webpage with dozens of video embeds
Status: NEW
Priority: P3
Created: 2023-03-04 19:14:01+00:00
Resolved: 2023-03-13 18:18:29+00:00

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

Steps to reproduce:

1. Open Firefox.
2. Go to https://sites.google.com/view/adaptive-agent/.
3. Scroll up and down on the page while it is loading.
4. Observe the reload button in the address bar without clicking on it.


Actual results:

The reload button in the address bar glitches between the "Reload" and "Cancel reload" icons repeatedly without clicking on it, especially when scrolling on the page while it is loading.


Expected results:

The reload button in the address bar should remain stable and not glitch when loading the website, even when scrolling on the page while it is loading.
Bug: Firefox renders raw code on YouTube pages.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-03-04 23:36:33+00:00
Resolved: 2023-03-30 17:59:19+00:00

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

Steps to reproduce:

Load any YouTube video page to see the raw code in Firefox.


Actual results:

Raw code appears in the top left corner of all YouTube video pages, the raw code even appears with the YouTube video is at full screen. The raw code that's shown is part of the code for the left side YouTube menu


Expected results:

Of course Firefox shouldn't be rendering raw code on YouTube pages.
Bug: Bookmark Toolbar icons refuse to move to the left of the bar
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-03-05 05:48:45+00:00
Resolved: 2023-05-18 13:30:47+00:00

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

Steps to reproduce:

Open Firefox.


Actual results:

Icons placed on the bookmark toolbar will no longer align to the left of the bar, regardless of how many spacers are added. They now jut awkwardly around the centre of the bar. This bug occurred on both my desktop and my laptop, which are sync'd via Firefox account. See the image for clarification.


Expected results:

My bookmarks and downloads icons should be sitting snuggly at the left side of the screen.
Bug: extensions.unifiedExtensions.enabled = false | Does not work
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-05 09:27:26+00:00
Resolved: 2023-03-05 11:02:13+00:00

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

Steps to reproduce:

Firefox 111.0b8 (64-bit)

about:config
extensions.unifiedExtensions.enabled > boolean > false






Actual results:

That about:config parameter does not disable the icon anymore. Somebody took the time to make sure that users have that icon visible at all times whether they like it or not.


Expected results:

extensions.unifiedExtensions.enabled > boolean > false in about:config should disable the icon. 

Actually, you should allow users to hide and move the icon like every other icon.
Bug: At most 3 search engines are offered to be added per site
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-05 10:25:43+00:00
Resolved: 2023-03-05 10:59:30+00:00

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

Steps to reproduce:

Go to site offering more than 3 search engines (OpenSearch descriptions).


Actual results:

Only 3 engines are offered to be added to the search bar. If you add one, the max. 3 remaining entries are offered, including the one that was hidden before.


Expected results:

All search engines should be offered to be added to the search bar.
Bug: extensions.unifiedExtensions.enabled = false | Does not work
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-05 10:59:52+00:00
Resolved: 2023-03-05 11:07:32+00:00

Hello! 

I have been a happy Firefox user forever. Recently You have introduced that 'puzzle' icon to manage extensions. Telemetry can show you that many of us -do not like it-. So we have been removing it from the about:config 

However, the decision was made to remove the option to disable it! 

So we, users, cannot move that icon, cannot remove it, cannot do anything but just accept it whether we like it or not. Respectfully, I find that attitude quite nasty and not what I've grown to expect from Mozilla. 

Can we, the peasant user at least get an explanation why it is so important to force-fed that anti-feature and that icon on all of us whether we like it or not? 

And maybe invite you to reconsider the thing. Or at least let us move it. We don't want to see it on the screen all the time.

+++ This bug was initially created as a clone of Bug #1820381 +++

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

Steps to reproduce:

about:config
extensions.unifiedExtensions.enabled > boolean > false






Actual results:

That about:config parameter does not disable the icon anymore. Somebody took the time to make sure that users have that icon visible at all times whether they like it or not.


Expected results:

extensions.unifiedExtensions.enabled > boolean > false in about:config should disable the icon. 

Actually, you should allow users to hide and move the icon like every other icon.
Bug: Privacy leak in private browsing mode via opening PDFs
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-05 22:03:25+00:00
Resolved: 2023-03-09 02:40:41+00:00

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

Steps to reproduce:

1. Firefox is configured to be in permanent private browsing mode, using as download location the default Downloads directory and to always ask where to save a file.
2. Open a PDF sent via "content-disposition: attachment", for example https://cdn.discordapp.com/attachments/712712343393533999/813101874382504037/arcade.pdf .


Actual results:

The downloads panel appeared showing me that it has downloaded the PDF, the PDF was stored in %USERPROFILE%\Downloads\arcade.pdf and Firefox opened an extra tab with the PDF pointing to file:///%USERPROFILE%/Downloads/arcade.pdf .


Expected results:

Since I'm in permanent private browsing mode private storage should not have been touched at all. The PDF should have been handled like one without "content-disposition: attachment" like https://us.download.nvidia.com/Windows/531.18/531.18-win11-win10-release-notes.pdf where the PDF is opened directly on this address and cached/handled in memory without touching private storage. This solution possibly doesn't even need to be limited to private browsing mode.


Additional details:

This issue has been reported as part of bug #1730179 . The first part of this ticket was solved via bug #453455 and the second part got marked as a duplicate for bug #1546969 . After bug #453455 got fixed and all the time that passed now the behavior is still the same in the core as bug #1546969 (both automatically leak data into the Downloads folder - just this bug doesn't ask where to store the final data and directly saves) but the potential solution is very different (e.g. handing "content-disposition: attachment" as PDF versus not pre-downloading data). If I'm wrong and this is still a duplicate feel free to mark it as such.
Bug: Title: Social Media (Facebook) login information remains in Firefox normal mode despite logging out in private mode.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-03-06 04:42:04+00:00
Resolved: 2024-05-30 18:06:20+00:00

Steps to reproduce:
1:)
Open Firefox browser in private mode.
2:)
Login to Facebook account.
3:)
Sign out from the Facebook account in private mode.
4:)
Close the Firefox browser in private mode.
5:)
Open Firefox browser in normal mode.
6:)
Go to Facebook website.
Notice that the Facebook login information remains in the normal mode, despite signing out in private mode.

Expected behavior:
When a user logs out of Facebook in private mode, the login information should be deleted and not stored in the normal mode.

Actual behavior:
The Facebook login information remains in the normal mode, even after signing out in private mode.

Impact:
This bug could compromise the security and privacy of users who rely on private mode to keep their online activities private. If the login information remains in the browser, other users who have access to the computer could potentially access the user's Facebook account without authorization.
                              Thank you !
                                     ManieshNeupane
Bug: JavaScript error: resource://activity-stream/lib/ActivityStreamPrefs.jsm, line 27: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIPrefBranch.removeObserver]
Status: NEW
Priority: P3
Created: 2023-03-06 09:50:43+00:00
Resolved: 2024-04-01 07:10:07+00:00

Seen in the following Wd spec test when it is happening during the shutdown of Firefox:

https://treeherder.mozilla.org/logviewer?job_id=407795203&repo=autoland&lineNumber=3164

```
[task 2023-03-04T01:50:42.471Z] 01:50:42     INFO - PID 1812 | JavaScript error: resource://activity-stream/lib/ActivityStreamPrefs.jsm, line 27: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIPrefBranch.removeObserver]
[task 2023-03-04T01:50:42.487Z] 01:50:42     INFO - PID 1812 | 1677894642495	Marionette	TRACE	Received observer notification quit-application
```
Bug: firefox freezes and stops responding on one particular web page
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-06 10:28:28+00:00
Resolved: 2023-03-08 19:18:59+00:00

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

Steps to reproduce:

just open https://predaj.zssk.sk/search
and try to fill/click first editbox


Actual results:

firefox freezes completely (all tabs) and stops responding after a while, you have to force quit with a crash report to apple.



Expected results:

enter city from and to ( its a train ticket portal )
Bug: All new tab tiles have a sponsored label in the context menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-06 12:59:35+00:00
Resolved: 2023-03-06 15:57:12+00:00

In the context menu for a non-sponsored tile we still show the "sponsored label" (see screenshot). 

:emilio pointed out that our context menu code also extracts text from hidden elements, such as the `.sponsored-label` el that exists for all tiles but is hidden for non-sponsored tiles: https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/browser/actors/ContextMenuChild.sys.mjs#396

A workaround would be to not add the label to non-sponsored tiles. But really we shouldn't use hidden text in the context menu!
Bug: Remove flicker exception for Firefox View button in browser_tabclose.js and other performance tests
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-03-06 15:05:33+00:00
Resolved: 2023-03-15 11:09:17+00:00

Adding an exception to the `browser_tabclose.js` test. Looking at the two frames showing the flicker (attached), this appears to be from the Firefox View icon. The regressor, bug 1815229, changed some image load timings. It's strange how this is only failing on beta, but given how close we are to the merge, I landed a patch in bug 1819084 to add an exception and filed this bug to investigate a proper fix.
Bug: E-mail addresses URLs of Mozilla Employees and users on archive.mozilla.org listed on web.archive.org index
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-06 17:49:22+00:00
Resolved: 2023-03-06 17:57:52+00:00

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

Steps to reproduce:

1. Visit the URL: https://web.archive.org/cdx/search/cdx?url=*.archive.mozilla.org/*&collapse=urlkey&output=text&fl=original
2. Search for '@mozilla.com' or '@gmail.com' or '@' or much more you will see users sensitive information leaked


Actual results:

Sensitive data of user exposed, violate the privacy of users and attacker can perform any malicious attack to the user because of exposed information by the company.


Expected results:

These urls contains very sensitive information of user like email Which violate the privacy of the Mozilla user so, removing the sensitive information from archive preserve the privacy of the users.
Bug: Files that are set to directly open in Firefox get saved and open instead
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-06 21:06:20+00:00
Resolved: 2023-03-16 16:12:40+00:00

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

Steps to reproduce:

1. Go to https://storage.googleapis.com/mobile_test_assets/test_app/downloads.html
2. Set Setting for any or all of the file types present on the page to Open in Firefox Developer Edition
3. Set Settings to Ask whether to open or save files
4. Set Settings to Always ask you where to save files
5. Click on any of the files set to open in FF (#2 above)


Actual results:

The file is beings saved in Downloads and opened in a new tab in the browser with file:/// URI.


Expected results:

The clicked file should be directly opened in the browser without being saved. Even PDF is being saved before opening contrary to what bug 1719892 claims to have fixed. All the files on the list above have `download` attribute set.

What works correctly: ctrl+clicking or opening file links in a new tab doesn't save files first.

This is a general case of bug 1769282.

Win10, FF 111.0b8 Dev Edition
Bug: Intermittent browser/modules/test/browser/browser_PermissionUI.js | single tracking bug
Status: REOPENED
Priority: P5
Created: 2023-03-06 22:31:12+00:00
Resolved: 2025-02-24 06:18:50+00:00

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

---
```
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - TEST-PASS | browser/modules/test/browser/browser_PermissionUI.js | Should be showing a <xul:popupnotification> - 1 == 1 - 
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - Console message: PopupNotifications._onButtonEvent: Button click happened before the security delay: -62.55899999999383ms
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - Buffered messages finished
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_PermissionUI.js | Test timed out - 
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - Not taking screenshot here: see the one that was previously logged
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_PermissionUI.js | Uncaught exception received from previously timed out test bound test_with_permission_key - popuphidden listener on #notification-popup not removed before the end of test
[task 2023-03-06T22:07:06.150Z] 22:07:06     INFO - Entering test bound test_on_before_show
[task 2023-03-06T22:07:06.197Z] 22:07:06     INFO - Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use �<!DOCTYPE html>�." {file: "http://example.com/" line: 0}]
[task 2023-03-06T22:07:06.322Z] 22:07:06     INFO - TEST-PASS | browser/modules/test/browser/browser_PermissionUI.js | Should have called onBeforeShown - true == true - 
```
Bug: CTA in about:privatebrowsing needs vertical padding reduced
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-03-06 23:03:08+00:00
Resolved: 2023-04-12 06:36:42+00:00

When compared to the [Figma protoype](https://www.figma.com/file/FAZxkK9IRLlCqyhXBqId7e/Auto-Cookie-Banner-Consent-Desktop-%26-Mobile?node-id=2755%3A34246&t=B7x0gp5yQBJoVamb-1), the CTA button in about:private browsing has a larger vertical padding than expected. According to UI, the padding of the CTA should be 8 x 16 (7 x 15 regular padding + 1px border for HCM).
Bug: If you open a URL in a new Window and then attach it back, the Right Click->"Duplicate" functionality doesnt work
Status: ASSIGNED
Priority: --
Created: 2023-03-07 02:58:46+00:00
Resolved: 2024-02-27 16:09:09+00:00

1. Start Nightly with a new profile
2. go to URL-bar and press the down key 
-> A drop-down menu with pre-populated URL will appear
3. use the down key to highlight a URL (e.g. youtube,com) and press Shift+Enter
-> Youtube.com will open in a new tab in a new window
4. Let youttube.com load completely
5. Attach the tab with youtube.com to the original Window from Step1
6. Right click on the youtube tab->Duplicate

ER: A new tab will open and load youtube.com
AR: A blank tab opens

The steps a somewhat complex. Please see attached video.


Regression: 
2023-03-07T08:19:48.290000: DEBUG : Found commit message:
Bug 1774242 - Make sure invariants for the test is correct. r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D149280