av9ash/GitBugs huggingface dataset:
Bug: Zoom is not applied on dropdown list items
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-11 13:08:25+00:00
Resolved: 2021-06-11 13:16:56+00:00

Tested with:
Nightly 91.0a1 (2021-06-10)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf:  https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3. Click on "+" icon to zoom in the pdf

Actual result:
 Zoom is not applied on dropdown list items and the text is blurry. See screenshot

Expected result:
Zoom should be applied in dropdown list items as in Adobe Reader.
Bug: [XFA & AcroForm] Zoom is not applied on dropdown list items
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-11 13:08:36+00:00
Resolved: 2023-06-02 15:21:38+00:00

Tested with:
Nightly 91.0a1 (2021-06-10)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf:  https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3. Click on "+" icon to zoom in the pdf

Actual result:
 Zoom is not applied on dropdown list items and the text is blurry. See screenshot

Expected result:
Zoom should be applied in dropdown list items as in Adobe Reader.
Bug: The “Make Firefox my default browser” primary button for Upgrading users should not be displayed if the “browser.shell.checkDefaultBrowser” pref is set to false
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-11 13:14:28+00:00
Resolved: 2021-10-15 13:53:07+00:00

**[Notes]:**
- The issue is not reproducible for the “about:welcome” page.
- The issue is also reproducible with the 2nd modal from the “Keep in Dock”, or “Pin to taskbar” Upgrading users flow. 

**[Affected Versions]:**
- Firefox Release 89.0 (Build ID: 20210527174632)
- Firefox Beta 90.0b5 (Build ID: 20210608185546)
- Firefox Nightly 91.0a1 (Build ID: 20210610094936) 


**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.4
- Ubuntu Linux 20.04


**[Prerequisites]:**
- Have Firefox Beta 89 installed and pinned.
- Have the `browser.shell.checkDefaultBrowser` pref set to `false`.

**[Steps to reproduce]:**

1. Open the Firefox browser with the profile from prerequisites.
2. Upgrade the browser to the latest version and observe the primary button.

**[Expected results]:**
- The “Choose a theme” primary button is displayed.
    
**[Actual results]:**
- The “Make Firefox my default browser” primary button is displayed.

**[Additional Notes]:**
- Attached a screen recording of the issue.
Bug: Missing text from radio button on pdf
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-11 13:25:26+00:00
Resolved: 2022-04-07 19:58:37+00:00

Tested with:
Nightly 91.0a1 (2021-06-10)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3. Go to "Personal details" section

Actual result:
"Yes" message is missing from the radio button. See screenshot

Expected result:
"Yes" message should be displayed on the radio button.
Bug: Text is unclear/pixelated when you open a pdf in Firefox
Status: NEW
Priority: P3
Created: 2021-06-11 13:47:08+00:00
Resolved: 2024-02-27 11:59:52+00:00

Tested with:
Nightly 91.0a1 (2021-06-10)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033

Actual result:
Text is unclear/pixelated in pdf. See screenshot

Expected result:
The text should be readable as in Adobe Reader.
Bug: The telemetry pings are wrongly duplicated if any button from the "about:welcome" page is double-clicked
Status: NEW
Priority: P3
Created: 2021-06-11 13:59:13+00:00
Resolved: 2023-11-20 23:12:01+00:00

**[Affected versions]:**
- Firefox Release 89.0 - Build ID: 20210527174632
- Firefox Beta 90.0b5 - Build ID: 20210608185546
- Firefox Nightly 91.0a1 - Build ID: 20210608185546

**[Affected Platforms]:**
- Windows 10 x64
- macOS 10.15.7
- Linux Mint 20 x64

**[Prerequisites]:**
- Have a new Firefox profile with the `browser.ping-centre.log` pref set to `true` in the "about:config" page.
- Have the "Browser Console" opened.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Double click the "Not now" button from the "about:welcome" page.
3. Focus the "Browser Console" and observe the displayed telemetry pings.

**[Expected result]:**
- Only one "CLICK_BUTTON" telemetry ping is displayed.
 
**[Actual result]:**
- Two "CLICK_BUTTON" telemetry pings of the same type are displayed.

**[Notes]:**
- This issue is reproducible with all the buttons from the "about:welcome" page.
- This issue is not reproducible with the "Make Firefox my default browser" and the "Import from previous browser" buttons.
- We have verified using a local telemetry server that the duplicated telemetry pings are sent to the server.
- Attached a screen recording of the issue.
Bug: Updated passwords are not Saved by FireFox
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-11 14:28:44+00:00
Resolved: 2021-07-01 11:00:00+00:00

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

Steps to reproduce:

Had to reset password for site. Have logged in multiple times since but FireFox always refills old password


Actual results:

new password not updated by Firefox


Expected results:

FireFox should ask to update password as it used to.
Bug: Preferences set by users before enrolling into an experiment which uses the same value are deleted/reset at unenrollment
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-06-11 16:52:10+00:00
Resolved: 2021-10-12 14:21:39+00:00

**[Affected Versions]:**
- Firefox Beta 90.0b6 (Build ID: 20210610185818)
- Firefox Nightly 91.0a1 (Build ID: 20210610215038)

**[Affected Platforms]:**
- Windows 10
- Linux Mint 20
- macOS 11.1

**[Prerequisites]:**
- Have a Normandy default type recipe for an experiment that will create some preferences with values not default to Firefox. 
E.g. default type recipe for:
 “browser.topsites.experiment.ebay-2020-1” to “true”
- Have a user.js file that will enroll you in the experiment.
- Have Firefox open (not enrolled in study).

**[Steps to reproduce]:**
1. Navigate to “about:config”
2. Create preferences with the experiment values (i.e. “browser.topsites.experiment.ebay-2020-1” to “true”)
3. Restart the browser.
4. Open the “Profile Directory” folder and copy the user.js file from prerequisites there.
5. Restart Firefox.
6. Navigate to “about:studies” and unenroll from the study.
7. Restart Firefox.
8. Go to "about:config" and observe the preferences.

**[Expected result]:**
- Preferences set before enrolling are kept on user value after unenrollment.

**[Actual result]:**
- Preferences set before enrolling are deleted after unenrollment if they have the same value as the one used by that branch.
Bug: The browser crashes when loading a specific PDF + XFA file
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-11 18:10:25+00:00
Resolved: 2021-07-08 10:57:53+00:00

**Note**
* When the user activates XFA support and attempts to open a specific PDF with XFA file, he will notice that a very long loading is observed, but eventually crashes.

**Affected versions**
* Nightly v91.0a1 2021-06-10

**Affected platforms**
* all

**Steps to reproduce**
1. Launch browser
2. Flip pdfjs.enableXFA to true in about:config
3. Attempt to open the "REQUEST FOR A CHANGE OF SEX OR GENDER IDENTIFIER" from www.canada.ca

**Expected result**
* The PDF is properly displayed.

**Actual result**
* The browser loads for a long time and eventually crashes.

**Regression range**
* Unfortunately, mozregression kept getting stuck and I could not finish the process, so I got all the info in the log and put it here:
* Nightly v90.0a1 (2021-05-03) displays the "unsupported" message.
* Nightly v90.0a1 (2021-05-20) correctly displays the PDF file.
* Nightly v91.0a1 (2021-06-01, 06-09) correctly displays the PDF file.
* Nightly v91.0a1 (2021-06-10) shows the issue described above.
* Regression range: 
2021-06-11T20:58:51.882000: INFO : Narrowed nightly regression window from [2021-06-08, 2021-06-10] (2 days) to [2021-06-09, 2021-06-10] (1 days) (~0 steps left)
Bisecting on mozilla-central [578715b6 - 8508c35e]
Bug: Captive portal detection incorrect
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-11 18:11:22+00:00
Resolved: 2021-07-14 17:53:52+00:00

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

Steps to reproduce:

Connect to internet via employer VPN. Open firefox to any site.


Actual results:

Bar appears below bookmarks bar indicating captive portal detection.


Expected results:

Nothing. No captive portal present. This was not happening prior to updating to firefox 89. No apparent change to the VPN setup on user end.
Bug: Firefox is displaying buttons rather than tabs in the tabstrip
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-11 18:14:39+00:00
Resolved: 2021-08-10 12:42:20+00:00

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

Steps to reproduce:

I launched the browser (Nightly 91 on MacOS)


Actual results:

The browser displays buttons in the tabstrip


Expected results:

Tabstrips should contain tabs
Bug: Help button is cut off in Page Info window
Status: NEW
Priority: --
Created: 2021-06-11 19:16:34+00:00
Resolved: 2023-04-11 10:07:15+00:00

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

Steps to reproduce:

Firefox 91.0a1 (2021-06-11) (64-bit) Nightly, on Fedora 33, GNOME, Wayland.
Open "Page Info" window for any website.


Actual results:

Bottom half of "Help" button doesn't fit in window.


Expected results:

Window should be big enough to fit all controls, including "Help" button. Also, when reducing window size manually minimum height should fit all controls and not allow hiding them.
Bug: Balrog dry run
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-11 19:28:24+00:00
Resolved: 2021-08-03 21:42:06+00:00

We intend to verify that we continue to have the capacity to ship system add-ons. We will be shipping a dry run add-on that has (nearly) no functionality, on a testing channel.

https://github.com/mozilla-extensions/balrog-dryrun

Using this bug for deployment.
Bug: Silent install continues even if it can't write to install dir
Status: REOPENED
Priority: P3
Created: 2021-06-11 19:36:50+00:00
Resolved: 2021-10-20 20:29:21+00:00

Steps:

1. Have UAC enabled at a default (prompt for system changes) level
2. Run the full install with `/S`
3. Decline the elevation prompt

The installation will attempt to proceed in Program Files, and it will fail, but a Mozilla Firefox / Firefox Nightly shortcut will still appear on the desktop. Probably there are other operations that are performed that should not be.

A silent install isn't expected to succeed without elevation because we only attempt to use a local path in [LeaveOptionsCommon](https://searchfox.org/mozilla-central/rev/78f4bb0d4d2c95ad302d54d78c77a223fea6ccb2/toolkit/mozapps/installer/windows/nsis/common.nsh#6222-6234), which only runs as part of the GUI (see also 1703180). But also in silent mode we don't abort the install if we can't write to the install dir, as the CanWriteToInstallDir checks are only done in [PreDirectoryCommon](https://searchfox.org/mozilla-central/rev/78f4bb0d4d2c95ad302d54d78c77a223fea6ccb2/toolkit/mozapps/installer/windows/nsis/common.nsh#6284) and [LeaveDirectoryCommon](https://searchfox.org/mozilla-central/rev/78f4bb0d4d2c95ad302d54d78c77a223fea6ccb2/toolkit/mozapps/installer/windows/nsis/common.nsh#6336), which are also part of the GUI.
Bug: Passwords should not Sync from a profile with a Primary Password to a profile without a Primary Password
Status: NEW
Priority: P5
Created: 2021-06-11 20:44:35+00:00
Resolved: 2025-02-17 14:15:32+00:00

A user with a Primary Password setup presumably wants their saved passwords protected with a Primary Password. When Sync is set up it should ensure that passwords transferred from a profile with a Primary Password set should only go to other profiles with a Primary Password set.

Steps to reproduce:
1) Set up a Primary Password.
2) Save some logins and passwords.
3) Set up Sync.
4) Create another profile and Sync the two profiles.

Expected result:
4) The saved passwords are protected by a Primary Password as was requested in step 1.

Actual result:
4) The new profile doesn't require a primary password to be entered to use or see the saved passwords.
Bug: Firefox 89 Downloads Panel - open file destination folder button/area is too small
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2021-06-11 21:55:46+00:00
Resolved: 2025-03-02 14:50:57+00:00

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

Steps to reproduce:

after updating to firefox 89, the browser design/UI changed. I have tried to disable proton in about:config and restart the browser, but that doesn't do any changes.


Actual results:

ISSUE: The Downloads Panel open destination folder button/area is too small about 40-50% than before, previously before updating firefox, you had a whole panel with "no limitation" in height. Screenshot in attachment showing the issue


Expected results:

revert the changes of the downloads file destination folder icon/button/area like in the screenshot attached to this.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_tabToSearch.js | Uncaught exception - Wait for tab key to be handled - timed out after 50 tries.
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-06-11 22:53:54+00:00
Resolved: 2022-07-25 23:16:57+00:00

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

---
```
[task 2021-06-11T21:05:55.545Z] 21:05:55     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_tabToSearch.js | Expected placeholder l10n when search mode is inactive - {"args":{"name":"Google"},"id":"urlbar-placeholder-with-name"} deepEqual {"id":"urlbar-placeholder-with-name","args":{"name":"Google"}} - 
[task 2021-06-11T21:05:55.545Z] 21:05:55     INFO - Leaving test bound activedescendant_arrow
[task 2021-06-11T21:05:55.545Z] 21:05:55     INFO - Entering test bound tab_key_race
[task 2021-06-11T21:05:55.546Z] 21:05:55     INFO - Test typing a letter followed shortly by Tab consistently selects a tab-to-search result
[task 2021-06-11T21:05:55.546Z] 21:05:55     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_tabToSearch.js | Sanity check urlbar is empty - "" == "" - 
[task 2021-06-11T21:05:55.546Z] 21:05:55     INFO - Type the beginning of the search string to get tab-to-search
[task 2021-06-11T21:05:55.547Z] 21:05:55     INFO - Awaiting for the query to start
[task 2021-06-11T21:05:55.547Z] 21:05:55     INFO - Awaiting for the urlbar panel to open
[task 2021-06-11T21:05:55.547Z] 21:05:55     INFO - Buffered messages logged at 21:05:49
[task 2021-06-11T21:05:55.548Z] 21:05:55     INFO - Urlbar panel opened
[task 2021-06-11T21:05:55.548Z] 21:05:55     INFO - Buffered messages finished
[task 2021-06-11T21:05:55.549Z] 21:05:55     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_tabToSearch.js | Uncaught exception - Wait for tab key to be handled - timed out after 50 tries.
```
Bug: Intl.DateTimeFormat not working
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-11 23:53:16+00:00
Resolved: 2021-06-12 00:14:37+00:00

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

Steps to reproduce:

Intl.DateTimeFormat is not workin as expected. We followed the MDM docs for it and notice that Chrome has the documented behavior, but Mozilla does not. 




Actual results:

Steps to reproduce:
1. Go do mozilla docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat

2. Open the dev tools in Firefox to follow the exact instructions from the docs:

const date = new Date(Date.UTC(2020, 11, 20, 3, 23, 16, 738));
console.log(new Intl.DateTimeFormat('en-GB', { dateStyle: 'full', timeStyle: 'long' }).format(date));

3. Notice that the output in the console is "19/12/2020", instead of the expected "Sunday, 20 December 2020 at 14:23:16 GMT+11"


Expected results:

Notice that the output in the console is "19/12/2020", instead of the expected "Sunday, 20 December 2020 at 14:23:16 GMT+11"
Bug: Infortmative Pop Up is in the wrong place
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-12 00:17:16+00:00
Resolved: 2021-06-13 23:33:28+00:00

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



Actual results:

Informative popups such as "this site is slowing down firefox" or "firefox blocked a pop-up" are located ABOVE the UrlBar


Expected results:

Informative popups such as "this site is slowing down firefox" or "firefox blocked a pop-up" should be located ABOVE the web view and UNDER the bars.
Bug: Google Ad Services not connecting/opening
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-12 03:52:19+00:00
Resolved: 2021-07-01 01:41:23+00:00

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

Steps to reproduce:

Tried opening different links that open on the same PC in Edge concurrently without issue


Actual results:

FireFox 89 does not connect or open link


Expected results:

Link should have opened to:

https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwifu7KFkpHxAhWSrsgKHVqUBjEYABAEGgJxdQ&ohost=www.google.com&cid=CAESPuD2srcjiwZ7G0YFep5ZxA14moGtVvlfjrCRH2SDzzeLbcudNDzCOw-tJ9x1HBX-rAF4QnT6jOueH5qbqbEu&sig=AOD64_2jvBD4f-Aplsl64x_d-GW-Wj8Frg&ctype=5&q=&ved=2ahUKEwib6amFkpHxAhXLneAKHZ0OBGEQ9aACegQIARBF&adurl=
Bug: Search box randomly huge until I restart FF
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-12 05:47:01+00:00
Resolved: 2021-06-14 19:35:00+00:00

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

Steps to reproduce:

I really have no idea, sometimes it happens after just a few minutes, other times it happens after several hours.

https://www.reddit.com/r/firefox/comments/nx87fh/why_does_my_search_sometimes_randomly_get/


Actual results:

https://i.imgur.com/7wL7CHR.png

Search box becomes humongous until FF is restarted. 


Expected results:

Search box stays the proper size
Bug: When dragging the url to the bookmarks bar the mouse arrow does not enter the box I have to release it and it goes to the end of the list I have to cut and paste the url on top because it does not drag in the box.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-12 13:11:04+00:00
Resolved: 2021-07-05 06:58:55+00:00

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

Steps to reproduce:

When dragging the url to the bookmarks bar the mouse arrow does not enter the box I have to release it and it goes to the end of the list I have to cut and paste the url on top because it does not drag in the box.
Bug: Opening large data uri based image with "open image in new tab" can be very slow
Status: NEW
Priority: --
Created: 2021-06-12 15:39:00+00:00
Resolved: 2024-04-04 02:07:56+00:00

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

Steps to reproduce:

This is probably a niche use case. I'm using TiddlyWiki, which displays images to the user via data:// URIs. When I right click a large (14MB PNG) image to "open image in new tab" ...


Actual results:

The browser became unresponsive for several seconds. There is also a noticeable delay for the right click menu to appear.


Expected results:

The browser should not become unresponsive, or the operation should be faster.
Bug: Firefox v89.0 violates/ignores Title Bar Color Standard set in Microsoft Windows settings
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-12 15:41:34+00:00
Resolved: 2021-06-13 13:18:22+00:00

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

Steps to reproduce:

What did I do? Nothing.  FF v89.0 installed unconditionally, and the Title Bar color that I've used for many years, a Win standard, was trashed, changed to an extremely light, no-contrast gray.


Actual results:

FF v89.0 installed unconditionally, and the Title Bar color that I've used for many years, a Win standard, was trashed, changed to an extremely light, no-contrast gray.


Expected results:

FF shouldn't make changes to User selected extremely important GUI elements or windows elements, or Windows standard elements.  Ever!  Changing an important GUI element to a no-contrast color is Bad design!  The Title Bar is used to change window size and location, it must be easily located, it must be distinguishable from other nearby elements.

I'm attaching a screenshot of how Title Bar color is selected.  I've picked RED because that's what this is, a major fault!  Since inception until 88.0 FF got it right, then came 89.0.
Bug: ui.key.chromeAccess = 5 no longer honored
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-12 17:19:42+00:00
Resolved: 2023-06-05 16:29:55+00:00

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

Steps to reproduce:

Steps to reproduce:

* Set ui.key.chromeAccess to 5 [Alt+Shift]. (Note: default is 4 [Alt])
* Restart Firefox.
* Press Alt+S.


Actual results:

History menu opens.


Expected results:

No menu should open. The History menu should require Alt+Shift+S and not respond to Alt+S.

I’ve set ui.key.contentAccess to 4 and ui.key.chromeAccess to 5 (the reverse of the default) because I use websites more than I use the browser chrome. This has always worked in prior versions but broke in version 89.0. Now, a website that uses accesskey='s' can no longer be used by the keyboard shortcut without unwantedly opening the History menu.

Setting the new option ui.key.menuAccessKey to 0 does not address my issue because that disables the menu entirely.
Bug: Freeze ver 89 Mint Linux using windy.com in draw_perspective_spans
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-12 20:11:21+00:00
Resolved: 2021-06-28 12:25:54+00:00

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

Steps to reproduce:

visit site windy.com
change location, click anywhere 


Actual results:

ff becomes unresponsive
close ff from system monitor
restart ff, do not restore session
open other sites...no issue 



Expected results:

windy.com worked normally in previous version with same system...eg Mint 19.3 Cinnamon
Bug: Exit while downloading dialog box has not been updated to Proton UI
Status: NEW
Priority: P3
Created: 2021-06-13 03:27:02+00:00
Resolved: 2021-07-23 13:26:47+00:00

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

Steps to reproduce:

I started downloading a file and tried to close Firefox.


Actual results:

It displayed the dialog box in the older style, screenshot is attached to this bug


Expected results:

It should have displayed in the Proton UI, similar to how the dialog box for multiple tabs displays.