av9ash/GitBugs huggingface dataset:
Bug: Persist search term is still displayed after adding the search bar
Status: NEW
Priority: P3
Created: 2023-09-15 08:20:47+00:00
Resolved: 2024-12-31 17:58:12+00:00

**Found in**
* Fx 118.0b9

**Affected versions**
* Fx 119.0a1
* Fx 118.0b9
* Fx 117.0

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

**Preconditions**
Have *browser.urlbar.showSearchTerms.featureGate* set to true (only required for beta and RC, currently default true in nightly builds).


**Steps to reproduce**
1. Launch Firefox.
2. Open a new tab and perform a search.
3. Open another new tab, click the address bar and then the cogwheel located at the bottom right of the address bar drop-down.
4. Enable the search bar from the preferences page.
5. Go back to the tab where the search was performed.

**Expected result**
* Full URL for the SERP page is displayed.

**Actual result**
* The search term is still displayed in the URL bar.

**Regression range**
* I'm not sure how or why this is happening, but I was unable to get a regression range on this. When I ran the bisection, it took me all the way back to the implementation of the feature, but this WAS NOT the initial behavior.

**Additional notes**
* Issue happens intermittently, but whenever I reproduced it, I was using the steps mentioned above.
* Searches performed after adding the searchbar correctly display the full URL of the SERP in the address bar and not the search term.
Bug: "Error: An unexpected error occurred" while taking full page screenshot
Status: NEW
Priority: P3
Created: 2023-09-15 08:56:56+00:00
Resolved: 2023-11-09 20:09:15+00:00

**Steps to reproduce**:
1. Go to: https://beta.ruff.rs/docs/rules/
2. Press `<Ctrl> + <Shift> + <S>` to open the screenshots UI
3. Click the "Save full page" button in the upper right corner

**Actual results**:
No screenshot is taken. Instead, the attached notification is shown with an error.

These errors also appear in the browser console:
```
[Exception... "Failure"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "<unknown>"  data: no] ExtensionCommon.sys.mjs:817
------Error in promise: Error: An unexpected error occurred catcher.js:78:15
<empty string> catcher.js:79:15
Unhandled error: 
Object { fromMakeError: true, name: "Error", message: "Error: An unexpected error occurred", stack: "" }
 undefined catcher.js:21:11
Promise error in screenshotPage: Error: An unexpected error occurred <empty string> communication.js:47:15
------Error in promise: BackgroundError: Error: An unexpected error occurred
    callBackground moz-extension://b04697bd-ceab-41ea-929b-824cc358cd3d/selector/callBackground.js:14
catcher.js:78:15
callBackground/<@moz-extension://b04697bd-ceab-41ea-929b-824cc358cd3d/selector/callBackground.js:14:19
catcher.js:79:15
Unhandled error: 
Object { fromMakeError: true, name: "BackgroundError", message: "BackgroundError: Error: An unexpected error occurred", stack: "callBackground/<@moz-extension://b04697bd-ceab-41ea-929b-824cc358cd3d/selector/callBackground.js:14:19\n", errorCode: undefined, popupMessage: undefined }
 undefined catcher.js:21:11
BackgroundError: Error: An unexpected error occurred callBackground.js:14:19
Unhandled error: 
Object { fromMakeError: true, name: "BackgroundError", message: "BackgroundError: Error: An unexpected error occurred", stack: "callBackground/<@moz-extension://b04697bd-ceab-41ea-929b-824cc358cd3d/selector/callBackground.js:14:19\n" }
 undefined
```

**Expected results**:
A screenshot is taken.

I tested with both Firefox 117.0.1 and the latest Firefox Nightly 119.
Bug: A blank sidebar is displayed until the analysis is completed after returning to the product using the back button
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2023-09-15 09:25:16+00:00
Resolved: 2023-09-21 16:12:14+00:00

**Found in**
* 119.0a1 (2023-09-14)


**Affected versions**
* 119.0a1 (2023-09-14)






**Tested platforms**
* Affected platforms:Ubuntu 20, macOS 12, Windows 10x64
* Unaffected platforms:  none

**Preconditions**
* browser.shopping.experience2023.enabled:true
* browser.shopping.experience2023.optedIn:1



**Steps to reproduce**
1. Open a random amazon product that needs to be analyzed.
2. Click to analyze the product.
3. Open another product.
4. Return to the previous product.

**Expected result** 
* The analyze is in progress sidebar state si displayed.

**Actual result**
* Blank sidebar is displayed until the product is analyzed.

**Regression**
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=eee016ea358757cdc29f185ab14066a12f15b4b8&tochange=797c9afc3d0ab909998ce6c753f091f437bd9ef1






**Additional notes**
* Attached a screen recording.
* Refreshing the page will not update the sidebar.
* The sidebar updates automatically after the analysis is completed.
* This is reproducible with Firefox 119.0a1 (2023-09-15) with the fix from bug 1852836 as well.
* S3 because maybe the user does not return so fast to the previous product and the analysis might be completed when he returns.
Bug: Tokens containing non-word characters are translated incorrectly
Status: RESOLVED
Priority: P3
Resolution: MOVED
Created: 2023-09-15 09:29:00+00:00
Resolved: 2024-07-19 19:08:44+00:00

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

Steps to reproduce:

Click Firefox Translations add-on to bring up a a translating window.
Translate German to English
Type in something like:

info@gmail.com
Email:info@akkus-de.com
info@akkus-de.com
ff@mozmail.com


Actual results:

@ sign gets translated sometimes to dash "-"
sometimes to "(at)"
in my specific case inside an email to "Ã3"

"ff@mozmail.com" translates to "ffÃ mozmail.com"


Expected results:

Tokens containing special characters like @,:;  maybe others should not be broken.

The "Ã3" probably indicates encoding problems in training dataset.
However tokens which contain more non-word characters (emails, URL's, ) probably shouldn't be translated
Bug: The review checker sidebar border is cut off
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-09-15 10:36:36+00:00
Resolved: 2023-09-20 08:07:08+00:00

**Found in**
* 119.0a1 (2023-09-14)

**Affected versions**
* 119.0a1 (2023-09-14)

**Tested platforms**
* Affected platforms: All

**Preconditions**
* browser.shopping.experience2023.enabled: **true**
* browser.shopping.experience2023.optedIn: **1**

**Steps to reproduce**
1. Open a [random amazon product page](https://www.amazon.com/LG-55-inch-OLED55C2PUA-3-1-3ch-Up-Firing/dp/B09WJX4BVY/ref=sr_1_1?crid=2IV4FJUUHAQ1D&keywords=lg%2Bc2&qid=1694774042&sprefix=lg%2Bc2%2Caps%2C178&sr=8-1&th=1).
2. Check the review checker sidebar.

**Expected result** 
* The border of the review checker sidebar goes all the way to the bottom.

**Actual result**
* The border is cut off at the bottom.

**Regression**
* This is a very recent regression. I'm going to run mozregression and add the result ASAP.
Bug: Consider removing "Underline links" from the color dialog
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-09-15 11:05:18+00:00
Resolved: 2023-11-05 15:05:29+00:00

This removes a global selector and some complexity from the UA sheet, and in general since there's no way to also enforce it it doesn't work consistently.
Bug: Print "current page" does not work for PDF files
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-09-15 12:07:51+00:00
Resolved: 2023-09-29 12:28:45+00:00

It seems as if `pdf.js` does not pass the current page number correctly to the print preview dialog. The preview works fine and shows correctly what would be printed and there is this combobox "Pages" in the print preview dialog, which allows "custom page" as a selection. That works fine if you manually enter a page number, but "current" from the same combobox does not and can only be used to print the first page of the document. Confirmed with Nightly 119.0a1 under Windows and Linux.

Steps to reproduce the problem:
1. Open a multi-page pdf file and scroll to page > 1
2. use `CTRL-p` to open the print dialog and choose `Pages: current`

What is the expected behavior?

The print preview shows the page which is also open in the browser.

What went wrong?

The first page of the PDF document is shown
Bug: screenshot is not working fine
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-09-15 15:04:02+00:00
Resolved: 2023-11-27 18:35:26+00:00

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

Steps to reproduce:

hi there,
in pervious version of firefox i am successfully taking screenshot of websites, but after updation of firefox 117. i am unable to take full page screenshot, it just take screenshot of visible screen. see the attchments file one is correct (which is full page screen shot) 2nd one is the wrong (which only take visible screen screenshot) please resolve this issue as soon as possible. thank you Rao
Bug: Make adding text into PDFs keyboard operable
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-09-15 16:01:19+00:00
Resolved: 2023-10-11 13:51:53+00:00

It is possible to move with the keyboard, but it is still not possible to add with the keyboard.

https://github.com/mozilla/pdf.js/pull/16761 would be necessary.
Bug: Make message bar in shopping sidebar more accessible
Status: NEW
Priority: P3
Created: 2023-09-15 17:01:30+00:00
Resolved: 2023-11-10 00:52:56+00:00

a11y note for the message container for engineers: it should be a live region, i.e. `aria-live="polite"` applied to the container (the container needs to be in the DOM when the sidebar initially loads, before any dynamic changes, otherwise the live region may be ignored by screen readers)
clarifying: the live region would include: icon/spinner + status text + button (when present)
Bug: Remove unintended context-stroke from warning-fill-12.svg
Status: NEW
Priority: P2
Created: 2023-09-15 17:13:44+00:00
Resolved: 2023-09-20 16:06:25+00:00

With the work done for [1704461](1704461),
we inadvertently introduced a [context-stroke on our warning badge](https://searchfox.org/mozilla-central/rev/926b6c9fc7d84b603f501448c31d489473862bca/toolkit/themes/shared/icons/warning-fill-12.svg#5). This was brought up during recent work being done for our Extensions panel. UX asked whether this was intentional and we discussed between designs systems and UX (:glussier), and then confirmed with engineering (:willdurand and :mhowell), and agreed this stroke can be removed as it's adding an unintentional black stroke to the warning badge.

We can just remove the `context-stroke` line from the `warning-fill-12.svg` icon to achieve this.
Bug: Incorrect link when moving to search engines using the keyboard.
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-09-15 20:29:24+00:00
Resolved: 2023-10-03 15:20:38+00:00

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

Follow up to address the additional bug QA found
Bug: certificate viewer doesn't handle keyUsage extensions that are unexpectedly long
Status: NEW
Priority: --
Created: 2023-09-16 09:30:55+00:00
Resolved: 2024-01-02 16:58:29+00:00

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

Steps to reproduce:

1.In Firefox, visit the url about:certificate?cert=(processed pem data) containing the certificate information.
2.Use Python to create a local server (e.g. using Flask) and specify a mutated certificate and private key. Access the Flask provided url in Chrome.
3.In your own developers' way, let the browser parse mutated certificate files, then observe the results.


Actual results:

Description: We tested with a mutated digital certificate as a test case. We have discovered differences in the parsing results of the certificate key usage extension for mutated digital certificates between Google Chrome and Mozilla Firefox browsers.
OS: Windows 10 22H2 19045.2604
Supplement: The mutated certificate is from this URL:'https://www.csdn.net/'.And The mutation certificate did not change the parsing result of key usage in Firefox
My exception: Confirm whether the discrepancy is a bug or not.


Expected results:

I don't know which of these two different certificate key usages is correct, but I want both browsers to have the same interpretation of the digital certificate. So I need you to confirm whether this difference is a bug or not.
Bug: Tabs which are received from sync after update and then closed are not saved to history
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-09-16 14:29:40+00:00
Resolved: 2023-09-22 18:26:56+00:00

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

Steps to reproduce:

1. Update desktop Firefox via package manager while Firefox is open
2. Sent tabs from phone via Sync to desktop
3. Close the received tabs


Actual results:

Tabs that were closed are neither visible in recently closed tabs nor in history


Expected results:

Tabs that were closed are visible in recently closed tabs and in history.
Bug: After linux package update pressing escape on an empty URL address bar in tabs waiting for Firefox restart doesn't restore the URL
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-09-16 14:33:52+00:00
Resolved: 2024-06-22 21:13:55+00:00

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

Steps to reproduce:

1. Update Firefox package while Firefox is running
2. Load some tab site
3. Observe Restart Required page being shown
4. Cut the URL from address bar
5. Press ESC button while address bar is empty and focused


Actual results:

URL is not restored.


Expected results:

URL is restored.
Bug: Firefox 117.0.1 freezes every time I try to upload or download files (and I have to exit and restart it)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-09-16 19:16:21+00:00
Resolved: 2023-09-28 15:43:16+00:00

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

Steps to reproduce:

Using Firefox 117.0.1 on Windows 10, try to download a file (eg right-clicking an image, 'Save image as...') or upload a file (eg a photo to Facebook or a PDF to Cloudconvert).


Actual results:

Ever since the last update but one, every time I do this, Firefox completely freezes (greys out) and no matter how long I wait this doesn't resolve. In the end I have to click the red X icon at top right, completely shut down the programme, then re-open it. And it continues to be impossible to upload or download.
(If it's relevant, I also enabled sync at about the same time the problem started happening. Could this be the issue?)


Expected results:

Download and upload should work smoothly.
Bug: [felt] Private windows are partially broken with Pocket button removed from toolbar
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-09-17 09:48:34+00:00
Resolved: 2023-10-03 12:32:20+00:00

STR:
1. Set `browser.privatebrowsing.felt-privacy-v1 = true`.
2. Remove the Pocket button from the toolbar or disable it with `extensions.pocket.enabled = false`.
3. Open a private window.
4. Click the hamburger menu.

Hamburger menu fails to open, initial private browsing page is blank purple.

Console error:

    Uncaught TypeError: can't access property "remove", document.getElementById(...) is null
        PBUI_init chrome://browser/content/browser.js:8382
        onLoad chrome://browser/content/browser.js:1710

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=366fe4ef2cd3ed22efdda09ad0e5d7b44a4a31ca&tochange=8b6aebdd4f919dc1515c304bbf8824a178e3f0ae

Regressed by Bug 1846583.
Bug: www.ncbi.nlm.nih.gov - "Save page as" fails
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-09-18 07:50:20+00:00
Resolved: 2023-09-28 15:24:54+00:00

From github: https://github.com/webcompat/web-bugs/issues/127127.

> <!-- @browser: Firefox 117.0 -->
> <!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0 -->
> <!-- @reported_with: unknown -->
> <!-- @public_url: https://github.com/webcompat/web-bugs/issues/127127 -->
> 
> **URL**: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7465160/
> 
> **Browser / Version**: Firefox 117.0
> **Operating System**: Windows 10
> **Tested Another Browser**: No 
> 
> **Problem type**: Something else
> **Description**: Save Page As, mostly fails with yellow icon, requiring a manual retry click.
> **Steps to Reproduce**:
> hi in firefox (current version or even several months back), when saving a web page, it fails most of the time, with a yellow warning icon in the top right downloads indicator, and i have to manually click the retry icon, and then it succeeds.
> 
> i am not sure if it is because i use u-block origin as well, but is there any way to simply have firefox automiatically retry the save (at least a few times), until it has fully suceeded? (maybe there can be a keep retrying for 60 seconds) to avoid a constant looping.
> 
> thanks :)
> 
> <details>
> <summary>Browser Configuration</summary>
> <ul>
>   <li>None</li>
> </ul>
> </details>
> 
> _From [webcompat.com](https://webcompat.com/) with ❤️_

Change performed by the [Move to Bugzilla add-on](https://addons.mozilla.org/en-US/firefox/addon/move-to-bugzilla/).
Bug: Tooltip's content showing the date the tracker was first blocked is always "Since January 1, 1970"
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-09-18 08:39:09+00:00
Resolved: 2023-10-02 09:18:53+00:00

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

Steps to reproduce:

1. Launch Firefox with a new profile.
2. Browse for a while.
3. Open the Protections Panel and hover over the "# Blocked".



Actual results:

* The tooltip's content is always "Since January 1, 1970".



Expected results:

* The date should be today.

Regressed by: Bug 1760047
Bug: submitter.formmethod is undefined
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-09-18 08:54:39+00:00
Resolved: 2023-09-19 08:42:32+00:00

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

Steps to reproduce:

Using a button like this, as submitter
```html
<button form="sender" formaction="..." formmethod="post" type="submit" name="name" value="value">text</button>
```


Actual results:

The "formmethod" property is missing 


Expected results:

Just add it, please :)
Bug: "IP:Port" URL still interpreted as HTTP even with trimHttps, leading to inconsistency
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2023-09-18 09:08:13+00:00
Resolved: 2024-01-03 14:28:30+00:00

Say I'm connected to `https://192.168.0.1:1234`. 

With `trimHttps` enabled, the address bar only displays `192.168.0.1:1234` but copying the entire location actually copies `https://192.168.0.1:1234`. This is fine.

However, when I then edit the location to say `192.168.0.1:12345` and press enter, it interprets this as `http://192.168.0.1:12345` instead of the `https://192.168.0.1:12345` I expected.

`https_first` and `https_only` modes do not help. I suppose IP:Port addresses are excluded here.
Bug: The focus ring on tags is misplaced inside the Pocket dropdown
Status: NEW
Priority: --
Created: 2023-09-18 12:53:18+00:00
Resolved: 2024-03-04 12:21:59+00:00

**Affected versions**
* 119.0a1 (2023-09-17)
* 118.0b9
* 117.0.1

**Affected platforms**
* Windows 10
* macOS 13

**Steps to reproduce**
**Preconditions:**
- Be logged into your Pocket account

1. Open any Page
2. Click the Save to Pocket button 
3. Add a tag and click Save button  
4.  Refresh the page and open the Pocket dropdown again
5. Navigate the dropdown using Tab key 


**Expected result**
* The focus ring fits the button in focus 

**Actual result**
* The focus ring doesn’t fit the button 

**Regression range**
- Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=27bc772916c3222b2d9b245fe31f89c15192000a&tochange=49817720177787a3698bdf2e23f081efea4e1212
- Potential regressor: [1781836](https://bugzilla.mozilla.org/show_bug.cgi?id=1781836)
Bug: [meta] Session Restore no longer working for some users after updating
Status: NEW
Priority: --
Created: 2023-09-18 15:23:07+00:00
Resolved: 2024-11-14 21:34:38+00:00

SUMO users reporting that in Fx 117.0.1, across multiple operating systems, session restore is not restoring sessions. 

Sumo Articles:
https://support.mozilla.org/en-US/questions/1424231
https://support.mozilla.org/en-US/questions/1424233
https://support.mozilla.org/en-US/questions/1423903
https://support.mozilla.org/en-US/questions/1424237
https://support.mozilla.org/en-US/questions/1423030

Some users mention that their "Open previous windows and tabs" option is checked
Bug: colour of the home page is not displayed as per the select colour
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-09-18 15:27:01+00:00
Resolved: 2023-11-15 12:32:32+00:00

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

Steps to reproduce:

open the browser 
click on the hamburger top of the right side


Actual results:

colour of the home page is not displayed as per the select colour


Expected results:

colour of the home page should display as per the select colour
Bug: NVDA reads the page title when navigating through the sub-menus of hamburger menu
Status: NEW
Priority: --
Created: 2023-09-18 16:57:29+00:00
Resolved: 2023-11-07 19:38:15+00:00

**Note**
* When using NVDA and Firefox and navigating with keyboard navigation to open the hamburger menu, then a submenu (ex. Bookmarks, History, More Tools...), NVDA will unnexpectadly read the page title before reading the focused button.
* Focusing the "back arrow" button from the sub-menus and tapping ENTER will also reproduce this unwanted behavior.

**Found in**
* Nightly v119.0a1

**Affected versions**
* Nightly v119.0a1
* Firefox Release v117.0.1

**Tested platforms**
* Affected platforms: Windows 10
* Unaffected platforms: unknown

**Steps to reproduce**
1. Launch NVDA.
2. Launch an installed version of Firefox.
3. Load any page.
4. Navigate to and open the Hamburger menu.
5. Select a submenu and tap ENTR. (ex. Bookmarks)
**Expected result**
* The First button in the submenu is verbalized by NVDA.
**Actual result**
* NVDA reads the current page's title and only then, it reads the focused button in the submenu.
6. Focus the "Back arrow" button from the sub-menu and tap ENTER.
**Expected result**
* The button name is read correctly.
**Actual result**
* NVDA reads the current page's title and only then, it reads the button's name.

**Regression range**
* This issue has 2 different behaviors that reproduce the same issue and these have different regression ranges:
1. When entering a submenu:
** First bad: Tested autoland build: 6f3920ec (verdict: b)
** Last good: Tested autoland build: cb44a968 (verdict: g)
** Pushlog:  https://phabricator.services.mozilla.com/D167311
** Potentially regressed by: 984589
2. When returning from a submenu:
** Not reproducible in Nightly v50.0a1 because the hamburger menu can't be navigated using the keyboard.
** This reproduces in builds as old as Nightly v60.0a1, even before the hamburger menu was made properly accessible.
** This behavior would appear not to be a regression, but an issue since implementation.

**Additional notes**
* I've set the affected and unaffected version flags for the first behavior of the two. Please take both into consideration considering they are both part of the same happy flow. Furthermore, if there should be a second bug report for the second behavior, I will happily log another one. Please let me know if it is necessary.
* Some builds have shown a somewhat intermittent reproduction for these issues, but the regressor found appears to be correct.
* I don't think a higher severity than S4 would be necessary considering it is only an annoyance, but feel free to change to a higher one.