av9ash/GitBugs huggingface dataset:
Bug: Window not resized to accommodate OK button when 6th+ language added
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-07-11 00:39:15+00:00
Resolved: 2023-04-11 05:56:43+00:00

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

Steps to reproduce:

1. Go to `about:preferences#general`
2. Under <strong>Language<strong>, click the <strong>Choose…</strong> button next to <strong>Choose your preferred language for displaying pages</strong>.
3. Ensure there are five languages in the list, by adding or removing languages as necessary, and click <strong>OK</strong>.
4. Repeat step 2.
5. Add another language (<strong>Select a language to add…</strong>, pick one, then click <strong>Add</strong>).

This is not high priority, but is a UX issue for multilingual users.  I've classed it as a &lsquo;defect&rsquo; thought it could be argued it is a &lsquo;request for enhancement&rsquo;.


Actual results:

Row of buttons with <strong>OK</strong> (& <strong>Cancel</strong> & <strong>Help</strong>) mostly disappeared off the bottom of the pop-up dialog/window.

As many settings no longer require the clicking of an <strong>OK</strong> or <strong>Apply</strong> button for them to take effect, it becomes no-longer-clear that in this situation there is an <strong>OK</strong> button that still needs to be clicked, and the dialog/window would need to be manually resized to reveal such.


Expected results:

At least one of the following:
- The dialog/window should be automatically resized to accommodate the row of buttons (OK, Cancel, Help);
- A scroll bar should be used with the UI control containing the list of languages, so that the dialog/window itself can be of a &lsquo;fixed&rsquo; size (like having `overflow-y: auto` set for the UI list control &ndash; probably the best solution, because it could theoretically be a long list); or
- Changes made should take effect immediately without the need for clicking OK.
Bug: File | Email Link… shows none of the mail handlers defined for mailto: when "Always Ask" is selected
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-07-11 04:46:19+00:00
Resolved: 2020-07-16 15:43:47+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Selecting File | Email Link when mailto: under Applications in about:preferences is set to "Always Ask"


Actual results:

A blank dialog is presented with no options available other than "Choose Application", even when other mailto: handlers exist.


Expected results:

The mailto: handlers defined under Applications in about:preferences should be available as options. The dialog box probably should have a title rather than being blank, as well.
Bug: Address bar autofill slow/unexpected result
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-11 05:30:45+00:00
Resolved: 2020-07-22 20:43:35+00:00

It feels like in recent Nightly builds that the address bar has become slower to respond.

If I start typing a long search string (like, say, "Firefox is really really great", it quickly autofills to "Firefox is (search with DDG)" and then stays with that as the selected item until a fraction of a second after I stop typing. This means that typing "Firefox is really really great" and immediately hitting return results in the browser navigating to "Firefox is", which is definitely not the behaviour I expect!
Bug: Urlbar search query does not update immediately upon typing anymore, you have to pause for a second before hitting enter
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-11 06:15:43+00:00
Resolved: 2020-07-11 06:39:49+00:00

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

Steps to reproduce:

- type a regular query like "how do you tie your shoes" into the urlbar, at least like 80 words per minute


Actual results:

- even though the characters you're typing appear in the urlbar instantly, they don't appear in the first urlbarView-row (or any of the other urlbar results) until after a short pause. and the first result is the one you end up searching if you hit enter. it wasn't like this a week or 2 ago. if you hit enter immediately after you finish typing, instead of searching "how do you tie your shoes" you'll search something like "how" or you'll end up selecting a bookmark, history item, or open tab that had "how" in the title, because this is so slow now.


Expected results:

- the urlbar results should update quickly like they did before. if that's no longer possible because something else is a higher priority to somebody, then the first urlbar result should not use the same type of predictive suggestion system or whatever. make some kind of boolean pref that will make it so when you hit enter (or click the "go" arrow in the urlbar) while typing in the urlbar, it will just resolve the user input, verbatim, as the search query. either as a domain or a search term. none of the settings in about:preferences seem to make a difference in the speed at which the results resolve. i tried toggling some prefs under browser.urlbar too, to no effect.
Bug: abnormal page reloads on google searchengine usage
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-11 08:07:04+00:00
Resolved: 2020-07-20 08:22:49+00:00

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

Steps to reproduce:

If the google search inside ff 78.0.1 is used, it can lead to a automatic page reload loop.


Actual results:

the google search result page reloads in an endless loop.

if opened via bookmark, it does not reload. 

Something changed how the call to open a page from inside ff searchengines is handeld


Expected results:

guess what ;)
Bug: pdf reader showing wrong character
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-07-11 08:56:05+00:00
Resolved: 2023-05-27 08:37:36+00:00

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

Steps to reproduce:

Open PDF file with firefox browser.


Actual results:

Most checkboxes in a form are displayed as a black clubs icon.


Expected results:

The checkboxes should display properly.
Bug: Entering a comment in Facebook crashes the FB tab.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-11 09:34:43+00:00
Resolved: 2020-09-18 08:32:02+00:00

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

Steps to reproduce:

Log in to Facebook.
Scroll to post with comment field.
Position the cursor into comment field.
Type just one character.


Actual results:

The Facebook tab crashes immediately.


Expected results:

Enter a comment and send it.
Bug: Tying in the address bar and pressing enter ignores some of the characters
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-11 09:58:49+00:00
Resolved: 2020-07-22 20:45:43+00:00

Starting yesterday (11 July 2020) on Nightly the address bar is sometimes ignoring some of the character I type in the URL bar when I press Enter. For example, I just typed "search for everything" and ended up on https://www.google.com/search?client=firefox-b-1-d&q=search+for+every .

This sounds the same as bug 1105967, fixed in 2015, but that was Windows.

At least one other person has seen this behavior, also on Linux.
http://forums.mozillazine.org/viewtopic.php?p=14867752#p14867752

I have fission.autostart set to true. I see the same behavior in Safe Mode. I tried a new profile with fission.autostart true and false and didn't see it, but this is an intermittent issue.
Bug: Pocket recommendations appear after upgrade to FF 78
Status: UNCONFIRMED
Priority: P2
Created: 2020-07-11 11:33:59+00:00
Resolved: 2020-10-14 11:00:05+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I had previously disabled Recommendations by Pocket from appearing in the new tab. My browser version was 77. I updated to 78.


Actual results:

Pocket recommendations were enabled when I re-opened the browser


Expected results:

They should have stayed disabled
Bug: Firefox loses the last few typed characters when pressing enter immediately after typing something into the address bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-11 14:26:20+00:00
Resolved: 2020-07-11 21:36:47+00:00

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

Steps to reproduce:

 - press Ctrl-T (open new tab, focus address bar)
 - type "test this "
 - wait a few seconds
 - press enter
 - OK! firefox loads https://www.google.com/search?client=firefox-b-d&q=test+this+
 - press Ctrl-T (open new tab, focus address bar)
 - type "test this now"
 - while you're typing, note that auto complete shows the previous "test this" search, even while typing "now"
 - wait a few seconds
 - autocomplete shows "test this now -- search with google" after the short pause
 - press enter
 - OK! firefox loads https://www.google.com/search?client=firefox-b-d&q=test+this+now
 - press Ctrl-T (open new tab, focus address bar)
 - type "test this now"
 - while typing, autocomplete shows "test this -- search with google" as before.
 - without waiting, immediately press enter
 - broken: firefox loads https://www.google.com/search?client=firefox-b-d&q=test+this+


Actual results:

Firefox loads the incorrect search results (as shown in the autocomplete before it was updated to include the last few chars typed).


Expected results:

As described above, that firefox navigates to the url or search query typed, i.e. to https://www.google.com/search?client=firefox-b-d&q=test+this+now in this example.
Bug: Store flyers will not display in Firefox. The same sites work fine in Safari.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-11 16:51:02+00:00
Resolved: 2020-07-21 13:06:42+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I opened the site and tried to look at their flyer, like I have been doing in Firefox for the last 20 years.


Actual results:

The flyer would not display. No empty space, nothing.


Expected results:

The flyer should display.
Bug: Rendering postion of fullwidth slider
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-11 17:19:11+00:00
Resolved: 2020-07-30 07:53:24+00:00

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

Steps to reproduce:

Enter this url and see postioning of full width masterslider image:
https://mac-designs.com/


Actual results:

The container offsets to the right of page: see attached screen shots:
If you move the page a few pixels less on width the the slider pops into the correct postion. 


Expected results:

It should fit to the width of the page and not offset to the left:

I'm certain its a box-sizing issue, its correct in all other browsers.
Bug: Fast typing in the urlbar, followed by enter, loses typed characters
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-11 23:05:37+00:00
Resolved: 2020-07-22 20:42:55+00:00

My current nightly: 80.0a1 - 20200711092223
OS: macOS & Linux

When quickly typing in the URL bar, followed by enter to start a search, Firefox opens the Google Search (my default search), but with some of the typed characters/words chopped off.

E.g. quickly typing `foo bar baz<enter>` opens the URL `https://www.google.com/search?client=firefox-b-d&q=foo+bar+ba`
See the missing `z`.
Sometimes full words are missing. Waiting for the first entry in the suggestions to catch up, then pressing enter leads to the right search.

I've narrowed it down to the bug marked here as the regression using [mozregression](https://mozilla.github.io/mozregression/).
This only happens in my main profile. Also happens in safe mode.
This does not happen on a fresh profile.
I got the same report from a friend, same Nightly, on Linux.
Bug: Addons that changes default newtab no longer focuses on address bar by default
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-07-12 04:39:13+00:00
Resolved: 2020-09-01 09:08:29+00:00

### Steps To Reproduce
1. Install Tabby Cat addon (last updated 3 years ago, Sep 6, 2017) which changes the default newtab to cats.
2. Open a new tab with the keyboard shortcut or the + icon.

### Expected Results
- A new tab is opened with the cursor focused on the address bar to type.

### Actual Results
- A new tab is opened and the focus is lost. This seemed to work fine a week or two ago.

### Device Information
Firefox Nightly, 80.0a1 (2020-07-11) (64-bit)
Mac OS, 10.15.5 (19F101)
Bug: Window not present in "Recently Closed Windows" if window closed before quit
Status: UNCONFIRMED
Priority: --
Created: 2020-07-12 05:31:51+00:00
Resolved: 2023-10-06 11:31:50+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

My intention was to restart Firefox, due to some misbehaving tabs (probably a network issue).  However, such misbehavior is not necessary to reproduce the issue.  The following is all that's necessary to reproduce it:

1. Have some tabs open
2. Close window in which tabs are open
3. Quit Firefox (such as via Firefox -> Quit Firefox)


Actual results:

* History -> "Recently Closed Windows" option is greyed out.  
* Menu -> Library -> History -> "Recently Closed Windows" 
* History -> "Restore Previous Session" is greyed out.


Expected results:

Recently closed window (including its tabs) should be present in "Recently Closed Window".  At the very least, it should be possible to "Restore Previous Session" and *then* open the window from Recently Closed Windows, but this seems like an unnecessary step.

When trying to restart the browser, closing the window before quitting the program is a perfectly natural thing to do.  It should not cause the user to lose data.
Bug: Links that use download attribute occasionally failing on save to Dropbox sync folder
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-07-12 06:33:52+00:00
Resolved: 2021-05-13 12:57:27+00:00

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

Steps to reproduce:

I created a HTML file with <a href="data:..." download="filename.txt"> link. I then open it in Firefox, and click the link to save the file to a Dropbox synced folder. I then choose to overwrite an existing file.


Actual results:

If I save it to a Dropbox sync folder over an existing file, it often (but not always) fails --- that is, it shows "Failed" in the Downloads dropdown. If I then click Retry, it (so far) always works.

I *think* it fails when I try to overwrite an existing file only. (I can't recall it failing when saving to a fresh file.)

By contrast:
1) If I save it to a normal folder, it works fine all the time
2) It saves fine to a Google Drive sync folder
3) Chrome always saves the file fine
4) If I load a plain text file in Firefox, and choose Menu -> Save Page As..., it always works. So it seems to be limited to page-generated saving, possibly just a[download] links.


Expected results:

It should, of course, always work.

I've attached the absolute minimal test case which shows the problem for me. Obviously, to replicate it, you'll need to save it to a Dropbox sync folder (on Win 10, presumably).

This took a *really* long time to narrow down. I appreciate it's very specific, but it's cost me some small lost work on a few occasions.
Bug: Word lost when typing in mixed CJK-and-Endlish words in the search bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-12 06:44:04+00:00
Resolved: 2020-07-12 14:34:30+00:00

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

Steps to reproduce:

Typing "ゆるキャン ost" or "ost ゆるキャン" in the search bar (address bar), then press enter immediately.


Actual results:

The second word is lost.
Unreproducible in pure-English, only in mixed CJK-and-Endlish.


Confirmed in safe mode.
Bug: The most used items disappeared from urlbar dropdown list
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-12 08:30:14+00:00
Resolved: 2020-07-21 08:27:03+00:00

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

Steps to reproduce:

1. Have 10 most frequently used URLs in the dropdown list of the urlbar (location bar).
2. Update to a new browser version (presumably 78.0.1+)


Actual results:

Two items have disappeared, one of them used to be the MOST frequently used one which has always been placed at the top of the list. The rest of the items is still there. The number of items switched to 8 in spite of browser.urlbar.maxRichResults bing explicitly set to 10.


Expected results:

The dropdown list of the urlbar (location bar) should not be affected by updates as this provides really poor user experience and basically destroys the normal workflow for most people using web browsers for more than a few years.
Bug: window can not be closed
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-12 08:55:41+00:00
Resolved: 2020-07-21 05:56:46+00:00

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

Steps to reproduce:

- open a older firefox
- configure firefox to remember the opened tabs and windows when opened next
- open multiple windows (I have 7) with multiple tabs, open webpages
- install Firefox 78.0.1
-  reopen firefox


Actual results:

some windows can not be closed, no matter if by mouse or keyboard,
I can not interact with these windows (e.g. open a new tab, change the tab, ...), but the tab titles, the content and the gui looks normal


Expected results:

windows should be closable and react
Bug: Superfluous animations and hover/focus effects are distracting and disorienting
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-07-12 08:55:45+00:00
Resolved: 2020-07-14 09:12:13+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36

Steps to reproduce:

I updated firefox (again)


Actual results:

Tons of animations, hover, and focus effects were added. They drastically reduce the enjoyment I get out of using firefox. They distract from what I'm doing and disorient me. I searched for half an hour for hacks to get rid of them. Most didn't work. I had to resort to creating a userChrome.css file to undo all the changes I wanted not to have.


Expected results:

It would be really nice if there were a single setting
"don't adopt future 'user experience improvements'"

This has been a constant battle for probably 15 years. Every new release I have to find an extension, secret setting, or hack to bring firefox back to 'normal'.

This isn't just a cry baby complaint. There are users with serious, real attention and psychological 'disorders' that these changes have serious negative effects on.

I appreciate the attention to detail these animations demonstrate, but I feel they were a swing and a miss. Instead of provoking 'joy', they are provoking 'anger' and 'frustration'.

Please give a blanket option to disable these minor-enjoyment-on-first-use visual appeal changes.
Bug: Address bar suggestions are not updating properly as you type, so that when you press Enter it searches for the wrong thing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-12 09:04:22+00:00
Resolved: 2020-07-13 12:40:00+00:00

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

Steps to reproduce:

1. Start typing a search query or URL in the address bar, at a decent speed.
2. Observe the suggestions shown as you type. Vary speed of typing, introduce delays, &c. Type many characters if you’re not seeing it, that seems to help with slowing it down.
3. Press Enter without waiting after typing something (at a time when the first suggestion is out of sync with what is typed).


Actual results:

Suggestions are not updated as you type, but only after you stop typing for a certain interval, which seems to vary by at least length.

It seems to only update the suggestions all at once, rather than updating the search/visit one immediately and others like history as the results come in. At a guess, something has become a single asynchronous value that was formerly either synchronous or an asynchronous stream, and when you type another character it cancels the previous task.

This is a regression from the last week or so, and it’s rapidly driving me bonkers. 🙂 I can record a video of it if you need (I haven’t done so because it’s a touch bothersome to acheive).


Expected results:

1. The suggestions should match what was typed in the address bar, not lag behind. Especially the first suggestion (visit/search), I see no reason why that one would ever need to lag.
2. When pressing Enter, it should search for/navigate to what is in the address bar, not the lagging-behind suggestion.
Bug: awsomebar search text gets truncated
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-12 12:14:44+00:00
Resolved: 2020-07-12 13:43:58+00:00

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

Steps to reproduce:

- Click on the address bar
- Type "hey there"
- Press enter


Actual results:

Taken to Google search results for "hey t" (truncated)


Expected results:

Taken to Google search results for "hey there"
Bug: Firefox SSB mode does not allow permission control (cannot use microphone access)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-07-12 13:40:20+00:00
Resolved: 2021-01-15 22:20:53+00:00

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

Steps to reproduce:

Load discord.com as an SSB with firefox --ssb https://discord.com. Attempt to make use of microphone in voice settings.


Actual results:

Microphone does not create output, and no permission popup to allow it.


Expected results:

Microphone either creates an output to the browser, or a permission popup allows me to enable it.
Bug: Searching from the url bar drops part of the search string
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-12 16:47:11+00:00
Resolved: 2020-07-13 04:46:46+00:00

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

Steps to reproduce:

- click on url bar
- type in a search phrase like "how does a proton freezer work"
- immediately hit enter to start a search with my default search engine (google) because I finished typing


Actual results:

google starts searching for "how does a proton free", or "how does a pro" or even "how does a p" 


Expected results:

this should go without saying, but firefox should have created the search URL with all the terms that I typed, and that it knows I typed because I could see exactly what I typed in the URL bar before I hit enter.
Bug: Search phrase is truncated when typing fast
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-12 17:18:23+00:00
Resolved: 2020-07-22 20:43:06+00:00

STR:
1. Focus into the awesome bar
2. Type a search phrase like "search for nasa spacex"
3. Press "Enter" quickly after finishing typing the phrase

Expected results:
Should land on search result page for "search for nasa spacex"

Actual results:
Land on search result page for "search for nasa spa", or "search for na" or sometimes just "search f"

Similar results for:
* "jenks city council" > "jenks ci"
* "never gonna give you up" > "never go"

Does NOT seem to happen on a new profile, so might be caused by lots of history in the awesomebar slowing something down?