av9ash/GitBugs huggingface dataset:
Bug: Permanent private browsing new tab pages should have a consistent tab title (either always "New Tab" or always "Private Browsing")
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-11-05 23:45:47+00:00
Resolved: 2021-01-07 20:51:51+00:00

Tested using Nightly on Linux

- Create a new Firefox profile
- In the settings set history to "Never remember history"
- Firefox will restart. 
- Note the first tab has title "New Tab". It seems to be temporarily "Private Browsing" before switching to "New Tab"

If one very quickly after start creates more tabs (ctrl+t), all those tabs get "New Tab".
Only after some time tabs start to get "Private Browsing" as the title
Bug: URL appears unformatted in the time it takes to get data from the server, when loading an unloaded tab or reopening last closed tab
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-11-06 11:20:59+00:00
Resolved: 2020-12-09 01:05:19+00:00

STR:
1. Set Nightly to restore previous session
2. Open several tabs which are somewhat slow to load like twitter.com, www.reddit.com, www.facebook.com
3. Open a new tab
4. Restart Nightly
5. Focus each unloaded tab, and see that in the time it takes to receive data from the server, the URL appears unformatted.

Regressed by bug 1577539.
Bug: avoid to make icon chaos of .app
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-06 11:21:57+00:00
Resolved: 2020-11-06 18:44:46+00:00

already before the new .app installation there was a bit chaos between esr, beta, normal. now is even worse, since it's all identical and you keep to name it firefox. so i always need to rename it. 

PS: if last time there was no need to rename beta...  plus the fact that i told it as beta, but seems you install it as normal. have you add the wrong .app to the beta download button?
Bug: Firefox does not restore sessions on update as it states. Not one of mine was restored.
Status: UNCONFIRMED
Priority: --
Created: 2020-11-06 12:06:49+00:00
Resolved: 2023-06-12 12:17:30+00:00

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

Steps to reproduce:

I clicked on Update and restore session when Firefox wanted to apply an update.


Actual results:

No sessions were restored.


Expected results:

My six sessions should have been restored.  I have no file to submit because I do not know how to send a file to represent this bug.
Bug: Address bar popup menu still suggests http:// in HTTPS-only mode
Status: NEW
Priority: P3
Created: 2020-11-06 12:07:02+00:00
Resolved: 2024-07-02 14:43:53+00:00

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

Steps to reproduce:

1. Enable HTTPS-only mode
2. Type example.com in address bar


Actual results:

Two hint were displayed.
One is to search "example.com" in search engine.
Another one is to go to "http://example.com"


Expected results:

Second hint should be "https://example.com"
Bug: BCP 47 format for locales is not recognized on top-sites collection, Remote Settings Stage
Status: RESOLVED
Priority: P5
Resolution: WONTFIX
Created: 2020-11-06 12:28:02+00:00
Resolved: 2020-11-13 18:31:15+00:00

On Remote Settings STAGE, top-sites collection, the locales to be included/excluded are documented to use BCP47 format.
However, BCP 47 format is not recognized when setting some locales: for example RO locale, for which the BCP47 would be `ro-RO`, the localized Firefox build being branded `ro`. Additionally, seems that the locale field is also key sensitive, which would enable `ro` to work, but `RO` not to work.

It might be a common mistake setting wrong locale when attempting to exclude/include a locale.


Suggested severity: S3
Bug: Perma browser/components/places/tests/browser/browser_default_bookmark_location.js | Should have menu folder selected by default - "Other Bookmarks" == "Bookmarks Menu" when Gecko 84 merges to Beta on 2020-11-16
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-11-06 14:26:11+00:00
Resolved: 2021-06-11 11:13:54+00:00

[central-as-beta simulation](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&selectedTaskRun=HYKtldwfQ0mkTCt8bapG-Q.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=7fc152a05bbb140751a1d1bc750910a93b6755d3)
[Failure log](https://treeherder.mozilla.org/logviewer?job_id=320955843&repo=try)

[task 2020-11-06T13:35:51.561Z] 13:35:51     INFO - Entering test bound test_change_location_panel
[task 2020-11-06T13:35:51.561Z] 13:35:51     INFO - Pref value: toolbar
[task 2020-11-06T13:35:51.564Z] 13:35:51     INFO - Waiting for item to move.
[task 2020-11-06T13:35:51.565Z] 13:35:51     INFO - Waiting for transactions to finish.
[task 2020-11-06T13:35:51.566Z] 13:35:51     INFO - Moved; waiting to hide panel.
[task 2020-11-06T13:35:51.567Z] 13:35:51     INFO - Waiting for pref change.
[task 2020-11-06T13:35:51.568Z] 13:35:51     INFO - TEST-PASS | browser/components/places/tests/browser/browser_default_bookmark_location.js | Bookmark was put in the menu. - 
[task 2020-11-06T13:35:51.569Z] 13:35:51     INFO - Buffered messages finished
[task 2020-11-06T13:35:51.573Z] 13:35:51     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_default_bookmark_location.js | Should have menu folder selected by default - "Other Bookmarks" == "Bookmarks Menu" - JS frame :: chrome://mochitests/content/browser/browser/components/places/tests/browser/browser_default_bookmark_location.js :: test_change_location_panel :: line 221
[task 2020-11-06T13:35:51.574Z] 13:35:51     INFO - Stack trace:
[task 2020-11-06T13:35:51.575Z] 13:35:51     INFO - chrome://mochitests/content/browser/browser/components/places/tests/browser/browser_default_bookmark_location.js:test_change_location_panel:221
Bug: The profile remains enrolled in the "QuantumBar v2 Group" branch after manually disabling the feature from about:config
Status: NEW
Priority: P3
Created: 2020-11-06 15:37:15+00:00
Resolved: 2020-11-11 10:48:26+00:00

**[Notes]:**
- I have discussed this behavior with Michael De Boer, and it is expected to still have the experiment enrolled in the profile.  This is an edgecase because the users have to manually disable the feature using "about:config" page and probably they are not aware of this pref.
- However, I have logged this behavior for tracking purposes and for all members involved in this experiment to be aware, in case that we will have any strange results at the end of the experiment. 
- Our concern is that the users enrolled in the "QuantumBar v2 Group" branch which will have the QuantumBar v2 feature enabled, will still remain enrolled in the experiment if they manually disable the feature. This can affect the gathered telemetry data because the users enrolled in this branch should have the QuantumBar v2 feature enabled.

**[Affected versions]:**
- Beta 83.0b9;
- Nightly 84.0a1;

**[Affected Platforms]:**
- All Windows;
- All macOS;
- All Linux;

**[Prerequisites]:**
- Have a new clean Firefox Profile.
- See this [document](https://docs.google.com/document/d/13yxuvfpIGojY1FSsUJYHKUUQldKkSW0UzrUirdC0kQ0/edit#bookmark=id.3qlajv1ku5v3) for the environment variable needed so you can enroll in the experiment.
- Copy this [user.js](https://drive.google.com/file/d/1VW0GPPqUMVLPMXj6wxNDsfjSjf5aBtql/view?usp=sharing) file in the profile folder.

**[Steps to reproduce]:**
1. Open the Firefox browser using the profile from prerequisites.
2. Navigate to "about:studies" to verify that the experiment is active.
3. Navigate to "about:config" and set the "browser.urlbar.update2" to false.
4. Open a new tab and verify that the QuantumBar v2 feature is disabled.
5. Navigate to "about:studies" page and observe the behavior.

**[Expected result]:**
- The profile is unenrolled from the experiment because the QuantumBar v2 feature was disabled.

**[Actual result]:**
- The profile remains enrolled in the experiment on the "QuantumBar v2 Group" branch even if the QuantumBar v2 feature is disabled.

**[Additional Notes]:**
- Attached a screen recording with the described behavior.
Bug: Text elements overlap in screenshot, but rendered fine on the screen
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-11-06 16:29:08+00:00
Resolved: 2023-01-19 23:20:48+00:00

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

Steps to reproduce:

Take a screenshot in desktop (Windows 10) Firefox, using the 3-dot menu, - of an area of the webpage - on a NextDoor.com page


Actual results:

The "Search" element is shown on top of the text (highlighted in yellow in the screenshot), and it was not the case on the screen. I am uploading two screenshots: one created by Firefox, and the other - taken in Windows, - during the process of choosing the area on the webpage.


Expected results:

The screenshot should reproduce the screen exactly.
Bug: Investigate the performance of tabswitch handling of bookmarks toolbar visibility
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-11-06 16:50:08+00:00
Resolved: 2023-07-31 23:39:26+00:00

bug 1674053 shows that there's some effect from the `onLocationChange` changes that impact tabswitch times. Because we're not intending for the tabswitch talos test to measure anything other than asynctabswitcher and painting performance, we'll disable the new changes in the bookmarks toolbar visibility for that performance measure.

However, we should still get to the bottom of what exactly is causing the timing changes and how we could improve them - although they're small (5-10ms) in the grand scheme of things, it's a bit unclear what their exact cause is about. Because we're close to 84 going to beta, I'm splitting off the broader investigation from fixing the perf issue at hand. I think the perf effects are small enough, and likely limited in impact enough (only affecting tabswitches between tabs where the toolbar appears/disappears, which are likely to be a minority) that we're comfortable running experiments on 84 even if we don't get to the bottom of this particular issue by then - though ideally we should address it before general release.
Bug: Plain text documents no longer open in Firefox
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-06 17:13:44+00:00
Resolved: 2020-11-06 17:54:53+00:00

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

Steps to reproduce:

Click on a plain text document to view it.


Actual results:

Pop-up: download


Expected results:

Text document used to open in Firefox. Now it "thinks" a plain text file is an octet stream and can no longer handle it. What changed? I became used to viewing text documents in Firefox over the decades. Seems Firefox no longer checks the file for magic numbers, only depends upon extensions. Many text files do not have extensions, such as readme files.
Bug: Firefox PDF rendering: extra spaces in between words and within words
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-06 18:52:30+00:00
Resolved: 2021-10-23 09:57:56+00:00

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

Steps to reproduce:

Firefox 82.0.2
macOS 10.14.6 

 - PDF https://www.dragos.com/wp-content/uploads/The_Four_Types-of_Threat_Detection.pdf page 15 

highlight the text "behavioral analytics", in the last paragraph 
copy the highlighted text

do the same thing in chrome


Actual results:

 - Text gets copied as `behavioral   anal  yti ` (sic) 

Notice that the space in between words has three spaces, and there are extra spaces added within the second word.

Also on the page you can notice this if you Ctrl-F find `behavioral a`, it doesn't show matches but if you find on `behavioral   a` (with three spaces), it matches. 

This isn't an issue with the find component, but implies the PDF text rendering to the DOM is not accurate and is adding extra spaces. (which can be confirmed in inspector, see attached screenshot).

Chrome PDF viewer does not have this issue 


Expected results:

text is represented and copied normally, without extra spaces rendered in 

p.s. is Bugzilla still the location for reporting Firefox PDF viewer issues ? 

I've seen https://github.com/mozilla/pdf.js/issues , but it seems like there are a lot of open issues on that project that aren't addressed. Maybe that's more of a prioritization and PM issue. 
It would be good to see some of these text rendering and copying issues addressed, if Mozilla is going to continue with the pdf.js project and PDF support in Firefox. 

Thanks for your work on this,
Bug: Removed One-Click Search Engines constantly readded after restart/relogin
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-06 20:02:24+00:00
Resolved: 2020-11-13 16:07:47+00:00

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

Steps to reproduce:

Bug looks very similar to Bug #1552559 and Bug #1544273, which were marked as resolved.

Under preferences --> search --> one-click search engines remove amazon, bing, duckduckgo, ebay and ecosia.
Then restart Firefox. Sometimes restarting is not sufficient to reproduce, but a relogin+restart always is.


Actual results:

The search engines ecosia, amazon and ebay are added automatically to the list, and the engine "leo.org GER-ENG" is moved to the last position of the list and has no visible icon.


Expected results:

Nothing, the search engines settings should stay as I set them.

I can reproduce the bug with a fresh, new profile, and even with a new user.

This happens on OpenSuse Leap 15.1 and 15.2. I already asked for help in a German forum, without result. Strangely, some users could reproduce, others couldn't: https://www.opensuse-forum.de/thread/64193-firefox-automatischer-reset-der-suchmaschinen-nach-login/
Bug: homepage url replaces search input while typing shortly after startup
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-06 21:04:28+00:00
Resolved: 2020-11-11 10:47: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:

With the address bar set for search and navigation I immediately start trying to type in a search after starting up firefox.


Actual results:

If I start entry before the homepage appears my entered text is replaced with the homepage url and my cursor moves to the front of the url, causing the text im still entering to show up before the https. 


Expected results:

The homepage url should not show up if I've already entered text.
Bug: Some widget moves are not recorded in telemetry
Status: NEW
Priority: P3
Created: 2020-11-07 00:40:33+00:00
Resolved: 2021-10-27 11:04:05+00:00

STR:

1. open new profile
2. open prefs, add searchbar into the toolbar
3. right click searchbar (on the border, to get the context menu for the item rather than the in-searchbar context menu)
4. "pin to overflow menu"

ER:
telemetry for the move

AR:
no telemetry, warning in the console: 

```
browser.ui.customized_widgets - The key length must be limited to 72 characters.
```
Bug: Tab does not exit search mode after a location change if it is switched away from quickly
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-11-07 12:39:47+00:00
Resolved: 2020-11-30 16:49:26+00:00

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

Steps to reproduce:

1. Open a new tab
2. Type a search keyword and a search term, e. g. `w test` (if w = Wikipedia)
3. Press <kbd>Enter</kbd>, then quickly switch to another tab in the same window, or open a new tab


Actual results:

After the search result page has loaded, the Awesome Bar shows the title of the search keyword next to an empty search field.


Expected results:

It should show the URL of the currently loaded page.
Bug: mouse hover selection highlight of Places contextmenu disappears (flickers)
Status: NEW
Priority: P3
Created: 2020-11-07 13:45:20+00:00
Resolved: 2023-06-02 15:20:10+00:00

Reproducible: always
  

Steps to reproduce:
1. Bookmarks menu open
2. Mouse hover on an bookmarks so that it will be highlighted
3. Right click on a bookmark so that places contextmenu will popup
4. Move mouse on to the context menu

Actual Results:
highlight disappears
See screencast https://youtu.be/6nSNNW__Qlk


Expected Results:
highlight should keep until mouse move to another menuitem
Bug: Firefox says I’m not connected to the internet but it let me search and visit the internet
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-11-07 17:15:51+00:00
Resolved: 2020-11-27 10:04:47+00:00

User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Mobile/15E148 Safari/604.1

Steps to reproduce:

Open Firefox and yesterday I synced a tab between firefox on ios and the one on my pc


Actual results:

Page loads but I can’t click any firefox button


Expected results:

firefox should work normally since I am connected to the internet
Bug: Some urlbar.picked.searchmode.* probes can record bogus data
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-11-07 22:57:07+00:00
Resolved: 2020-11-12 14:58:42+00:00

The `urlbar.picked.searchmode.*` probes are incremented when a result is picked and the Urlbar is in search mode. That check is made [here](https://searchfox.org/mozilla-central/rev/d6d8ea296d3560615f04ec3cc5538b827aa3151f/browser/components/urlbar/UrlbarController.jsm#553). Unfortunately, when a result that _enters_ search mode is picked, the Urlbar is already in search mode preview when we arrive at that line. A bogus entry is recorded. This affects:
`urlbar.picked.searchmode.tabtosearch`
`urlbar.picked.searchmode.tabtosearch_onboard`
`urlbar.picked.searchmode.keywordoffer`
`urlbar.picked.searchmode.topsites_urlbar`

I manually tested the other probes and they are unaffected. This includes `urlbar.picked.searchmode.shortcut`, which I understand is the one Product is most interested in. To fix this problem, we need to add a check that search mode is confirmed when those probes are incremented. I already have a patch ready.

~~Since users _must_ pick a result to trigger the `keywordoffer` and `topsites_urlbar` search mode entry points, they always record a bogus entry in their `urlbar.picked.searchmode.*` probe. Thus, we can find their true values by subtracting the summed value of their `urlbar.searchmode.*` equivalent (e.g. `sum(urlbar.picked.searchmode.keywordoffer) - sum(urlbar.searchmode.keywordoffer)`).~~

~~The true values of the tab-to-search probes are harder to discern. When the user tabs to the tab-to-search result and starts typing, we do not consider the tab-to-search result "picked" and so we don't record the bogus data. However if the user clicks the tab-to-search result or highlights it and presses Enter, the bogus data is recorded.~~

EDIT: The crossed out information above is inaccurate. See comment 5.
Bug: Remove tabindex="-1" from tab modal prompt `.infoBody`
Status: NEW
Priority: --
Created: 2020-11-08 03:20:30+00:00
Resolved: 2020-11-12 19:20:11+00:00

From Jamie in https://phabricator.services.mozilla.com/D61442:

> I think we should probably remove this tabindex. That will probably break a test, but I'd say  the test is probably wrong. I don't see any good reason for this to be focusable. That said, this would need to be tested to be certain. Just thought I'd flag this ASAP.


Without `tabindex="-1"` on `.infoBody`, these test failures happen:

* toolkit/components/prompts/test/test_modal_prompts.html 
`buttons don't focus on OS X, but infoBody does instead - got null, expected "infoBody"`

* accessible/tests/mochitest/relations/test_ui_modalprompt.html
`Test timed out.`

`outline: none; `on `.infoBody` was added along with the `tabindex="-1"` (still can't remember why the CSS rule was useful, though I think it was platform specific?). It may be removable here too, along with the tabindex.

For more context, the modal can be triggered from `alert`/`prompt`/`confirm` JS functions, and `.infoBody` is the modal text.
Bug: Can't delete default search engine (Amazon) after updating Firefox
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-08 05:58:46+00:00
Resolved: 2020-11-13 16:09:02+00:00

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

Steps to reproduce:

Auto-updated Firefox to the latest version 82.0.2


Actual results:

After updating Firefox I noticed two new (default) search engines appeared in my search bar: Amazon and eBay. I had previously deleted/removed these default engines (and all other default engines) and replaced all of them with custom search engines. None of the custom engines had identical names to the default engines.

I proceeded to remove the two "new" engines (eBay and Amazon) and restart Firefox. 

However the Amazon engine will NOT be removed. It re-appears after I restart the browser. 

I decompressed `search.json.mozlz4` and notice that it DOES say "hidden: true" against the Amazon entry so I have no idea why this is happening.


Expected results:

My search engines should have been left well alone!
Bug: Default search engines were restored/un-hidden after updating Firefox
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-08 06:00:42+00:00
Resolved: 2020-11-13 16:11:21+00:00

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

Steps to reproduce:

Updated Firefox to the latest version 82.0.2.


Actual results:

Two default search engines which I had previously removed (Amazon and eBay) suddenly re-appeared in my search engine list after the update.


Expected results:

My list of visible search engines should not have been modified.
Bug: Searching empty strings does not work anymore
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-11-08 08:57:00+00:00
Resolved: 2024-04-28 20:20:48+00:00

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

Steps to reproduce:

Up till I updated to 83.0b6-1 (on Linux Manjaro), I would often go to the homepage of search engines just by typing its assigned name and hitting enter. (e.g. for YouTube I would type 'y' then 'enter').


Actual results:

Now what happens when I do that is that it either goes to the first website which begins with the name of the search engine in my bookmarks or it searches the string.


Expected results:

Well, before it would go to the homepage of the website. Now it seems when I hit "space" after the name of the search engine, a blue box with the selected engine appears. So I think it'd be neat if, once that blue box appears, hitting enter without any additional input would go to the homepage of the search engine (or search with %s replaced by an empty string or something like that, which I guess should redirect to the home page for most websites). (So, to keep my example, I'd say typing "y" then "space" then "enter", if "y" is the name of youtube.com, would go to youtube.com)
Bug: Removing a substantial amount of downloads takes unreasonably long
Status: NEW
Priority: P3
Created: 2020-11-08 09:28:44+00:00
Resolved: 2025-03-02 14:51:43+00:00

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

Steps to reproduce:

When using the "Clear Downloads" button in the "Downloads" Library to clear a large amount of downloads at once (>10000) is way too slow (this is on a Ryzen 5 with PCIe SSD).

During that time, all Firefox windows are not responding. After Firefox starts responding again, it is very slow for another two minutes or so.

Removing the downloads from the Library takes more than an order of magnitude longer than physically deleting those files from disk. It seems that something here scales linearly (or even hyperlinearly), even though it really shouldn't. Maybe Firefox is flushing sort sort of transaction cache for each individual download.