av9ash/GitBugs huggingface dataset:
Bug: Nightly Build 74.0a1 (2020-01-22) (64-Bit) broken - don't open tabs or follow any link
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-23 07:30:51+00:00
Resolved: 2020-02-15 12:23:54+00:00

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

Steps to reproduce:

Windows 10
- Download latest Nightly Build 74.0a1 (2020-01-22) (64-Bit)
- Start it, and see nothing
- see only browserwindow with favorites and the address bar
- but no pages, or new tabs open


Actual results:

- Nighly build not usable
- not possible to close the browser without taskmanager


Expected results:

Open Tabs or links should work as expected
Bug: Show all bookmarks not displayed when bookmarks list is long
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-01-23 08:28:20+00:00
Resolved: 2020-02-24 09:17:19+00:00

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

Steps to reproduce:

1. Click bookmarks icon from toolbar 
2. Click bookmarks



Actual results:

With a lot of bookmarks a long list of bookmarks are displayed, but the button "Show all bookmarks Ctrl + Shift + B" is indiscernible.


Expected results:

The button should be displayed in full
Bug: Proxy credentials show the "Discard" dialog for saving changes
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-01-23 09:11:12+00:00
Resolved: 2022-09-19 06:06:08+00:00

**Affected versions**
Nightly 74.0a1 74.0a1 (2020-01-21) (64-bit)
Beta 73.0b8 (64-bit)
Release 72.0.2 (64-bit)

**Affected platforms**
Windows 10 x64
MacOS 10.15

**Steps to reproduce**
1. Launch Firefox
2. Set up manual Proxy configuration
3. Go to a site on the same tab to toggle the auth dialog
4. Enter valid credentials and save them
5. Go to about:logins
6. Edit the password and click on "Save Changes"

**Expected result**
The changes should be saved

**Actual Result**
The "Discard unsaved changes" dialog appears.
Clicking "Discard" will discard the changes
Clicking "Cancel" will **save** the changes

*This only happens to Proxy credentials, http, ftp and other credentials don't have this issue*

**Note**
Last good build was 71.0a1 (2019-09-17)

**Regression-Range**
Mozregression found Bug 1579184.
Bug: Can't open .msg files from Firefox in Outlook 365
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-23 10:58:55+00:00
Resolved: 2020-02-24 16:47:00+00:00

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

Steps to reproduce:

Open any .MSG file with outlook directly from Firefox.


Actual results:

Give out an error.


Expected results:

.MSG file should open in outlook.
Bug: "Restore old session" is opening old and unwanted tabs, even when I've deliberately closed them.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-23 12:21:54+00:00
Resolved: 2020-05-19 08:29:57+00:00

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

Steps to reproduce:

This is a fresh install of an operating system I have previously had no issues with. The only thing I did was create a new user profile, and changed one setting that allowed me to load userChrome.css files. Loaded in a CSS theme, and checked the "restore old session" button. 


Actual results:

My settings are set to restore old sessions, but FF will persistently open these tabs that I have already closed and will only do it with some tabs. I don't know whats causing it, but the same three video tabs keep coming up even thogh I have watched the video and closed the tab (with keyboard shortcuts and mouse) Nothing. They just keep coming back. Mind you, this is on a fresh install of an operating system I have used before. No idea what's causing this.


Expected results:

The tabs that are closed should NEVER reopen upon opening a new window.
Bug: Format numbers in the font size drop-down using mozIntl.NumberFormat
Status: NEW
Priority: P3
Created: 2020-01-23 14:47:57+00:00
Resolved: 2022-10-11 23:52:42+00:00

#### Affected versions:

ALL
#### Affected platforms:

ALL

#### Preconditions:
Install an AR build.

#### Steps:

  1. Launch Firefox with a new profile using the AR build and go to about:preferences.
  2. Scroll down to Language and Appearance section.

#### Actual result:

Font size drop-down displays western numerals. Default zoom drop-down displays eastern arabic numerals I think.
#### Expected result:

All drop-downs should display the numbers in the same format.
Bug: Firefox Home - First Highlights tile does not immediately reflect correct bookmark name
Status: NEW
Priority: P3
Created: 2020-01-23 15:57:26+00:00
Resolved: 2022-10-11 23:52:43+00:00

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

Steps to reproduce:

1. Download the latest FF nightly. (No existing user data or bookmarks.)

2. Visit Wikipedia.org or any other site.

3. Bookmark the page via the star icon in the address bar. Give the bookmark a new name other than the title of the page, such as "WikipediaCustomName".

4. Navigate to Firefox Home via the home button and scroll to the Highlights section.


Actual results:

The name on the first Highlights tile is the default name, not the new name (e.g. "Wikipedia", not "WikipediaCustomName").

This only affects the first tile. Repeating the process with another website moves the first bookmark (Wikipedia) to a second tile, and that name updates to the correct name. However, the new first tile will have an incorrect name.

Refreshing the page has no effect. However, on restarting Firefox, the first tile's name updates to the correct name.

I'm not sure how this issue relates to "non-bookmark" Highlights tiles such as those for frequently visited sites.


Expected results:

As for all such tiles, the name on the first Highlights bookmark tile should always be the current bookmark name, not the default name.
Bug: macOS Urlbar border is hard to make out
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-01-23 20:53:04+00:00
Resolved: 2020-03-30 12:06:25+00:00

Bug 1606930 comment 6 points out that our macOS Urlbar border is not the right colour. This is because we're using `-moz-mac-focusring` for the colour, which is transparent. This doesn't look good with the new 1px border, especially on dark theme.
Bug: Malicious use of AddSearchProvider method
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-23 21:17:27+00:00
Resolved: 2020-04-14 15:34:55+00:00

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

Steps to reproduce:

The DOM method window.external.AddSearchProvider() can be used in various malicious way to prevent Firefox from responding or forcing a user to add (malicious) search engines to Firefox. I found it in the wild and could easy replicate it with some javascript. Here are some examples of malicious use of the method. It uses the OpenSearch XML from the Firefox Addon website as example.

Example 1
----------------
while(true) {
    window.external.AddSearchProvider('https://addons.mozilla.org/nl/firefox/opensearch.xml');
}
----------------

Examples 2
----------------
setInterval(function() {
    window.external.AddSearchProvider('https://addons.mozilla.org/nl/firefox/opensearch.xml');
}, 10);
----------------

Tested on system with Firefox version 72.0.2 / Windows 10 Pro 1909 / Intel Core i5-7200U / 8 GB RAM.


Actual results:

Example 1
----------------
On a clean Firefox profile, CPU usage rises to 80% and system RAM goes up to 95%, slowing down the users system and rendering Firefox unresponsive.

On my personal profile, which is quite clean but already survived a few update rounds and has a few addons installed, it freezes my whole system when the RAM is filled up. It may take a few minutes depending on the amount of system RAM. No system interrupts are available (e.g. no task manager or CTRL+ALT+DELETE. Had to hard power cycle the system.
----------------

Example 2
----------------
A thousand confirmation boxes opens in which Firefox asks the user to add the search engine. You can't escape it, like closing the tab, or closing the Firefox window (with either the top right corner X-button or via the taskbar). Task manager has to be used to close Firefox.

I can imagine some users might actually add the (malicious) search engine to get rid of the dialog windows.
----------------



Expected results:

Example 1
----------------
Firefox should have at least give me the usual "A web page is slowing down your browser" message with the option to quit the page. Or just let the tab crash without filling up my system memory.
----------------

Example 2
----------------
Add an option to prevent the page from creating more dialog, just like the normal alert() dialogs.
----------------
Bug: tab contents lost after a forced (upgrade) restart
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-23 21:48:53+00:00
Resolved: 2020-06-05 00:27:57+00:00

After upgrading Firefox, it works normally for some time then starts displaying "one small thing, we need to restart" in every new tab.  That's its usual behaviour.

The "one small thing" message happens for not just genuinely new tabs, but also for tabs that had been for some reason unloaded (like, have not been switched to since session restore, been evicted due to low memory, etc).  And if "one small thing" is shown, then after restart, the tab's contents is gone.  Its caption shows "New Tab", there's no back button enabled, it's not in history, etc.  I found no way to recover it other than restoring the profile from last backup (fortunately, I snapshot /home hourly thanks to btrfs).

A tab that's unloaded but haven't been switched to between Firefox discovers it wants to restart and the actual restart is restored normally.
Bug: Some context menu items that modify values should be disabled for disabled form controls
Status: NEW
Priority: P3
Created: 2020-01-23 23:27:35+00:00
Resolved: 2022-10-11 23:52:50+00:00

The following menu items (which isn't an exhaustive list) should IMO be disabled on disabled form fields e.g. <input>:
* Cut
* Paste
* Fill Login/Password
* Use generated password…
* Spelling suggestions

Perhaps [`onEditable`](https://searchfox.org/mozilla-central/rev/e878e5b81bb319c141900ce9cfcde732df5c8449/browser/actors/ContextMenuChild.jsm#1046) should be false for `@disabled` fields like it is for `@readOnly`… but then that makes me think perhaps `SpellCheckHelper.EDITABLE` should also be `false` in this case…

Perhaps the spell checker underline should also be removed in this case?
Bug: Latest revision does not allow printing to pdf creator. It stops responding
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-23 23:42:05+00:00
Resolved: 2020-01-28 18:23:05+00:00

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

Steps to reproduce:

Tried printing to PDF Creator with Firefox with latest Firefox version 72.0.1.


Actual results:

Firefox stopped responding.


Expected results:

It should have opened a window asking for the location to save the created PDF file. I tried printing to PDF Creator from other applications and it works fine. I removed and re-installed PDF Creator with the same results.
Bug: When using dark mode and bringing up the right click menu, the menu is dark as well, and hard to read and use.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-24 01:10:10+00:00
Resolved: 2020-01-31 12:18:07+00:00

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

Steps to reproduce:

Right click anywhere and use dark mode


Actual results:

The menu the right click brings up has messed up colors (some buttons are light, some are too dark, with dark text)


Expected results:

Light text on a uniformly dark menu
Bug: Start page/address bar search does not accept foreign coding
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2020-01-24 10:24:06+00:00
Resolved: 2020-01-28 21:31:46+00:00

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

Steps to reproduce:

Firefox starting search page and address bar (set to default) does not process special chars/letters for language selected in Mozilla. In this example Polish Language. 

All special letters existing in Polish are not interpreted correctly when typed in and searched. Default browser search set to https://duckduckgo.com in this example.


Actual results:

I search for polish wording 'Piękne łąki' (trans. beautiful fields) from the address bar or Mozilla starting search page and then duckduckgo page opens automatically and shows search results for 'Pi&#281;kne &#322;&#261;ki'.

All special letters have been changed to ASCI number I believe.


Expected results:

The exact wording as typed should be sent to the website in this example 'Piękne łąki'.
Bug: Show the full permission prompt for notifications (e.g. after user click)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-24 11:28:41+00:00
Resolved: 2020-01-28 12:13:50+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.4 Safari/605.1.15

Steps to reproduce:

1. A website asks permission for push notifications (e.g. after a click on a button)
2. Firefox display only a small badge icon near the lock in the address bar and returns "blocked" automatically


Actual results:

The users don't see that small badge icon...

That is really confusing when the user explicitly clicked a subscribe button on the website that should display the notifications prompt. The user clicks a subscribe button and then the status blocked is automatically returned to the website: this doesn't make sense and breaks most subscription flows.

It also breaks all the double opt.-in workflows, that are recommended by Google usability guides. Try to subscribe to notifications here for example:
1. Visit https://pushpad.xyz/
2. Click Allow on the custom prompt
3. You would expect to get a browser permission prompt, but instead "blocked" is returned immediately to the website
4. The user doesn't even notice the small badge icon
5. Even if the user notices the notification icon and allows notifications, he would have to click Allow a third time on the custom prompt

Finally the website might say that the notifications are blocked by browser preferences: at this point the user clicks the lock to see permissions and the notification block is not even reported there (as anyone would expect).

This new flow is completely messy, confusing for the user and breaks most subscription flows. You should use it only when there is no user interaction, for example when the permission prompt is displayed on page load, not after a user click.


Expected results:

1. Display the full permission prompt (and not a small icon) when the prompt is triggered by a user event (like a click). 
2. Also, in that case, allow users to actually choose their preferences and don't return "blocked" immediately.
Bug: Passwords still visible after loss of sync
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-24 14:38:52+00:00
Resolved: 2020-01-25 05:11:40+00:00

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

Steps to reproduce:

Started Firefox on a machine which had previously been signed in to Firefox Sync.

It has now updated Firefox on that machine (to 72.0.2, unsure of previous version).

Clicked on the account/person icon and saw "Sign in to Firefox, Turn on Sync", so my account wasn't sync'd on this machine.


Actual results:

When I went to a website, it offered to autofill my password.  On checking the "Logins and Passwords" page, all my passwords are still visible.


Expected results:

No passwords should be visible.
Bug: v2 personaliztion console error
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-01-24 14:58:58+00:00
Resolved: 2020-02-03 21:50:48+00:00

Saw this error this morning while testing it preffed on in nightly:

TypeError: nbTagger.tagTokens is not a function RecipeExecutor.jsm:146:29

I believe it's an issue with loading from cache, which I think the issue starts here:

https://searchfox.org/mozilla-central/source/browser/components/newtab/lib/PersonalityProvider.jsm#108

I don't know if we want to do more validation on the data before using it, or if we can clean up the data we cache. The old AS v2 didn't use this cache, and now I see why. I think it only works as in memory cache, and not persistent cache. So probably best to just not use this item as cache as using it as in memory cache has very little performance gains. I think this time though a comment as to why we cannot cache this would help hitting this again in the future.
Bug: backgroundPageThumbsContent.js mixes nsIRequest and nsIWebNavigation load flags
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-01-24 17:17:32+00:00
Resolved: 2020-01-29 21:38:45+00:00

See https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/toolkit/components/thumbnails/content/backgroundPageThumbsContent.js#48-52.

This bitfield is being assigned to the docShell's `defaultLoadFlags`, which should be comprised of `nsIRequest` load flag bits. The `nsIWebNavigation` bit that is OR'd in has a value of 0x0040 which happens to be an undefined bit in `nsIRequest`, so for now I guess it's benign, but this is not enforced anywhere as far as I can tell.

I didn't actually check whether this bit is actually respected as intended by this script by consumers of `defaultLoadFlags`, but it seems like a fair assumption.

Mark and Drew, hg blame suggests that you might understand the intention of this code? Can you help here? :)
Bug: JavaScript error: resource://gre/actors/PictureInPictureChild.jsm, line 414: TypeError: can't access property "disarm", state.mousemoveDeferredTask is null
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-24 20:22:59+00:00
Resolved: 2020-02-06 20:53:24+00:00

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

Steps to reproduce:

Navigating between sites, twitter and news sites


Actual results:

Error:
 ```JavaScript error: resource://gre/actors/PictureInPictureChild.jsm, line 414: TypeError: can't access property "disarm", state.mousemoveDeferredTask is null
```


Expected results:

No errors.

Thanks!
Bug: New-tab pocket recommendation thumbnails have visual artifacts introduced by our PNG-->JPEG post-processing
Status: NEW
Priority: P3
Created: 2020-01-24 21:06:14+00:00
Resolved: 2022-10-11 23:53:03+00:00

It seems the Pocket-powered recommendations on the New Tab Page are taking PNG images, downscaling & reencoding them as JPEG images, and using that lossy/visual-artifact-laden result for the thumbnail.

For photos this may be fine, but for simpler graphics, it looks pretty gross. See attached screenshot, which shows weird "halo"/"ghost" JPEG artifacts in a thumbnail for a simplisafe sponsored article.

If I right-click the image to get its URL, I can see that it is the following (which also shows the artifacts if I load it directly):
https://img-getpocket.cdn.mozilla.net/296x148/filters:format(jpeg):quality(60):no_upscale():strip_exif()/https%3A%2F%2Fs.zkcdn.net%2FAdvertisers%2F1d95cdbde5a74b448a6c7525cd7341ec.png

If I snip out and url-decode the last ~third of that URL, I can get the source image which is:
https://s.zkcdn.net/Advertisers/1d95cdbde5a74b448a6c7525cd7341ec.png
...which does not have any such artifacts.
Bug: Struggling to remove pocket item from the address bar when using user.js
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-24 21:25:22+00:00
Resolved: 2020-01-26 21:25:53+00:00

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

Steps to reproduce:

This issue is related with #1498914 (the Pocket icon removal does not persist accross reboots) and also the three dots menu in the title bar.

Pocket icon in the address bar:
1. Open Firefox.
2. Remove Pocket icon from address bar.
3. Restart Firefox.
4. Pocket icon is again in the address bar.

I have tried to modify `browser.pageActions.persistedActions` (both in `about:config` and in `user.js`), the result is same, or even worse: `Add search Engine` is added to the three dots menu (which was not there before playing with the setting).

Also, there is not GUI way to _remove_ items from the three dots menu (I think it would be nice to add this option to the right-click menu, where there is only _Add to Address Bar_ option).

Just a note: I have enabled Firefox sync.


Actual results:

All (let’s say) default address bar items and the three-dot menu items are displayed and the `browser.pageActions.persistedActions`  setting is reset. Sometimes even  `Add search Engine` was added to the list.


Expected results:

Only those address bar items and the three-dot menu items should be displayed, which are enabled by the `browser.pageActions.persistedActions` setting.
Bug: DOS via insecure form submission prompt
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-24 21:33:08+00:00
Resolved: 2020-02-25 10:52:50+00:00

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

Steps to reproduce:

The first time I've proceed with a reboot. The second time it corrupt Firefox and I need to reinstall my browser.
Bug: Long-click on New Tab button doesn't give the option to open a tab in a container
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-25 00:51:41+00:00
Resolved: 2020-02-04 22:32:00+00:00

A couple of days ago I was able to open a tab in a different container with a long click on the new tab "+" button on the tab bar. This doesn't work today.

Tried in my normal profile and in Safe Mode. Using Nightly on Linux.

Steps to reproduce:
1. Click and hold on the new tab "+" in the tab bar.

Expected result:
1. A menu with a list of containers pops up.

Actual result:
1. Firefox waits for the click to end and opens a new tab.