av9ash/GitBugs huggingface dataset:
Bug: User's search term is accidentally sent to ISP without user's consent.
Status: NEW
Priority: P3
Created: 2020-06-02 13:36:09+00:00
Resolved: 2022-08-31 14:59:08+00:00

This is an external bug report received by Duy Khuong via security@mozilla.org:

## Description:
When an user types a search term (e.g. "a-very-sensitive-word") into the address bar and enter, the quick search feature will bring up search results from a search engine (either from Google or DuckDuckGo) which is an expected behavior.
However, the search term ("a-very-sensitive-word") is also "mistakenly" sent to one of the (DNS) servers of the user's ISP. The user's privacy is compromised.

The issue happens even if DoH (DNS over HTTPS) is in place. Even though, this should not happen in any circumstances, with or without DoH. Any information users type or search for must not not be sent out (especially to the ISP) without the users' consent.

## Other observation:
- The issue only happens when the search term is ONE word ("word", "one-word", "many-words-without-spaces"... are eligible ones).
- The issue does not occur when the search term consist of multiple words (i.e. "this will not cause the issue").
- ISP's server address is set (by default) as one of the "Connection-specific DNS suffixes". THIS IS THE MOST IMPORTANT POINT!

## Details:
- The user wants the highest level of security & privacy, so he already enabled DoH in Firefox setting.
- He also set DuckDuckGo as the default search engine in Firefox, to protect his privacy.
- He types some random search in the address bar of Firefox.
- He wants to confirm if DoH really works by checking DNS logs (with command "ipconfig /displaydns").
- SURPRISINGLY, the term he used for his search apeared in the DNS log, in one of the queries sent to ISP's servers.

## Analysis:
- An ISP's server address is set as one of the "Connection-specific DNS suffixes", when DHCP is used.
- With a DNS suffix is set, Firefox (mis-)interpret the search term (followed by the suffix, "search-term.[suffix]") as a potentially-valid domain name and therefore sends a DNS query to ask for its IP address.
- The problem is, despite the fact that DoH is enabled by the user, when sending the DNS query, Firefox does not treat the "search-term.[suffix]" in the same way as other domain names and therefore send it in plain text.
- As a consequence, the DNS query is logged and the search-term is recorded and sent to the suffix server (which belongs to ISP), without user's consent.

## Impact/Risk:
- The ISP can track user's activities and use his searching history for the purposes against the user.
- A malicious actor on the network can setup a rogue DHCP server and intentionally set the user's DNS suffixes to one of the attacker's servers. By monitoring that server, the attacker can track the user's activities and use his searching history for malicious purposes (e.g. selling data, advertising, ransom,...)

## Mitigation (temporary workaround until Firefox provides the fix):
- Set IP address manually (do not use DHCP).
- Make sure DNS suffixes do not consist of any unusual addresses.
Bug: Text in about:certificate page is unreadable in OS dark mode - default theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-02 15:00:46+00:00
Resolved: 2020-06-03 05:57:26+00:00

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

Steps to reproduce:

On Windows 10 64-bit dark mode, open Firefox using default theme, and then navigate to about:certificate page.


Actual results:

The elements "<about-certificate-items>" have a white text under a white-grayish background. This makes it impossible to read the texts


Expected results:

The elements "<about-certificate-items>" have text with better color contrast with its background
Bug: Disable URL bar expanding with Firefox 77
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-06-02 15:05:58+00:00
Resolved: 2020-08-18 08:23:41+00:00

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

Steps to reproduce:

With Firefox 76, we can:

- Type in the address bar about:config and press Enter (ignore the warning)
- Type in the search bar and look for these preferences: browser.urlbar.openViewOnFocus
browser.urlbar.update1
browser.urlbar.update1.interventions
browser.urlbar.update1.searchTips
- and set its value to false

Then close and restart Firefox.


Actual results:

With Firefox 77, this does not work.
What is the solution?


Expected results:

URL bar expanding must be disabled.
Bug: Intermittent TEST-UNEXPECTED-FAIL karma | activity-stream:ASRouter:#init should migrate provider impressions to group impressions: expected {} to have property 'onboarding'
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-06-02 17:38:39+00:00
Resolved: 2020-06-30 19:07:46+00:00

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

---

[task 2020-06-02T17:11:56.366Z] npm ERR! errno 1
[task 2020-06-02T17:11:56.366Z] npm ERR! activity-streams@1.14.3 testmc:unit: `karma start karma.mc.config.js`
[task 2020-06-02T17:11:56.366Z] npm ERR! Exit status 1
[task 2020-06-02T17:11:56.366Z] npm ERR! 
[task 2020-06-02T17:11:56.366Z] npm ERR! Failed at the activity-streams@1.14.3 testmc:unit script.
[task 2020-06-02T17:11:56.366Z] npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
[task 2020-06-02T17:11:56.366Z] 
[task 2020-06-02T17:11:56.366Z] npm ERR! A complete log of this run can be found in:
[task 2020-06-02T17:11:56.366Z] npm ERR!     /builds/worker/.npm/_logs/2020-06-02T17_11_56_341Z-debug.log
[task 2020-06-02T17:11:56.381Z] TEST-UNEXPECTED-FAIL karma | activity-stream:ASRouter:#init should migrate provider impressions to group impressions: expected {} to have property 'onboarding'
[task 2020-06-02T17:11:56.381Z] AssertionError@http://localhost:9876/base/node_modules/chai/chai.js?db92883971379fbea71a12c25b271c26a3afc3f6:9449:13
[task 2020-06-02T17:11:56.381Z] [3]</module.exports/Assertion.prototype.assert@http://localhost:9876/base/node_modules/chai/chai.js?db92883971379fbea71a12c25b271c26a3afc3f6:239:13
[task 2020-06-02T17:11:56.381Z] assertProperty@http://localhost:9876/base/node_modules/chai/chai.js?db92883971379fbea71a12c25b271c26a3afc3f6:2227:12
[task 2020-06-02T17:11:56.381Z] methodWrapper@http://localhost:9876/base/node_modules/chai/chai.js?db92883971379fbea71a12c25b271c26a3afc3f6:7824:25
[task 2020-06-02T17:11:56.381Z] [6]</module.exports/assert.property@http://localhost:9876/base/node_modules/chai/chai.js?db92883971379fbea71a12c25b271c26a3afc3f6:5442:60
[task 2020-06-02T17:11:56.382Z] @http://localhost:9876/base/test/unit/unit-entry.js?8094dae78ea2f4248975e7011dda26db4001b247:107005:14
[task 2020-06-02T17:11:56.382Z] 
[task 2020-06-02T17:11:56.383Z] { checkBundles: true, karma: false }
[task 2020-06-02T17:11:56.383Z] CODE 1
[taskcluster 2020-06-02 17:11:56.878Z] === Task Finished ===
[taskcluster 2020-06-02 17:11:56.878Z] Unsuccessful task run with exit code: 1 completed in 784.786 seconds
Bug: aboutNetError triggers full l10n fallback chain just to check if a string exists
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-06-02 18:37:20+00:00
Resolved: 2020-07-08 01:33:55+00:00

Regressed by bug 1622269.

The issue is in https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/browser/base/content/aboutNetError.js#180-191

This code calls asynchronous localization method to check if the string with a given ID exists in the codebase.

This is an anti-pattern, because Fluent has a sophisticated lazy mechanisms to react to missing strings. In particular, it triggers loading of the fallback locale. In today's world in practice that may not seem like a lot, but as we improve our multilingualism, we'll get users with longer chain of locales that will all be loaded one by one just to verify that this string doesn't exist in any of them.

Instead, this code should have a list of known IDs and just check against it.
Bug: It's possible to screen-capture the next tab after tab close
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-06-02 19:39:50+00:00
Resolved: 2022-05-15 02:18:32+00:00

From bug 1641802 comment 4, when screen-capturing the Firefox window (or the "Entire screen" with Firefox on it), JS may capture a split second ***after*** tab close, capturing the next tab shown. This is not POLA, and could be exploited to put users' privacy at risk.

STRs:
 1. Open a random victim tab, e.g. https://gokitty.com
 2. Open https://fiddle.jshell.net/jib1/0sjrmkuh/show
 3. Click the `Capture screen!` button, and select the Firefox window (or Entire Desktop) + Allow
 4. Close the fiddle tab.
 5. Re-open the fiddle tab.

Expected result:
* A screen-grab of the fiddle tab

Actual result:
* A screen-grab of gokitty.com

I've tried it on both Windows 10 and macOS 10.15.4. My success-rate is about 1/5 times.

Similarly, I've tried sending the capture to another tab over WebRTC (open [this](https://jsfiddle.net/jib1/w3L7ujpo/) in two tabs), but not had success reproing that way. Although, this being timing-related, we perhaps shouldn't rule it out.

The repro fiddle doesn't work in release for some reason (`uncaught exception: Object`), it's unclear why. But this weakness is most likely not a regression, and an exploit that works in release could presumably be written.
Bug: Can't login to Scotiabank (page just refreshes)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-02 19:55:13+00:00
Resolved: 2020-08-04 13:21:31+00:00

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

Steps to reproduce:

When I attempt to login to Scotiabank
https://www.scotiaonline.scotiabank.com/online/authentication/authentication.bns
I click the Sign In button and it the screen rapidly refreshes but doesn't log in.
Apparently Scotiabank is doing something with their login system so this may be related.

We are getting the same result on two computers with FF 77.

It works with Chrome on the same computer.

May be similar to the issue with Royal Bank in FF73?  (bug 1613943)


Actual results:

Screen refreshes.


Expected results:

Should login to Scotiabank and display accounts.
Bug: Youtube subs tiles
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-02 21:30:03+00:00
Resolved: 2020-06-29 20:06:35+00:00

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

Steps to reproduce:

Do not switch the list of YouTube subscriptions. After refreshing the page, it remains in the "tiles" mode


Actual results:

After i close tab or open in new tab YT it's set to tiles again.


Expected results:

Switch view to list mode and save it
Bug: Ensure PEM file is stripped of all data before import
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-06-02 21:39:57+00:00
Resolved: 2020-07-13 15:29:50+00:00

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

Steps to reproduce:

Firefox 77.0 on openSUSE 15.1:

Update policies.json to automatically install/trust my CA certificate.
    "Certificates": {
      "Install": ["/path/to/my/certificates/myca.pem"]
    }

Verified the certificate file is valid via: openssl x509 -in /path/to/my/certificates/myca.pem -text -noout


Actual results:

about:policies shows the following Policy Error:
Unable to add certificate - /path/to/my/certificates/myca.pem

Browser console shows:
Policies.jsm: Unable to add certificate - /path/to/my/certificates/myca.pem Policies.jsm:284


Expected results:

Firefox should add this CA certificate to its trust store and not show this error.

There is nothing in the documentation on what logging module will help debug this.  I tried pipnss:4 but that did not log anything related.
Bug: [meta] Remove ALL references of blacklist/whitelist within Gecko
Status: NEW
Priority: P3
Created: 2020-06-02 21:40:35+00:00
Resolved: 2023-07-24 10:59:24+00:00

It's widely accepted that black and whitelist is outdated and Edge reportedly has removed it: https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/b/blacklist

There are many other examples too like https://whatwg.org/style-guide#tone

There have been many attempts to follow suit in Firefox codebase and it now feels time to remove all the remainder.

This is a meta bug to find, remove and prevent all further references to this use of language.
Bug: Web extensions can't edit headers since firefox 77
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-02 21:59:46+00:00
Resolved: 2020-06-02 22:13:24+00:00

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

Steps to reproduce:

I'm the owner of this web extension
https://addons.mozilla.org/fr/firefox/addon/ignore-x-frame-options-header/

This web ext edits the header "Content-Security-Policy" to remove the "frame-ancestor" rule.

Since firefox 77, any edition done to the header value by a webextension are ignored

How to reproduce:

create a demo webext with this in background.js : 
(this demo shows for content-security-policy but it would bug alsoon others)

function setHeader(e) {
	var headersdo = {
		"content-security-policy":(x=>{
			x.value = x.value.replace(/frame-ancestors[^;]*;?/, "frame-ancestors *;")
			return true;
		}),
		"x-frame-options":(x=>{return false})
	}
	e.responseHeaders= e.responseHeaders.filter(x=>{
		var a_filter=headersdo[x.name.toLowerCase()];
		return a_filter?a_filter(x):true;
	})
	console.log(e) //Show the header string edited 
  	return {responseHeaders: e.responseHeaders};
}
browser.webRequest.onHeadersReceived.removeListener(setHeader)
browser.webRequest.onHeadersReceived.addListener(setHeader,{urls :   ["<all_urls>"]},["blocking", "responseHeaders"]);

then visit this test page https://www.w3schools.com/code/tryit.asp?filename=GEFNSY7F440P (click run)

You'll see the frame not loading, despite the value set at "frame-ancestors *;"

reference; https://developer.mozilla.org/fr/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onHeadersReceived




Actual results:

Since firefox 77, any edition done to the header value by a web ext are ignored


Expected results:

Any edition done to the header value should have been taken in account
Bug: Rubbish website content on FF 77 32bit
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-02 22:01:52+00:00
Resolved: 2020-06-29 19:16:31+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36

Steps to reproduce:

Visit websites like google.com is broken on Firefox 76.x. 


Actual results:

The website doesn't show. Instead, rubbish content appears
like that

S��2a�����(*{?�)�+��ՙ������ ��?�e;.�������O����%�Y:S�#h��L����ټ��x�y�D�DSa�t�ӽ/�jyƆR�-{08�i�^%P�J ���}������ݗSK�=R$bm,F<3J�m�W<��;��d:��Kp֞�u��ꘒZ[���J78���M���?.�����x��L ������ۑ���u�3�_h�� ��H*~$gP�����^&�D�@vH�W�J� Y�Q*��YRD�-�8���X�Z����zv������L&��DΜ;bHb���_����Viu�1�d�{������+�N|�{@{2�戓0�؎��EL2�N��6���KQt�E������ �$��/I�qιV�j!@���f�,��~i��qρc Mת�z�G�M����m$תY�4����~nI���G�Ru�:������9$5�&��~R%.��bw�ٹ�l�ѬNv&��΂�w��g��rU�+�j�!A��B����ch�O~�/�����y�\x�������^v�G�}����c�"���M�dt~����/������[�y��}[oN�/������K/�������$�@2� ��.O嗆e��h��_6F�W_BW��+��)_���p�t�R�'�D����WŦ���� �����A;�Ե�����YhDaDp1�̩�fw��)}����?j�IL���h�~��X&hY(.;�m������H�T�Q�X� ʺF�ɺnW���1r͂#R��p��o�5�v�����F�Św��$�k�*�����__��t�.�Б/��.a�˺F�ḮQl����{2E��\�*�<�!W��P�����C���Ӭ��]k$#�T��O�)Bw]���R<��0����,T(!N�,�#��!��D���tP���f.l[��N\d,�+t��IK��yKq-�M)6��9QS�\�'䔯'�T�����4m��ҟ����� F`a�j04�����or��'1�,LG� �OSx�BUJ�X��XQ:"�~��1����0�1d�q�� ].�F�("���|�y?D��(@���Fk�%�u��tḾ5��N������N���Ҙ�I͖�raBp|�ꉦS�&B�U��- ��c�Ρ�C�>�\�J�$, !]\/\���XD��j�F�&�DU��@Z5/�n�����!��=|A�]������j ҹ�5�4|�}��e����};�}�J�, o��D�4"�L�i4L�u�$�OYF�r���6A}�K� �פ�y����o2H�M=Z�8�6�]*�J񂉘�]�n�0���p�@7GXt�ڼ�L�������;��H��e��j�u[*��V�(�g]c�'rJ�����>Xf��hϛ2RtB+A�6?:E �w�f"����lm�PJDɫi��DL5l�BZ�B�½���x^��l�0S�����R�˖$�Lt�r1��c�f~�I�XY� ,��9ڒ��@Lv�4�๿as�;Iם߹���V�(�2��7.�AO@zw���Y��D������'{�k`�W�8ik��#�e��<���,��f/��gtډ7H���ϥ뮎y�M��<�;_��n���Wmc)�ه8�\?� }����o�Ѫ@�>�5����8e�d-L�)/ [a�0�u2��hv ��Y_���(m�?�#T�D�:x�U�U�� @Z��4���Z���\��G�B�M��+�=-��R�`*�G� u1i��E�S�x���zQ�_'W��F#P��S�A�& �ħ��s���W�U��V*��nC �PV���QYN����ᲷR�,����Q;p��~~�#��^Й�9�*��51���~@�n�^r�Ua��&,Ye�üt�s��/q�Qa�ƣ�bY�Ų%\w�Kw����s-A)�X��&3���]�._ �ˌ�-ǖ��,ғ��������1e�=�bDq5��p.�7�d*�2Mv����h��ә@5��z@�@ ��V�Ye-�� ��l�x�@��J4���Wo��gO#�/�usۂ�uyẝk�$;�3���9��R��(����tnW���uW�n�rQV�O�����==�<�^�������hx������ۛ0h��GBv}�Fg�8 ��!���k0�=�e�$>�F����K�����zp�����Q������ptu�xu~s�n<��=�sB/�^׳rz�t��ã���q��ip}~X�}�8<�>�?}x��x7}u�k���nuǯM�9gI�lyx{u{s��8r�ϯ�:���n��+�<��_y~����������`�ϋ���o�OJ�ݜ>WF��!q�qt�l�<��m�ϥ֞��~�F�\Z��������������~~}�>Sw�� ���s{�(WW���oO�G~�[�j C���>V�s��z5p d}}�����i:�jD.ꆝ����F��!i(s�]�8Q�GLئ��W u& 2)����Jf�}8Q�{�yj|7o��]�+�;�I�.\�ô���In]?��(Ua��X{��>�v6\������%� C��<>!(\�'kp};�ٙo�yW����y�m����7����3�An_�뻳���KS/w�Ɗ�;~��r@�W���&�{wL���G��� D��k����w^˯���k2��k��������M,����3�h��p��]���;Y����du�dtV�.�x�i�Х���uq_����qե��k'�ר�HW��K����5��G�u�


Expected results:

Normal website loading.
Bug: Minimize button is larger when the camera icon is not displayed
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-06-02 22:11:20+00:00
Resolved: 2020-06-17 23:20:35+00:00

Note

Minimize button is larger when the camera icon is not displayed.

Affected versions

nightly v78.0a1
beta b77.0b8

Affected platforms

Windows 10
Windows 7

Steps to reproduce:
Precond:
privacy.webrtc.allowSilencingNotifications - true
privacy.webrtc.legacyGlobalIndicator - false

Engage in a video conference.
Allow the microphone and camera sharing.
Click on the camera icon from the app to set it off.

Expected result

The area with the minimize button should be by design.

Actual result

The area with the minimize button is larger than in the design. Please see the attached screenshot.

Regression range
It is a feature implementation regression.

Additional notes

This issue is found to reproduce in Hangouts and Zoom apps on Windows 10 and 7.
This bug description will suffer changes in the next few days until feature testing is completed.
Bug: The notifications aren't re-enabled after ending screen-share, but only after ending call
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-06-02 22:14:42+00:00
Resolved: 2020-06-17 21:47:23+00:00

**Note**
* The notifications are only blocked after starting screen-share, but they don't end when screen-sharing is stopped, but only when the call is ended.

**Affected versions**
* Beta v77.0b8
* Nightly v78.0a1

**Affected platforms**
* Windows 10

**Steps to reproduce**
Required prefs:
* Flip privacy.webrtc.allowSilencingNotifications to true
* Flip privacy.webrtc.legacyGlobalIndicator to false

1. Engage in a Video Call in the expected web-app.
2. Click the button to share your screen view.
3. Select the option to share a window/screen from the drop-down.
4. Select the checkbox to silence notifications and allow screen share permission.
5. Receive a notification. (a tool to use: https://davidwalsh.name/demo/notifications-api.php)
Observe: Notifications are blocked as expected.
6. Stop screen-sharing.
7. Receive a notification. (a tool to use: https://davidwalsh.name/demo/notifications-api.php)

**Expected result**
* The notification is displayed because the user is not sharing the screen.

**Actual result**
* The notification is NOT displayed; 
* However notifications received after the call ends are being displayed.

**Regression range**
* Feature implementation issue.

**Additional notes**
* This issue has been found to reproduce with Zoom, Meets on Windows 10 & 7 (so far).
* This bug description will suffer changes (updates) until the feature testing is completed.
Bug: Incorrect overlay size after stop/start the camera while the overlay is minimized
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2020-06-02 22:22:51+00:00
Resolved: 2020-07-20 18:52:54+00:00

#### Affected versions:

Beta 77.0b8
Nightly 78.0a1(2020-05-22)
#### Affected platforms:

Windows 7
Windows 10
#### Preconditions:
  
Flip privacy.webrtc.allowSilencingNotifications to true
Flip privacy.webrtc.legacyGlobalIndicator to false

#### Steps:

  1. Launch firefox and access: https://meet.google.com/
  2. Start a video call and share the screen.
  3. Minimize the overlay
  4. Stop the camera from the web-app's camera button.

#### Actual result:
The overlay is restored having a bigger size (see the overlay bottom part).
#### Expected result:

The overlay should be restored with the same size.
#### Regression range:

It is a feature implementation regression.

Note: The issue is also reproducible on Zoom.
Bug: Global Sharing Overlay can't be brought up after being closed
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2020-06-02 22:36:40+00:00
Resolved: 2020-10-21 16:03:19+00:00

**Preconditions**
* Flip privacy.webrtc.allowSilencingNotifications to true
* Flip privacy.webrtc.legacyGlobalIndicator to false

**Affected versions**
* 77.0b9
* 78.0a1 (2020-05-22)

**Affected platforms**
* Windows 10

**Steps to reproduce**
1. Launch Firefox and access: https://whereby.com/
2. Start a video call.
3. Hover over the Firefox icon in the taskbar.
4. Close the window with the Global Sharing Overlay.

**Expected result**
* The Global Sharing Overlay shouldn't be closable or there should be a way for it to be brought back up.

**Actual result**
* The bar is closed and you can't make it appear again on the same call.

**Regression range**
* It's a feature implementation bug.

From dbodea:

> This new Global Sharing Indicator cannot be closed on MacOS and this seems to be a correct approach; It can be minimized in the dock, but not closed. Furthermore, the old Global Sharing Indicator can't be closed on Windows either, it can just be dragged on the top of the main screen.
>
> It appears that this issue is also reproducing on Ubuntu 18.04.4LTS.
>
> So this is an issue that occurs on both Windows and Linux OSes, but not on MacOS.
This might need a UX opinion, but the impossibility of closing the Global Sharing Overlay might be the best approach. It is how it was previously designed.
Bug: The corners of the Global Sharing Indicator should be rounded, not pointy
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2020-06-02 22:40:03+00:00
Resolved: 2020-09-27 13:54:20+00:00

**Note**
* The Global Sharing Indicator corners should be rounded, not pointy, according to the mockup screenshot.


**Affected versions**
* Beta v77.0b8
*Nightly v78.0a1

**Affected platforms**
* Windows 10
* Windows 7
* most probably also applicable to MacOS/Linux

**Steps to reproduce**
1. Engage in a video call.
2. Allow microphone/camera permission.
Notice that the Overlay is already displayed (on the main screen, above the taskbar, centered horizontally, having pointy corners).
3. Start screen-sharing.
Notice the "Stop Sharing" button and relevant icon+message are added to the overlay.

**Expected result**
* The corners of the Global Sharing Overlay should be rounded.
**Actual result**
* The corners of the Global Sharing Overlay has pointy corners.

**Regression range**
* Implementation bug.