av9ash/GitBugs huggingface dataset:
Bug: [macOS 11 Big Sur] Firefox does not switch or close tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-09-08 11:11:04+00:00
Resolved: 2020-09-21 07:32:13+00:00

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

Steps to reproduce:

Try to switch to different tab or close tab. Many times firefox just does not switch or close the tab.

I have the impression that this works better if I click in the lower part of the tab, but as the behaviour is inconsistent this is difficult to determine.

In any case the tab 'indicator' only gets highlighted when the mouse is in its lower part.


Actual results:

Most of the times firefox just does not switch or close the tab.


Expected results:

Firefox should switch to selected tab or close tab.
Bug: Remove default topsites that match the current default engine, even if specified in the topsites collection
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-09-08 11:24:20+00:00
Resolved: 2020-11-13 12:21:10+00:00

##### [Sugested Severity:]
S3

##### [Description:]
See https://bugzilla.mozilla.org/show_bug.cgi?id=1663179#c3

##### [Environment:]
Windows 10
81.0b7 20200906164749

##### [Steps:]
1. Add https://baidu.com as a topsite in the Remote Settings configuration.
2. From the Remote Settings configuration, set the https://baidu.com to be a search shortcut.
3.  Publish the changes and set Firefox to connect to the respective collection. 
4.  Set a Firefox profile to connect to the configuration while switching the browser.topsites.useRemoteSetting to true and setting browser.search.region to CN
5.  Download a zh-CN build and setart Firefox with the previously prepared profile.
6.  Start-up Firefox with the above profile configuration.
7.  From about:preferences#search change the default search engine to something else than baidu.
8. From about:preferences#search change the default search engine back to baidu.

##### [Actual Result:]
6. default engine: baidu ; Topsite: baidu - not pinned, not search shortcut marked.
7. default engine: not_baidu; Topsite: baidu - pinned, search shortcut marked.
8. default engine: baidu; Topsite: baidu - pinned, search shortcut marked.

##### [Expected Result:]
6. default engine: baidu ; Topsite: baidu is not listed in the topsites
7. default engine: not_baidu; Topsite: baidu - pinned, search shortcut marked.
8. default engine: baidu; Topsite: baidu is not listed in the topsites
Bug: for ... of String skips repeated characters
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-09-08 14:53:31+00:00
Resolved: 2020-09-08 14:56:11+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:

1. Open the JavaScript console
2. Enter this code from MDN docs on for ... of when iterating strings:

```
const iterable = 'boo';

for (const value of iterable) {
  console.log(value);
}
```


Actual results:

The output is:
> b
> o

And an o is missing.

Try adding more o's, or try words like "feel" or "hoot" and you will see "fel" or "hot".


Expected results:

There should be outputs like:

"boo"
> b
> o
>o

"feel"
> f
> e
> e
> l
Bug: ETP Custom Content Blocking List choosing UI is broken in Nightly 82
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-09-08 19:17:59+00:00
Resolved: 2020-09-14 14:05:20+00:00

The list chooser is broken again in Nightly 82. We very recently fixed a regression in Bug 1657679 that caused this issue.

STR:
1. In a new profile enable the preference `browser.contentblocking.customBlockList.preferences.ui.enabled`. This preference will be enabled for any users that had the Level 2 blocklist enabled when we previously deprecated the list chooser UI.
2. Go to `about:preferences#privacy`
3. Choose ETP Custom and click "Change block list"

ER: A single popup opens with two list options

AR: Two popups open, both of which are blank. Oddly enough, the double pop-up only occurs the first time. Clearing all Firefox data (via "Clear Recent History") will cause the double pop-up to re-appear, but only once until storage is cleared again.
Bug: Having sync issues - It auto logged me out, wouldn't accept my password, made me change it, and now wont let me log in at all
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-09-09 00:01:34+00:00
Resolved: 2020-09-10 05:05: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:

Thinking that I had my password wrong, I reset it


Actual results:

It let me change my password and then log in to Sync. However today (maybe yesterday) , it has auto-logged me out again and is not accepting my new password


Expected results:

I should have been able to log in using my new password. It suggests to me that I had used my password correctly the other day and I didn't need to change it. Perhaps there is an issue with Sync?
Bug: Printing a pdf email attachment opens an extra about:blank if you configure opening PDFs to "always ask"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-09-09 03:18:18+00:00
Resolved: 2020-11-10 17:19:55+00:00

I'm on a Mac, using today's Nightly and trying to print a pdf email attachment opens about:blank before showing the dialog option of opening in firefox or adobe or saving it. In addition, if I choose to open in adobe but then cancel to print, it doesn't cancel the first time and opens up the print dialog again and I have to cancel again.
Even if open in firefox is chosen, that extra blank tab still remains.
I'm attaching screen recordings to show the behavior.
Bug: transparent part of some popups turns black on linux with EGL
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-09-09 05:01:13+00:00
Resolved: 2020-09-10 04:38:42+00:00

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

Steps to reproduce:

1. enable EGL via MOZ_X11_EGL=1
2. click on the hamburger icon, or any of the extension icons to bring up a popup.


Actual results:

There is black borders around those popups.


Expected results:

Those part should be transparent, nice-looking.

I'm on Linux and X11 and I've checked that my compositor works. This is a regression, and mozregression finds:

 5:02.73 INFO: No more integration revisions, bisection finished.                                                                        5:02.73 INFO: Last good revision: 645d922a048ce0d9ef0a3ba6d50ce9f05011f80a                                                             
 5:02.73 INFO: First bad revision: e9d534d12e77469312104876f513cb749c25cce5                                                             
 5:02.73 INFO: Pushlog:                                                                                                                 
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=645d922a048ce0d9ef0a3ba6d50ce9f05011f80a&tochange=e9d534d12e774693121
04876f513cb749c25cce5
Bug: "Content Copying" Document Restriction is not effective
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-09-09 05:07:45+00:00
Resolved: 2020-09-09 22:57:58+00:00

I haven't fully tested all document restrictions, but the "content copy" restriction doesn't work in pdf.js.

Step to Reproduce:
1. Generate a PDF file which has "Content Copy: Disallowed" document restriction
2. Open the PDF file in Firefox
3. Select text and then Copy and Paste

Actual Result:
The selected text is copied and pasted.

Expected Result:
Text cannot be copied.
Bug: privacy.js: Identical code for different branches
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-09-09 06:35:03+00:00
Resolved: 2021-06-11 11:10:28+00:00

https://searchfox.org/mozilla-central/source/browser/components/preferences/privacy.js#2418-2422

This is the same code in the two branches.

Maybe it should be only
```
      telemetryContainer.hidden = checkbox.checked;
```
Bug: Preferences react immediately when users type in its search box and the resulting highlighting and hiding of items can be problematic
Status: NEW
Priority: P3
Created: 2020-09-09 08:57:03+00:00
Resolved: 2023-06-02 15:20:07+00:00

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

Steps to reproduce:

I tried to check my autoplay settings, to confirm that I'm blocking as much as possible.

I can't scroll about:preferences, see bug 1658601.

So I try to type autoplay into the search bar.


Actual results:

As I type, the whole page flashes and animates.


Expected results:

The search bar should wait until users hit enter to show results. If there is a hidden setting to control this, I can't find it.
Bug: pdf.js shows a domain of "pdf.js" when going fullscreen
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-09-09 09:27:26+00:00
Resolved: 2020-09-12 22:04:54+00:00

"pdf.js" isn't a valid domain name.  At least until some country comes around that is assigned a .js ccTLD.

According to gijs, "This will be because we use uri.host for that notification, and PDF.js runs on resource://pdf.js/..., and therefore uri.host is pdf.js."  That seems right, but it suggests a bunch of different options.

That URI uses the authority form, with an authority of a filename, which is maybe right in the sense that a filename is *in some sense* the authority.  But that means that we have some awkward collisions like this, so it probably isn't the best plan.  resource:///pdf.js/... (three slashes) might be more correct, in line with file:///.  Or maybe the right answer here is to override handling for the resource scheme to return a null or fixed value for uri.host.

That's structural work that might be expensive, so we could just implement a workaround in the fullscreen code and provide a custom string for the resource: scheme (with i18n, of course).
Bug: Search suggestions not always visible for Amazon and Wikipedia.
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-09-09 15:02:20+00:00
Resolved: 2020-10-02 08:56:10+00:00

**Tested on**
Firefox nightly 82.0a1 and affects:
Windows10 64bit
MacOS 10.15
Ubuntu 18.04

**Description**
Search Results not always visible for Amazon and Wikipedia.

I noticed that in some cases the search results in megabar are not visible using Amazon and wikipedia
This happens every time i execute firefox, and it also happens when i type the search result really fast.
I tried this using the one-offs.


**steps to reproduce**

1. Click on address bar
2. Type word "cats"
3. Click on amazon one off (or click on wikipedia one-off)
4. Click on address bar, press backspace to delete everything
5. Type word "cats" 
6. Click on amazon one off (or click on wikipedia one-off)

or

1. Click on address bar
2. Click on amazon one off (or click on wikipedia one-off)
3. type the word "cats" really fast
4. click on address bar, press backspace to delete everything
5. Click on amazon one off (or click on wikipedia one-off)
6. type the word "cats" slowly

**actual result** 
When i type the word cats really fast or after launching firefox,  i don´t get the search results in the megabar.

**expected result**
I should get search results always (this happens when i do Steps5 and Step6 on windows10. 
On Mac0s and ubuntu it seems to fail also on step 5 and 6
Bug: Alt+down key combination when clicking a one-off with mouse uses wrong engine.
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-09-09 15:29:22+00:00
Resolved: 2020-09-12 02:11:48+00:00

**tested on**
 Firefox nightly 82.0a1 and affects:
Windows10 64bit
MacOS 10.15
Ubuntu 18.04


**steps to reproduce**

1. Click on a one off, like bing > (search mode appears for bing)
2. Type any word like Cats > (search suggestions appear)
3. Press ALT + DOWN a couple times untill DUCKDUCKGO is highlighted in blue
4. WITH the mouse click on one of the search SUGGESTIONS.


**actual result**
it opens a duckduckgo search, but you had bing search box on the megabar

**expected result** 
should do a bing search, since search container had bing in the megabar
Bug: One-offs missing if topsites is disabled
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2020-09-09 15:33:48+00:00
Resolved: 2020-09-15 15:00:19+00:00

**tested on**
 Firefox nightly 82.0a1 and affects:
Windows10 64bit
MacOS 10.15
Ubuntu 18.04

One-offs missing if topsites is disabled

**steps to reproduce**
1. go to about:preferences#search
2. click on "Change preferences for search engine suggestions"
3. uncheck top sites
4. click on megabar


**actual result**
one-offs are missing

**expected result** 
one-offs now should always be visible.
Bug: user-preference-changed-sideload unenrollments after Firefox upgrade
Status: NEW
Priority: P3
Created: 2020-09-09 15:59:47+00:00
Resolved: 2023-03-01 03:01:51+00:00

Many users in the treatment branch of the [Comcast steering experiment](https://experimenter.services.mozilla.com/experiments/comcast-steering-experiment/) (`bug-1647305-pref-comcast-steering-experiment-release-78-80`) were unenrolled with reason `user-preference-changed-sideload`: https://sql.telemetry.mozilla.org/queries/74510/source#186220

The volume of these events increased when Firefox 80 was released. Most unenroll events are sent from Fx 80.0 or 80.0.1: https://sql.telemetry.mozilla.org/queries/74517

The upgrade could have triggered the unenrollment or there could be something Fx 80-specific. Windows and Mac users were both affected.

The treatment branch sets the prefs `doh-rollout.provider-steering.enabled` to `true` and resets `doh-rollout.provider-steering.provider-list` to its default value, both on the default pref branch. The prefs have default values set [in firefox.js](https://searchfox.org/mozilla-central/rev/b2716c233e9b4398fc5923cbe150e7f83c7c6c5b/browser/app/profile/firefox.js#1937).

The unaffected control branch only sets `doh-rollout.provider-steering.enabled` to its default value (`false`).

The check that fails that causes the error to be sent is https://searchfox.org/mozilla-central/rev/b2716c233e9b4398fc5923cbe150e7f83c7c6c5b/toolkit/components/normandy/lib/PreferenceExperiments.jsm#260-261, which indicates that Normandy discovered that the preference had an unexpected value for the user's branch.
Bug: Disabled "Show search suggestions in address bar results" still shows suggestions with a one-off selected
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-09-09 16:08:41+00:00
Resolved: 2020-09-09 17:00:09+00:00

**tested on**
 Firefox nightly 82.0a1 and affects:
Windows10 64bit
MacOS 10.15
Ubuntu 18.04

"Show search suggestions in address bar results" disabled still shows suggestions with a one-off selected


**steps to reproduce**

1. go to about:preferences#search
2. uncheck "Show search suggestions in address bar results"
3. open new tab, search "cats" > suggestions are not visible.
4. click on the duckduckgo one-off for example and keep clicking other one-offs.


**actual result**
suggestions appears after i click a one-off

**expected result** 
 if user removed the checkbox suggestions should not appear.

Notes: Before the one-offs changes we did not have this problem with suggestions.
Bug: Double Escape key on search mode shows blank megabar link
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-09-09 16:30:35+00:00
Resolved: 2020-09-30 09:21:43+00:00

**tested on**
 Firefox nightly 82.0a1 and affects:
Windows10 64bit
MacOS 10.15
Ubuntu 18.04

Double Escape key on search mode shows blank megabar link

**steps to reproduce**
-go to www.cnn.com
-Click on megabar, type any word
-Select a one-off like Bing
-Press Escape key Once > suggestion panel is closed
-Press EScape key Once more 

**actual result**
address bar is blank.

**expected result** 
"Search Mode" for Amazon is removed. b) search terms are also removed. c) https://edition.cnn.com/ is showing up in url bar.""


notes: I need to click escape key a third time in order to see https://edition.cnn.com in the url bar
Bug: sign-in AUTHORISATION CODE sent by email NOT ACCEPTED by FIREFOX
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-09 18:02:01+00:00
Resolved: 2020-10-26 13:36: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:

Tried to sign in to my Firefox account about 5 times, received authorisation code by email each time


Actual results:

entered appropriate authorisation codes, but  'INVALID authorisation code' pop-up appeared every time


Expected results:

access to my firefox account!
Bug: Clients repeatedly failed to unenroll from Comcast steering experiment
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2020-09-09 21:03:06+00:00
Resolved: 2023-03-01 03:01:57+00:00

Many clients experienced failures attempting to unenroll from the [Comcast steering experiment](https://experimenter.services.mozilla.com/experiments/comcast-steering-experiment/).

Grafana shows a high number of events: https://grafana.telemetry.mozilla.org/d/XspgvdxZz/experiment-enrollment?panelId=22&fullscreen&orgId=1&var-experiment_id=bug-1647305-pref-comcast-steering-experiment-release-78-80&from=1597017600000&to=

Deduping by client shows that clients are each sending many events, all for reason `already-unenrolled`.

The branches were affected more or less evenly; about 31k users per branch (~4% of clients) were affected: https://sql.telemetry.mozilla.org/queries/74591/source

The filter expression is straightforward, and is notable only for a geolocation clause:

```
"filter_expression": "(normandy.channel in [\"release\"]) && (normandy.country in [\"US\"]) && ([normandy.userId,\"doh-comcast-rollout\"]|bucketSample(8999,1000,10000)) && ((normandy.version>=\"78\"&&normandy.version<\"79\")||(normandy.version>=\"79\"&&normandy.version<\"80\")||(normandy.version>=\"80\"&&normandy.version<\"81\")||(normandy.version>=\"81\"&&normandy.version<\"82\")||(normandy.version>=\"82\"&&normandy.version<\"83\")||(normandy.version>=\"83\"&&normandy.version<\"84\")||(normandy.version>=\"84\"&&normandy.version<\"85\")||(normandy.version>=\"85\"&&normandy.version<\"86\"))",
```

The original unenrollments for affected users were overwhelmingly for reason `filter-mismatch`. https://sql.telemetry.mozilla.org/queries/74591/source

We did not expect clients to unenroll but it's not surprising that some users would have inconsistent geolocation results over time.

The unenrollments began as soon as the experiment launched. There was not a spike associated with the Fx 80 launch, unlike bug 1663971.
Bug: about:welcome should only be able to load in the privileged about process
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-09-09 21:47:25+00:00
Resolved: 2020-09-11 17:44:24+00:00

Nika pointed this out in Element (thanks Nika!)

I presume the consequence of this is that (some of the time?  usually?) we have more privileged code running in some random content process, meaning that the attack surface for exploit trampolining from web site holes is larger than it needs to be.  Nika, is this the right analysis?  Since it's a straightforward fix, is this something we would want to try and uplift into 81? (I don't really have a good sense of the risk of uplifting this fix)

We don't have the remoteTypes attribute set in the JSWINDOWACTORS definition in BrowserGlue.jsm.  Nika included a link to where the NewTab code does this correctly:

https://searchfox.org/mozilla-central/rev/8a0745cd346f0cfb89ae71690babbf7bff706113/browser/components/BrowserGlue.jsm#187
Bug: Heartbeat: Notifications in dark theme are unreadable
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-09-09 23:20:40+00:00
Resolved: 2020-09-14 14:53:01+00:00

Heartbeat notifications have a white text on a light background that make them unreadable (see screenshot). This is not an issue in Firefox 79. 

Steps to produce:

1. Download and install the Normandy devtools extension
2. Run one of the Heartbeat recipes
3. See that the notification is not readable.
Bug: Intermittent browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-09-10 05:48:34+00:00
Resolved: 2021-09-21 17:03:44+00:00

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

---
```
>[task 2020-09-10T04:38:03.011Z] 04:38:03     INFO - TEST-INFO | screenshot: exit 0
[task 2020-09-10T04:38:03.011Z] 04:38:03     INFO - Buffered messages logged at 04:37:17
[task 2020-09-10T04:38:03.011Z] 04:38:03     INFO - Entering test bound test
[task 2020-09-10T04:38:03.011Z] 04:38:03     INFO - Buffered messages logged at 04:37:18
[task 2020-09-10T04:38:03.011Z] 04:38:03     INFO - Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://mochi.test:8888/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.html" line: 0}]
[task 2020-09-10T04:38:03.011Z] 04:38:03     INFO - Buffered messages finished
[task 2020-09-10T04:38:03.012Z] 04:38:03     INFO - TEST-UNEXPECTED-FAIL | browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.js | Test timed out - 
[task 2020-09-10T04:38:03.012Z] 04:38:03     INFO - GECKO(3960) | MEMORY STAT | vsize 2104563MB | vsizeMaxContiguous 67238909MB | residentFast 322MB | heapAllocated 95MB
[task 2020-09-10T04:38:03.012Z] 04:38:03     INFO - TEST-OK | browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.js | took 45045ms
[task 2020-09-10T04:38:03.012Z] 04:38:03     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-09-10T04:38:03.012Z] 04:38:03     INFO - TEST-UNEXPECTED-FAIL | browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.js | Found a tab after previous test timed out: http://mochi.test:8888/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.html - 

*[task 2020-09-10T04:37:17.949Z] 04:37:17     INFO - TEST-START | browser/components/privatebrowsing/test/browser/browser_privatebrowsing_placesTitleNoUpdate.js*```