av9ash/GitBugs huggingface dataset:
Bug: Don't show "Open link" in context menu for invalid domains
Status: NEW
Priority: P5
Created: 2021-03-02 07:44:46+00:00
Resolved: 2024-02-27 15:58:23+00:00

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

Steps to reproduce:

Not long ago, when you wrote "runtime.getBrowserInfo" to the address bar, it would actually try to load a page "https://runtime.getBrowserInfo" instead of searching.
This is now fixed in bug 1080682:
https://bugzilla.mozilla.org/show_bug.cgi?id=1080682

It would be nice to use the same technique to not show "Open link" in the context menu when you select text containing dot.

Steps to reproduce
1) select this text:
runtime.getBrowserInfo
2) right click


Actual results:

The first option should be "Copy".


Expected results:

First option is "Open link", even though it's not a valid link.
Bug: Certain type of entries render erroneously in the download history toolbar menu
Status: NEW
Priority: P3
Created: 2021-03-02 08:52:39+00:00
Resolved: 2021-03-04 13:51:39+00:00

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

Steps to reproduce:

1. Download a file.
2. Delete the downloaded file.
3. Cause the entry for the deleted file to hide in the "Show All Downloads" menu; this can be easily done by downloading more individual files.
4. Cause the entry for the deleted file to appear again; this can be easily done by deleting entries created in step 3.


Actual results:

Entries that appeared in this fashion rendered the "Open Containing Folder" button next to them, as though their related files were still in the file system. The button for those entries disappears after closing and reopening the menu.


Expected results:

The buttons for those entries should have been absent as they were rendered.
Bug: Crash
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-02 09:02:45+00:00
Resolved: 2021-03-02 14:23:28+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36
Firefox for Android
Bug: Fix ASRouter/AboutNewtabParent console error messages
Status: NEW
Priority: P3
Created: 2021-03-02 09:20:21+00:00
Resolved: 2022-09-06 14:42:28+00:00

> AbortError: Actor 'ASRouter' destroyed before query 'NEWTAB_MESSAGE_REQUEST' was resolved

> InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable (AboutNewTabParent.jsm:41)

Issue is I can't find a way to consistently reproduce them. Will follow up.
Bug: If the CSV file contains two identical logins, one login is imported and the other one receives the "missing field" error
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2021-03-02 11:16:13+00:00
Resolved: 2021-03-24 13:36:36+00:00

**[Affected versions]:**
- Firefox Nightly 88.0a1 (Build ID:20210301220015);

**[Affected Platforms]:**
- Windows 10 x64;
- macOS 10.15.7;
- Linux Mint 20 x64;

**[Prerequisites]:**
- Have the latest Firefox Nightly/Beta installed.
- Have a CSV file with 2 identical logins.

**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to "about:logins" page. 
3. Open the menu and click the "Import from a File..." option.
4. Select and open the CSV file.
5. Click the "View detailed Import Summary" link.
6. Observe the import report.

**[Expected result]:**
- One login is successfully added and the other one is marked as " Duplicate: Exact match of existing login".

**[Actual result]:**
- One login is successfully added and the other one is recognized as "Missing field" error even if the login is identical with the imported one.

**[Notes]:**
- Attached a screen recording of the issue.
Bug: Tab tooltip should be hidden when scrolling tabstrip
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2021-03-02 12:24:43+00:00
Resolved: 2021-03-12 17:47:10+00:00

This is a recent regression. 

Reproducible: without proton

Steps to reproduce:
1. Open many tabs so that tab strip will over flow.
2. Mouse hover over a tab so that tab tooltip will pop up.
3. Rotate mouse wheel to scroll tabstrip. (don't move mouse position)

Actual Results:
The tab tooltip will remain visible. 
After scrolling, as a result, the content of the tooltip becomes unrelated to the tab at the mouse pointer position.

Expected Results:
Like Firefox87.0b4, tab tooltip should be hidden when scrolling tabstrip.
Bug: Bookmarks / History tooltips always hide the next two items regardless of mouse position
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-03-02 12:49:18+00:00
Resolved: 2021-06-11 10:05:01+00:00

Bookmarks / History tooltips always hide the next two items regardless of mouse position,
So, the tooltips interfere with finding bookmark labels.
Finding bookmarks is difficult without moving the mouse pointer.

Reproducible: without/with proton.

Steps to Reproduce:
Mouse hover a bookmarks

Actual Results:
Bookmarks / History tooltips always hide the next two items regardless of mouse position.
Finding bookmarks is difficult without moving the mouse pointer.

Expected results:
The tooltips should pop up near the mouse pointer if possible. So, the next two items will be identifiable. Makes it easier to find bookmarks.
Bug: The application menu tooltip says "Close Application Menu" even if it's already closed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-02 13:04:12+00:00
Resolved: 2021-03-16 11:30:46+00:00

STR:

1. Open the application menu (the "hamburger menu")
2. close the menu
3. move the cursor over the application menu button

Expected:

The tooltip says: "Open Application Menu"

Actual:

The tooltip says: "Close Application Menu"
Bug: FxA submenu arrow is displayed while the browser is resized even if there doesn't exist a submenu
Status: NEW
Priority: P3
Created: 2021-03-02 14:16:08+00:00
Resolved: 2021-03-26 11:36:36+00:00

#### Tested with:

Nightly 88.0a1 (2021-03-02)

#### Tested on:

Windows 10
MacOS 10.15
#### Preconditions:

In latest Nightly, set browser.proton.enabled = true
#### Steps:

 1. Launch firefox and resize the browser until the "more tools" arrows are displayed (right next to the address bar).
 2. Click the arrows in order to expend the submenu and click on "Firefox Account" option.

#### Actual result:

There is an arrow displayed to the right of the "Firefox Account" (which suggest there is a submenu) like for the options that expends a submenu, even if there doesn't exist a FxA submenu.
#### Expected result:

The arrow should not be displayed since there is not a submenu opened. By clicking on the Firefox Account, the user is redirected to the Firefox Sync page.

Notes:
The issue is reproducible only with Proton enabled. In Release 86, Beta 87 or latest Nightly without Proton enabled there is a submenu that is opened.
Bug: Perma browser/base/content/test/contextMenu/browser_contextmenu.js and accessible/tests/browser/mac/browser_app.js failures when Gecko 88 merges to Beta on 2021-03-22
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-02 15:42:44+00:00
Resolved: 2021-03-18 18:48:51+00:00

* [central-as-beta simulation](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=a6d04d45a28bab5a434d5014c3d116dc57d43fd5&selectedTaskRun=JtouODUkQQ-YdFyfEXOQTA.0)
* [How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)

[Failure log accessible/tests/browser/mac/browser_app.js](https://treeherder.mozilla.org/logviewer?job_id=331738237&repo=try)
[task 2021-03-02T12:36:47.246Z] 12:36:47     INFO - TEST-PASS | accessible/tests/browser/mac/browser_app.js | Location bar has correct value - 
[task 2021-03-02T12:36:47.246Z] 12:36:47     INFO - Leaving test bound 
[task 2021-03-02T12:36:47.246Z] 12:36:47     INFO - Entering test bound 
[task 2021-03-02T12:36:47.247Z] 12:36:47     INFO - Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "data:text/html,<a id="exampleLink" href="https://example.com">link</a>" line: 0}]
[task 2021-03-02T12:36:47.247Z] 12:36:47     INFO - Buffered messages finished
[task 2021-03-02T12:36:47.247Z] 12:36:47     INFO - TEST-UNEXPECTED-FAIL | accessible/tests/browser/mac/browser_app.js | Context menu on link contains 14 or 15 items depending on release - Got 13, expected 14
[task 2021-03-02T12:36:47.247Z] 12:36:47     INFO - Stack trace:
[task 2021-03-02T12:36:47.247Z] 12:36:47     INFO - chrome://mochikit/content/browser-test.js:test_is:1359
[task 2021-03-02T12:36:47.247Z] 12:36:47     INFO - chrome://mochitests/content/browser/accessible/tests/browser/mac/browser_app.js:null:219

[Failure log browser/base/content/test/contextMenu/browser_contextmenu.js (macOS, Windows)](https://treeherder.mozilla.org/logviewer?job_id=331738184&repo=try)
TEST-UNEXPECTED-FAIL | browser/base/content/test/contextMenu/browser_contextmenu.js | checking item #14 (context-inspect-a11y) name - Got "context-inspect", expected "context-inspect-a11y" 
...
Bug: [Win10][Proton] When lightweight theme light/dark-ness doesn't match OS light/darkness, menus/dropdowns in the library/sidebar/preferences/other-non-lwthemed contexts do not have the right colour scheme
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-03-02 18:30:40+00:00
Resolved: 2022-03-25 23:28:02+00:00

In bug 1692238 / bug 1692237, we made it so we honour OS dark theme for the windows 10 custom context menu and <select>/<menulist> dropdowns, in window contexts where we don't know the lightweight theme status. This includes the sidebar, the preferences, the library window, and similar contexts. We did this because in those contexts, it is not trivially possible to get the lightweight-theme based information.

This means that if you use the "light" lightweight theme, and the OS dark theme, we will use a dark context menu (and dark dropdowns for `<select>` and/or `<menulist>` elements). The inverse is presumably also true - with the Firefox "dark" lightweight theme, and the OS light theme, we will use light context menus.

UX has indicated that the Firefox theme should be what determines the colour theme.

This will probably mean setting some kind of root attribute in all of the contexts that don't currently get styled by the lightweight/webextension theme, based on the same computation that we use to apply the `lwtheme-brighttext` pseudo-selector on the main Firefox window.

We cannot easily start applying all the same lwtheme pseudo-selectors because that would affect a lot of other colours/layouts in ways that the styling of all those contexts is really not able to cope with right now, and we don't have the time to change that.
Bug: Restore-search-defaults Add-on
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-02 19:41:15+00:00
Resolved: 2021-03-23 13:58:13+00:00

+++ This bug was initially created as a clone of Bug #1681486 +++

Private Repo is here: https://github.com/mozilla-extensions/restore-search-defaults

We'll be shipping a new version of this add-on soon and I wanted to file a bug to track deployment and data review.

https://jira.mozilla.com/browse/PI-979
Bug: Bookmark keyword searches using Hangul/Korean IME intermittently don't work
Status: NEW
Priority: P3
Created: 2021-03-02 20:54:12+00:00
Resolved: 2023-01-10 17:06:58+00:00

STR

1. Create a bookmark for `https://dict.naver.com/search.nhn?dicQuery=%s` with keyword `d`
2. Open a private window
3. Type `d 하나` (`d GKSK` in ASCII)
4. Observe that the heuristic result is correct (more or less, it's actually missing the second character): `dict.naver.com: 하`
5. Press enter

Firefox does a Google search for `d 하나` instead of correctly loading the bookmark. The problem doesn't happen in non-private windows.

I debugged this a little, and in both private and non-private windows, `UrlbarInput.handleNavigation` makes it all the way to the end, where it calls `UrlbarUtils.getHeuristicResultFor`, because there isn't a result up to that point. That doesn't seem right since there's clearly a heuristic result in the view. But regardless, in non-private windows we end up doing the right thing.

The only difference in private windows is that the query is stopped. UnifiedComplete is correctly called, but the query is stopped and `pending` is false before `_matchPlacesKeyword` can fetch a match.

The extra stop is due to [this call](https://searchfox.org/mozilla-central/rev/c24ecdc6f5025ea7e60d0691673de030bd5bf411/browser/components/urlbar/UrlbarController.jsm#143):

```js
      // TODO (Bug 1549936) this is necessary to avoid leaks in PB tests.
      this.manager.cancelQuery(queryContext);
```

I tested this in Windows using [Nalgaeset IME](http://moogi.new21.org/bin/Ngs1010Setup_x64.msi) (see bug 1679697 comment 0) but I don't know whether it's a problem with other IMEs, languages, or platforms.
Bug: recommendation notification in addressbar doesn't react to clicks and cannot be expanded when tab gets revisited
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-03-02 23:25:07+00:00
Resolved: 2021-03-10 12:25:08+00:00

Firefox 87.0b4 on Windows 8.1

This reproduces with a profile which gets cloned from a pretty bare bones one which only gets carried along as blueprint for these testing clones. It doesn't reproduce with a fresh new profile.

The 'Recommendation' notification in the address bar doesn't react to clicks and cannot be expanded when the tab gets revisited.

Steps to reproduce:
1. Launch Firefox.
2. Copy this link into the clipboard: https://www.bloomberg.com/news/articles/2021-02-27/cathie-wood-s-power-in-some-stocks-is-even-bigger-than-it-seems?srnd=premium
3. Focus the address bar in Firefox.
4. Paste with the clipboard.
5. Press Enter to load the page

Actual result:
'Recommended' badge/notification shown.

6. Click on the 'Recommended' notification.

Actual result:
Nothing happens.

Expected result:
More information.

7. Open a new tab.
8. Switch back to the tab with the pasted url.
9. Click the minimized badge (light bulb).

Actual result:
Nothing happens.

Expected result:
More information.

From the browser console:

app.normandy.recipe-runner	ERROR	Could not execute recipe Opt-out - Pioneer Enrollment Study (Bug 1382761):: Action opt-out-study is either missing or invalid. Log.jsm:723
app.normandy.recipe-runner	ERROR	Could not execute recipe Pref Flip: Geolocation OS API for <=60, Windows [bug 1527748]:: Action preference-experiment is either missing or invalid. Log.jsm:723
app.normandy.recipe-runner	ERROR	Could not execute recipe Pref Flip: Geolocation OS API for <=60, Mac [bug 1527748]:: Action preference-experiment is either missing or invalid. Log.jsm:723
app.normandy.recipe-runner	ERROR	Could not execute recipe Pref Flip: Geolocation OS API for <=60, Linux [bug 1527748]:: Action preference-experiment is either missing or invalid. Log.jsm:723
app.normandy.recipe-runner	ERROR	Could not execute recipe Hotfix: Office 365 Legacy Keycode And Charcode:: Action preference-experiment is either missing or invalid. Log.jsm:723
app.normandy.recipe-runner	ERROR	Could not execute recipe Pref-Flip Study: Activity Stream CFR Pinned Tabs - Treatment [Bug 1536650]:: Action preference-experiment is either missing or invalid.

TypeError: localeStrings is null CFRPageActions.jsm:356:24

Is this caused by stale CFR recipes?
Bug: Normandy should not attempt to unenroll expired preference experiments who's filters don't match
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-02 23:40:00+00:00
Resolved: 2021-03-25 01:44:13+00:00

If Normandy client has a preference experiment that has already unenrolled, and receives the recipe for that experiment again, it will re-evaluate the filters. If the filters don't match, it will try to unenroll the client from the experiment, which fails because the client is already unenrolled. This is producing a lot of bad telemetry (see bug 1693402)
Bug: Insecure downloads are placed in the wrong location
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-03-03 00:23:10+00:00
Resolved: 2021-04-29 21:44:37+00:00

When doing an insecure download I get a prompt for the location to save it, after saving the download fails to start as expected. After clicking "Allow Download" in Download Details dialog the download is saved to the default download location instead of the location that I chose.
Bug: Make Manage account link in Sync Options open in a new tab
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-03-03 01:09:36+00:00
Resolved: 2022-10-24 13:13:40+00:00

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



Actual results:

Clicking Manage account open the account page in the same browser tab


Expected results:

I would expect the link to open in a new tab by default, so the user isn't taken away from the option/settings pages within the browser
Bug: Immediately logs out of franklin templeton website
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-03 04:58:21+00:00
Resolved: 2021-05-03 08:25:26+00:00

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

Steps to reproduce:

logged into https://www.franklintempletonindia.com/


Actual results:

Immediately the page refreshes on login and logs me out


Expected results:

It should not have logged me out.

(I had experienced this also on the firefox nightly version before the update was rolled out to the general firefox build and now facing the same in the public build)
Bug: Proton Context Menu Not Working in Ubuntu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-03 09:36:49+00:00
Resolved: 2021-03-04 13:18:30+00:00

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

Steps to reproduce:

In about:config

browser.proton.appmenu.enabled
browser.proton.contextmenus.enabled
browser.proton.enabled
browser.proton.tabs.enabled	
browser.proton.urlbar.enabled

On Nightly 88.0a1 (20210302134918)
OS: Ubuntu 20.10


Actual results:

It does not show the new proton context menu as it is in windows.
Bug: Firefox PDF-Viewer shows unmarked checkboxes as marked (interpretes booleans as true)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-03 09:57:41+00:00
Resolved: 2021-03-03 13:12:44+00:00

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

Steps to reproduce:

The attached PDF-File was opened in Firefox. If it is opened in another PDF-viewer or browser it is displayed correctly.


Actual results:

All checkboxes on the upper left side are displayed as checked.  I assume the status of all checkboxes is always intepreted as "true" by the internal PDF-viewer.


Expected results:

Only two of the four checkboxes should have been checked. You can see the desired result in other PDF-viewers, as stated above.
Bug: Switch-to-tab results open in same tab on Ctrl+click instead of in new tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-03 11:24:33+00:00
Resolved: 2021-03-03 13:53:43+00:00

When Ctrl+clicking a result that was originally switch-to-tab, the result opens in the current tab, breaking the otherwise universal behavior of the link-modifier Ctrl.

The basic problem is that the code[0] sets the attribute "actionoverride" regardless of which modifier was used (Alt, Shift or Ctrl/Cmd), and then[1] decides that this means that the tabs needs to be opened "here".

[0] https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#2152
[1] https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#774

## STR:
1. Open a page in one tab
2. Open a new tab
3. Type something matching the first tab into the address bar
4. Hold Ctrl (or Cmd) while clicking the link

## Actual results:
Unlike any other result, switch-to-tab results will open in the current tab

## Expected results:
Result should open in a new tab
Bug: [Ubuntu] The edit bookmark dropdown from the Star icon in address bar is offset
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-03 11:37:31+00:00
Resolved: 2021-03-16 14:24:15+00:00

**Affected versions**
- Firefox 87.0b5
- Firefox 88.0a1

**Affected platforms**
- Ubuntu 20.04

**Steps to reproduce**
1. Launch Firefox
2. Access for example [Wikipedia](https://www.wikipedia.org/)
3. Click on the Star icon in address bar
4. Extend the Bookmarks folder in the dropdown
5. Click outside the dropdown to dismiss it
6. Click again on the Star icon

**Expected result**
- The edit dropdown is extended from the Star icon

**Actual result**
- The edit dropdown is offset to the left of the star icon

**Regression range**
- I will see for a regression

**Additional notes**
- The issue can be seen in the attachment
- Windows and macOS are not affected
Bug: Bookmark drop down menu is slightly moved sometimes when clicking Show/Hide Bookmarks folder
Status: NEW
Priority: P5
Created: 2021-03-03 11:44:39+00:00
Resolved: 2023-03-05 15:44:18+00:00

*Affected versions*
* 88.0a1 (20210302134918)
* 87.0b5 (20210302185821)
* 86.0 (20210222142601)
* 78.8.0esr (20210217034806)
	
*Affected platforms*
* Windows 10x64
* Ubuntu 20


*Steps to reproduce*
1. Open Firefox and access a random page.
2. Click on Bookmark this page icon.
3. Select Show/Hide Bookmarks folder.

*Expected result*
* The window is not moved.

*Actual result*
* Drop-down menu is slightly moved sometimes when clicking Show/Hide Bookmarks folder.
 
*Regression range*
* I will search for one ASAP.


*Notes*
* Attached a screen recording.
* I cannot reproduce the issue on macOS 11.2.
* The issue is intermittent.
Bug: PDF takes long to finish rendering and uses a lot of CPU on 2015 MBP
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-03 12:46:16+00:00
Resolved: 2023-05-13 12:39:13+00:00

This PDF takes long* to render even after it has been fully downloaded and Firefox' main thread CPU spikes during the time.
https://www.randwick.nsw.gov.au/__data/assets/pdf_file/0012/26103/Waste-clean-up-zones.pdf

*~1 min. while macOS' Preview opens it instantaneous
Bug: In certain regions, Amazon search shortcut from remote settings gets pinned when it wasn't without remote settings
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-03-03 15:34:03+00:00
Resolved: 2021-03-12 11:51:51+00:00

follow-up from bug 1691478

##### [Environment:]
Windows 10, Mac 10.14.6, Ubuntu 20.04

##### [Steps]:
1. Start an en-ca localized older version (87.0a1) with an user.js that has 
      user_pref("browser.search.region", "CA");
      user_pref("browser.topsites.useRemoteSetting", false);
2.  Note down the topsites: the order would be amazon.ca is on pos 5 unpinned.
3.  Close Fx down, edit the said user.js and change user_pref("browser.topsites.useRemoteSetting", true);
4. Download latest beta - 87.b05
5. Start beta 87.b05 with the above profile. (migration scenario)

##### [Actual Result:]
amazon.ca is pinned and on position 1

##### [Expected Result:]
amazon.ca is pinned and on position 5

##### [Note:]
Unpinning in the above actual result will send the amazon.ca to position 5 (order 50).