av9ash/GitBugs huggingface dataset:
Bug: Intermittent browser/base/content/test/protectionsUI/browser_protectionsUI.js | The label is correctly set to Standard. - Got "Custom", expected "Standard"
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-09-27 19:40:00+00:00
Resolved: 2022-01-25 17:02:41+00:00

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

---
```

```
Bug: [Linux]Icons for minimize, maximize, and close buttons are not shown in KDE Plasma 5.23
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2021-09-28 03:23:32+00:00
Resolved: 2021-10-03 16:13:10+00:00

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

Steps to reproduce:

If I hide the title bar, icons for minimize, maximize, and close buttons are not shown and leaves a transparent zone.

I am using KDE git build, not sure if it's caused by the new default theme introduced in Plasma 5.23. Because on Plasma 5.22 the bug does not occur.

Operating System: openSUSE Tumbleweed 20210924
KDE Plasma Version: 5.23.80
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.6-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics
Memory: 15.0 GiB of RAM
Graphics Processor: AMD RENOIR
Bug: ambiguous Expires field in certificate viewing dialog
Status: RESOLVED
Priority: P5
Resolution: INVALID
Created: 2021-09-28 03:40:10+00:00
Resolved: 2021-10-04 16:18:04+00:00

When loading the certificate file at the URL below, with locale en_AU I get a dialog box that says "Expires: 22/09/31" but this is ambiguous, the date could be 2022-09-31 or 2031-09-22 in ISO-8601 format. Only when I expand the "Details" arrow and scroll further down can I get an unambiguous date where I see "Not Valid After: 2031-09-22" in the "Issued Certificate" section.

https://wiki.osuosl.org/_downloads/f644563c3d6314fdb61b3ace1a4be97b/ca.crt
Bug: FIrefox labels MiB file size as MB
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-09-28 07:21:57+00:00
Resolved: 2024-02-02 13:20:15+00:00

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

Steps to reproduce:

Download a file of exactly 8388608 bytes (8 MiB).
(Dummy file attached)


Actual results:

The download prompt shows the file size as 8 MB.


Expected results:

The download prompt should show 8 MiB or 8.4 MB.
Bug: Firefox uses its built-in PDF reader for locally stored files, no matter what is configured
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-09-28 09:54:11+00:00
Resolved: 2021-09-30 13:19:38+00:00

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

Steps to reproduce:

Use File/Open to open a PDF which is stored on my local drive


Actual results:

Firefox uses it's built-in pdf reader, no matter what is configured.


Expected results:

Firefox should act as configured, e.g. ask, what to do (use external program, download, etc.)
If the pdf is stored on some web server, Firefox acts as expected. The bug happens only, when the file is stored locally.
Bug: Hover highlight does not follow cursor in Bookmarks Menu button when context menu is showing
Status: NEW
Priority: P5
Created: 2021-09-28 10:21:39+00:00
Resolved: 2022-01-17 15:41:37+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
Build ID: 20210927153454

### Steps to reproduce
1. In a new profile, put Bookmarks Menu button onto toolbar.
2. Click the button. Right click on a bookmark.
3. Keep the context menu opened, move cursor to another bookmark.
4. (Optional) right click on the new bookmark, select `Open in YYYY` or other operations.

### Expected result
The hover highlight effect should follow the cursor.

### Actual result
(Please refer to the attached screencast.)
The highlight effect stays on the first bookmark.
If I perform step 4, the actions act on the new bookmark instead of the highlighted item, which is expected.

This bug is reproducible in:
1. Bookmarks Menu button
2. Bookmarks Toolbar > `Most Visited` or `Other Bookmarks`
3. Bookmarks in alt-menu
4. Alt-menu in general [1]

but *not* reproducible in:
1. History button on toolbar
2. Individual items on Bookmarks Toolbar
3. Hamburger menu > Bookmarks/History
4. Sidebar > Bookmarks/History

[1]: Other than `Bookmarks`, this bug does not affect much, function-wise, for other alt-menu items since their context menu options are unrelated to the item underneath them. Bookmark's context menu, however, directly corresponds to the item it is triggered on.

### Notes
This is not a Proton bug. I can reproduce it as far back as in 2011-01-01 build.
Bug: Some radio button selections can not be managed using keyboard only navigation
Status: NEW
Priority: --
Created: 2021-09-28 11:07:10+00:00
Resolved: 2023-06-02 15:22:08+00:00

**Note**
* When the user reaches specific radio buttons and attempts to make a selection, he might not be able to select correctly.

**Affected versions**
* Nightly v94.0a1

**Affected platforms**
* Ubuntu 20

**Steps to reproduce**
1. Launch browser.
2. Load https://www.w3.org/WAI/UA/TS/html401/cp0101/0101-RADIO.html
3. Tab through to the radio buttons.
4. Attempt to move the selection to the other radio button using the keyboard.

**Expected result**
* The user is able to make the other selection using the arrow keys.

**Actual result**
* The user is not able to select the other radio button using the keyboard.

**Regression range**
* Not a recent regression.

**Additional notes**
* This issue does not occur on Chrome.
* This test page is an example where the user has to tap the arrow keys more times to reach the next radio button to select it:
http://opensource.perlig.de/tdi/examples/html5form.html
* This is an example where this issue does not reproduce:
http://test.rubywatir.com/radios.php
Bug: Fix highlight/hover state of click-to-open items (with the improvements-to-downloads pref turned on)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-09-28 12:02:22+00:00
Resolved: 2021-10-14 07:12:28+00:00

When I changed the hover state in bug 1715001 I accidentally neglected to change it for the click-to-open-while-still-downloading state (which we're not shipping yet; it's behind the `browser.download.improvements_to_download_panel` pref). It should visually match the hover states for completed downloads.
Bug: The hamburger menu full screen button icon is not updated accordingly if keyboard only navigation is used
Status: NEW
Priority: P3
Created: 2021-09-28 12:35:30+00:00
Resolved: 2021-10-01 14:48:08+00:00

#### Tested with:

Release 92
Beta 93
Nightly 94.0a1 (2021-09-28)
#### Tested on:

Windows 7 

#### Steps:

  1. Using the keyboard only, open the hamburger menu and press the full screen button
  2. Using the keyboard only while in full screen, access the hamburger menu and press the full screen button again in order to exit from the full screen mode.

#### Actual result:

The hamburger menu full screen button icon is not updated accordingly if keyboard only navigation is used.
#### Expected result:

The hamburger menu full screen button icon should be updated correctly, as when the user access it with the mouse.

#### Regression range:
Will try to find the regression range (if its a regression) asap.
Bug: The context menu text is not visible while navigate through the menu with high contrast white on Windows 7
Status: NEW
Priority: --
Created: 2021-09-28 13:22:00+00:00
Resolved: 2023-06-02 15:22:09+00:00

#### Tested with:

Release 92
Beta 93
Nightly 94.0a1 (2021-09-28)
#### Tested on:

Windows 7 

#### Preconditions:
Have the High Contrast White enabled

#### Steps:

   1. Launch Firefox and right click anywhere in order to open the context menu.
   2. Navigate through the context menu.

#### Actual result:

The context menu text is not visible at all while navigate through the menu. 
#### Expected result:

The text should be white on black background. The context menu text should change the color to white while hovering over the text, like the buttons from about:preferences. (see the video attached).

#### Regression range:
Will try to find the regression range (if its a regression) asap.

Note: This is an intermittent issue. I cannot reproduce it every time.
Bug: The address bar secure connection icon is cut off in high contrast on Windows 7
Status: NEW
Priority: --
Created: 2021-09-28 13:44:27+00:00
Resolved: 2023-06-02 15:22:09+00:00

#### Tested with:

Release 92
Beta 93
Nightly 94.0a1 (2021-09-28)
#### Tested on:

Windows 7 

#### Preconditions:
Have the High Contrast White/Black enabled

#### Steps:

   1. Launch Firefox and access https://www.wikipedia.org/
   2. In the address bar, click on the lock icon.

#### Actual result:

The "Connection secure" lock icon is cut off.
#### Expected result:

The "Connection secure" lock should be displayed accordingly as without high contrast enabled.

#### Regression range:
Will try to find the regression range (if its a regression) asap.

#### Note: 
The issue is not reproducible on Windows 10.
Bug: Intermittent [tier 2] browser/base/content/test/tabcrashed/browser_multipleCrashedTabs.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: 2021-09-28 13:46:09+00:00
Resolved: 2023-06-02 12:01:32+00:00

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

---
```
[task 2021-09-28T12:44:19.385Z] 12:44:19     INFO - TEST-PASS | browser/base/content/test/tabcrashed/browser_multipleCrashedTabs.js | Got the expected 'multiple' state. - false == false - 
[task 2021-09-28T12:44:19.385Z] 12:44:19     INFO - Leaving test bound test_multiple_tabcrashed_pages
[task 2021-09-28T12:44:19.386Z] 12:44:19     INFO - Buffered messages finished
[task 2021-09-28T12:44:19.386Z] 12:44:19     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabcrashed/browser_multipleCrashedTabs.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 2021-09-28T12:44:19.387Z] 12:44:19     INFO - GECKO(7504) | MEMORY STAT | vsize 2104342MB | vsizeMaxContiguous 68340600MB | residentFast 289MB | heapAllocated 83MB
[task 2021-09-28T12:44:19.388Z] 12:44:19     INFO - TEST-OK | browser/base/content/test/tabcrashed/browser_multipleCrashedTabs.js | took 50008ms
[task 2021-09-28T12:44:19.389Z] 12:44:19     INFO - checking window state
[task 2021-09-28T12:44:19.389Z] 12:44:19     INFO - TEST-START | browser/base/content/test/tabcrashed/browser_printpreview_crash.js
```
Bug: ORCA does not read the permission door hanger correctly when it is displayed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-09-28 17:06:13+00:00
Resolved: 2021-10-15 21:00:13+00:00

**Note**
* When the attempts to join a WebRTC call while using ORCA Screen Reader, he will notice that, when the permission door hanger is displayed, ORCA will only say "Alert" instead of reading it fully.

**Affected versions**
* Nightly v94.0a1

**Affected platforms**
* Ubuntu 20

**Steps to reproduce**
1. Launch browser and ORCA Screen Reader.
2. Load: whereby.com/olacreola
3. Press Enter to request permissions.
Notice that the permission door hanger is displayed.

**Expected result**
* ORCA Screen Reader reads the whole permission door hanger's text and voices the shortcuts. (Ctrl + B to Block; Ctrl + A to Allow)

**Actual result**
* ORCA Screen Reader only voices "Alert."

**Regression range**
* Appears to be a regression:
Bug 1697295 - Replace camera and microphone labels with icons in WebRTC permission panel when Proton is enabled. r=pbz,Jamie,fluent-reviewers,desktop-theme-reviewers,harry,Gijs
This is not an exhaustive redress of the WebRTC panel. It just replaces the labels
preceding the camera/microphone selectors with icons if Proton is enabled. There's
still a bunch of styling work to do in this panel for Proton, but that will occur
in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D107718
2021-09-28T22:59:25.294000: DEBUG : Did not find a branch, checking all integration branches
2021-09-28T22:59:25.299000: INFO : The bisection is done.
2021-09-28T22:59:25.303000: INFO : Stopped

* Furthermore, on different builds, the doorhanger is read once, and on others it is read twice.

**Additional notes**
* If this regression is resolved, then an enhancement to vocalize the shortcuts/hotkeys should be logged.
Bug: [Windows 7] The reset zoom level button from toolbar zoom controls is not correctly centered in high contrast
Status: NEW
Priority: --
Created: 2021-09-28 17:41:06+00:00
Resolved: 2021-09-28 17:41:06+00:00

#### Tested with:

Release 92
Beta 93
Nightly 94.0a1 (2021-09-28)
#### Tested on:

Windows 7 

#### Preconditions:
Have the High Contrast White/Black enabled

#### Steps:

   1. Launch Firefox and go to customize toolbar.
   2. Add the zoom controls to the toolbar.

#### Actual result:

The reset zoom level button from the toolbar zoom controls is not correctly centered (vertical) with high contrast enabled.
#### Expected result:

The reset zoom level button from the toolbar zoom controls should be correctly centered with high contrast enabled as it is with high contrast disabled.

#### Regression range:
Will try to find the regression range (if its a regression) asap.

#### Note: 
The issue is not reproducible on Windows 10.
Bug: Consider Never Automatically Unloading WebRTC Tabs
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-09-28 23:16:46+00:00
Resolved: 2021-10-24 15:43:57+00:00

Automatically unloading a WebRTC tab seems likely to be an annoyance for users because it will cause users to be disconnected from their calls and possibly miss important information. This is different from typical sites and most video sites that are easily restored to their previous state. Although this has not been a problem on Nightly and Beta so far, it could be a problem when we ship tab unloading to release in 93.

It's not clear to me how much of a risk this for release. If we had to uplift a fix to prevent WebRTC tabs from being unloaded, I expect it would be a small change to have [`usingWebRTC()`](https://searchfox.org/mozilla-central/rev/8db61933e64b13c4a0ae456bcaccbd86a519ccc5/browser/modules/TabUnloader.jsm#77) return `NEVER_DISCARD`.
Bug: browser.urlbar.maxRichResults=0 prevents visiting search engine homepages
Status: NEW
Priority: P5
Created: 2021-09-29 00:09:33+00:00
Resolved: 2021-09-29 18:38:44+00:00

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

Steps to reproduce:

On a stock profile, set `browser.urlbar.maxRichResults` to 0. Then try to visit the homepage of a configured search engine (google.com, duckduckgo.com, etc)


Actual results:

The urlbar is emptied and nothing else happens. The page does not load.

I have attached a screen recording of this behavior.


Expected results:

The website in question should have loaded.
Bug: Intermittent browser/base/content/test/general/browser_bug734076.js | Uncaught exception - at chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug734076.js:31 - TypeError: can't access property "document", content is null
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-09-29 02:47:21+00:00
Resolved: 2022-07-25 23:11:41+00:00

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

---
```
[task 2021-09-29T01:48:50.765Z] 01:48:50     INFO - TEST-START | browser/base/content/test/general/browser_bug734076.js
[task 2021-09-29T01:48:51.575Z] 01:48:51     INFO - TEST-INFO | started process screentopng
[task 2021-09-29T01:48:52.085Z] 01:48:52     INFO - TEST-INFO | screentopng: exit 0
[task 2021-09-29T01:48:52.086Z] 01:48:52     INFO - Buffered messages logged at 01:48:50
[task 2021-09-29T01:48:52.087Z] 01:48:52     INFO - Entering test bound 
[task 2021-09-29T01:48:52.087Z] 01:48:52     INFO - Buffered messages logged at 01:48:51
[task 2021-09-29T01:48:52.088Z] 01:48:52     INFO - Run subtest view image with background image
[task 2021-09-29T01:48:52.089Z] 01:48:52     INFO - Buffered messages finished
[task 2021-09-29T01:48:52.091Z] 01:48:52     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug734076.js | Uncaught exception - at chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug734076.js:31 - TypeError: can't access property "document", content is null
[task 2021-09-29T01:48:52.091Z] 01:48:52     INFO - Stack trace:
[task 2021-09-29T01:48:52.092Z] 01:48:52     INFO - @chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug734076.js:31:31
[task 2021-09-29T01:48:52.093Z] 01:48:52     INFO - execute@resource://specialpowers/SpecialPowersSandbox.jsm:141:12
[task 2021-09-29T01:48:52.093Z] 01:48:52     INFO - _spawnTask@resource://specialpowers/SpecialPowersChild.jsm:1656:15
[task 2021-09-29T01:48:52.094Z] 01:48:52     INFO - receiveMessage@resource://specialpowers/SpecialPowersChild.jsm:310:21
[task 2021-09-29T01:48:52.094Z] 01:48:52     INFO - Leaving test bound 
[task 2021-09-29T01:48:52.095Z] 01:48:52     INFO - GECKO(1554) | MEMORY STAT | vsize 20975844MB | residentFast 1584MB
[task 2021-09-29T01:48:52.095Z] 01:48:52     INFO - TEST-OK | browser/base/content/test/general/browser_bug734076.js | took 823ms
[task 2021-09-29T01:48:52.096Z] 01:48:52     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-09-29T01:48:52.097Z] 01:48:52     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug734076.js | Found an unexpected tab at the end of test run: about:blank - 
```
Bug: Search engine name is not visible on address bar while navigate through the search engine bar with high contrast white
Status: NEW
Priority: --
Created: 2021-09-29 09:25:06+00:00
Resolved: 2021-09-29 09:27:07+00:00

Tested with:
Nightly 94.0a1 (2021-09-28)

Tested on:
Windows 10
Windows 7

Preconditions:
Have the High Contrast White enabled

Steps:
1. Launch Firefox
2. Go to address bar and select one of the search engine.

Actual result:
Search engine name is not visible on address bar while navigate through the search engine bar

Expected result:
Search engine name should appear on address bar while navigate through the search engine bar.

Regression range:
Will try to find the regression range (if its a regression) asap.
Bug: [Windows 7] Multiple about:pages text is not visible in high contrast white
Status: NEW
Priority: --
Created: 2021-09-29 09:55:10+00:00
Resolved: 2023-06-02 15:22:09+00:00

#### Tested with:

Release 92
Beta 93
Nightly 94.0a1 (2021-09-29)
#### Tested on:

Windows 7 

#### Preconditions:
Have the High Contrast White enabled

#### Steps:

   1. Launch Firefox and go to about:policies#documentation.
   2. Hover the mouse over some random policy name.

#### Actual result:

The policy name text is not visible at all.
#### Expected result:
The policy name text should be visible.

#### Regression range:
Will try to find the regression range (if its a regression) asap.

#### Notes: 
1. The issue is not reproducible on Windows 10.
2. The issue is reproducible on multiple about:pages (see comment 1).
Bug: Intermittent toolkit/components/thumbnails/test/browser_thumbnails_storage.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-09-29 10:12:11+00:00
Resolved: 2023-10-27 12:02:18+00:00

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

---
```
[task 2021-09-29T09:10:34.414Z] 09:10:34     INFO - TEST-START | toolkit/components/thumbnails/test/browser_thumbnails_storage.js
[task 2021-09-29T09:11:19.424Z] 09:11:19     INFO - TEST-INFO | started process screenshot
[task 2021-09-29T09:11:19.509Z] 09:11:19     INFO - TEST-INFO | screenshot: exit 0
[task 2021-09-29T09:11:19.515Z] 09:11:19     INFO - Buffered messages logged at 09:10:34
[task 2021-09-29T09:11:19.515Z] 09:11:19     INFO - Entering test bound thumbnails_storage
[task 2021-09-29T09:11:19.515Z] 09:11:19     INFO - Buffered messages finished
[task 2021-09-29T09:11:19.516Z] 09:11:19     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/thumbnails/test/browser_thumbnails_storage.js | Test timed out - 
[task 2021-09-29T09:11:19.517Z] 09:11:19     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-09-29T09:11:19.518Z] 09:11:19     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/thumbnails/test/browser_thumbnails_storage.js | Uncaught exception received from previously timed out test - waitForCondition timer - Waiting for http://mochi.test:8888/ to exist. - still pending at the end of the test
[task 2021-09-29T09:11:19.518Z] 09:11:19     INFO - GECKO(7144) | MEMORY STAT | vsize 2104151MB | vsizeMaxContiguous 65749860MB | residentFast 225MB | heapAllocated 79MB
[task 2021-09-29T09:11:19.519Z] 09:11:19     INFO - TEST-OK | toolkit/components/thumbnails/test/browser_thumbnails_storage.js | took 45053ms
[task 2021-09-29T09:11:19.519Z] 09:11:19     INFO - checking window state
[task 2021-09-29T09:11:19.520Z] 09:11:19     INFO - GECKO(7144) | Completed ShutdownLeaks collections in process 6564
[task 2021-09-29T09:11:19.520Z] 09:11:19     INFO - TEST-START | Shutdown
```
Bug: Denying requestStorageAccess prompt can lead to empty permission panel
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-09-29 10:12:43+00:00
Resolved: 2021-10-15 12:07:11+00:00

Denying a requestStorageAccess permission prompts leads to an invalid site identity / permission panel state. We show a permission indicator, but the permission panel doesn't list any permissions.

I suspect this comes from setting a temporary block when the user denies the prompt. The permission may not have a UI state.

Mozregression points to Bug 1695356.

STR:
1. Set `dom.storage_access.max_concurrent_auto_grants` to `0` to get the storage access prompt on first request.
2. Open https://factual-solar-climb.glitch.me/
3. Click the first button "Request Storage Access and Open a new Window"
4. In the permission prompt that opens, select "Block"

Expected:
The permission icon in the identity section should be hidden. It shouldn't be possible to open the permission panel.

Actual:
The identity section shows a permission icon. Clicking on the permission icon opens the permission panel. The permission panel does not list any permissions.