av9ash/GitBugs huggingface dataset:
Bug: Potential race condition between Normandy timer and Normandy initialization
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-02-01 17:30:13+00:00
Resolved: 2024-05-31 15:29:44+00:00

We have been having problems that seem like recipes are running before Normandy proper has initialized. Specifically, during Normandy initialization, the values of default prefs are updated to match their rollout and experiment values. We are getting unenrollments from recipes that seem to imply this happens, and [it happens more on computers with fewer CPU cores and slower drives](https://metrics.mozilla.com/protected/tdsmith/2021-01-29_normandy-unenrollment-perf.html).

The Normandy RecipeRunner runs in response to 3 things:

1. When it is first initialized in some cases, which is strictly after Normandy initializes
2. After RemoteSettings syncs (delayed up to 60 minutes), which is not strictly ordered to be after Normandy initialization
3. When Firefox's update timer procs and calls the recipe runner.

Third third is the one that I expect is getting us most often, since the first is only called synchronously after prefs are applied, and it should be too uncommon for the random delay on the second to be fast enough to cause this problem in the volume we see.

I expect this will fix bug 1663971, but I'm making a separate bug since we aren't sure of the cause of that bug yet, and this may not fix it.
Bug: Consistently delete all update data on uninstall, but leave configuration data on install
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-01 18:51:37+00:00
Resolved: 2024-08-09 09:24:18+00:00

It seems that when a paveover install is performed, we only delete the update directory if the "updates" subdirectory exists. We should probably be consistent about this and either always delete it or always leave it, otherwise we aren't consistent about whether or not we reset the update configuration.
Bug: Intermittent [tier2] TV browser/base/content/test/general/browser_bug676619.js | file name should match (link14) - Got "dummy.not-pdf", expected "dummy.pdf"
Status: RESOLVED
Priority: P5
Resolution: INVALID
Created: 2021-02-01 19:52:22+00:00
Resolved: 2021-02-08 06:17:58+00:00

**Filed by:** abutkovits [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=328480486&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/czgWT-6LRzC7TJz-y15gvA/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/czgWT-6LRzC7TJz-y15gvA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2021-02-01T19:47:32.740Z] 19:47:32     INFO - TEST-PASS | browser/base/content/test/general/browser_bug676619.js | Download page appeared - 
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - TEST-PASS | browser/base/content/test/general/browser_bug676619.js | beforeunload shouldn't have fired - "Okay" == "Okay" - 
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - Buffered messages finished
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug676619.js | file name should match (link14) - Got "dummy.not-pdf", expected "dummy.pdf"
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - Stack trace:
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - chrome://mochikit/content/browser-test.js:test_is:1351
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug676619.js:testLink:48
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - Checking link14 with name: dummy.not-pdf
[task 2021-02-01T19:47:32.741Z] 19:47:32     INFO - Download window shown...```
Bug: window.focus() not working after window.open() using already open named window
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-02-01 20:35:02+00:00
Resolved: 2021-02-08 13:00:57+00:00

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

Steps to reproduce:

Use the link on the following/attached page to launch a page in a new named window/tab. https://www.jeffersonscher.com/res/focusnamedtab.html Returned to the page and clicked the link again. 


Actual results:

The window.focus() function did not work.


Expected results:

Prior to Firefox 85, window.focus() worked in this scenario. Mozregression points to:

Bug 1679456 - Consume user activation on popup opening and remove popup opening tokens.

I suspect this is the issue in a WordPress Editor Preview problem flagged by a user on SUMO: https://support.mozilla.org/questions/1324139

Thanks.
Bug: Updating the Search Engine Name doesn't work from an add-on
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-02-01 21:47:59+00:00
Resolved: 2023-12-12 20:27:45+00:00

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

Steps to reproduce:

Step 1: Have a searchprovider with a name: WebSearch1
Step2: Update the name of searchProvider to WebSearch2


Actual results:

The extension fails and after restart defaults to google search


Expected results:

Should have worked with name as WebSearch 2

After debugging the ff code found that in SearchServices.jsm the code searches for the searcheengine based on the key and any update on engine name does not change the key and only the _name inside values
Bug: Intermittent TEST-UNEXPECTED-TIMEOUT | browser/base/content/test/tabs/browser_viewsource_of_data_URI_in_file_process.js | application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-02-01 23:24:18+00:00
Resolved: 2023-06-07 12:02:26+00:00

**Filed by:** abutkovits [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=328493632&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/L5tKTN_gTDm55cnODx52wQ/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2021-02-01T22:39:14.309Z] 22:39:14     INFO - TEST-START | browser/base/content/test/tabs/browser_viewsource_of_data_URI_in_file_process.js
[task 2021-02-01T22:45:33.972Z] 22:45:32     INFO - Buffered messages logged at 22:39:14
[task 2021-02-01T22:45:41.428Z] 22:45:40     INFO - Entering test bound 
[task 2021-02-01T22:45:44.029Z] 22:45:42     INFO - Buffered messages finished
[task 2021-02-01T22:45:49.167Z] 22:45:48    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/base/content/test/tabs/browser_viewsource_of_data_URI_in_file_process.js | application timed out after 370 seconds with no output
[task 2021-02-01T22:45:54.453Z] 22:45:53    ERROR - Force-terminating active process(es).```
Bug: about:restartrequired doesn't clear after restarts (in fission)
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-02-02 02:16:21+00:00
Resolved: 2021-04-13 15:12:53+00:00

about:restartrequired?e=restartrequired&u=about%3Ablank&c=UTF-8&d=%20 stays visible in the select tab after selecting Restart Nightly.  I am able to open a new tab and browse with it.

Using fission, on mac.  There was another nightly instance running in a different profile at the start.  I exited that, no change in behavior.  I opened About Nightly, and let it download and apply an update, and there was no change.

Not sure fission is a cause here
Bug: us bank log in failure
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-02 02:59:49+00:00
Resolved: 2021-02-11 11:06:07+00:00

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

Steps to reproduce:

0a. Last week with V84.0.2 I was able to log into usbank.com.
0b. Updated to V85 some time after last usbank visit.
************
1. Went to usbank.com today
2. Entered saved log in information
3a.  First, third and fourth time: PW or Username incorrect
3b.  Second time: usbank website spinning wheel for 3 minutes, refreshed, same, waited 5 mins, refresh, same.
4. Hand entered username and password from cheat sheet.
5. PW or username not valid.
6. Opened Safari 12.1.2
7. Went to usbank.com
8. Hand entered username and password (never saved in Safari, so not automatic).
9.  I was able to log on instantly.


Actual results:

Was not able to log into usbank using FF
WAS able using Safari.


Expected results:

log into usbank with FF
Bug: Firefox 85 Can no longer invoke the browse for file dialog box in any web app
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-02 03:38:22+00:00
Resolved: 2021-02-15 13:31:45+00:00

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

Steps to reproduce:

This occurs in the most recent version of firefox (85) on Ubuntu with 20.10 with budgie desktop environment.

This behavior is confirmed in any web application featuring a browse button I have tried: sabnzbd and the transmission bittorent web interface as we the "browse" button on the bug submission form in bugzilla.

Sabnzbd: 1.) Click the Add NZBD button
2.) Select "browse" 

Transmission: 1.) Click the "folder" in the top left to open a torrent
2.) Select the "browse" button




Actual results:

No Dialog opens that would allow you to select a file


Expected results:

Typically a dialogue box would appear allowing you to browse for a file
Bug: Proton Tab Styling Conflicts with Container Tabs Indicator
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-02-02 04:15:27+00:00
Resolved: 2021-03-28 10:12:27+00:00

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

Steps to reproduce:

Enabled Container Tabs through one of the many different addons.


Actual results:

The Proton Tab subtext has insufficient padding when the coloured container tabs indicator is enabled.


Expected results:

Sufficient padding be present between the media status subtext and the container tabs indicated
Bug: FIrefox 85 blocking safe sites
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-02 05:47:22+00:00
Resolved: 2021-03-26 13:27:50+00:00

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

Steps to reproduce:

Firefox updated on January 28, 2021.  Since then some of my safe usual sites like https://gallica.bnf.fr/accueil/fr/content/accueil-fr?mode=desktop and https://cnrtl.fr/ have stopped working in Firefox 85


Actual results:

I have tested said sites with Opera Browser & Epic Browser.  The sites are working fine. These browsers are on the same computer.


Expected results:

The site should have opened normally and allowed me to work on my research projects.
Bug: TypeError: can't access property "uninit", this._router is null
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-02-02 11:05:12+00:00
Resolved: 2021-02-05 09:40:19+00:00

> JavaScript error: resource://activity-stream/lib/ASRouterNewTabHook.jsm, line 61: TypeError: can't access property "uninit", this._router is null
Bug: Existing Basic Auth popup prevents others from appearing
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-02 11:18:30+00:00
Resolved: 2021-03-17 10:59:05+00:00

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

Steps to reproduce:

1. Open https://www.httpwatch.com/httpgallery/authentication/ twice
2. Click "Display Image" on the first
3. Observe that the basic auth prompt pops up. 
4. Go to the second tab
5. Click "Display Image"
6. Observe that nothing happens


Actual results:

No basic auth prompt pops up


Expected results:

Basic auth prompt should have popped up.

If you have two separate pages with basic auth, opening the first but leaving the request causes the second page's request to not appear until the first's is cancelled  or entered. This is my real concern, but I don't know of two separate public-facing pages with basic auth.
Bug: Jiangmin on VirusTotal detected TrojanDropper.Autit.ra in stub installer
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-02 15:22:35+00:00
Resolved: 2021-03-29 22:36:27+00:00

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

Steps to reproduce:

I downloaded Firefox Installer.exe and ran it through https://www.virustotal.com/ 


Actual results:

Virus Total flagged it, identifying TrojanDropper.Autit.ra in the file.


Expected results:

There should not have been anything flagged.
Bug: Extension Management via Group Policy: "This field can contain a maximum of 2048 characters per line."
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-02 15:25:31+00:00
Resolved: 2021-02-03 15:09:51+00:00

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

Steps to reproduce:

In the Group Policy Management Editor, I browse to the administrative template we have installed for Mozilla Firefox, to add an extension to the Extension Management GPO:

Computer Configuration > Policies > Administrative Templates > Mozilla > Firefox > Extensions > "Extension Management"

We have the setting "Enabled" with numerous extensions defined in the appropriate JSON format. The setting is functional, with everything we've defined so far appropriately enforced by the policy. Some extensions are forced install, while numerous others are allowed install.

We have apparently reached an undocumented/unforeseen limitation of the policy setting in question.



Actual results:

Upon trying to add another allowed extension to the policy object, I am given this error upon trying to apply:

"This field can contain a maximum of 2048 characters per line. Make sure that you enter 2048 or fewer characters per line."

I have tried to reformulate the contents of the setting in such a way that each extension is on its own line, but this yielded the same error.


Expected results:

The setting should be able to handle unlimited characters, so that we can continue to add extensions to the policy as needed.
Bug: Printing wrong characters to PDF from message from Outlook365
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-02 15:34:16+00:00
Resolved: 2021-02-05 10:12:47+00:00

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

Steps to reproduce:

After the update of Firefox 85.0 (MacOS, Mojave) I have the problem that the title of Outlook365, including text "To:" and "From:" messages are not printed correctly to PDF (rectangular characters). Reinstalling Firefox 84.0.2 fixed the problems. Continuing with Firefox 85.0 again returns the problems again.
Bug: The option to show bookmark only in the new tab page doesn't work if a blank page is set as the new tab page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-02 16:28:10+00:00
Resolved: 2021-02-09 19:13:30+00:00

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

Steps to reproduce:

1. Set the bookmark bar to appear only in the new tab page
2. Change the new tab screen to a blank page


Actual results:

Bookmark bar doesn't show up.
Bug: Remove checks for exposure ping and allow it to be sent multiple times
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-02-02 16:28:35+00:00
Resolved: 2021-02-10 03:42:20+00:00

Exposure ping should be sent every time feature branch is requested.
See https://jira.mozilla.com/browse/CIRRUS-50
Bug: [RTL] The skeleton UI placeholder animations should flow from the right to the left
Status: NEW
Priority: P3
Created: 2021-02-02 16:53:04+00:00
Resolved: 2021-02-11 17:15:16+00:00

STR:
1. Enable skeleton UI
2. Set `intl.l10n.pseudo` to `bidi`
3. Restart Nightly
4. While the skeleton UI appears, notice the placeholders animation flow.

ER:
It should flow from the right to the left.

AR:
From the left to the right.
Bug: Simplify the Web Developer menu
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-02-02 17:46:28+00:00
Resolved: 2021-03-08 09:18:13+00:00

I believe this is something that can ship pre-Proton. The DevTools menu is a bit special - it constructs itself dynamically, inserting `<xul:menuitem>` elements at runtime into the `menuWebDeveloperPopup` popup defined here: https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/browser/base/content/browser-menubar.inc#410-414

Interestingly, the "Page Source" item is baked into that popup to begin with, and our DevTools code knows how to put it in the expected position: https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/devtools/client/framework/browser-menus.js#269-274

What we need to do is dramatically pare down the Web Developer menu. Specifically, we're going to be removing all of the menuitems for the various individualpanels of the DevTools toolbox.

I can imagine, however, that we'll want to keep the keyboard shortcuts for those panels around. That might involve putting `<key>` elements for those menuitems we're removing into the mainKeySet instead: https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/browser/base/content/browser-sets.inc#124

The new contents of the menu should be:

```
Web Developer Tools
Remote Debugging
Browser Toolbox (if enabled)
Browser Content Toolbox (if enabled)
Browser Console
Responsive Design Mode
Eyedropper
Page Source
Extensions for Developers
```

So, things to do here:

1. Port the necessary DevTools strings to Fluent, forking them so that we have a set for the menubar, and a set for panels.
2. Change the "Toggle Tools" strings to "Web Developer Tools".
3. Remove the Inspector, Web Console, Debugger, Network, Style Editor, Performance, Storage Inspector, Accessibility, Application and DOM menuitems from the list. Also remove the separators. This will likely involve changing how they're dynamically inserted (see above). We should try to keep the keyboard shortcuts around, however, by adding key commands to the mainKeySet.
4. Update the "Get More Tools" strings to be "Extensions for Developers"

Remember when updating strings to ensure that they're not re-used elsewhere - if so, double-check that the propagated change is acceptable with UX, or create a new string just for the menu.

Also remember that if you're updating a string, you still have to update the ID of it so that our localizers know to re-translate.

Naturally, any tests that rely on the old structure or old behaviours will need to be modified as well.
Bug: updateFxaToolbarMenu touches the DOM between 2 style flushes
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-02 19:23:54+00:00
Resolved: 2021-02-26 09:46:02+00:00

See this profile of opening a new window: https://share.firefox.dev/2MOfObn

Focusing the url bar triggers a sync style flush (see bug 1445811 for what we could do about it), then `updateFxaToolbarMenu` makes the DOM dirty by calling `Element.setAttribute` and then we flush styles again during the refresh driver tick.

Without knowing anything about what the FxA code is trying to do, it feels like swapping these 2 lines would save us a style flush: https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/browser/base/content/browser.js#1768,1770

Looking at the code actually setting an attribute (https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/browser/base/content/browser.js#699) I wonder if this attribute really needs to be set dynamically or if it could be in the initial markup of browser.xhtml.
Bug: Proton tab-strip changing size when in customize-mode
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-02-02 19:24:05+00:00
Resolved: 2021-03-17 13:36:05+00:00

STR:
1. Open the app-menu and click customization

**Expected result:**
Tab-strip should have the same height as before

**Actual result:**
Tab-strip gets slightly smaller
Bug: It's hard to see which page is the current page in the PDF sidebar
Status: REOPENED
Priority: P1
Created: 2021-02-03 02:46:18+00:00
Resolved: 2023-06-02 15:21:02+00:00

The only indication of the current page is a slightly darker grey outline on a light grey background. I find this hard to see.  I'm attaching a screenshot comparing Firefox (left) with Chrome (right).  Chrome uses a light blue outline around the current page on a dark grey background which I find much easier to see. It also dims all the other pages (not sure if I like that though).

Maybe we can switch to a blue outline? (blue because it indicates "selected").

(I'm using Nightly on Linux)
Bug: Background color of Bookmarks menu footer
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-02-03 06:09:16+00:00
Resolved: 2021-02-03 16:28:45+00:00

Syeps to reproduce
1. Click hmburger menu > Library > Bookmarks
   or
   Click library toolbutton > Bookmarks

Actual results:
No background color
See attached screen shot
Bug: Editing URL on local server removes HTTP and starts search
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-03 09:32:58+00:00
Resolved: 2021-02-04 07:23:09+00:00

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

Steps to reproduce:

While testing local application I need to edit the URL often. So I click in the URL bar to change/remove parameters or change the path.


Actual results:

When I start to remove the parameters after Question-Mark everything is fine. As soon as I remove the Question-Mark the icon in front of the URL changes from "Visit" to "Search on Google" and when I press enter I get indeed redirected to google with my local URL. It doesn´t happen if there is a port after the computer name, or if the URL is FQDN, e.g. domain.com
Samples:
myComputer/myApp/SomePage.aspx -> Search
myComputer/myApp/SomePage.aspx? -> Visit
myComputer:80/myApp/SomePage.aspx -> Visit
myComputer.com/myApp/SomePage.aspx -> VisitWhen I click in the URL bar and start to remove the parameters after Question-Mark everything is fine. As soon as I remove the Question-Mark the icon in fron of the URL changes from "Visit" to "Search on Google" and when I press enter I get indeed redirected to google with my local URL. It doesn´t happen if there is a port after the computer name, or if the URL is FQDN, e.g. domain.com
Samples:
myComputer/myApp/SomePage.aspx -> Search
myComputer/myApp/SomePage.aspx? -> Visit
myComputer:80/myApp/SomePage.aspx -> Visit
myComputer.com/myApp/SomePage.aspx -> Visit


Expected results:

After editing the URL, I should always be able to visit the URL by pressing enter, e.g. it shouldn´t change to "Search" as myComputer is a valid address too.
Bug: Avoid updating the bookmarks toolbar multiple times when removing bookmarks
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-02-03 10:38:10+00:00
Resolved: 2021-02-09 04:26:52+00:00

Batching of bookmark remove notifications is being added in bug 1607245.

I noticed that `BookmarkingUI.handlePlacesEvents` will not be very efficient. This is an existing issue, but we can resolve it now due to the added batching:

https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/browser/base/content/browser-places.js#2355-2358

We should use a flag for the `this.maybeShowOtherBookmarksFolder();` call and only execute once after the loop.

Likewise `this.updateEmptyToolbarMessage()` should only be executed after the loop.

These are both functions which potentially end up with us executing SQL.

I don't think it is worth splitting out the `this._updateStar();` that should only be called once per batch.

Whilst here we could also clean up this code to only happen in the following if statement when we're building the bookmarks button:

https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/browser/base/content/browser-places.js#2452-2453