av9ash/GitBugs huggingface dataset:
Bug: Sometimes rendering failure in about:firefoxview#opentabs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-03-04 15:16:23+00:00
Resolved: 2024-03-06 11:51:50+00:00

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

Steps to reproduce:

1. Fresh Firefox on Ubuntu Linux (snap store) or Fedora Linux (Fedora repos).  I could not reproduce the bug on Mac OS.  I can try Windows 10 soon.
2. "about:firefoxview#opentabs"
3. ctrl+a ctrl+c (for efficient testing)

4. hold the ctrl key
5. 'n' [new window]
6. 'v' [paste]
7. enter [visit url], and release ctrl.  Not important what order you do these two in, I think.
8. ctrl+w

Repeat steps 4-8, ten or twenty times. Quickly might work best, but I'm not sure.


Actual results:

After step 7, sometimes the titles and icons of the tabs in each window are not rendered.


Expected results:

about:firefoxview#opentabs should always render the titles and icons of each window
Bug: Free Highlighting in PDF will record the "other" Highlight method with Glean
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-03-04 15:25:59+00:00
Resolved: 2024-03-11 08:30:33+00:00

**Found in**
* Nightly 125.0a1 (2024-03-04)

**Affected versions**
* Nightly 125.0a1 (2024-03-04)
* Beta 124.0b7
* Release 123

**Affected platforms**
* All

**Preconditions:**
Enable  pdfjs.enableHighlightEditor	true

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight editor from the Toolbar.
3. Free Highlight anywhere.
4. Reach about:glean and submit a "metric" type Telemetry.
5. Reach https://debug-ping-preview.firebaseapp.com/ and search for the previously submitted ping.

**Expected result**
* The Following metric should be recorded.
*  "pdfjs.editing.highlight.method": {
        "main_toolbar": 2
      },

**Actual result**
* The following metric is recorded:
      "pdfjs.editing.highlight.method": {
        "__other__": 2
      },

**Regression range**
Not a regression.
Bug: Transient, inconsistent icon rendering in about:firefoxview#opentabs
Status: NEW
Priority: P3
Created: 2024-03-04 15:35:34+00:00
Resolved: 2024-03-11 14:02:45+00:00

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

Steps to reproduce:

1. Visit the URL about:firefoxview#opentabs.

2. If it does not show the titles and icons for the tabs in each browser window, you have hit bug #1883386.  This bug is intermittent.  Simply try again, until Firefox shows you the titles and icons of the browser tabs in each browser tab.

3. Open a second tab, and visit about:firefoxview#opentabs again.

4. DO NOT SWITCH TO A DIFFERENT WINDOW

5. Notice what the icons look like inside about:firefoxview#opentabs , for the two "Firefox View" tabs that you have opened.


Actual results:

The icon inside about:firefoxview#opentabs for the second Firefox View tab, is a colourful Firefox logo.

The icon for the first one, is a wireframe of a sphere.

If you disturb the page e.g. switching to a different window and back again, or by opening a new tab and closing it again, then the icon for the second tab changes to match the first one, the wireframe sphere.


Expected results:

about:firefoxview#opentabs should show the same icon for both "Firefox View" tabs, and those icons should not change if you open and close a new tab.
Bug: Update OAuth desktop crypto code
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-03-04 16:54:53+00:00
Resolved: 2024-05-05 23:48:16+00:00

Got some feedback from the security team on minor changes we could make to the crypto code with the prefed off oauth flow. This bug tracks fixing those issues. The issues were minor and the flow is still off, so this is okay to be public
Bug: The dismissal acknowledgment is displayed outside the Firefox Suggest section after dismissing a non-top-pick Yelp suggestion positioned at the top of the section
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-03-04 19:55:42+00:00
Resolved: 2024-04-11 06:42:47+00:00

**[Affected versions]:**
- Firefox Nightly 125.0a1 - Build ID: 20240301091852
- Firefox Beta 124.0b7 - Build ID: 20240304091753

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.6.1
- Linux Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the following prefs set with the values to enable the feature:
`browser.search.region` = US (connect to a VPN server if outside US)
`browser.urlbar.yelp.featureGate` = true
`browser.urlbar.yelp.suggestedIndex` = 0
- Have a bookmark/history result that contains a keyword that would trigger a Yelp result (e.g. pet shop).

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Type the “pet shop” keyword in the Address Bar.
3. Click the “Feedback” button from the Yelp suggestion.
4. Click the “Don’t show this” option.
5. Dismiss the suggestion by clicking any of the “Not relevant” or “Not interested” options.
6. Observe how the message is displayed.

**[Expected result]:**
- The dismissal acknowledgment remains displayed inside the Firefox Suggest section, on the row where the Yelp suggestion was previously displayed.

**[Actual result]:**
- The dismissal acknowledgment is displayed outside the Firefox Suggest section.

**[Notes]:**
- This issue is not reproducible when the Yelp suggestion is positioned as the second result, nor the last one (at the bottom of the section).
- Here is a [screen recording](https://drive.google.com/file/d/1zMkOAvfFqFEPPQPZzktgiZVtTckEMYX7/view?usp=sharing) of the issue.
Bug: password manager allows searching for passwords
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-03-05 09:14:49+00:00
Resolved: 2024-03-05 14:27:31+00:00

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

Steps to reproduce:

1. insert a new entry in the password manager, e.g.
  - website-address: `https://example.com`
  - username: `user`
  - password: `password`
2. open the password manager
 - (notice that no authentication is required)
 - search for `w`


Actual results:

1. after typing `w` in the search field, the password-manager shows me one entry: `example.com -- user`.
(this is because the password contains the letter `w`)
since neither the hostname nor the username contain the letter `w`, we now know that the password contains the letter `w`.

2. add another letter to the search, so it now reads `we`.
   notice that the `example.com -- user` entry has been removed from the list, so the password does not contain the sequence `we`

3. change the search field again so it now reads `wo`.
  notice that the `example.com -- user` reappears, so we now know two letters of the password.

rinse and repeat until you have found out the entire password without having to type the master password.



Expected results:

the actual passwords must only be revealed if the user knows the master password.

so i would have expected, that i can only search within plaintext passwords if i have recently entered the master password (same logic as with the "reveal password" functionality) - e.g. via an explicit option "search within passwords" (that pops up the master password dialog when activated)
Bug: "Take screenshot" does not take the zoom factor into account
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-03-05 09:19:38+00:00
Resolved: 2024-03-12 17:04:47+00:00

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

Steps to reproduce:

My Zoom Faktor: 120%
Take a screenshot: Select an area and download.



Actual results:

The graphic shows only part of the selected area


Expected results:

The graphic should show the entire selected area
Bug: Highlighting an inserted text field will make it unclickable after saving
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-03-05 10:58:09+00:00
Resolved: 2024-03-15 16:24:44+00:00

**Found in**
* Beta 124.0b7 (2024-03-04)

**Affected versions**
* Nightly 125.0a1 (2024-03-04)
* Beta 124.0b7
* Release 123

**Tested platforms**
* Affected platforms: All

**Steps to reproduce**
1. Open any PDF which has a text field in Firefox (eg: http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf).
2. Add text in any one of the fields.
3. Enable the Highlight tool.
4. Free Highlight the added text.
5. Save the PDF and reopen it in Firefox.
6. Click inside the highlighted field and try to add some text.

**Expected result**
* The text can be added successfully, without any issue.

**Actual result**
* Highlighting the field will add a layer which won't let the user to click behind it.  

**Regression range**
* Not a regression.

**Additional notes**
* If the field is entirely highlighted, saved and then reopened that will make impossible for the user to add text to that field.
Bug: Highlighting with Caret Browsing a second time will cause the Caret cursor to jump at the beginning of the PDF file
Status: NEW
Priority: --
Created: 2024-03-05 11:35:01+00:00
Resolved: 2024-03-07 19:48:52+00:00

**Found in**
* Nightly 125.0a1 (2024-03-05)

**Affected versions**
* Nightly 125.0a1 (2024-03-05)
* Beta 124.0b7

**Affected platforms**
* All

**Preconditions:**
Enable  pdfjs.enableHighlightEditor	true

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight editor from the Toolbar.
3. Enable Caret browsing.
4. Highlight any text with Caret Browsing.
5. Use the Down arrows on the keyboard in order to reach a different text.
6. Use Shift + Right arrow in order to Highlight text a second time.

**Expected result**
* The user should be able to Highlight the Text with Caret browsing.

**Actual result**
* When the user tries to Highlight text a second time the Caret cursor will jump at the beginning of the pdf.

**Regression range**
Not a regression.
Bug: Pinned tabs and non-pinned tabs are restored into different windows.
Status: NEW
Priority: P3
Created: 2024-03-05 12:51:25+00:00
Resolved: 2024-03-25 18:58:20+00:00

Hit this twice in the last 2 weeks, each time with Nightly:

https://bugzilla.mozilla.org/show_bug.cgi?id=1237041#c9 (but also without crashes, unless it hung in shutdown and I didn't notice)

a) Closed the browser, restart.
b) Browser restarts only with the pinned tabs.
c) History->Recently Closed Windows restores all other tabs, but now in a separate window.

If you don't know about that option in history this is effectively a dataloss bug. Even without, it's highly disruptive (slightly less so if you know you can drag tabs between windows).
Bug: Pinned tabs should be expanded to two rows when the first row is full
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-03-05 13:09:47+00:00
Resolved: 2024-03-12 09:14:40+00:00

**Affected versions**
* 125.0a1

**Affected platforms**
* Windows 10x64
* Ubuntu 23
* MacOS 13

**Steps to reproduce**
1. Open Firefox and load lots of different websites in tabs
2. Select all the tabs and with right click context menu select Pin tabs option
3. Navigate to Firefox View Open Tabs

**Expected result**
* Pinned tabs are expanded to two rows when the first row is full

**Actual result**
* Pinned tabs are not expanded to two rows when the first row is full with pinned tabs

**Regression range**
* New feature
Bug: When using ‘cmd’ to import from other browsers two Firefox windows are opened.
Status: NEW
Priority: P3
Created: 2024-03-05 13:36:30+00:00
Resolved: 2024-03-19 07:38:45+00:00

**Found in**
* version: 124.0b6

**Affected versions**
* version1:125.0a1

**Tested platforms**
* Affected platforms: Windows.
* Unaffected platforms: 

**Preconditions**
* precondition 1: Have Firefox installed.

**Steps to reproduce**
1. Start Firefox with command: “firefox.exe -p --migration”.
2. Select one browser to import (Chrome).
3. Finish the import process. Click done.
4. Hover the Firefox icon from taskbar. 

**Expected result**
* Firefox should contain only one window.

**Actual result**
* Firefox contains two windows and only one can be opened/viewed.

**Regression range**
* To be added.

**Additional notes**
* Reproduces for all browsers when using the migration parameter.
Bug: Highlights from the Edge of a PDF are not Saved or Printed
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-03-05 13:46:42+00:00
Resolved: 2024-03-13 09:52:34+00:00

**Found in**
* Nightly 125.0a1 (2024-03-05)

**Affected versions**
* Nightly 125.0a1 (2024-03-05)
* Beta 124.0b7

**Affected platforms**
* All

**Preconditions:**
Enable  pdfjs.enableHighlightEditor	true

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight editor from the Toolbar.
3. Highlight the Edges of a PDF file.
4. Print > Save to PDF.

**Expected result**
* The area near the edge should be completely highlighted.

**Actual result**
* The Highlight will not cover the Edges of the PDF file.

**Regression range**
Not a regression.
Bug: Always need to fill google recaptcha when searching in private mode with google
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-03-05 14:40:35+00:00
Resolved: 2024-03-19 05:57:52+00:00

Steps to reproduce:

Every time i try to search something with google in private mood, I need to fill google recaptcha. It's always time consuming and maximum of time filling correctly shows need to try again. 



Expected results:

Expected is to search and get result without filling any recaptcha in private mode with google.
Bug: Web content can receive and dispatch events used by the screenshot component
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-03-05 15:09:57+00:00
Resolved: 2024-09-19 02:36:38+00:00

These events can be observed by web content. Additionally, web content can dispatch these events and the Screenshots component will respond! Not good...

- Screenshots:Close
- Screenshots:Copy
- Screenshots:Download
- Screenshots:RecordEvent
- Screenshots:OverlaySelection
- Screenshots:ShowPanel
- Screenshots:HidePanel

Steps to reproduce:
1) Open a fresh profile in Firefox Nightly
2) Load the attached test case

Actual results:
The attached test case can observe these events.
The attached test case is able to modify the user's clipboard and downloads folder.

Expected results:
The attached test case can't do that, ideally.

I found this issue while trying to figure out how to write an automated test for bug 1880634.
Bug: Notification/attention dot is no longer centered for bookmarked pinned tabs in Firefox View
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-03-05 17:05:59+00:00
Resolved: 2024-03-28 07:13:56+00:00

It looks like the changes added [here](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/fxview-tab-row.css#105-108) have caused the notification dot to be off-centered when the tab is also bookmarked.

We should update this selector to add `:not(.attention)`  or some such to make sure that notification dot is never affected by it. The same may apply to other indicators.
Bug: Incorrect pixel count of screenshots on macOS with component Screenshots enabled
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-03-05 17:25:51+00:00
Resolved: 2024-04-08 13:30:54+00:00

**Found in**
* Nightly 125.0a1

**Affected versions**
* Nightly 125.0a1

**Tested platforms**
* Affected platforms: macOS 13, macOS 14
* Unaffected platforms: Ubuntu 22.04, Windows 10 x64

**Steps to reproduce**
1. Navigate to reddit.com
2. Take a screenshot of one of the photos
3. Observe the pixels counter.

**Expected result**
* The pixel count should match the resolution of the device.

**Actual result**
* The size of the screenshot is larger than expected. For example, on a MacBook device with a resolution of 1792 x 1120, the recorded size of the screenshot is 1,500x1,408 px. Please see the attached screenshot for more details.

**Regression range**
* This is not a regression, it's reproducible only when the component version of Screenshots is enabled.

**Additional notes**
* When using the extension version of Screenshots ('screenshots.browser.component.enabled' set to false in about:config) or the OS integrated tool, the size of the same picture is around 750 x 705 px.
* Issue reproducible on a MacBook Pro 16-inch, 2019.
Bug: [RTL] Screenshot UI is displayed as LTR
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-03-05 21:03:22+00:00
Resolved: 2024-04-25 14:06:14+00:00

See attached, the senctence is in reverse (the dot in the wrong spot, and the `ESC` makes the text to appear in the wrong order).
This is being forced to LTR by this:
https://searchfox.org/mozilla-central/rev/6b0b8c1003504e302e243c300355ef4d61e24909/layout/style/res/ua.css#454
Bug: Possible unauthorized access to a user's saved credentials (Firefox Standard Release 123.0, Desktop)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-03-05 22:34:42+00:00
Resolved: 2024-05-30 18:21:25+00:00

While working at my internship, I discovered a potential security vulnerability that allows unauthorized access to another person's credentials if the victim's PC is left unlocked. Exploiting this vulnerability involves opening the Firefox desktop app and entering 'about:logins' in the browser bar, revealing all the victim's saved emails and passwords for that website without additional authentication.

This vulnerability poses a significant risk when combined with a ducky script that automates the process of opening Firefox, extracting the credentials, and sending them to the attacker in a short amount of time.

While it is crucial for individuals to take responsibility in locking their PCs, a simple solution could enhance overall security. Implementing an extra verification step, such as requiring a password or using biometric authentication (e.g., fingerprint reader), before accessing saved credentials, would provide an additional layer of protection.

If needed, I can provide an example of the ducky script code I created to illustrate the potential severity of this vulnerability.
Bug: Crashed Tabs end up with a weird-looking "chimera" favicon (due to having `crashed.svg` superimposed over the real site's favicon, potentially blending together to create something unrecognizable)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-03-06 00:29:34+00:00
Resolved: 2024-03-06 23:48:15+00:00

STR:
1. Visit https://www.youtube.com/ in Firefox Nightly
2. Hover the tab and note the first PID in the tooltip.
3. In a terminal, run `kill -11 [PID]` (using the PID from step 2) to kill that process.
4. Look at the favicon in the tab.

ACTUAL RESULTS:
The favicon looks sorta bizarre -- like a weird red hexagon with an exclamation point.
In fact, it's actually the YouTube favicon (a red rounded-rectangle), with Firefox's [tab-crashed favicon](https://hg.mozilla.org/mozilla-central/raw-file/tip/browser/themes/shared/tabbrowser/crashed.svg)  (referenced as `chrome://browser/skin/tabbrowser/crashed.svg`) **rendered in front of it**.

EXPECTED RESULTS:
Just a single favicon -- probably the tab-crashed one? Or, if we really want to include the original site's favicon for some reason, we need to be sure our "crashed" overlay doesn't blend into it -- i.e. we need to add an easy-to-see outline, and perhaps make our overlay a bit smaller and offset-from-center so that the user has a chance to actually see the covered-up favicon.

This is sort of the same issue as discussed in bug 1858539, though it's more general than I had thought when I was filing that bug, so I'm filing this separately/fresh.
Bug: Tab title changes to a stale title (from previous origin) when a tab crashes in the background
Status: NEW
Priority: P2
Created: 2024-03-06 00:42:43+00:00
Resolved: 2024-07-08 19:15:26+00:00

STR:
1. Open two tabs in Firefox Nightly.
2. In the first tab, visit https://getfirefox.com
3. In that same tab, now navigate to https://youtube.com and **immediately switch tabs** (so YouTube loads in the background)
4. Hover the tab title to get YouTube's PID (or find it on `about:processes`)
5. In a terminal, run `kill -11 [PID]` to kill the YouTube content process.
6. Look at the tab in your tab-strip for the YouTube tab whose content-process you just killed.
7. Now click on that tab and see what happens.

ACTUAL RESULTS:
When the crash happens (after step 5): the tab **retains YouTube's favicon** but the tab's title reverts to a **stale tab-title from the previously-loaded site**, which in this case is getfirefox.com.
When you foreground the tab (step 7), *then* the tab updates to show "Tab Crash Reporter" as the title and to include the crashed.svg favicon (as an overlay, which itself is a little awkward, but that's bug 1883795 so no need to go into it here.)

EXPECTED RESULTS:
When the crash happens, the tab title should immediately change to "Tab Crash Reporter". It should *not* show a title from a previous/stale origin.)
The tab favicon should also immediately change, too (to show or overlay `crashed.svg`).
Bug: PDF form's radio buttons and check boxes have weird triple focus ring
Status: NEW
Priority: --
Created: 2024-03-06 03:50:34+00:00
Resolved: 2024-03-12 17:08:03+00:00

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

Steps to reproduce:

Open a simply styled [PDF form](https://bugzilla.mozilla.org/attachment.cgi?id=9227383) with radio buttons and/or check boxes.
Click on a radio button or checkbox to select. Observe element's focus highlight.


Actual results:

Radio button or checkbox shows three focus rings (see attached image).


Expected results:

Radio button or checkbox should be highlighted normally.
Bug: Firefox View "Move to End" option is persistent over the right most pinned website in Open tabs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-03-06 07:25:43+00:00
Resolved: 2024-03-20 16:25:10+00:00

**Affected versions**
* Firefox 125.0a1

**Affected platforms**
* Windows 11
* Ubuntu 22.04
* MacOS 14.3.1

**Steps to reproduce**
1. Open Firefox and load lots of different websites in tabs
2. Select some of the tabs and with right click context menu select Pin tabs option
3. Navigate to Firefox View Open Tabs
4. Right click on the right most pinned tab and hover over "Move Tab" option

**Expected result**
*  "Move to End" option is not available in the list

**Actual result**
*  "Move to End" option is available in the list and does nothing when clicked

**Additional Notes**
* The issue can be seen in the [following attachment](https://drive.google.com/file/d/1Vwj9No-BShUyseeTzDaYXLjLlRCnB9WA/view?usp=sharing)
* It should act like "Move to Start" which is not available if the pinned site is the first one in the list, or greyed out if trying to move a website from the actual Tab Strip.
Bug: Firefox View focus shifts to Recent browsing after refreshing the page
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-03-06 09:14:37+00:00
Resolved: 2024-03-29 10:54:05+00:00

**Affected versions**
* Firefox 125.0a1

**Affected platforms**
* Windows 10 x64
* Ubuntu 22.04
* MacOS 14.3.1

**Steps to reproduce**
1. Open Firefox View and select any other category than Recent Browsing
2. Refresh the page

**Expected result**
* The focus is still over the selected category after refreshing the page

**Actual result**
*  The focus shifts to Recent browsing after refreshing the page

**Regression Range**
* This seems to have been introduced on 125.0a1 (2024-02-20) by Bug 1850591

**Additional Notes**
* The issue can be seen in the [following attachment](https://drive.google.com/file/d/1D3ASWX9HgDZ8DqgNyMpc3ayBdghwz5vd/view?usp=sharing)