av9ash/GitBugs huggingface dataset:
Bug: The strings from the operating system’s authentication dialog are not localized
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-03-18 13:00:46+00:00
Resolved: 2020-04-29 19:17:22+00:00

[Affected versions]:
- Firefox Nightly 76.0a1 (Build ID: 20200313095322)

[Affected Platforms]:
- Windows 10 x64;
- Mac 10.14;

[Prerequisites]:
- Have a profile with at least one saved login.
- Have an OS password set.
- Have the OS language set in a different language (eg: DE).
- Have the Nightly de build extracted or installed.

[Steps to reproduce]:
1. Open the latest Nightly Firefox browser de build.
2. Navigate to the "about:logins" page and select a saved password.
3. Click on the "Show Password" button from the login item.
4. Observe the operating system’s authentication dialog.

[Expected result]:
- All the strings are localized.

[Actual result]:
- Windows: The "Verify your identity to reveal the saved password" text is not translated.
- macOS: only the "reveal the saved password" text is not translated.

[Notes]:
- The issue is also reproducible when the "Copy" or "Edit" button is clicked.
- The issue is also reproducible if trying to check the "Use a master password" option from "about:preferences#privacy" page.
- I have tested this only on DE and es-ES languages.
- Here is a screenshot with Windows DE language: [link](https://drive.google.com/open?id=1QIDwPfMY25qtxzW5hXQRwGNWsBPKpJWO).
- Here is a screenshot with Windows es-ES language: [link](https://drive.google.com/open?id=1YbvPINQAK5v5RYSFrP8EsXxKklUGRWSk).
- Here is a screenshot with Mac OS DE language: [link](https://drive.google.com/open?id=1aX755QLrhE_UE2PhNX4qniltSq3xKnBz).
Bug: Firefox Sync clears most bookmark folders
Status: UNCONFIRMED
Priority: P4
Created: 2020-03-18 13:53:36+00:00
Resolved: 2022-10-12 00:04:34+00:00

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

Steps to reproduce:

Sign into my Firefox Sync Account. 



Actual results:

After a few moments all my bookmarks that are in a sub-folder are lost. The folder structure itself stays in tact.

I could restore my bookmarks from before I signed into Sync (from yesterday). I tried a few times, but result is always the same!


Expected results:

Do not delete all my bookmarks when syncing!

Please note: I am using Firefox on Ubuntu for more than 10 years now and am a Sync user since the beginning.
Bug: Remove about:library stub page
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-03-18 13:55:34+00:00
Resolved: 2020-03-20 15:06:23+00:00

The stub was added 2 years ago. Since then, we've repeatedly thought that we'll do something there "soon", and it's repeatedly not happened. If/when we do, people can just revert the commit removing this page. In the meantime, we shouldn't be shipping something unusable to people.
Bug: url cut
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-03-18 16:09:34+00:00
Resolved: 2020-04-13 18:42:19+00:00

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

Steps to reproduce:

Art. 35 del Decreto Nazionale 2 Marzo 2020 n° 9)
https://www.gazzettaufficiale.it/…/id/2020/03/02/20G00026/sg
the ... is cutting url. (url size is max 4kb) the domain name is 128max char length, mail is 128@128 max length file name is ./128/128.128 char


Actual results:

insert ./.../ this create a bad url. use a full text
Bug: Firefox theme changes autmatically when I drag & drop out of Firefox to make a new window
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-03-18 16:32:40+00:00
Resolved: 2020-04-10 13:39:20+00:00

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

Steps to reproduce:

I drag and drop a tab to generate a new window


Actual results:

The active theme automatically changed to another one that I haven't installed. When I checked Theme in Add-ons manager, it shows the theme I selected originally as active but the actual theme in Firefox is totally different. I tried, refreshing firefox too. Still same issue.


Expected results:

The active theme stays as it as.
Bug: Removing a container doesn't work
Status: NEW
Priority: P3
Created: 2020-03-18 20:00:35+00:00
Resolved: 2020-05-12 00:06:36+00:00

When I click "Remove" on a container I get message that says:
"If you remove this Container now, 2 container tabs will be closed. Are you sure you want to remove this Container?" I choose "Remove Container" but then nothing happens. The container tabs are not closed.
Bug: Cannot screenshot some websites [e.g. Tantek.com homepage]
Status: RESOLVED
Priority: P4
Resolution: WORKSFORME
Created: 2020-03-18 21:12:32+00:00
Resolved: 2024-05-09 20:04:30+00:00

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

Steps to reproduce:

Visit Tantek.com, click elipsis, screenshot, full-page.


Actual results:

Nothing happens. No errors, no messages. Nada


Expected results:

Either take screenshot or give me an error code / reason why; in a way that: 

I understand what I've done
I understand what Tantek has done
I understand what has gone wrong
Bug: Back button never gets disabled / greyed-out in a new window.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-19 01:24:51+00:00
Resolved: 2020-04-29 19:40:36+00:00

Just updated to build 20200318213346

The back button in a new window will never get disabled.

STR:
Open a new window (Ctrl-N or Command-N)
type: google.com
Press the back button

What happens: the back button is still active. You can still press back many times 

What should happen: the back button should be greyed after the 1st click.
Bug: Firefox Crashed when visiting long url
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-03-19 03:53:49+00:00
Resolved: 2020-04-09 17:40:11+00:00

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

Steps to reproduce:

When the User visiting very long URL the Firefox gets crashed and no activity can be done at the time 


Actual results:

Firefox browser crashed 
Takes full computer Power



Expected results:

When visiting the very large URL it should be rejected
Bug: Security Key prompt triggers focus request on every window
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-03-19 05:36:32+00:00
Resolved: 2020-06-20 16:26:54+00:00

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

Steps to reproduce:

Open multiple firefox windows
Login into a site that requires touching your security key (like gmail or github)



Actual results:

Once the prompt triggers, every window will request focus


Expected results:

Only the window that has the tab requesting the security key press should request focus
Bug: General Preference > Applications option "Do this Automatically for files like this from now on" not respected
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-19 06:00:07+00:00
Resolved: 2020-04-28 01:10:28+00:00

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

Steps to reproduce:

Set Application preference for WAV file to use QuickTime and selected "Do this Automatically for files like this from now on".


Actual results:

When opening WAV file, e.g. via email (Yahoo), Firefox DOES open the file with QuickTime BUT selecting the "Do this Automatically for files like this from now on" choice is not respected...the dialogue box keeps coming up. 

(this has been going on for several versions)


Expected results:

Selection this option should remember the choice and automatically open the file with the selected application.
Bug: Distribution engines are not being marked as built-in engines (reappear after each update)
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-03-19 11:33:51+00:00
Resolved: 2020-04-01 13:58:38+00:00

Distribution engines are currently not being marked as built-in.

We regressed this here in bug 1405670 (the changes in the two sections after the highlights):

https://searchfox.org/mozilla-central/diff/47b9babf07b15b7bb6f7e873c87cd2ceddd1d4ec/toolkit/components/search/nsSearchService.js#3383,3408

The main effect of this, is that if the user removes a built-in engine that has been added or modified by a distribution, then we'll re-add it after update.

STR

1. With a Firefox distribution that is 59 or later, set up a profile, and remove one of the search engines that the distribution alters/adds.
2. Upgrade to the same Firefox distribution that is based on 69 or earlier (69 has another bug that makes things worse).

Actual Results

The engine that was removed re-appears.

Expected Results

The engine that was removed stays hidden.
Bug: Search Engine Cache corruption detection is incorrectly handling distributions
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-19 11:35:17+00:00
Resolved: 2020-03-30 09:15:20+00:00

After doing some detailed analysis of the telemetry data we're receiving about cache corruption, I realised that we are always detecting distributions as having corrupt caches. This is because of two reasons:

* Distribution engines are loaded separately from the legacy config, so we don't know how many engines would be loaded when we check the cache. As a result, the distribution is likely to have more engines than we expect, and therefore we think the cache is corrupt.
* Distribution engines are not being marked as built-in. This will also potentially confuse the detection, as we're comparing built-in engines only (bug 1623597)

There's a couple of adverse effects as a result of this:

* We'll be rebuilding the search engine cache every start-up, which may affect start-up performance (though I expect the effect to be small).
* If the user removes an engine that is added or altered by the distribution, this setting will not be preserved.

I'm going to handle the cache detection issue in this bug. The built-in issue I'll handle in bug 1623597, since I think that needs a little bit of its own focus to ensure there's no separate issue with that.
Bug: URL Spoofing using LATIN SMALL LETTER L WITH STROKE ( ł )
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-19 15:10:23+00:00
Resolved: 2023-05-23 04:28:59+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Go to https://googłe.com/


Actual results:

It showed the URL https://googłe.com/ spoofing URL of google.com


Expected results:

it should be converted into punnycode.
Bug: Replace #d74345 with an accessible CSS variable
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-03-19 16:47:48+00:00
Resolved: 2020-03-26 12:56:31+00:00

https://searchfox.org/mozilla-central/search?q=color%3A+%23d74345%3B&case=false&regexp=false&path=

It should be a CSS variable with accessible colors for each theme. For `#d74345`, the dark theme contrast is 2.00 and the light theme contrast is 4.39 (checked using the a11y inspector), while the WCAG standards asks for at least 4.5 for normal text, 3 for large text.
Bug: String encoding issues in the Lockwise OS authentication dialog on Windows
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-19 17:42:37+00:00
Resolved: 2020-03-26 09:07:41+00:00

From https://bugzilla.mozilla.org/show_bug.cgi?id=1194529#c24,
"the Italian version of Windows/Firefox shows strange chars in the authentication window."

See attached screenshot.
Bug: Intermittent TEST-UNEXPECTED-TIMEOUT | browser/components/fxmonitor/test/browser/browser_fxmonitor_doorhanger.js | application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-03-19 19:55:30+00:00
Resolved: 2020-04-14 17:04:35+00:00

**Filed by:** cbrindusan [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=293878261&repo=mozilla-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NmAxZKKTTIONvZSHqNUPHA/runs/0/artifacts/public/logs/live_backing.log

---

[task 2020-03-19T16:09:55.099Z] 16:09:55     INFO - TEST-START | browser/components/fxmonitor/test/browser/browser_fxmonitor_doorhanger.js
[task 2020-03-19T16:09:55.665Z] 16:09:55     INFO - GECKO(2952) | ###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
[task 2020-03-19T16:16:05.665Z] 16:16:05     INFO - Buffered messages logged at 16:09:55
[task 2020-03-19T16:16:05.665Z] 16:16:05     INFO - Entering test bound test_main_flow
[task 2020-03-19T16:16:05.665Z] 16:16:05     INFO - Test that we show the first alert correctly for a recent breach.
[task 2020-03-19T16:16:05.665Z] 16:16:05     INFO - Buffered messages finished
[task 2020-03-19T16:16:05.665Z] 16:16:05    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/components/fxmonitor/test/browser/browser_fxmonitor_doorhanger.js | application timed out after 370 seconds with no output
Bug: Allow the setting (and locking) of the default Autoplay value
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-03-19 20:23:59+00:00
Resolved: 2020-04-28 13:03:47+00:00

In bug 1588197 we added support for enabling autoplay for domains, but we didn't provide a way to set the global default.

We should add that.
Bug: Dynamic price index on exchanges charts based on tradingview.com is misplaced
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-03-19 20:47:28+00:00
Resolved: 2020-11-04 13:54:29+00:00

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

Steps to reproduce:

Just visit the following exchanges, whose trading charts are based on the tradingview.com engine:
https://www.bitstamp.net/market/tradeview/
https://www.pionex.com/en-US/trade/BTC_USDT/pionex.v2


Actual results:

The price index, which moves dynamically up or down depending on the current value, is on top of its framing box.


Expected results:

The price index should be displayed inside its defined box.
Note that this does not happen on tradingview.com website itself.
Bug: Remote debugging over USB shows "Waiting for browser..."
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-03-19 20:59:26+00:00
Resolved: 2020-04-29 19:17:41+00:00

Steps to reproduce:

1. Open Firefox 68.6.0 on an Android device (in my case, a Pixel 2 running Android 10) with USB debugging enabled.
2. Connect it to with a USB cable to a desktop/laptop running Firefox 74.0.
3. Enter "about:debugging" in the URL bar in Firefox 74.0.

The left side of the window shows "Waiting for browser..." as shown in the attached screenshot.

This problem has also been reported on [Stack Overflow](https://stackoverflow.com/questions/59807976/remote-debugging-over-usb-with-android-phone-is-stuck-in-waiting-for-browser).
Bug: 2.78% - 13.52% tp5n nonmain_normal_fileio (windows10-64-shippable) regression on push 1692426a9549efd97f3241b8fc314eac0786a750 (Mon March 9 2020)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-03-20 06:06:25+00:00
Resolved: 2020-04-08 19:09:10+00:00

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=718652138136a4e4903197925698b752a5c793b6

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

[Compare view](https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=ad7d0f8b2d3a56556a3e27859b1dfcef28b70f6c&newProject=try&newRevision=087c62614c5913ca3f83a8aa6fe1d604148fa4f7&framework=1#table-header-3462712076)


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=25297

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://wiki.mozilla.org/TestEngineering/Performance/Talos

For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/TestEngineering/Performance/Talos/Running

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/TestEngineering/Performance/Talos/RegressionBugsHandling
Bug: Lost identifiers on one peripheral but not others [Solved]
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-03-20 08:51:49+00:00
Resolved: 2020-03-24 11:02:33+00:00

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

Steps to reproduce:

I have several peripherals with synchronized firefox : laptop (Ubuntu 1804), computer (Windows 10), smartphone (Android).
Yesterday, on my laptop, Firefox Sync asked me to reconnect with my  account, what I did.


Actual results:

All my identifiers have disappeared on my laptop, but are still present on my computer and smartphone. Only identifiers are concerned. I still have bookmarks and historic on laptop.
Even after manual synchronization, I am not able to recover identifiers on my laptop.
Synchronization between my peripherals is working since this connection. When I add a new identifier/password, all peripherals receive it. So my laptop have several identifiers, but lost all previously recorded identifiers.


Expected results:

Synchronization should recover previously recorded identifiers on my laptop
Bug: Gmail is only showing my Inbox when using Firefox but fine in Chrome
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-03-20 10:15:07+00:00
Resolved: 2020-03-25 14:26:50+00:00

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

Steps to reproduce:

Just opened Firefox on my Macbook and started gmail.


Actual results:

My normal gmail desktop has been replaced with just the contents of my Inbox only (as file attached)


Expected results:

Should have seen gmail desktop. (Which is still working in Chrome).
Bug: [macOS] The operating system’s authentication dialog can't be accepted if the OS doesn't have any password set
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-20 11:26:35+00:00
Resolved: 2020-03-31 13:02:54+00:00

[Affected versions]:
- Firefox Nightly 76.0a1 (Build ID: 20200319215651)

[Affected Platforms]:
- Mac 10.15.3
- Mac 10.14.6 

[Prerequisites]:
- Have a profile with at least one saved login.
- No OS password is set.

[Steps to reproduce]:
1. Open the latest Nightly Firefox browser.
2. Navigate to the "about:logins" page and select a saved password.
3. Click on the "Show Password" or "Copy" or "Edit" button from the login item.
4. Observe the behavior.

[Expected result]:
- The password is shown or copied or the edit more is opened without entering any password.

[Actual result]:
- The operating system’s authentication dialog is displayed even if no OS password is set.

[Notes]:
- The issue is also reproducible if trying to check the "Use a master password" option from "about:preferences#privacy" page.
- The OS auth is triggered and the "OK" button is clicked two times, the dialog is dismissed. However, this doesn't happen if an OS password is set. This behavior can be observed in the screen recording added bellow. 
- No errors are displayed in the browser console.
- This issue is no longer reproducible on Windows.
- Attached a screen recording with the issue: [link](https://drive.google.com/open?id=13FB54xqZ04jZ9-a3UskR-nF4X1im9WvP).
Bug: No “Recommendation” button displayed on https://www.cnn.com when accessing a random article
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-20 13:08:35+00:00
Resolved: 2020-03-30 21:59:54+00:00

*Affected versions*
* 76.0a1 (20200320095353)
* 75.0b6 (20200319224147)
* 74.0 (20200309095159)

*Affected platforms*
* Windows 10 x64
* Ubuntu 18.04
* macOS 10.15


*Steps to reproduce*
1. Open Firefox with a new profile and go to https://www.cnn.com. 
2. Choose a random link and click on it.


*Expected result*
* The “Recommendation” button is displayed. 

*Actual result*
*  No “Recommendation” button is displayed.

*Regression Range*
* I will search for one ASAP if there is one

*Notes*
* Attached a screen recording with the issue.
* If outside us the cnn.com is redirected to https://edition.cnn.com/ wich is not working as well.
* With a VPN connection to the US and accessing https://www.cnn.com and a random article the “Recommendation” button is still not displayed.
Bug: URL spoof: RTL character in URL flips domain and path if domain contains no directional characters (e.g. ip address)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-03-20 13:37:29+00:00
Resolved: 2024-05-30 17:12:44+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

1) Post the following link in the status bar: 127.0.0.1/ا/http://attack.com





Actual results:

You would notice that the URL has been flipped from Right to left and the status bar dispays http://attack.com/‭ا/127.0.0.1 while it displays the content from the IP address.


Expected results:

Ip address should be shown first.
Bug: The CFR button is not minimized when clicking the 'Not Now' option
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-20 14:26:57+00:00
Resolved: 2020-04-03 08:53:30+00:00

**Affected platforms**
* Windows
* Ubuntu
* macOS

**Steps to reproduce**
1. Launch Firefox.
2. Trigger the CFR addon recommandation.
3. Click the 'Not Now' option displayed on the doorhanger.

**Expected result**
* The doorhanger is dismissed and the CFR button is minimized, but still displayed.

**Actual result**
* The CFR button is not minimized.

**Regression range**
* Last good revision: e1a3a62f20351336f9afbcd3df26996b2acc14ae
* First bad revision: 532b71703571a8a65e58330208afa0b28febfba8

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e1a3a62f20351336f9afbcd3df26996b2acc14ae&tochange=532b71703571a8a65e58330208afa0b28febfba8

**Additional notes**
* This issue occurs for the CFR pin tab recommandation as well.
Bug: network.proxy.backup.socks breaks proxy dialog
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-20 15:36:40+00:00
Resolved: 2020-04-02 15:31:48+00:00

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

Steps to reproduce:

In a pretty old Firefox profile on my work PC when I go to settings/network and in the proxy dialog choose manual settings I can't fill in the socks proxy settings: when I start typing the letters disappear instantly.

I had to go to about:settings and reset each and every setting to default until I found that deleting these two actually helps:

    network.proxy.backup.socks=""
    network.proxy.backup.socks_port=0

I never edited these settings manually before. However I did have Frigate installed in the past.

See this forum topic for additional info: 
http://forums.mozillazine.org/viewtopic.php?f=38&t=3060066&p=14860356#p14860356



Actual results:

letters disappear


Expected results:

The remnants of uninstalled addons like network.proxy.backup.socks should not break typing in the proxy dialog.