av9ash/GitBugs huggingface dataset:
Bug: Library button is briefly shown when under Overflow Menu due to small Firefox Window while bookmarking a page and maximize/minimize the browser
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-15 11:44:23+00:00
Resolved: 2020-01-22 03:06:38+00:00

*Affected versions*
* 74.0a1 (20200114214307)
* 73.0b5 (20200115020958)
* 72.0.1 (20200107212822)

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

*Steps to reproduce*
1. Open Firefox and make the browser window smaller (until the Library button enters the overflow menu).
2. Bookmark a random webpage and maximize/minimize the window by double-clicking on the tab bar.

*Expected result*
* No glitches presented when minimizing/maximizing the browser.

*Actual result*
* The library button is briefly displayed on the address bar.  

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

*Notes*
* Attached a screen recording.
* This bug was opened on request after was discussed on bug 1607160 [comment 6](https://bugzilla.mozilla.org/show_bug.cgi?id=1607160#c6) and [comment 7](https://bugzilla.mozilla.org/show_bug.cgi?id=1607160#c7).
Bug: [Windows] Download dialog for application/zip (and any other mimetypes not listed in the registry) doesn't offer to open with the default application anymore
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-01-15 17:10:15+00:00
Resolved: 2020-12-17 13:24:49+00:00

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

Steps to reproduce:

I set "Always ask" for all types of downloaded files.
When I click a link to download a ZIP file, the download dialog show the Browse button instead of the drop-down menu. This does not happen in the previous version of Firefox 71. 


Actual results:

1) The Browser button is show for the following MIME type: application/zip.

2) The drop-down menu is shown only for the following MIME type: application/x-zip-compressed.

See attached Image-1.jpg
Bug: nightly 74.0a1 crashes repeatedly in Hacl_Chacha20Poly1305_128_aead_decrypt:1235
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-15 18:37:45+00:00
Resolved: 2020-01-16 19:04:20+00:00

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

Steps to reproduce:

Upon the initial crash I merely did a restart of firefox with the nightly crash report widget still on the screen. This results in another crash immediately. I took note that the crash seems to happen with attempt to access the wikipedia site. 

https://crash-stats.mozilla.org/report/index/9fe9e608-81e5-4a2b-b72d-5f2a70200115

I closed some of the tabs upon restart from this crash and when I tried to access the wikipedia site again I got the crash : 

https://crash-stats.mozilla.org/report/index/3a7d3063-77f6-4132-a37a-13a080200115

At this point I did a restart and flushed out history and all tabs and also disabled javascript from the about:config page with javascript.disabled.  When I tried to access the wikipedia site we see another repeatable crash : 

https://crash-stats.mozilla.org/report/index/bf97e6bb-795d-4738-afc3-5fd100200115

Finally I tried one last time to merely access wikipedia.org and again a crash and always in the same place : 

https://crash-stats.mozilla.org/report/index/ae58eb14-4cf7-417a-9fe8-c12bb0200115

Looks like security/nss/lib/freebl/verified/Hacl_Chacha20Poly1305_128.c:1235 is the problem and we see a recent change Wed, 15 Jan 2020 10:10:15 +0000 (8 hours ago) there : 

https://hg.mozilla.org/mozilla-central/annotate/28abd2840682f762f865e07d2713e3d0b3c4410d/security/nss/lib/freebl/verified/Hacl_Chacha20Poly1305_128.c#l1235

I suspect this is the issue but hope others are seeing this also.


Actual results:

https://crash-stats.mozilla.org/report/index/ae58eb14-4cf7-417a-9fe8-c12bb0200115




Expected results:

Wikipedia page should have loaded.
Bug: Library button drop down menu displays small window and in the wrong position
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-15 18:51:51+00:00
Resolved: 2020-01-15 19:39:36+00:00

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

Steps to reproduce:

Click on the library menu.


Actual results:

Menu doesn't display fully or in the proper position.


Expected results:

Full menu should appear under the appropriate menu (library) button.
Bug: Video has lag / shuttering
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-15 19:00:28+00:00
Resolved: 2020-01-20 15:09:40+00:00

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

Steps to reproduce:

After a fresh install of windows 10 the Video on YouTube when FullScreen has lag. Like the person on the video is teleporting 10 frames but without to say i have dropped frames.


Actual results:

I can't reproduce on version 71 ...


Expected results:

Why :((
Bug: Focused input in devtools add-on panel is unable to type "'" or "/"
Status: UNCONFIRMED
Priority: --
Created: 2020-01-15 20:49:48+00:00
Resolved: 2022-10-24 12:15:28+00:00

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

Steps to reproduce:

1. Create a devtools add-on panel with an input field
2. Attempt to type ' or / into the field

My guess is this is related to the Accessibility.typeahead feature because when this feature is disabled, I am able to successfully type those values into an input inside of a devtools add-on panel. Attached is an example extension to reproduce the issue.


Actual results:

Unable to type ' or / into focused input field


Expected results:

Able to type ' or / into focused input field
Bug: When the address manager subdialog is scrollable, it overlaps the scrollbar for the <select> element
Status: NEW
Priority: P3
Created: 2020-01-15 21:07:17+00:00
Resolved: 2022-10-11 23:50:56+00:00

STR:
 1. Navigate to "about:preferences"
 2. Search for "addresses"
 3. Click the button that reads "Saved Addresses..."
 4. Add addresses so that there are at least 8 total.
 5. Observe that there is now a scroll bar on the <select> element that displays the addresses.
 6. Close the address manager subdialog.
 7. Resize the Firefox window so that it is quite small
 8. Click "Saved Addresses..." again

Expected Results:
Both the scrollbar for the dialog and the scrollbar for the <select> element should be visible
Actual Results:
The scrollbar for the <select> element is not visible because it is hidden under the scrollbar for the dialog. There isn't even a horizontal scrollbar we could use to bring it into frame.

A couple of notes about this:
 - I discovered this while fixing Bug 1608246, which was preventing the subdialog from being shown at all when the Firefox window was too small. You may need to wait for that patch to merge to be able to reproduce this. I did, however, double check with a build from before Bug 1608246 was introduced to verify that this bug was preexisting behavior rather than something I caused.
 - I discovered this on Windows. I know that macOS scrollbars are, by default, a bit unusual and like to hide, so I have no idea whether this issue appears there or how it presents.
Bug: UI/Accessibility Barrier: Forms in add-on dropdowns impossible to fill with on screen keyboard on desktop Linux
Status: UNCONFIRMED
Priority: --
Created: 2020-01-15 22:38:55+00:00
Resolved: 2022-10-11 23:50:57+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.118 Safari/537.36

Steps to reproduce:

I rely on the Onboard onscreen keyboard for typing on Linux. 

I open a Firefox addon dropdown with a form field (Bitwarden's login screen or renaming a container tab group in Mozilla's Firefox Multi-Account Containers extension). 

I click on the form field to give it focus.

I attempted to type using Onboard as usual. 


Actual results:

When clicking on a letter on the keyboard, the extension loses focus and closes. As a result, these forms are impossible for me to fill. 

As a result, I cannot log in to my password manager. 

This is likely because the dropdown loses focus too easily. 


Expected results:

The onscreen keyboard should be able to type in these fields.
Bug: userChrome.css and userContent.css don't work on New Tab page
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-16 00:19:00+00:00
Resolved: 2020-01-16 02:57:39+00:00

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

Steps to reproduce:

Visited the New Tab page.

Since certain objects animate on mouseover, tried to use userChrome.css to block this. Also tried userContent.css. Neither worked.


Actual results:

There is no domain, so I can't use that to limit the css to this page.

I tried to use the object names, as follows:

/* Remove new tab page animation */

.top-site-outer {
transition: none !important;
animation-duration: 0s !important;
transition:unset !important; }

More aggressively, to see if this is doing anything with the css:

/* Remove new tab page animation */

.top-site-outer {
display: none !important
transition: none !important;
animation-duration: 0s !important;
transition:unset !important; }

Also tried:

/* Remove new tab page animation */

#main-window[title^="New Tab"]
transition: none !important;
animation-duration: 0s !important;
transition:unset !important; }

Nothing happened.


Expected results:

The New Tab page should follow user css, at least for accessibility fixes.
Bug: Users shouldn't have to "Block" future permissions to back out of  *changing* camera or mic
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-01-16 01:54:30+00:00
Resolved: 2022-08-24 01:24:07+00:00

A page may call `getUserMedia` many times requesting different devices. Hitting "Deny" on _any_ of these prompts temporarily blocks all further gUM permissions on that page. That seems overly severe.

A common use flow is in-content device selection where a user switches camera or microphone:

**STR (requires 2 cameras, or use a phone):** (Remove persistent permissions first):
1. Open https://whereby.com/room12345 and "Request permission" 
2. Hit "Allow" in Firefox's gUM prompt
3. (You realize you wanted to use a different camera and) click the ⚙️ gear icon to change to the other camera (or flip ↻ front/back on phone)
4. Pick your other camera. A Firefox gUM prompt for that device appears.
5. (You change your mind and) hit "Deny" in this second gUM prompt

**Expected result:**
* The first camera is still chosen and working, and repeating steps 4-5 works (at least on a third camera).

**Actual result:**
* "Cam and mic are blocked" & the user is stuck until they refresh the page (see image).

**Side-bug:**
* As the image shows, the page-info drop-down has icons showing permission is blocked, but the text still says "Allowed Temporarily". The text appears to be a refresh bug, as the permission actually appears blocked. In fact, dragging the live tab into its own window causes the text to refresh to show "Blocked Temporarily").

**Proposed solution**
* Only add temporary blocks from "Deny" in *first* prompt (but `☑ Remember this decision` + "Deny" still adds permanent block even in subsequent ones).
* The definition of "first" may need hashing out. I think it's:
  * The page has not been granted gUM previously in this session, or since the user last revoked permission manually in this session.
Bug: Google Maps Infowindow stopped showing
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-16 08:51:30+00:00
Resolved: 2020-01-22 05:17:01+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 accessing a page on my company website on which Google Maps Infowindow was working fine previously. Suddenly, today we noticed that the location Infowindow no longer displays on clicking a location marker on Firefox, but they do show up on other browsers.
I tried creating a jsFiddle to make sure the issue nowhere related to our website. 

jsFiddle: https://jsfiddle.net/shivambarve/tf9vxgja/12/


Actual results:

The same behavior was seen in the jsFiddle. The Infowindow was not working there too when accessed through Firefox. Whereas, it was working when accessed through other browsers.


Expected results:

The Infowindow should have shown on click of the location marker.
Bug: Snippets broken in Nightly 74
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-01-16 09:58:49+00:00
Resolved: 2020-02-07 07:49:31+00:00

#### Affected versions:

Nightly 74.0a1 (2020-01-16)
#### Affected platforms:

ALL

#### Preconditions:
Have the "browser.newtabpage.activity-stream.asrouter.devtoolsEnabled" pref set to "true" in the "about:config" page.

#### Steps:

  1. Navigate to the "about:newtab#asrouter" page and select the "snippets_local_testing" from the "Messages" section's dropdown menu.
  2. Click the "Show" button from the "SIMPLE_TEST_1" section.

#### Actual result:

The "SIMPLE_TEST_1" snippet is displayed in the bottom part of the browser but there is no hyperlink.
#### Expected result:

The body text of the snippet should contain a hyperlink in the right part of the firefox icon.

Please see also the following bug, might be related to this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1601880

#### Regression range:
Last good revision: 72bc4f39b6598b06925c9a3372a5076f5e6f78ab
First bad revision: 01fde39940c3d8baa41dc747bf4454cf312be78c
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=72bc4f39b6598b06925c9a3372a5076f5e6f78ab&tochange=01fde39940c3d8baa41dc747bf4454cf312be78c
Bug: Firefox does not generate an accessibility tree for PDFs
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-01-16 12:28:40+00:00
Resolved: 2022-07-28 21:41:08+00:00

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

Steps to reproduce:

Run NVDA on Windows 10
Visit https://www.pdfa.org/wp-content/uploads/2019/09/PDF-Association-flyer-A4.pdf in Firefox - this PDF file is known to be tagged for accessibility.
Use the standard keyboard input controls for browsing the document (e.g. H for headings) or inspect the Accessibility tree in the dev tools


Actual results:

Document semantics, aria roles, accessible names and descriptions are ignored. Dev tools > Accessibility reports the existence of a document, but not much else. It appears that Firefox is not generating an accessibility tree for PDF content, even when the PDF is tagged.


Expected results:

Should be able to navigate the document via its semantics (landmarks, headings etc.) exactly as you can with Adobe Acrobat (using the exact same PDF). Dev tools accessibility should map these semantics as a tree, exactly as it would with a correctly-made HTML or SVG file.
Bug: The new version of Firefox does not allow viewing pdf files; displays dialog rearding how to name the file
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-01-16 13:20:47+00:00
Resolved: 2020-02-06 13:12:13+00:00

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

Steps to reproduce:

I tried to open a pdf file on Firefox. Using my Windows system I did the following:
- once I found the file I wanted to open, I opened a pdf file by using the open with... right click option and selecting "Firefox";
-It opened a new tab, but nothing was shown;


Actual results:

The file was not displayed in the browser in the new tab, and a dialog box popped up showing the file explorer directory and asking how to save the file in my Windows machine  ( I have already the file in my windows system) ;


Expected results:

It should have displayed the file in the new tab in Firefox.
Bug: Pressing Enter when using Bing.com doesn't start the search
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-16 14:32:50+00:00
Resolved: 2020-01-21 19:42:52+00:00

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

Steps to reproduce:

- Launch https://www.bing.com/
- Type your search terms
- Press "Enter"


Actual results:

The search didn't start. We need to click on the "Magnifying Glass" to get the search started.


Expected results:

The search should have started upon pressing the "Enter" key
Bug: 'Pin to the list' tooltip is not correctly positioned
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-01-16 14:57:32+00:00
Resolved: 2020-01-20 08:51:51+00:00

**Affected versions**
* 74.0a1(1/16/2020)
* 73.0b5
* 72.0.1

**Affected platforms**
* Windows 7x64

**Steps to reproduce**
1. Launch Firefox on a dirty profile (or have some browser history saved before going to the next step).
2. Right click on the Firefox icon from the taskbar.
3. Hover on any website from the context menu's "Frequent" section.
4. Hover on the pin icon.

**Expected result**
* The "Pin to the list" tooltip is displayed correctly right beside the cursor.

**Actual result**
* The "Pin to the list" tooltip is displayed over "Pin this program to taskbar" option from the menu.

**Regression range**
* This issue is not a recent regression since I was able to reproduce it on Firefox 69.0b5. I'll come with a regression range asap.

**Additional notes**
* For more details, see the attached screen recording.
* This issue is also reproducible with  Firefox 73.0b5 Developer Edition.
Bug: [Firefox 71] The "Lockwise Moments Page" is wrongly displayed for the users that are connected with a Firefox Account linked to the "Firefox Lockwise" mobile app
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-16 15:00:11+00:00
Resolved: 2020-01-21 16:20:55+00:00

**[Affected versions]:**
- Firefox Release 71

**[Affected Platforms]:**
- Windows 10 x64
- Mac 10.15.2
- Ubuntu 18.04 x64

**[Prerequisites]:**
- Have a Firefox profile older than 30 days.
- Have a Firefox Account that is linked with the Firefox Lockwise app.
- Have the environment set to "Stage" using the "Remote Settings Devtools" add-on (1.2.0) installed from [here](https://github.com/mozilla/remote-settings-devtools/releases).
	
**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Click the "Firefox Account" toolbar and log in with the account from prerequisites.
3. Restart the browser and wait ~10 minutes.
4. Restart the browser and observe the behavior.

**[Expected result]:**
- The browser is successfully restarted and no other page is opened.

**[Actual result]:**
- The browser is restarted and the "Lockwise Moments Page" is also opened.

**[Notes]:**
- This issue is not reproducible with the latest Firefox Release 72.0.1, latest Firefox Beta 73.0b5, or with the latest Firefox Nightly 74.0a1.
Bug: [Regression] Gah. Your tab just crashed. + Firefox has just been updated in the background. Click Restart Firefox to complete the update.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-01-16 16:36:49+00:00
Resolved: 2020-09-08 20:12:31+00:00

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

Steps to reproduce:

upgrade from 69* to any newer version, either packaged one via os updates or tar.bz2 downloaded from mozilla website

*version 69.0.3+build1-0ubuntu1 in ubuntu 19.10 eoan amd64

ubuntu@wsl1:~/nightly/firefox$ apt policy firefox
firefox:
  Installed: 69.0.3+build1-0ubuntu1
  Candidate: 72.0.1+build1-0ubuntu0.19.10.1
  Version table:
     72.0.1+build1-0ubuntu0.19.10.1 500
        500 http://archive.ubuntu.com/ubuntu eoan-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu eoan-security/main amd64 Packages
 *** 69.0.3+build1-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
        100 /var/lib/dpkg/status

it does not matter if I create a fresh profile, same results, any version above 69 behaves the same


Actual results:

firefox shows messages:

1. in a separate tab:

Nightly has just been updated in the background. Click Restart Nightly to complete the update.

2. in other tab:
Gah. Your tab just crashed.



Expected results:

just keep working
Bug: Desktop Firefox - users accessing any website with DNS-Over-HTTPS enabled are vulnerable to a Web Activity leakage through HTTP Requests
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-01-16 17:03:18+00:00
Resolved: 2020-02-04 02:43:37+00:00

From bug 1609329 comment 4, reported by "rgfulw":

After some research, this issue also affects Desktop platforms.
'HTTPS Everywhere' was just encrypting the HTTP request. Resolved by temp disabling the add-on.

The HTTP request is not sent when modifying the URL address on the same tab, only when the user opens another tab and enters an address.
This will explain why the success rate was not 100%.

Something interesting, the HTTP request does not send if user manually enters 'HTTPS://' before URL.
If user simply enters 'test.com' then the HTTP request is sent disclosing the DNS hostname inside, even though user has DoH enabled.
If the user enters 'https://test.com' then the HTTP request is not sent, or maybe just encrypted.

Again, no other tested Desktop browsers display this behaviour.

Debian & Windows tested, MacOS to be tested.

WINDOWS DEMO: -
Using Firefox 72.0.1

*DoH Disabled*
Step 1.)    Setting up listener with Wireshark. [0:00 - 0:10sec]
Step 2.)    User opens Firefox and accesses site 'duckduckgo.com'. [0:10 - 0:14sec]
Step 3.)    Stop packet capture, view captured data. [0:14 - 0:19sec]
Step 4.)    Proof DNS requests are unencrypted, and HTTP request is sent. [0:19 - 0:29sec]

*DoH Enabled - Both browser and system, to ensure DNS requests are encrypted*
Step 5.)    Setup DNS-Over-HTTPS encryption. [0:29 - 1:09sec]
Step 6.)    User opens Firefox and access site 'duckduckgo.com'. [1:09 - 1:15sec]
Step 7.)    Proof DNS requests are encrypted, and HTTP request is sent with DNS name inside. [1:15 - 1:32sec]

(In reply to rgfulw from comment #5)
> Windows: - https://mega.nz/#!k5Yw3YAa!OlFtZEHt3rT75Jna8JgG11CIKGlvhAlBEI_uMwMZDJs
Bug: Redhat Linux EL 6.10 Firefox v68, Set as Desktop Background not working - Dialog appears and allows but image not actually set
Status: UNCONFIRMED
Priority: P3
Created: 2020-01-16 18:32:32+00:00
Resolved: 2022-10-11 23:51:12+00:00

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

Steps to reproduce:

run Firefox, searched for desktop backgrounds, pulled up the page with an image I liked, right clicked on image and selected Set as Desktop Background.  The dialog pops up where you can set the position and color.  Clicked on Set as Desktop Background button on the dialog.


Actual results:

Nothing, the dialog goes away and the desktop background is not set.


Expected results:

The image should have been set as the background image for the desktop.
Bug: Can not edit or delete bookmarks, no error msg
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-16 19:57:42+00:00
Resolved: 2020-01-22 09:35:13+00:00

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

Steps to reproduce:

First I tried to delete a bookmark from my Bm toolbar: right click -> delete. Nothing happened. Then I tried to edit properties of the same bookmark (right click -> properties). I got the Edit popup filled with the data of my bookmark, I edited and clicked Save, the Edit popup gone and again: nothing happened. Also tried to do it on several bookmarks and from the Top menu -> Bookmarks but no luck. I don't get any error message.

I'm on FF 72.0.1 x64 on latest Win 10 Ent.


Actual results:

Nothing. I mean, the bookmark I wanted to delete or modify is still there untouched and I didn't get any error message.


Expected results:

Bookmarks should be removed or edited.