av9ash/GitBugs huggingface dataset:
Bug: website history is not working fine as i require
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-08-05 22:18:43+00:00
Resolved: 2023-08-06 15:58:30+00:00

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

Steps to reproduce:

Hi Firefox Team,
I want "when i type on address bar any characters the firefox must show websites from my history" 
I did set  Show search suggestions ahead of browsing history in address bar results in search Suggestions section. but the result is showing by firefox is not revlent as i expect. 


Actual results:

for example i had opened many pages of the website https://www.uni-jena.de/. but now when i type jena in address bar the firefox shows only nine suggestions from my history. but in reality it is not true. i want firefox show all pages from jena website. right now it show most recent pages from jena 


Expected results:

i want to see all pages from jena which i opened earleyer. for this i have to open history tab and search jena then i see my expected result. please make it correct.
many thanks,
Mohsin Rao
Bug: Impossible to remove a UI language from settings (remove button not working)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-08-06 00:40:03+00:00
Resolved: 2023-08-10 16:15:02+00:00

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

Steps to reproduce:

1. make sure that "English (CA)" is added to your browser-languages list at about:preferences#general
2. in language settings, click on "Search for more languages..."
3. in the dropdown list, also click on "Search for more languages..."
4. Click on "English (CA)"
5. click on "Remove"
6. click on "OK"


Actual results:

"English (CA)" still is in the list.


Expected results:

Any language removed should actually be removed and not remain.
Bug: "remove from pocket" button acts exact same as "remove" button, it also removes any article from the news cards entirely
Status: NEW
Priority: --
Created: 2023-08-06 00:53:48+00:00
Resolved: 2023-08-21 12:13:31+00:00

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

Steps to reproduce:

1. be logged in to getpocket.com
2. save an news cards article in pocket
3. click "remove from pocket"


Actual results:

article entirely removed from the entire news cards page


Expected results:

Only clicking on "remove" should remove the article from the entire news cards page entirely. Clicking on "remove from pocket" should *ONLY* remove the article from this custom list: https://getpocket.com/saves?src=navbar
Bug: Clicking on dropdown link in Google has no effect
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-08-06 02:44:10+00:00
Resolved: 2023-08-08 09:38:28+00:00

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

Steps to reproduce:

Search for "ingredients of nuggets" in Google.
In the "People also ask" section, click on any of the links.


Actual results:

No effect

Take a look at the attached screenshot, with the red arrows pointing at the dropdowns that I click, which has no effect.


Expected results:

The link drops down to show more data.
In the same steps with Chrome, it works.
Bug: Links from pinned tabs always open in tab bar Start
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-08-06 07:10:08+00:00
Resolved: 2023-08-15 11:20:39+00:00

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

Steps to reproduce:

1. set both browser.tabs.insertRelatedAfterCurrent and browser.tabs.insertAfterCurrent to false
2. pin a tab
3. open a link (different domain) from a pinned tab


Actual results:

The link is opened in a new tab in the Start position of the tab bar


Expected results:

The link is opened in a new tab in the End position of the tab bar.
This was the behaviour up to release 115.1
Bug: FF does not remember DUO (Cisco) authorisation for 14 days
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-08-06 12:48:06+00:00
Resolved: 2023-10-10 22:03:27+00:00

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

Steps to reproduce:

Sign into a 2FA using CISCO DUO


Actual results:

Signed in, selected "Remember me for 14 days"; sign in worked.  CLosed FF, went back to site, FF does NOT remember me; this is new behaviour in FF 116.0 in Pop_OS 22.04


Expected results:

Should have remembered me across open/close & reboots for 14 days.
Bug: [Translate This Page] No possibility to deactivate this feature at all
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-08-06 19:25:30+00:00
Resolved: 2023-08-07 14:46:26+00:00

Nightly 118.0a1 (2023-08-05) (64-Bit)
macOS 13.5


Steps to reproduce:
1.) Use System Language DE
2.) Vist macrumors.com
3.) In the Address Bar the "Translate This Page" Bubble appears
4.) Search for a setting to deactivate this feature at all

Actual: No setting to deactivate this feature.

Expected: A setting to deactivate this feature.
Bug: I have to cut and paste this message because my keyboard dosen’t work right in Firefox since last update
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-08-06 22:38:59+00:00
Resolved: 2023-09-13 04:57:52+00:00

Steps to reproduce:

Everything I was told to do in help and troubleshoot, including refreshing FF


Actual results:

Nothing good. I had to reconfigure FF and am still working on it.


Expected results:

I don’t know. The keyboard should have started working I guess. I’ve since downloaded Opera just so I can read my emails. I’m not computer savvy and don’t claim to be, but I can follow directions.
Bug: Download option asking whether to save or open with has no radio buttons
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-08-07 06:30:32+00:00
Resolved: 2023-08-07 06:41:19+00:00

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

Steps to reproduce:

Step 1: Open Firefox and go to Settings
Step 2: In the General section, scroll down to Files and Applications and toggle "Ask whether to open or save files" on.
Step 3: Go to a download test page and click any file


Actual results:

No radio buttons to indicate which one is selected besides the border surrounding the Save file...


Expected results:

There should be radio buttons for indication.

This bug appears similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1818432 except the checkbox does appear. It only started happening with version 117.
Bug: [Linux] The backgrounds of the illustrations from the “about:welcome” page are no longer visible if the “High Contrast” Mode is enabled
Status: NEW
Priority: P2
Created: 2023-08-07 07:56:50+00:00
Resolved: 2023-10-04 16:23:02+00:00

**[Notes]:**
- This issue is reproducible only on Linux distributions.

**[Affected versions]:**
- Firefox Beta 117.0b4 - Build ID: 20230807001816

**[Affected Platforms]:**
- Linux Mint 21.1

**[Prerequisites]:**
- Have the Firefox browser opened.
- Have the system’s “High Contrast” mode enabled.

**[Steps to reproduce]:**
1. Navigate to the “about:welcome” page and navigate through the “about:welcome” screens.
2. Observe the backgrounds of the images.

**[Expected result]:**
 - The background images are visible.

**[Actual result]:**
- The background images are NOT visible.


**[Notes]:**
- Attaching a screen recording of the issue:
Bug: vsync keeps running if the shopping sidebar is hidden - should tell gecko when it's not needed/visible
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-08-07 16:54:08+00:00
Resolved: 2024-01-18 08:32:14+00:00

See bug 1847584.

This ends up happening when we're in the "loading" state and the sidebar is hidden.

For now, we should probably manually set `docShellIsActive` to false on the browsingcontexts that are hidden, and back to `true` when unhiding them. This also (it appears) applies to tab switches.
Bug: Setting as 'default browser' on Linux does not associate with x-scheme-handler/http
Status: UNCONFIRMED
Priority: --
Created: 2023-08-07 18:06:03+00:00
Resolved: 2023-08-08 15:41:25+00:00

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

Steps to reproduce:

On a Debian-based system with both firefox-esr and google-chrome installed, set Firefox to handle HTML but Chrome to handle http: and https:.

$ xdg-mime default google-chrome.desktop x-scheme-handler/http x-scheme-handler/https
$ xdg-mime default firefox-esr.desktop text/html

Then check about:preferences. It will say Firefox is the 'default browser'.

Then try some external application that can follow HTTP or HTTPS hyperlinks, e.g. LibreOffice opening any document containing such a hyperlink. Follow the link (Ctrl+Click on LibreOffice).


Actual results:

It launches Chrome, not Firefox.


Expected results:

Either it should have launched Firefox, or Firefox should not claim to be the default browser. Note that the application (here LibreOffice) does not maintain its own browser setting.

The Linux-specific (distro-specific) instructions in Firefox support pages (https://support.mozilla.org/en-US/kb/setting-firefox-default-browser-does-not-work) appear to work by associating Firefox with the MIME type "text/html". My best guess is that this is also what the about:preferences page is checking for when it says "Firefox is currently your default browser". (But I *am* just guessing about this.)

An association with text/html is not enough... it is also necessary to associate with x-scheme-handler/https and x-scheme-handler/http, and I found that Firefox was not associated with these even while it claims to be the default browser. The associations can be queried using the 'xdg-mime' tool, specifically

$ xdg-mime query default text/html
$ xdg-mime query default x-scheme-handler/https
$ xdg-mime query default x-scheme-handler/http

... I found that the latter two were not associated with Firefox.

They can be updated with (on my system, using the ESR version of Firefox)

$ xdg-mime default firefox-esr.desktop x-scheme-handler/http x-scheme-handler/https

After doing this, I get the expected behaviour. It would be great if Firefox could do this automatically when setting itself as the default browser.

This is related to bug 1599717 'Consider delegating "is this the default browser" checks to "are we the default for http/https protocols" checks on the external protocol service' and bug 1489541 'Firefox says it is default browser in KDE despite xdg default-web-browser setting'. However, I don't think it is the same. For example, the xdg 'default-web-browser' setting is empty on my system; it does not point to Chrome.
Bug: Closing a window with a single about:newtab tab with no history results in a recently closed window entry
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-08-07 18:21:21+00:00
Resolved: 2023-08-14 19:18:31+00:00

STR:
* Open a new browser window. It only tab should be the New Tab page (about:newtab). 
* Close the browser window -without having typed anything in the New Tab page, or navigated it

Expected: 
* This is considered a "empty" window with no useful state to save, so no new entry in the History > Recently Closed Windows list is created

Actual
* A new Recently Closed Windows menu item is created, with "New Tab" as its label

In SessionStore.sys.mjs `maybeSaveClosedWindow` has the logic where we determine if there is useful state/history to save when closing a window. It evaluated each of the currently-open tabs in the window against `this._shouldSaveTabState()`, which has a [list of URLs we consider not worth keeping](https://searchfox.org/mozilla-central/rev/fb43eb3bdf5b51000bc7dfe3474cbe56ca2ab63c/browser/components/sessionstore/SessionStore.sys.mjs#6150-6154). 

As the window is closed, we handle a `domwindowclosed` observer notification, and call `this.onClose`, which in turn calls `maybeSaveClosedWindow`. At this point the tab's entries array is empty and we return false to not save the window data. 

`maybeSaveClosedWindow` is called again when the promise from `TabStateFlusher.flushWindow` resolves. The [`tabData` gets updated from data from cache](https://searchfox.org/mozilla-central/rev/e4d8451468be3a0f8a9faa3d37cadf07200821ec/browser/components/sessionstore/SessionStore.sys.mjs#2259), and now the tab.entries[0].url is `about:home`. `about:home` is not in the list in `_shouldSaveTabState`, so we return true from there and `maybeSaveClosedWindow`, so the window's state is saved into `this._closedWindows` - which is the collection used to populate the "Recently Closed Windows" lists.
Bug: Empty 'Security Software' section in about:support that wasn't there before
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-08-08 03:31:30+00:00
Resolved: 2023-09-05 13:10:25+00:00

Steps to reproduce:
1) Navigate to about:support

Actual results:
Empty 'Security Software' table

Expected results:
No empty 'Security Software' table
Bug: Consider waiting for the page to be ready before identifying the language
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-08-08 06:45:02+00:00
Resolved: 2023-09-07 15:53:33+00:00

STR (starting with a fresh profile):
1. Visit https://easyview.app/lp/spb-chroma/ (warning, this is a page that's advertising a browser add-on, which I don't know much about; probably best not to interact with it much).
2. If you don't see a translation dialog yet, try reloading.

ACTUAL RESULTS:
A "Firefox Translation (beta)" dialog appears, offering to translate the page from German to English.

EXPECTED RESULTS:
No such dialog. The page is already in English.  And if I click "translate", it leaves the page mostly untouched -- just e.g. converting `away` to `a way` and one or two other small changes.

NOTE: The page does seem to briefly flash a German-language version of the content when it first loads, and then it immediately replaces it. Maybe that's the version that Firefox Translation is seeing, even though that version disappears ~immediately?

I'm using Nightly 118.0a1 (2023-08-07) on Ubuntu 22.04
Bug: "Import browser data" tool in Settings section only displays "Bookmarks from HTML file" option
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-08-08 10:45:48+00:00
Resolved: 2023-08-11 13:47:59+00:00

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

Steps to reproduce:

Followed instructions for importing login data from a file as described here - https://support.mozilla.org/en-US/kb/import-login-data-file# 
However, the only option Firefox displays for my device/version is the "Bookmarks from HTML file." Not displayed are the "Passwords from CSV file" as well as the other web browser options (Chrome, Safari, etc.).
Bug: URI Fixup always prepends 'http' even when original url used 'https'
Status: NEW
Priority: P2
Created: 2023-08-08 11:00:38+00:00
Resolved: 2023-09-20 15:15:25+00:00

When a customer has '.trimHttps' enabled (a pref that is introduced in #1846261), then the fixup uri should also have "https://" as the scheme.
Bug: Radio buttons are in the same group when they mustn't
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-08-08 12:48:50+00:00
Resolved: 2023-09-01 13:53:57+00:00

It's a mirror bug of:
https://github.com/mozilla/pdf.js/issues/16805

and it's a regression caused by bug 1839774 and especially:
https://github.com/mozilla/pdf.js/pull/16563
Bug: Reuse of client side UI state causing hydration issue with primed cache reloads (session restore restoring the disabled state of the button)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-08-08 17:57:07+00:00
Resolved: 2024-04-29 15:53:00+00:00

Steps to reproduce:

1. Save the following code to a `server.mjs` file.  This creates the simplest possible React Server Side Rendering setup with hydration (uses CDN copies of react to avoid the need for a bundler).  It renders a disabled button on the server and then after hydration on the client - it enables the button 2.5 seconds later.

2. Run node `server.mjs`

3. Load http://localhost:3000 and notice no errors in the console.  

```
import http from "node:http";
import * as React from "react";
import * as ReactDOMServer from "react-dom/server";

function App() {
  let [disabled, setDisabled] = React.useState(true);

  React.useEffect(() => {
    setTimeout(() => setDisabled(false), 2500);
  }, []);

  return React.createElement(
    "html",
    null,
    React.createElement(
      "head",
      null,
      React.createElement(
        "style",
        null,
        "button { border: 2px solid green; } " +
          "button[disabled] { border: 2px solid red; }"
      )
    ),
    React.createElement(
      "body",
      null,
      React.createElement("button", { disabled: disabled }, "Hello Button"),
      React.createElement("script", {
        crossOrigin: "true",
        src: "https://unpkg.com/react@18.2.0/umd/react.development.js",
      }),
      React.createElement("script", {
        crossOrigin: "true",
        src: "https://unpkg.com/react-dom@18.2.0/umd/react-dom.development.js",
      }),
      React.createElement("script", {
        async: "async",
        dangerouslySetInnerHTML: {
          __html:
            App.toString() +
            "\n" +
            "ReactDOM.hydrateRoot(document, React.createElement(App));",
        },
      })
    )
  );
}

let server = http.createServer((req, res) => {
  let doc = ReactDOMServer.renderToString(React.createElement(App));
  res.setHeader("Content-Type", "text/html");
  res.write("<!DOCTYPE html>" + doc);
  res.end();
});

server.listen(3000, () => {
  console.log("server listening on http://localhost:3000");
});
```


Actual results:

We would expect reloads (coming from the network or from the cache) to hydrate successfully with an initial client side "disabled" state.


Expected results:

Soft reloads from a primed cache _after_ 2.5 seconds (and the button has been enabled client side) cause a hydration error.

- hard reloads (holding shift key) before the 2.s mark are OK
- hard reloads (holding shift key) after the 2.s mark are OK
- soft reloads (with a primed cache) before the 2.s mark are OK
- soft reloads (with a primed cache) after the 2.s mark cause the error

It appears FireFox is preserving some aspect of the client side DOM on soft reloads such that it thinks the initial state of the button is enabled.  This causes an issue in React's hydration step because the server always sends a disabled button.

I'm using Firefox 116.0.2 64 bit on Mac OSX Ventura 13.5.
Bug: Entering web authentication text and clicking Sign In flashes to previously-loaded content
Status: NEW
Priority: --
Created: 2023-08-09 01:44:22+00:00
Resolved: 2023-11-02 13:45:04+00:00

Steps to Reproduce:
1) Navigate to some site.
2) Navigate to this web authentication test site: httpbin.org/basic-auth/foo/bar.
3) Note that the previous page's content has been replaced by a blank background with an authentication box on top of it.
4) Enter authentication text "asdf" / "asdf" (or any text other than "foo" / "bar" which is the correct authentication text). Click the "Sign In" button.

Expected Results:
Background remains blank while the dialog is re-presented with blank entry fields. 

Actual Results:
Background flashes to previous content, then becomes blank while the dialog is re-presented with blank entry fields.

This flash is distracting and can cause users to think that the new site they are navigating to is presenting this old content. If the correct authentication text is entered, the old content is displayed while a dialog box asks if the user wishes to save the login information. This is also distracting. The user has navigated away from this old content and it's a bad user experience to show it to the user during the authentication process at the new navigation url.
Bug: Race condition in feature callout tourend page events
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-08-09 12:42:39+00:00
Resolved: 2023-08-12 16:04:44+00:00

On dismiss, callouts tear down their `tourend` page event listeners before the handlers can resolve. Pretty easy fix, just rearranging the order of some things.

I also want to fix another nagging issue here - the FOUC when callouts are loaded for the first time too early in startup. It's because we use a `link` element to load the stylesheet. There's not really a way to wait for it to truly apply to the content. A `load` event listener would tell you when it loads, but I guess not when it registers or applies to the content. I had to just use a different method of loading the stylesheet altogether.

Then finally, change the logic for picking an `initialFocus` target a bit. We should include radio buttons/checkboxes as eligible initial focus targets. That way, if the primary button is disabled (as it will be initially for survey screens, which start with no radios/checkboxes checked), we won't just focus the dismiss button (or a link), but instead focus the main element we want the user to interact with. In the survey case it makes a lot more sense to focus the first radio button than to focus the dismiss button, which we don't want them to click at all.
Bug: Translations icon throbber constantly spins when re-translating a page when network is disabled
Status: NEW
Priority: P3
Created: 2023-08-09 13:31:58+00:00
Resolved: 2023-08-24 19:17:05+00:00

Affected versions:
- Nightly (118.0a1/20230808212319)
- Beta (117.0b5/20230808215502)

Steps to reproduce:
1. Access https://es.wikipedia.org/wiki/Wikipedia:Portada
2. Translate the page
3. Disable network
4. Open the translations panel and click on “Show original” to revert the translation
5. Translate the page once more

Actual:
The throbber will spin continually until the page is reloaded.

Expected:
The throbber should stop spinning after a few seconds and the translations panel should pop open and display the “There was a problem translating. Please try again” error message as in the case of disabling network when a translation is in progress.

NOTE:
Re-enabling network will not cause the throbber to stop spinning, however reloading the page will. Translations can be performed without issues after this point.
Bug: Re-analyze Reviews link on the sidebar has low color contrast against yellow background
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2023-08-09 14:49:31+00:00
Resolved: 2023-09-06 16:32:18+00:00

When updates are available and a `Re-analyze reviews` link is added to the yellow notification section, the color contrast of the on-screen text for the link is low: it's 1.32:1 for the blue against yellow while at least 4.5:1 color contrast ratio is expected for standard text this size.

This makes the text hard to read, especially for users with low vision, users with color deficiency, and users with glare on their screens too. Using `blue-50` #0060df or darker would provide a color contrast of 4.6:1 or higher against the yellow background.

This may be the component-wide color contrast issue, thus CCing Jules for visibility

[URL used](https://www.amazon.com/Utz-Delightfully-Cholesterol-Trans-Fat-Certified/dp/B09F8ST2ZS)
Bug: Firefox 116 should not have been released
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-08-09 17:34:15+00:00
Resolved: 2023-08-11 13:09:47+00:00

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

Steps to reproduce:

visited many websites I routinely visit that now broke after installing 116.0.2

blank pages, links 404, functions stopped working


Actual results:

blank pages, 404, addons broken

after reverting to 115.0.3, mozilla hosed my profile

took an hour to reset passwords, filling out dozens and dozens of captchas on the way


Expected results:

i downloaded 115.0.3, and mozilla did not like that, so mozilla hosed my profile, whereby I have no access to years of history, bookmarks, passwords.

never trust mozilla.