av9ash/GitBugs huggingface dataset:
Bug: Webpage can fetch moz-extension://fb7e288e-72c9-4b18-bd61-c297a452e942/res/gmail/0.png
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-02-25 19:25:39+00:00
Resolved: 2020-02-26 22:28:21+00:00

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

Steps to reproduce:

1) Install https://addons.mozilla.org/firefox/addon/xnotifier-neo/
2) Open https://jsfiddle.net/tq4jym9x/


Actual results:

The icons 0.png and 1.png are loading from moz-extension://fb7e288e-72c9-4b18-bd61-c297a452e942/res/gmail/


Expected results:

The icons should not load (or are icons are allowed to load?).

If i do in console:
fetch("moz-extension://fb7e288e-72c9-4b18-bd61-c297a452e942/res/gmail/0.png");
no security error is thrown.

But, if i do
fetch("moz-extension://fb7e288e-72c9-4b18-bd61-c297a452e942/res/gmail/");
then it shows an security error.
Bug: https://magmalabs.io redirects to https://www.magmalabs.io in Chrome but not Firefox [SSLCommonNameMismatchHandling]
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-02-25 19:30:09+00:00
Resolved: 2020-10-07 21:39:45+00:00

### Steps to reproduce

1. Load https://magmalabs.io/

### Expected results

https://magmalabs.io/ should redirect to https://www.magmalabs.io/ like Chrome does using its SSLCommonNameMismatchHandling heuristics. Here is a 2016 blog post about Chrome's SSLCommonNameMismatchHandling:

https://medium.com/servertastic/chrome-testing-https-redirect-when-certificate-hostname-is-invalid-925f0974c72b

### Actual results

https://magmalabs.io/ produces a TLS error in Firefox (and Safari and IE11):

> Nightly does not trust this site because it uses a certificate that is not valid for magmalabs.io. The certificate is only valid for the following names: m.magmalabs.io, www.magmalabs.io
>
> Error code: SSL_ERROR_BAD_CERT_DOMAIN

Firefox, Safari, and IE11 seem to be making a more conservative security stance here than Chrome, but this could be a webcompat problem for Firefox.

B.J. Herbison debugged in Chrome a bit and wrote:

> I opened up the Network panel in https://magmalabs.io/ and saw a request for magmalabs.io appear in red with the message Failed, and then it loaded www.magmalabs.io and went on--and it cleared the previous entries as it does when it starts the display of a new page. So it gives up quickly, tries an alternative, and doesn't report the original error to the user.
>
> Actually, going back to the console I find this:
>
> `Redirecting navigation magmalabs.io -> www.magmalabs.io because the server presented a certificate valid for www.magmalabs.io but not for magmalabs.io. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling`
Bug: German spellcheck: systematic error in dictionary  ->  wrong corrections
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-02-25 23:53:16+00:00
Resolved: 2020-02-26 16:25:57+00:00

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

Steps to reproduce:

In a newly installed Manjaro (KDE) I installed the german language pack via pacman.
Then I restarted Firefox and checked: Automatic spell checking in German (Rechtschreibung während der Eingabe überprüfen) was already activated in menu
Einstellungen(Preferences).

I can also reproduce this bug in 'KDE neon 5.18.80 unstable' life linux when installing German language pack via 'Select a language to add'-> German -> 'Anwenden und neu starten'

Reproducible: Always


Actual results:

Automatic spell checking in German worked but I noticed that it's not working correctly: All words that contain the German character 'ß' (sharp s) are marked as misspelled. If you wrongly write same words with 'ss' instead of 'ß' then they are not marked as misspelled.
It seems as if a wrong (maybe special purpose) German dictionary is deployed in which the German character 'ß' is completely ignored, (whereby the other German special characters 'ÄÖÜäöü' are treated normal.)


Expected results:

Correct German spell checking in accordance with the new orthographical form of 1999.
(The clear rule is 'ss' after short vowels like in 'Bass, müssen, Kissen, Fluss',
and 'ß' after long vowels like in 'Straße, gießen, Buße,  stoßen'.)
Bug: Intermittent browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js | iconBox animating -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-02-25 23:55:18+00:00
Resolved: 2020-04-21 17:04:36+00:00

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

---

>[task 2020-02-25T22:07:44.256Z] 22:07:44     INFO - TEST-PASS | browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js | iconBox not active - 
[task 2020-02-25T22:07:44.257Z] 22:07:44     INFO - TEST-PASS | browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js | iconBox not animating - 
[task 2020-02-25T22:07:44.257Z] 22:07:44     INFO - Load a test page containing tracking elements
[task 2020-02-25T22:07:44.257Z] 22:07:44     INFO - Buffered messages logged at 22:07:43
[task 2020-02-25T22:07:44.257Z] 22:07:44     INFO - Console message: [JavaScript Warning: "The resource at “http://trackertest.org/” was blocked because content blocking is enabled." {file: "about:blank" line: 0}]
[task 2020-02-25T22:07:44.257Z] 22:07:44     INFO - TEST-PASS | browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js | iconBox active - 
[task 2020-02-25T22:07:44.257Z] 22:07:44     INFO - Buffered messages finished
[task 2020-02-25T22:07:44.258Z] 22:07:44     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js | iconBox animating - 
[task 2020-02-25T22:07:44.258Z] 22:07:44     INFO - Stack trace:
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochikit/content/browser-test.js:test_ok:1292
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochitests/content/browser/browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js:testTrackingProtectionAnimation:52
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochitests/content/browser/browser/base/content/test/trackingUI/browser_trackingUI_animation_2.js:testPrivateBrowsing:255
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1062
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1097
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:925
[task 2020-02-25T22:07:44.259Z] 22:07:44     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:914
Bug: Spectrum.net now will only load a blank white page.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-02-26 03:54:43+00:00
Resolved: 2020-03-23 00:47:34+00:00

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

Steps to reproduce:

Tried loading many times every time it shows loading wheel then show only blank white page. Tried other browsers and loaded fine.


Actual results:

Attempted to load my home page(http://www.spectrum.net/?domain-redirect=true&tab=My+Channels) and get loading wheel then get only a blank page. Address bar says I am on Spectrum.net but only a white/blank page is displayed.


Expected results:

http://www.spectrum.net/?domain-redirect=true&tab=My+Channels
Up till today has always displayed a Spectrum log-in page.
Bug: Intermittent OSError: [Errno 2] No such file or directory: '/Users/cltbld/tasks/task_XXXX/checkouts/*something*'
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2020-02-26 04:30:41+00:00
Resolved: 2020-03-16 06:22:28+00:00

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

---

[vcs 2020-02-26T04:06:18.119Z]   File "/usr/local/Cellar/mercurial/5.0.1/lib/python2.7/site-packages/mercurial/posix.py", line 597, in makedir
[vcs 2020-02-26T04:06:18.119Z]     os.mkdir(path)
[vcs 2020-02-26T04:06:18.119Z] OSError: [Errno 2] No such file or directory: '/Users/cltbld/tasks/task_1582686150/checkouts/hg-shared/8ba995b74e18334ab3707f27e9eb8f4e37ba3d29/.hg/store/data/browser/components/sessionstore/test'
[vcs 2020-02-26T04:06:18.119Z] abort: No such file or directory: '/Users/cltbld/tasks/task_1582686150/checkouts/hg-shared/8ba995b74e18334ab3707f27e9eb8f4e37ba3d29/.hg/store/data/browser/components/sessionstore/test'
[taskcluster 2020-02-26T04:06:18.174Z]    Exit Code: 255
[taskcluster 2020-02-26T04:06:18.174Z]    User Time: 1m35.085072s
[taskcluster 2020-02-26T04:06:18.174Z]  Kernel Time: 10.224647s
[taskcluster 2020-02-26T04:06:18.174Z]    Wall Time: 2m24.765268684s
[taskcluster 2020-02-26T04:06:18.174Z]       Result: FAILED
[taskcluster 2020-02-26T04:06:18.174Z] === Task Finished ===
[taskcluster 2020-02-26T04:06:18.174Z] Task Duration: 2m24.769313714s
[taskcluster 2020-02-26T04:06:18.174Z] [mounts] Preserving cache: Moving "/Users/cltbld/tasks/task_1582686150/checkouts" to "/Users/cltbld/caches/C-K6NWJ2TmKoVzEPSVsR4w"
[taskcluster:error] exit status 255
Bug: Bookmarks created from bookmark star go into the wrong folder
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-02-26 05:19:45+00:00
Resolved: 2020-02-27 07:52:33+00:00

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

Steps to reproduce:

This bug is hard to describe concisely because I don't know the terminology Mozilla uses for the various parts of the FF UI. I can attach annotated screenshots if this writeup is unclear.

Steps to reproduce:

1. With a bookmarkable page loaded, click on the address bar bookmarking star to create a new bookmark. 

2. Use the "show all the bookmark folders" button (down arrow) to select a target folder for the bookmark.

3. Click done.

4. Navigate to a *different* page.

5. Click on the address bar bookmarking star to create a new bookmark. 

6. Use the folders dropdown menu (NOT "show all the bookmark folders" -- using that part of the UI does not trigger the bug)  to select a target folder for the bookmark. The target folder must be different from the one chosen in step 2.

7. Wait around one second.

8. The selected bookmark shown in the (now closed) folder dropdown menu will jump from the bookmark folder that was chosen in step 6 to the bookmark folder chosen for the *previous* bookmark, in step 2.

9. Click 'done.' The bookmark will be in the folder that FF autoselected in step 8, not the one chosen by the user in step 6.


Additional notes: This bug appears to be profile-specific and appears to be 'contagious' among Firefox installs that share bookmarks using profile synchronization. It first manifested for me on a Windows machine then, some time later, spread to multiple Linux machines that sync their bookmarks. Since this bug broke out on the first profile, it has now spread to another independent profile. The number of bookmarks might be a trigger; this bug has not yet manifested for me on profiles that have only a handful of bookmarks. The two impacted profiles have around 1000 and 100 bookmarks respectively.


Actual results:

See step 9 under the 'what did you do' block of this bug report: the bookmark was placed in the wrong folder.


Expected results:

The bookmark should have been placed in the folder selected in step 6 of the the description given under 'what did you do'
Bug: address bar search term is interpreted as scheme when Firefox runs in an environment where flatpak claims to understand all protocols/schemes
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-02-26 06:24:03+00:00
Resolved: 2024-10-30 07:27:59+00:00

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

Steps to reproduce:

Using the address bar for both search and direct address input (as is the default).

Searching for 

"site:mozilla.org firefox"

as that's a common query for different search engines.


Actual results:

Firefox attempts to open the address "site:mozilla.org firefox", which results in a dialog to open the "site" with the default system handler for this scheme.

The search term is misinterpreted as scheme part of an URL. As soon as the query contains a colon and a character after it, the hint in the address bar changes from "search with x" to "visit q", resulting in the corresponding action.

I know that "//" are not necessarily part of an URI, but I think the space(s) in the search query should make it obvious that the user is not requesting an address directly.


Expected results:

The default search engine should be queried with the query string. I'm marking this as bug rather than feature request because it's a regression.
Bug: Firefox 73 crash
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-02-26 08:32:31+00:00
Resolved: 2023-02-26 09:56:33+00:00

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

Steps to reproduce:

This is another Firefox 73 crash. I could be related to #1616182, although this time I was _downloading_ multiple files.

https://pastebin.com/jQ7WejLp
Bug: tips/interventions -shown telemetry should not be incremented in the provider
Status: NEW
Priority: P3
Created: 2020-02-26 08:43:13+00:00
Resolved: 2020-07-09 04:32:30+00:00

The fact the provider returns a tip/intervention is not enough to tell whether it was shown, it's possible in the meanwhile the search was canceled and the providersManager will ignore those results.
We should probably increment telemetry in the frontend when tips/interventions are effectively shown.
Bug: [Protections Panel] Tracking Protection UI is overlapped in tracking content panel
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-02-26 09:40:18+00:00
Resolved: 2023-02-23 11:56:36+00:00

**Affected versions**
- Firefox 73.0.1
- Firefox 74.0b8
- Firefox 75.0a1

**Affected platforms**
* macOS 10.XX retina based

**Steps to reproduce**
- Precondition - issue is reproducible only on retina based systems

1. Launch Firefox and access [Reddit](https://www.reddit.com/)
2. Open Tracking Protection panel by accessing the shield found in URL bar
3. Disable the protection and wait for the page to reload
4. Open Tracking Protection panel and access tracking content
5. Hover over "Manage protection settings"

**Expected result**
- The list is rendered correctly

**Actual result**
- "Manage protection settings" button is being overlapped on hover

**Regression range**
- Will see for a regression.

**Additional notes**
- The issue can be seen in this [attachment](https://drive.google.com/open?id=1TqJ4CW7yor5kokg0A47b9656BXwB9xyr).
- This is reproducible only on retina mac systems.
Bug: An error occurred during a connection to 10.71.100.16:8009. Cannot communicate securely with peer: no common encryption algorithm(s).  Error code: SSL_ERROR_NO_CYPHER_OVERLAP
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-02-26 10:23:33+00:00
Resolved: 2020-03-23 00:46:49+00:00

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

Steps to reproduce:

I have tried to open the local page with URL https://10.71.100.16:8009


Actual results:

Secure Connection Failed

An error occurred during a connection to 10.71.100.16:8009. Cannot communicate securely with peer: no common encryption algorithm(s).

Error code: SSL_ERROR_NO_CYPHER_OVERLAP

Same URL is working with Chrome, IE brwosers but failing in mozilla



Expected results:

It should have navigated to login page
Bug: The "New Tab" page is wrongly scrolled down if the "Highlights" context menu button is clicked after navigating back to the page
Status: NEW
Priority: P2
Created: 2020-02-26 11:04:56+00:00
Resolved: 2022-10-12 00:00:08+00:00

**[Affected versions]:**
- Firefox Release 73.0.1 Build ID 20200217142647
- Firefox Beta 74.0b7 Build ID 20200221211950
- Firefox Nightly 75.0a1 Build ID 20200225214332

**[Affected Platforms]:**
- Windows 10
- Mac 10.14
- Linux Ubuntu 16.04

**[Prerequisites]:**
- Set “browser.search.region” to “US” or “CA”
- Restart the browser

**[Steps to reproduce]:**
1. Open a New Tab page.
2. Scroll down the page until the “Highlights” section.
3. Click on any of the highlighted cards.
4. Click the “Go back one page” arrow.
5. Click on the context menu button of the same card.

**[Expected result]:**
Context menu button is opened.

**[Actual result]:**
Page is scrolled down. Context menu is not opened (Win and Linux).

**[Notes]:**
- Issue is not reproducible if the Recommended by Pocket sections is disabled.
- On Mac OS, the context menu is displayed, but the scrolling issue remains.
Bug: Add telemetry for downloads and download panel usage
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-02-26 11:49:15+00:00
Resolved: 2022-01-28 08:26:06+00:00

UR revealed that users struggle to find the download panel once a download is made, leading to users redownloading files.
There is no telemetry currently for file downloads or download panel usage to understand how frequent of a use case downloading a file is and how much of a problem finding the download panel is once you achieve a file download.

User stories:
- As a product manager I'd like to understand if file download is a frequent use case, so that I can focus efforts on making it a great experience.
- As a product manager I want to understand if users experience pain when attempting to find doanloaded files, so I can clarify if it could be a churn driver.

Acceptance criteria:
- New telemetry allows identifying share of DAU/MAU that downloads files
- New telemetry allows identifying number of files downloaded per profile per day
- New telemetry allows understanding the ratio number of files downloaded / number of  times download panel was opened per profile
Bug: A saved to Pocket highlight card redirects to 2 different pages at direct click vs. “Open in New (Private) Window” context menu click
Status: NEW
Priority: P2
Created: 2020-02-26 12:16:15+00:00
Resolved: 2024-02-27 16:49:52+00:00

**[Affected versions]:**
- Firefox Release 73.0.1 Build ID 20200217142647
- Firefox Beta 74.0b7 Build ID 20200221211950
- Firefox Nightly 75.0a1 Build ID 20200225214332

**[Affected Platforms]:**
- Windows 10
- Mac 10.14
- Linux Ubuntu 16.04

**[Prerequisites]:**
- Have a card from the Highlights section saved to Pocket.

**[Steps to reproduce]:**
1. Click the saved to pocket card from prerequisites.
2. Click the “Open in a New Window” option from the context menu for the same card.

**[Expected result]:**
Both actions redirect the user to the same page.

**[Actual result]:**
At step 1 the user is redirected to an app.getpocket.com specific page.
At step 2 the user is redirected to the original location of the card.

**[Notes]:**
- Reproducing also for “Open in a New Private Window” option.
- We should show consistency while accessing the same card in different ways.
Bug: [about:logins] Hover effect for [Sort by] button triggered of wrong element
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-02-26 13:37:36+00:00
Resolved: 2020-11-10 17:45:25+00:00

**Affected versions**
* 74.0b8, 75.0a1 (2020-02-26);  

**Affected platforms**
* Windows 10/8.1, Ubuntu 18.04, macOS 10.13;

**Steps to reproduce**
1. Launch Firefox, access about:logins
2. Move the mouse towards the Sort By (Name) button;

**Expected result**
* hover effect triggered when mouse reaches button;

**Actual result**
* hover effect triggered before;

**Regression range**
* will provide one asap;
* might be linked with bug 1584162 at first glimpse;

**Additional notes**
* attached recording with the issue;
Bug: The New folder input field is overextended if previously a long title one was created
Status: NEW
Priority: P5
Created: 2020-02-26 13:52:34+00:00
Resolved: 2024-09-23 15:44:08+00:00

**Affected versions**
* 75.0a1 (2020-02-25)
* 74.0b8
* 73.0

**Affected platforms**
* Windows 10
* macOS 10.15
* Ubuntu 18.04

**Steps to reproduce**
1. Open any site
2. Click on the Star icon inside the address bar
3. Expand the folder section
4. Create a new folder and rename it with a long title (that extends the visible input area)
5. Attempt to create a new folder 

**Expected result**
* The New Folder input field keeps its default size

**Actual result**
* The New Folder input field increases its width

**Regression range**
* First bad:  b0124f06562982dce60b820d95aad23afd5cec90
* Last good: 1e64b8a0c546a49459d404aaf930d5b1f621246a
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1e64b8a0c546a49459d404aaf930d5b1f621246a&tochange=b0124f06562982dce60b820d95aad23afd5cec90

**Additional notes**
*  The scrollbar (when enabled) is already overlapped only by clicking the New folder button, but with the steps mentioned above the input field is way out of bound (see the screenshot)
Bug: "Start New Session" should store existing session in sessionstore-backups
Status: NEW
Priority: P2
Created: 2020-02-26 15:00:20+00:00
Resolved: 2024-01-05 17:37:26+00:00

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

Steps to reproduce:

1. Have an existing session.
2. Restart the browser.
3. Accidentally select "Start New Session" instead of "Restore Session."


Actual results:

The old session was destroyed without a current backup in sessionstore-backups. previous.jsonlz4 and the most recent upgrade.jsonlz4-[DATE] were 8 days old.


Expected results:

The most current existing session should be stored in sessionstore-backups when a user clicks "Start New Session."
Bug: Cards/Section context menu dropdowns overlap snippets when the page is scrolled up
Status: NEW
Priority: P3
Created: 2020-02-26 15:01:51+00:00
Resolved: 2022-10-12 00:00:16+00:00

**[Affected versions]:**
- Firefox Release 73.0.1 Build ID 20200217142647
- Firefox Nightly 75.0a1 Build ID 20200225214332

**[Affected Platforms]:**
- Windows 10
- Mac 10.14
- Linux Ubuntu 16.04

**[Prerequisites]:**
- Have a snippet displayed.

**[Steps to reproduce]:**
1. Open a New Tab page.
2. Scroll down the page. (not necessarily until the bottom)
3. Click on any card context menu button.
4. Scroll up the page.
5. Observe context menu dropdown.

**[Expected result]:**
The context menu dropdown hides under the snippet.

**[Actual result]:**
The context menu dropdown overlaps the snippet.

**[Notes]:**
- The issue is not reproducible while scrolling the page content (with context menu opened) under the search bar layout.