av9ash/GitBugs huggingface dataset:
Bug: about:addons sections are not visible on high contrast mode and dark theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-04 17:47:52+00:00
Resolved: 2023-06-02 15:21:50+00:00

#### Affected versions:

    Nightly 92.0a1 (2021-08-04)

#### Affected platforms:

     MacOS11

#### Preconditions:

    Have High Contrast Black(system settings) and dark theme(build settings) set.


#### Steps to reproduce:

    1. Go to about:addons
    2. Observe the left side of the page(sections side)

#### Expected result:

    The text from the about:addons sections should be visible.

#### Actual result:

     The text from the about:addons sections  (Recommendations, Extensions, Themes, Plugins) text is not visible.
Bug: EME-free 1.0's popup blocker option NOT allowing popups for my 3riversFCU online bank account site
Status: RESOLVED
Priority: P3
Resolution: INCOMPLETE
Created: 2021-08-04 22:38:01+00:00
Resolved: 2022-01-31 10:49:59+00:00

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

Steps to reproduce:

TWIMC:

Hi,
First of all, Mozilla needs to properly vet whomever they are hiring to make this software. It also helps if one THOROUGHLY tests their software BEFORE publishing it!!!
EME's popup blocking option for "CLICKING TO ADD" a blocked url is greyed-out and won't allow a simple click to free-up (white-list?) my DESIRED/NECESSARY url. Also, when trying to MANUALLY add the url to the exceptions list, EME's software SHORTENS/ALTERS the url when saving it which then makes it impossible for the popup blocker software to recognize the url I want to open appropriately.

FG AMATEURS...AARRGGHH!!!

>:(




Actual results:

Wanted to show you a "print screen" file but, for some unknown reason - my win 7 desktop is getting nothing but blacked-out screenshots - no matter what app I am trying to capture a screenshot with the ps button!!




Expected results:

DUU-UUHH!!! TRY READING THE ABOVE STATEMENTS!!!
Bug: Handlers set by policy aren't cleared when the policy is
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-08-05 00:57:46+00:00
Resolved: 2021-08-06 03:44:12+00:00

I'm not sure if this a problem outside of the tests, but it is certainly a problem for Thunderbird in the tests. After running browser_policy_handlers.js, any test that opens about:preferences causes the test to crash by attempting to access www.example.org, because of an icon set on a menulist in the handlers preferences. In Firefox the menulist is hidden until you click on it, so it doesn't attempt to load the icons.

I also don't know why this wasn't happening until yesterday, when a bunch of other tests started failing on us.
Bug: Mozilla Firefox 88.0.1 - File Extension Execution of Arbitrary Code
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-05 01:07:16+00:00
Resolved: 2021-08-05 23:06:51+00:00

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

Steps to reproduce:

# Date: 05/AUG/2021
# Tested on: Windows XP Professional SP3 32-bit, Windows 7 Professional SP1 64- 
   bit, Windows 10 20H2 (build SO 19042.805)
# Mozilla-Firefox-content-type-confusion-unsafe-code-execution

A vulnerability has been identified in the way Mozilla Firefox handles downloaded files on Windows.
Unlike the other most used browsers (Google Chrome, Internet Explorer, Edge), the action Mozilla Firefox takes is based on the "Content-Type" attribute.
Let's consider a scenario in which a server responds to the client in this way:

Content-Type: audio/mpeg
Content-Disposition: attachment; filename="test.jpg"

What one would expect, is that Mozilla Firefox will handle the file as an image (.jpg) but it is not and the "open-with" window will ask the user to open a mp3 file.
By itself, this is not a problem (although we do not agree with the choice), however we have found that in a particular circumstance, it is possible to "confuse" Firefox using a combination of "Content-Type" attribute and file extension which leads to the arbitrary execution of code. Specifically, if a server responds with a "Content-Type: text/html" and a filename that has the extension ".jpg", Mozilla Firefox will show the end user an "open-with" mask, asking to open the jpg file with the default program (usually a browser), but will download the above mentioned file into the system's temporary folder using the extension ".html". Subsequently, the downloaded file will be opened using the default program for .html files (browsers). It is easy to understand that it is possible to create a fake image, containing JavaScript code, which will lead to the execution of the code itself.


Actual results:

As proof of concept, we used the following ready-made python web-server
(server.py):

please find attached (.txt) file 


Expected results:

Then we ran the python script in this way: python server.py test.jpg

Once a user browse the malicious server, Mozilla Firefox will ask for opening the file and, if the user click confirms the operation, the file will be downloaded and executed.
Bug: URLBar use light colors in system dark theme when focused
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-05 02:10:29+00:00
Resolved: 2021-08-10 12:13:25+00:00

STR:

0. Set your Linux OS to use a dark theme (e.g. Adwaita-dark)
0. In Firefox, go to about:addons > theme
0. Enable System theme
0. Focus the urlbar

AB:

The urlbar use the light theme colors instead of the dark theme one

EB:

It should use the dark theme colors

Additional information:

- https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ffeb2a3d80381264c0ad9329b4d07b3f343a4ca&tochange=c7687ceeff3f99555aa7d3f744da33952aef236f
Bug: Firefox 90.0.2 will not load Google Calendar. I have reinstalled and cleared cache, etc.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-08-05 03:15:36+00:00
Resolved: 2021-08-24 20:18:20+00:00

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

Steps to reproduce:

Every time I try to load Google Calendar.


Actual results:

Firefox just grinds but doesn't open Google Calendar. GMail and Drive work just fine.


Expected results:

My Calendar should have opened.
Bug: Intermittent browser/components/sessionstore/test/browser_tabs_in_urlbar.js | Should have found all the tabs - 1 == 0 - JS frame :: chrome/browser/browser/components/sessionstore/test/browser_tabs_in_urlbar.js :: test_unrestored_tabs_listed
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-08-05 05:19:44+00:00
Resolved: 2021-11-09 17:02:11+00:00

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

---
```
[task 2021-08-05T04:04:25.503Z] 04:04:25     INFO - TEST-PASS | browser/components/sessionstore/test/browser_tabs_in_urlbar.js | Should have the found result 'http://example.org/#2' in the expected list of entries - true == true - 
[task 2021-08-05T04:04:25.504Z] 04:04:25     INFO - TEST-PASS | browser/components/sessionstore/test/browser_tabs_in_urlbar.js | Should have the found result 'http://example.org/#3' in the expected list of entries - true == true - 
[task 2021-08-05T04:04:25.504Z] 04:04:25     INFO - Buffered messages finished
[task 2021-08-05T04:04:25.505Z] 04:04:25     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_tabs_in_urlbar.js | Should have found all the tabs - 1 == 0 - JS frame :: chrome://mochitests/content/browser/browser/components/sessionstore/test/browser_tabs_in_urlbar.js :: test_unrestored_tabs_listed :: line 134
[task 2021-08-05T04:04:25.505Z] 04:04:25     INFO - Stack trace:
[task 2021-08-05T04:04:25.505Z] 04:04:25     INFO - chrome://mochitests/content/browser/browser/components/sessionstore/test/browser_tabs_in_urlbar.js:test_unrestored_tabs_listed:134
[task 2021-08-05T04:04:25.506Z] 04:04:25     INFO - Leaving test bound test_unrestored_tabs_listed
[task 2021-08-05T04:04:25.506Z] 04:04:25     INFO - GECKO(2204) | MEMORY STAT | vsize 2104580MB | vsizeMaxContiguous 65105044MB | residentFast 403MB | heapAllocated 136MB
[task 2021-08-05T04:04:25.507Z] 04:04:25     INFO - TEST-OK | browser/components/sessionstore/test/browser_tabs_in_urlbar.js | took 420ms
```
Bug: favicon of not tabs not loaded yet sometimes not shown
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-08-05 07:55:25+00:00
Resolved: 2022-04-06 04:19:20+00:00

Firefox 92.0a1 20210804214554 on Windows 8.1

Starting with Tuesday's or yesterday's build, after a Firefox restart the favicons of still unloaded tabs can be missing, e.g. for docs.google.com or treeherder.mozilla.org. Only tabs which had been recently active are affected.

Setting as regression of bug 1546847, please correct if it isn't.
Bug: AMO Stage/Dev RTAMO flow is broken
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-08-05 08:43:48+00:00
Resolved: 2021-08-31 19:15:49+00:00

[Steps to reproduce]:
    1. Access AMO Stage/Dev on a browser different from Firefox (example: Microsoft Edge) and afterwards the page of a recommended add-on (for testing on Stage https://addons.allizom.org/en-US/firefox/addon/bubbles-for-mozilla-3/ was used AND for testing on Dev https://addons-dev.allizom.org/en-US/firefox/addon/bubbles-for-mozilla-appr/ was used)
    2. Click on the “Download Firefox and get the extension” blue button from the add-on’s page
    3. On the newly opened page, click on the blue “Download Firefox” button
Note: Firefox will be downloaded, installed and will start after the installation is complete
    4. Close Firefox
    5. Download and install the latest Nightly from https://archive.mozilla.org/pub/firefox/nightly/2021/08/ 
    6. Launch Nightly and access about:config
    7. Set the following prefs:
    • xpinstall.signatures.required = false
    • xpinstall.signatures.dev-root = true
    • extensions.getAddons.get.url = https://services.addons.allizom.org/api/v4/addons/search/?guid=%IDS%&lang=%LOCALE% (for Stage)
    • extensions.getAddons.get.url = https://services.addons-dev.allizom.org/api/v4/addons/search/?guid=%IDS%&lang=%LOCALE% (for Dev)
    8. Type about:welcome in the URL bar to reach the RTAMO onboarding page
    9.  Notice that the RTAMO onboarding page is not displayed, but the default about:welcome page
    10.  Go to “C:\Users\#user#\AppData\Local\Mozilla\Firefox and check for the presence of the “postSigningData” file. 
    11. Observe the “postSigningData” file was not created when initializing the RTAMO flow from Stage/Dev.

[Expected results]:
The RTAMO flow should work as intended when initializing it from Stage/Dev.

[Actual results]:
The RTAMO flow is broken when initializing it from Stage/Dev.

NOTES:
    1. The Prod RTAMO flow is undisturbed and works as intended.
    2. Tests were performed on Windows 10 x64 in accordance to the steps from here: https://gist.github.com/pdehaan/71028fb23b3f3d36f8dc55a6cfd2643e
Bug: Undo closed tabs is unreliable after closing multiple tabs
Status: NEW
Priority: --
Created: 2021-08-05 08:50:10+00:00
Resolved: 2021-08-06 05:34:13+00:00

Nightly 92 20210804093931 on macOS

1. Open a new window, and open 4 tabs (e.g. Twitter, Youtube, Reddit, Google), leave another one for the New Tab, for a total of 5 tabs in this window.
2. Select 3 of these tabs (Twitter, Youtube, Reddit) and close them. Then close also Google. You're left with only the New Tab.
3. Press Cmd+Shift+T to reopen the last closed tab (Google).

Step 3 should only reopen Google, but in my case it reopens Twitter and Google.

If I repeat the same steps on a window with more tabs open (8 tabs and 9 pinned), the behavior is yet different (it restores 3 tabs).
Bug: [A11y] The browser crashes when using VoiceOver while focusing the address bar and pressing VO + Shift + Down
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2021-08-05 11:56:09+00:00
Resolved: 2021-08-11 07:54:55+00:00

**Note**
* When the user has VoiceOver activated and focuses the address bar and presses VO + Shift + Down (arrow key), he will notice that the browser will crash.

**Affected versions**
* Nightly v92.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Start VoiceOver.
2. Launch browser.
3. Focus the address bar.
4. VO + Shift + Down

**Expected result**
* The browser does not crash.

**Actual result**
* The browser crashes immediately.
* https://crash-stats.mozilla.org/report/index/bp-c201e553-8ec5-4c2f-8ead-7f47c0210805

**Regression range**
* Appears to be a regression. WIll come back with mozregression results.

**Additional notes**
* This issue does not occur with NVDA (Windows) or ORCA (Ubuntu).
Bug: URL address field and history drop-down suggestions no longer use correct colors in Windows "High Contrast Black" color scheme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-05 11:58:53+00:00
Resolved: 2021-08-06 14:24:22+00:00

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

Steps to reproduce:

1. Set Windows 10 to "High Contrast Black" color scheme (Win+I > Ease of Access > High Contrast > Select a Scheme > "High Contrast Black"
2. In Firefox, press ctrl+t to create a new tab


Actual results:

URL show up as black text on white rather than white text on black as expected in "High Contrast Black" color scheme.

If I start to type in a URL, the suggestions drop-down list is also black text on white.
This only started happening in FF Nightly 2021-08-04.


Expected results:

As in previous versions of FF Nightky, the URL field and drop=down list should be showing white text on a black background.
Bug: menu History > Recently Closed Tabs/Windows: favicons not shown
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-08-05 12:50:33+00:00
Resolved: 2024-09-24 08:03:27+00:00

Latest Firefox 92.0a1 (20210805092724) on Windows 8.1

Bisection confirmed it's a regression from bug 1546847.

Menu "History" > "Recently Close Tabs"/Windows doesn't show the pages' favicons anymore. The frequently visited pages shown in the "History" have their favicons, even if they are the same pages.

Steps to reproduce:
1. Launch Firefox.
2. Open a new tab.
3. Open a page with a favicon, e.g. https://crash-stats.mozilla.org/report/index/e1bbee9b-743a-4353-bbf4-fe72b0210805#allthreads
4. Close the tab.
5. Either press the Alt key and open the menu "History" > "Recently Closed Tabs" or do it from the menu button.
Bug: Recently closed tabs/windows are missing favicons, getClosedTabData returns an integer for "image" instead of a URL
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-05 13:04:04+00:00
Resolved: 2021-08-05 14:31:40+00:00

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

Steps to reproduce:

- Open and close some tabs
- Open the history panel
- Click "Recently closed tabs"


Actual results:

- The closed tab items are missing image attributes.
- The closed tab item is from `SessionStoreInternal.getClosedTabData`. I don't know much about how that works but I can see it's no longer returning complete information. When you check the `image` property from the closed tab data returned by that method, it's an integer like 33, not a URL.


Expected results:

The closed tab/window items should of course have favicons. The closed tab data image's value should be a URL, not a number
Bug: Localized address bar chiclet is not entirely visible with some locales
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-08-05 13:23:13+00:00
Resolved: 2021-08-25 13:15:19+00:00

**Affected versions**
* Nightly 92.0a1 2021-08-04

**Affected platforms**
* Windows 10 64-bit
* Ubuntu 18.04 64-bit

**Steps to reproduce**
1. Download a Firefox localized build (eg: ta, pl)
2. Open a certificate error page (eg: https://wrong.host.badssl.com/)
3. Check the address bar chiclet
4. Narrow browser width to min and verify the address bar chiclet
5. Check if a tooltip is available when the chiclet is not entirely visible

**Expected result**
* As described in Figma, the chiclet text should always be visible, no matter the window size

**Actual result**
* Longer strings are replaced by ellipses even on normal screens 
* On narrow windows, text can be totally replaced by ellipses 
* There is no tooltip for address bar chiclet

**Regression range**
* Not a regression
Bug: Certificate error pages warning triangle is not visible on small viewports
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-08-05 14:49:35+00:00
Resolved: 2022-02-15 10:25:20+00:00

**Affected versions**
* Nightly 92.0a1 2021-08-04

**Affected platforms**
* Windows 10 64-bit
* Ubuntu 18.04 64-bit

**Steps to reproduce**
1. Open a certificate error page (eg: https://wrong.host.badssl.com/)
2.a Zoom in the page (250% or more) / 
2.b Open the warning page in an iframe
2.c Narrow browser width and height
3. Check the plain warning triangle

**Expected result**
* Warning triangle is visible all the time

**Actual result**
* The top part of the warning triangle is hidden

**Regression range**
* Not a regression
Bug: Intermittent browser/components/preferences/tests/browser_security-2.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-08-05 14:55:30+00:00
Resolved: 2021-09-07 17:01:27+00:00

**Filed by:** archaeopteryx [at] coole-files.de
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=347522362&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NupEb4l7TlqMB9FaSGvshg/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2021-08-05T12:30:12.416Z] 12:30:12     INFO - TEST-PASS | browser/components/preferences/tests/browser_security-2.js | malware table has been sorted - ["goog-malware-proto","goog-unwanted-proto","moztest-unwanted-simple","test-malware-simple"] deepEqual ["goog-malware-proto","goog-unwanted-proto","moztest-unwanted-simple","test-malware-simple"] - 
[task 2021-08-05T12:30:12.416Z] 12:30:12     INFO - Buffered messages logged at 12:29:27
[task 2021-08-05T12:30:12.417Z] 12:30:12     INFO - Longer timeout required, waiting longer...  Remaining timeouts: 1
[task 2021-08-05T12:30:12.417Z] 12:30:12     INFO - Buffered messages finished
[task 2021-08-05T12:30:12.418Z] 12:30:12     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_security-2.js | Test timed out - 
[task 2021-08-05T12:30:12.419Z] 12:30:12     INFO - GECKO(4108) | JavaScript error: resource:///modules/sessionstore/ContentSessionStore.jsm, line 467: Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_CONTENT_COLLECT_DATA_MS" was already initialized
[task 2021-08-05T12:30:12.419Z] 12:30:12     INFO - GECKO(4108) | JavaScript error: resource:///modules/sessionstore/ContentSessionStore.jsm, line 473: Error: TelemetryStopwatch: finishing nonexisting stopwatch. Histogram: "FX_SESSION_RESTORE_CONTENT_COLLECT_DATA_MS", key: "historychange"
[task 2021-08-05T12:36:22.440Z] 12:36:22     INFO - Buffered messages finished
[task 2021-08-05T12:36:22.440Z] 12:36:22    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/components/preferences/tests/browser_security-2.js | application timed out after 370 seconds with no output

```
Bug: "Error in parsing the app package." with new MSIX packages
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-08-05 16:26:47+00:00
Resolved: 2021-08-06 21:32:57+00:00

Clearly there's a difference between the (many!) MSIX packages we build in try and what happened in automation last night.  The Windows App Installer reports "Error in parsing the app package.", strongly suggesting that there's an error in the `AppManifest.xml` we're producing.  I will investigate immediately.
Bug: The "Copy Link" hotkey is broken
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-05 19:12:55+00:00
Resolved: 2021-08-06 10:52:36+00:00

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Right click a link and press A.


Actual results:

Nothing.


Expected results:

The link should have been copied to the clipboard.

There is NO replacement key in 88+, repeat NO replacement key. A proposed key on the other side of the keyboard, not reachable by anyone without looking down, reaching across, pressing the key, and resetting youself, is not a replacement. It is not usable, so this issue is still open.
Bug: noscript hiding content ever tho javascript is disabled
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-08-05 19:42:45+00:00
Resolved: 2021-08-06 17:43:32+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.2 Safari/605.1.15

Steps to reproduce:

disable all script domains
load https://cardinalglen.org/owners/register/



Actual results:

<noscript><div id="noscriptmsg">You must have javascript enabled to login!</div></noscript>
is not displayed


Expected results:

<noscript><div id="noscriptmsg">You must have javascript enabled to login!</div></noscript> 
should be displayed
Bug: My previously set default search engine (DDG) is regularly and without my consent automatically replaced on my Mac with Google
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-08-05 20:07:31+00:00
Resolved: 2021-09-06 08:03:53+00:00

User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148

Steps to reproduce:

I set DuckDuckGo as my default browser through Settings and Search. Many times it has been replaced automatically by the Google search engine. I have changed it many times to DDG with the same result. This is defeating the whole point of why I went with Mozilla.


Actual results:

DDG has been replaced automatically by Google without any action by me.


Expected results:

DDG should remain my default search engine and Google should be shut out from manipulating my settings without my knowledge. This should actually be a criminal violation.
Bug: Simplify the responsive design of error pages.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-05 20:28:41+00:00
Resolved: 2021-08-05 20:35:31+00:00

According to:
https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/browser/base/content/certerror/aboutNetError.js#600-602

`vh` doesn't work correctly in iframes, however that may no longer be true. Unfortunately that limitation is causing the the top of the warning triangle to be cut off on high zoom levels, small browser widths and on iframes. After the changes made in Bug 1721658.

If `vh` is working we should be able to replace this JS code with simpler CSS code, and fix the warning triangle visibility problem at the same time.
Bug: Information Disclosure through history logging
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-08-06 05:38:34+00:00
Resolved: 2021-08-06 09:42:38+00:00

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

Steps to reproduce:

1. Open Mozilla Firefox and login to Gmail and start viewing emails
2. Now open View all history in Firefox
3. Check the recent history from Gmail
4. Did you notice the Email URL and Subject is getting listed in history?


Actual results:

All the emails are expected to have subjects and some emails will have some sensitive info in the email subject itself. So there is a possibility that a particular user's PII data is getting leaked through this browser history.

You might think that this needs physical access to the computer, But this is not a targeted attack. An attacker can just go to a browsing cafe and view the browser history.

All the details including email and subject are getting listed in history.

POC: A screenshot is been submitted of the history


Expected results:

History logs must only have the URL data and must not include any user's particular data. It is not intended to have such a behavior.