av9ash/GitBugs huggingface dataset:
Bug: NOT REFRESH GOOGLE PAGE
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-27 08:13:51+00:00
Resolved: 2020-11-27 18:01:28+00:00

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

Steps to reproduce:

PRESS F5 ON GOOGLE PAGE


Actual results:

THE PAGE DIDN`T REFRESHED


Expected results:

THE PAGE SHOULD REFRESH
Bug: Using policy in registry have some glitches...
Status: RESOLVED
Priority: P5
Resolution: WONTFIX
Created: 2020-11-27 15:47:17+00:00
Resolved: 2021-11-01 16:09:04+00:00

I know i'm in a corner case, but i hope this info can be useful anyway to improve firefox.

I'm trying to install and manage extensions with the new Policy, but using direct windows registry editing, not the json file or the GPO (that currently i don't have).

I've found two 'bugs', or at least strangeness (errors come from Help -> Troubleshoot page, i was able to clik on 'Corporate policies' (on 'Active') and lead to a 'policy debug page'):

1) if there's an EMPTY hive (eg: no key defined in this hive) like:
        HKLM\SOFTWARE\Policies\Mozilla\Firefox\Extensions\Install
        HKLM\SOFTWARE\Policies\Mozilla\Firefox\Extensions\Locked
firefox start but on the debug page there's an error, say 'empty array'.

2) if in these hive i create a key type REG_SZ NOT called '1', the debug page emit the error:
  Array expected but not received
and:
  Invalid parameters specified for Extensions.

Note that it suffices to have *ONE* key called '1', all subsequent keys can be called as you want, and woks as expected. This seems a bit strange to me.

Note that i triggered this using direct registry editing, but because GPO get written exactly to HKLM\SOFTWARE\Policies\Mozilla\Firefox, could be that this can be triggered also via GPO.

I've extensively tested this on TB78, but seems the same behaviour happen on FF78.

I hope i was clear. Thanks.
Bug: FF 83 search takes two hands (or tortured clicks)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-11-27 16:42:14+00:00
Resolved: 2020-12-01 19:45:36+00:00

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

Steps to reproduce:


I found about 8 posts like this one (https://www.reddit.com/r/firefox/comments/jwnkae/this_new_crap_i_want_to_go_directly_to_website/) the day after FF 83 came out and made the custom-search feature unusable by normal/sane software usability standards since a single mouse click is no longer enough.

This press release announces the questionable change: https://www.mozilla.org/en-US/firefox/83.0/releasenotes/

A web browser link is a one-click paradigm. It's not 3D modeling software that we use for work with one hand on a keyboard and one hand on a mouse. It's for relaxed reading type activity.

When FF makes these changes we wonder if Mozilla is now bought out by Google and is trying to make FF unusable to make Google's browser more attractive.


Actual results:

Clicked Wikipedia icon to search Wikipedia, nothing happens, doubts own sanity.


Expected results:

Search Wikipedia.
Bug: Investigate removing alternate fixup to avoid Firefox redirecting http://https://.. to http://https.com/ (or other malware sites)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-11-27 16:53:24+00:00
Resolved: 2022-12-19 17:09:36+00:00

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

Steps to reproduce:

Type the following into the address bar:  http://https://mozilla.org/


Actual results:

Firefox redirected to http://https.com/ , which then redirects to a number of malware sites.


Expected results:

Firefox should have indicated a syntax error in the URL (or perhaps taken some other action).  I understand the motivation to "guess" what website the user wanted to visit by appending dot-com to the end of the server name.  However, it appears that https.com is currently owned by a bad actor and certainly is NOT what a user is expecting to visit if, for whatever reason, the string, "http://" is appended to the front of a legitimate URL.
Bug: 'Do this automatically for files like this...' doesn't work
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-27 17:45:45+00:00
Resolved: 2020-12-10 13:18:06+00:00

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

Steps to reproduce:

- Click a PDF download link

-When the dialog asking how to handle opens, Check `Do this automatically for files like this from now on`

- Click another PDF link

Note that this happens on Windows, and Manjaro Gnome Linux, across multiple Firefox versions.


Actual results:

The same dialog opens


Expected results:

The PDF should open using the option selected in the first dialog
Bug: ublock origin button and settings crash on 84beta1 through beta5
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-11-27 21:59:11+00:00
Resolved: 2025-03-02 14:51:42+00:00

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

Steps to reproduce:

clicking on ublock origin button in firefox toolbar or launching preferences


Actual results:

blank window and/or tab/app crashes


Expected results:

clicking the taskbar button should bring up the usual ublock origin controls, and selecting preferences should bring up the preference pane with available settings
Bug: Intermittent browser/base/content/test/tabs/browser_privilegedmozilla_process_pref.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-11-27 23:14:53+00:00
Resolved: 2023-07-03 12:01:56+00:00

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

---
```
[task 2020-11-27T20:35:22.067Z] 20:35:22     INFO - TEST-PASS | browser/base/content/test/tabs/browser_privilegedmozilla_process_pref.js | Parent and child process should agree on the remote type. - 
[task 2020-11-27T20:35:22.067Z] 20:35:22     INFO - Buffered messages logged at 20:35:21
[task 2020-11-27T20:35:22.067Z] 20:35:22     INFO - TEST-PASS | browser/base/content/test/tabs/browser_privilegedmozilla_process_pref.js | Check that privileged page is in privileged mozilla content process after location change. - 
[task 2020-11-27T20:35:22.067Z] 20:35:22     INFO - Leaving test bound process_switching_through_navigation_features
[task 2020-11-27T20:35:22.068Z] 20:35:22     INFO - Buffered messages finished
[task 2020-11-27T20:35:22.068Z] 20:35:22     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_privilegedmozilla_process_pref.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2020-11-27T20:35:22.069Z] 20:35:22     INFO - GECKO(1768) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2020-11-27T20:35:22.069Z] 20:35:22     INFO - GECKO(1768) | MEMORY STAT | vsize 7634MB | residentFast 273MB | heapAllocated 98MB
[task 2020-11-27T20:35:22.069Z] 20:35:22     INFO - TEST-OK | browser/base/content/test/tabs/browser_privilegedmozilla_process_pref.js | took 74920ms
[task 2020-11-27T20:35:22.069Z] 20:35:22     INFO - checking window state
[task 2020-11-27T20:35:22.144Z] 20:35:22     INFO - TEST-START | browser/base/content/test/tabs/browser_privilegedmozilla_process_pref.js
[task 2020-11-27T20:36:35.145Z] 20:36:35     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-11-27T20:36:35.146Z] 20:36:35     INFO - Buffered messages logged at 20:35:22
[task 2020-11-27T20:36:35.146Z] 20:36:35     INFO - Entering test bound setup
[task 2020-11-27T20:36:35.146Z] 20:36:35     INFO - Leaving test bound setup
[task 2020-11-27T20:36:35.146Z] 20:36:35     INFO - Entering test bound webpages_in_privileged_content_process
[task 2020-11-27T20:36:35.146Z] 20:36:35     INFO - Buffered messages logged at 20:35:23```
Bug: Garbled text in xterm screen
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-11-28 01:04:11+00:00
Resolved: 2021-03-29 17:23:48+00:00

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

Steps to reproduce:

Use an XTerm console on a website.


Actual results:

Text is garbled and unreadable.


Expected results:

Text should be readable in console.
Bug: page info dialog claims http://thepiratebay.org has a certificate when visited in a private browsing window
Status: RESOLVED
Priority: --
Resolution: INACTIVE
Created: 2020-11-28 11:44:48+00:00
Resolved: 2022-06-01 18:09:59+00:00

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

Steps to reproduce:

Enter http://thepiratebay.org
It does several redirections


Actual results:

It shows the site is insecure and uses http yet clicking on more details shows a valid certificate


Expected results:

It should have shown https and not http and not mark any secure errors
Bug: Regression: Address Bar keeps focus after a search with new Search Buttons
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-11-28 18:12:22+00:00
Resolved: 2020-12-08 15:03:39+00:00

Nightly 85.0a1 (2020-11-28) (64-Bit)
MacOS 10.15.7

Steps to reproduce:

1.) type google into the Address Bar
2.) arrow down until you focus the new Google Search Button
3.) press Enter to clean up the Result List
4.) now type e.g. mozilla 
5.) press Enter

Actual: Google Search page opens with "mozilla" results, but the Address Bar keeps still focus.

Expected: The Address Bar should not have focus. The Page should have focus instead.

A screencast is attached.

This is a regression in latest Tring. Works fine in latest Firefox Stable.

Thanks for checking.
Bug: Get msg that indicates page isn't HTTPS when it is.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-11-28 18:54:49+00:00
Resolved: 2021-01-06 12:56:26+00:00

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

Steps to reproduce:

Try to go to any page (after enabling FF's own force HTTPS) 


Actual results:

and get a message that the page is not HTTPS, even though the address URL says it IS. 


Expected results:

Should go directly to the page without the 2 step process.
Bug: Firefox does not bring up the "save bookmark" dialog when bookmarking a page
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-11-28 22:25:40+00:00
Resolved: 2020-11-29 21:30:53+00:00

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

Steps to reproduce:

Navigate to a website that I want to bookmark
Go to the Bookmarks menu and select "bookmark this page"


Actual results:

Firefox automatically places the bookmark in "other bookmarks" instead of showing the "add bookmark" dialog window. This not only prevents me from choosing a folder in the bookmarks menu to put the bookmark in, it also prevents the bookmark from appearing in the bookmarks menu at all

This has been a problem on this PC since I first installed Firefox on it and that was Firefox 78, and this issue is yet to be resolved. 

Firefox installations that have been around since 2019 are unaffected.


Expected results:

Firefox should bring up the add bookmark menu and I should be allowed to place the bookmark in any folder in the bookmarks menu that I want. Also, these bookmarks should appear in the bookmark menu without me needing to manually move it out of "other bookmarks"
Bug: Comments in PDF viewer sometimes not shown (are streakthroughs in same line the problem?)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-11-29 18:11:25+00:00
Resolved: 2020-12-15 16:52:55+00:00

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

Steps to reproduce:

Opened a PDF Document that had comments (annotations for added text and strikethroughs for deleted text). The program by which the document was edited is not known.


Actual results:

Hoovering over a strikethrough (displayed as text with red strikethrough) resulted in a reddish pop-up with the name of the commenter. Hoovering over some annotations (displayed as yellow highlighter) caused a yellowish pop-up with the content of the annotations and the name of the commenter, but hoovering over other annotations, which had a strikethrough in the same line as the annotations, caused a reddish pop-up with just the name of the commenter to appear, so that the content of the annotations doesn't show up. But this didn't happen to every comment with a strikethrough in the same line, but just with some of them.


Expected results:

The expected result would be that all annotations would show a yellowish pop-up after hoovering over them, which would contain the text added by the commenter. 
This was tested in Adobe Acrobat Reader DC, where it worked correctly, so it's probably not a problem of the PDF document itself.

The attached picture contains 2 photos (because the pop-ups don't show in screenshots) of one annotation that doesn't work (no text shows up, and red colour of strikethrough) and one that works correctly despite of the strikethrough on the same line.
Bug: `@bing 하나` unexpectedly opens Google instead of Bing with Korean IME
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-11-29 18:12:13+00:00
Resolved: 2021-03-03 01:13:01+00:00

1. Get a new profile and Microsoft Korean IME (or optionally install [Nalgaeset IME](http://moogi.new21.org/bin/Ngs1010Setup_x64.msi) because it reproduces consistently on it while it's intermittent on MS IME)
2. Type "@bing 하나" (GKSK in QWERTY)
3. Tap Enter key while the composition is not finished yet (in other words, while the underline exists)

Expected: A search page with Bing
Actual: A search page with Google
Bug: Search engine selection unexpectedly disappears when composition starts
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-11-29 18:16:36+00:00
Resolved: 2020-11-30 17:12:40+00:00

1. Type @ on the address bar
2. Select any search engine by tapping arrow down button
3. Start typing with Korean/Japanese/Chinese IMEs in Hangul/Kana/Pinyin mode

Expected: The search engine should be kept selected
Actual: The selection disappears
Bug: Firefox 83.0 opens new window instead of new tab when following target="_blank" link
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-11-30 00:41:29+00:00
Resolved: 2020-12-10 10:55:37+00:00

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

Steps to reproduce:

Click a target="_blank" link.
This occurs in any websites. For example:
https://ss1.xrea.com/ango.g3.xrea.com/jkkn/firefox_bug.html


Actual results:

The link opens in new window instead of new tab


Expected results:

The link should be opened in new tab
Bug: Intermittent browser/components/pocket/test/browser_pocket_ui_check.js | application terminated with exit code -6
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2020-11-30 03:06:44+00:00
Resolved: 2021-03-01 06:39:00+00:00

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

---
```
[task 2020-11-30T02:33:21.013Z] 02:33:21     INFO - TEST-PASS | browser/components/pocket/test/browser_pocket_ui_check.js | element appMenu-library-pocket-button is present - 
[task 2020-11-30T02:33:21.013Z] 02:33:21     INFO - checking content context menu
[task 2020-11-30T02:33:21.013Z] 02:33:21     INFO - TEST-PASS | browser/components/pocket/test/browser_pocket_ui_check.js | element pocket-button is present - 
[task 2020-11-30T02:33:21.013Z] 02:33:21     INFO - TEST-PASS | browser/components/pocket/test/browser_pocket_ui_check.js | element context-pocket is present - 
[task 2020-11-30T02:33:21.013Z] 02:33:21     INFO - Buffered messages finished
[task 2020-11-30T02:33:21.015Z] 02:33:21    ERROR - TEST-UNEXPECTED-FAIL | browser/components/pocket/test/browser_pocket_ui_check.js | application terminated with exit code -6
[task 2020-11-30T02:33:21.015Z] 02:33:21     INFO - runtests.py | Application ran for: 0:00:12.971296```
Bug: `browser.showPersonalToolbar` in distribution.ini no longer works
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-11-30 05:27:15+00:00
Resolved: 2020-12-14 08:37:22+00:00

The pref was first introduced in bug 1239949.

A similar Enterprise policy was updated as part of bug 727668's patch [1], but not this one.

[1]: https://hg.mozilla.org/mozilla-central/diff/45bbeabb0c89/browser/components/enterprisepolicies/Policies.jsm
Bug: Remove delay until download OK button becomes enabled
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-11-30 14:53:28+00:00
Resolved: 2020-12-10 19:38:57+00:00

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

Steps to reproduce:

Download a file.


Actual results:

When the download dialog pops up, the OK button to go ahead with the download is disabled. Two things are wrong:

1) It doesn't start the download ahead of time before clicking the OK button.
2) The OK button is disabled for a second or so, before it's possible to click it.


Expected results:

The OK button doesn't need to be disabled for a second. This is only annoying to those who want to quickly download something. There is no need to require the user to wait until the OK button is enabled.

There is no security gain. There is no usability gain. This delay until the button becomes enabled should be removed.
Bug: un-blocklisted addon is not re-added in search service
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-11-30 19:26:09+00:00
Resolved: 2021-03-03 23:46:13+00:00

If an addon is blockisted, then un-blocklisted (e.g. via update), the engine is not added back into the search service.  

It will get added back upon restart, so I suspect this is a low severity.  However, it may also be an issue for an addon that adds a search engine during an update (v1 doesn't have an engine, v2 does), which I'd give a higher severity for.

The reason is that it is seen by the search service as an upgrade and it attempts to upgrade an engine that it does not have.

https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/toolkit/components/search/SearchService.jsm#1638-1643

STR
1. disable blocklist
2. install an addon that would be blocked
3. enable blocklist
4. verify addon is blocked, engine is removed
5. install/update to a version that is not blocklisted

EXPECTED:
engine is listed in search (about:preferences)

ACTUAL:
engine is not listed in search
Bug: Slow page loading in new tab, stuck "waiting to transmit response"
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-11-30 22:27:01+00:00
Resolved: 2021-01-12 14:36:15+00:00

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

Steps to reproduce:

OS: Kubuntu Linux 20.04 Kernel 5.4.0-54-generic
Basic Steps
- open new tab
- go to any website

My test setup using the firefox profiler
- use firefox safe mode
- have test url in clipboard (e.g. https://httpbin.org/get)
- press CTRL + T to open new tab
- press CTRL + SHIFT + 1 to start profiler
- press CTRL + V and ENTER to open page
- notice long initial loading


Actual results:

Significantly longer initial load time (1000 - 4000 ms). Only happens once per new tab. Afterwards pages load quickly in that tab. Also happens in safe mode.

Firefox profiler shows that a long time is spent in "Waiting to transmit response".
Profiler dump1 (target httpbin.org): https://share.firefox.dev/3fSGpyv
Profiler dump2 (target mozilla.org firefox logo):  https://share.firefox.dev/3oaUr1f


Expected results:

Pages should not load slow when opened in new tab
Bug: pinned tabs prevent deletion of session cookie
Status: REOPENED
Priority: --
Created: 2020-12-01 09:11:44+00:00
Resolved: 2022-02-04 09:10:42+00:00

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

Steps to reproduce:

- Create a webserver with a *session* cookie expiration setting
(session cookies by design should expire when the session is closed !)
- pin a tab (I pinned a gmail tab) in firefox
- open a tab from the webserver with the session cookie, the session cookie would be a new cookie
- close firefox, and restart it, ensure that the firefox session save function is diabled
- reopen firefox, revisit the website with a session cookie, this cookie *WOULD NOT HAVE EXPIRED* because of the pinned tab

also, I'm clearly not the first person to have this problem
see : https://stackoverflow.com/a/64140760/6743697


Actual results:

Session cookie did not expire when firefox restarted because of a pinned tab, this is a security risk as this could mean that people could keep pinned tabs in a browser, and browsers would keep login information even in sites where "remember me" was disabled (and essentially sites that use a session cookie)

this problem does not occur when there are no pinned tabs, and session cookies expire normally




Expected results:

the session cookie should have expired
Bug: JavaScript error: resource://normandy/lib/PreferenceExperiments.jsm, line 223: TypeError: can't convert undefined to object
Status: NEW
Priority: --
Created: 2020-12-01 09:25:02+00:00
Resolved: 2021-10-25 15:23:03+00:00

When running Marionette tests I can always see the following line in the logging output during Firefox startup:

```
JavaScript error: resource://normandy/lib/PreferenceExperiments.jsm, line 223: TypeError: can't convert undefined to object
```

The affected code is here:

https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/toolkit/components/normandy/lib/PreferenceExperiments.jsm#223

Note that Marionette sets `app.normandy.api_url` to an empty string, but that shouldn't affect `store.data.experiments` to be undefined, right?
Bug: Intermittent missing cursor in URL bar when opening a new tab
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-12-01 16:55:22+00:00
Resolved: 2020-12-09 21:23:24+00:00

This happens to me very rarely and I am not sure how to debug it.

I think the steps are usually something like this, but I can't reliably reproduce:
- Press CTRL + T
- Start typing

The URL bar basically behaves like normal, even giving me autocomplete results, but the cursor is missing or invisible.

Doing almost anything like trying to take a screenshot usually makes the cursor appear again.
Bug: Screen sharing requester to big to fit screen
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-12-01 17:14:31+00:00
Resolved: 2022-10-13 22:16:19+00:00

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

Steps to reproduce:

Version in use: firefox-82.0.2-1.fc34.aarch64
Device: PINEPHONE
Display: Landscapemode
Resolution at that time: 720*1440 

Videoconference with Meet Jitsi. 
ScreenSharing opening -> Big requester "without" lower Buttons => unuseable :D


Actual results:

nothing. It's not closeable, it's not deny- or permitable ( out of sight ) 


Expected results:

Scaled requesterwindow to fit into screen space.
Bug: Blocking visiting a site via policy should block Save Link As
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-12-01 19:43:40+00:00
Resolved: 2021-01-06 13:08:47+00:00

See:

https://github.com/mozilla/policy-templates/issues/714

In Chrome, if a site is blocked via policy, save link as doesn't work.