av9ash/GitBugs huggingface dataset:
Bug: Many modules loaded eagerly before first paint when setting the url bar placeholder
Status: NEW
Priority: P3
Created: 2022-06-06 11:05:50+00:00
Resolved: 2023-01-16 16:31:45+00:00

In a startup profile, I noticed this tree of module imports before first paint: https://share.firefox.dev/3Np2sg4

This usually indicates that the code would benefit from doing more lazy loading.

The code triggering all these loads is at https://searchfox.org/mozilla-central/rev/4c3f6e8bf87fffb7c62feb4c76a14e0eb0b94c1f/browser/components/urlbar/UrlbarProvidersManager.jsm#93-94

How many of these modules do we really need to set the urlbar place holder before first paint?
Bug: SearchService.jsm is loaded too early during startup
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-06-06 11:40:34+00:00
Resolved: 2024-07-15 17:17:36+00:00

While working on improving startup times for Firefox 57, we ensured the search service wasn't loaded before first paint.

https://searchfox.org/mozilla-central/rev/4c3f6e8bf87fffb7c62feb4c76a14e0eb0b94c1f/browser/base/content/test/performance/browser_startup.js#59 was meant to prevent this from regressing, but the file has been renamed without renaming the denylist entry.

I just captured a startup profile, and SearchService.jsm is now loaded during early startup, while installing add-ons. Seems to be a regression from bug 1552559.
https://share.firefox.dev/3MgJyXr

SearchSettings.jsm and SearchUtils.jsm are also loaded at that time.

The SearchUtils.jsm load is likely triggered by the loadConsole line at https://searchfox.org/mozilla-central/rev/4c3f6e8bf87fffb7c62feb4c76a14e0eb0b94c1f/toolkit/components/search/SearchService.jsm#1780, causing https://searchfox.org/mozilla-central/rev/4c3f6e8bf87fffb7c62feb4c76a14e0eb0b94c1f/toolkit/components/search/SearchService.jsm#33

The SearchSettings.jsm load is from the SearchService constructor: https://searchfox.org/mozilla-central/rev/4c3f6e8bf87fffb7c62feb4c76a14e0eb0b94c1f/toolkit/components/search/SearchService.jsm#94

I noticed this while reviewing https://phabricator.services.mozilla.com/D148196.
Bug: Toolbar keyboard navigation doesn't work correctly in the tabs toolbar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-06 11:43:46+00:00
Resolved: 2022-06-09 16:31:11+00:00

With the Firefox View changes, the tabs toolbar is navigable with tab and arrow keys by [the same means](https://searchfox.org/mozilla-central/source/browser/base/content/browser-toolbarKeyNav.js) as other toolbars. This is a nice improvement, but because there can be buttons on either side of the tab strip, and the tab strip has its own internal focus behavior, the user can't tab through the elements on the tabs toolbar in an intuitive way.

(I'm gonna use the terms left/right to make this easier but I really mean start/end, as I believe all of this is reversed for RTL) I would expect there to be a tabstop for elements to the left of the tabstrip (like the Firefox View entry point), another tabstop for the tabstrip itself, and another tabstop for elements to the right of the tabstrip.

So, when an element to the left of the tabstrip is focused, arrow keys would only advance through those elements to the left of the tabstrip. When a tab is focused, arrow keys would only advance through tabs. And when an element to the right of the tabstrip is focused, arrow keys would only advance through those.

That would mean if we Shift+Tab backwards from the urlbar, we should hit the back button, then hit the "all tabs" button or the new tab button, then hit the tabstrip, then hit the Firefox View button. In other words, Tab should advance through at least 3 zones in the tabs toolbar.

Currently, there's only one tabstop in the tabs toolbar, so when we Shift+Tab backwards from the urlbar, we jump right to the tabstrip, then another Tab press focuses the Firefox View button.

That means the only way we can focus the buttons to the right of the tabstrip is to focus the Firefox View button (to the left of the tabstrip) and then use the right arrow key. This is pretty unintuitive behavior, jumping past the right side items with Tab, and jumping over the tabstrip with the arrow keys. (Keep in mind you can only test this if `browser.tabs.firefox-view` is enabled when the window opens.)

If we had additional tabstops we could keep the arrow keys confined to the left/right-of-tabstrip zones. That would be analogous to what happens with the urlbar when navigating buttons in the navbar. But I think we also need to change the focus behavior for the tabstrip to avoid some jank. I'll investigate that further later, unless someone else wants to work on this.
Bug: [Win7] Menu bar options are not visible at hover when using White high contrast and Dark theme.
Status: NEW
Priority: --
Created: 2022-06-06 12:00:14+00:00
Resolved: 2022-09-04 21:19:41+00:00

**Affected versions**
* Beta 102.0b4 (64-bit)

**Affected platforms**
* Win 7 x86

**Steps to reproduce**
1. Set White High contrast on Win10x64.
2. Open Firefox and set Dark theme.
3. Open Customize and enable Menu bar.
4. Hover the File menu from menu bar.

**Actual results:**
At hover ‘File’ text is not visible (see screenshot attached).

**Expected results:**
'File' Text should be visible.

**Suggested Severity**
* S4, since it is a display issue reproducing under certain conditions.
Issue is reproducing for all Menu bar options (File, Edit, View, History, Bookmarks, Tools and Help).
Issue is **not** reproducing on Ubuntu20.4 and Mac10.13.

**Regression range**
I will add one asap.
Bug: i have a problem while file upload on my create site
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-06-06 12:22:24+00:00
Resolved: 2022-06-10 13:17:52+00:00

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

Steps to reproduce:

I'm having trouble uploading files to my own website. Same problem in chrome.


Actual results:

There was no such problem before. Occurred after last update. Other users have the same problem.
Bug: about:logins search/filters accounts by password when searching
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-06 15:24:14+00:00
Resolved: 2022-06-06 15:45:49+00:00

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

Steps to reproduce:

- Go to: about:logins
- Go to "search logins" box
- start typing some if your own password



Actual results:

login list is filtered automatically by the password value being searched


Expected results:

login list is filtered should not be filtered by the password value being searched. Filter should be only done by email or website value... Currently, it leaks security information, as one I can figure out which password contain certain digits/characters. Also, from the GUI, we can see the password length, which is another leak of information.

Security thread:  someone gets access to my browser (e.g. I left my laptop untended/unlock in my office/desktop).  Then opens a tab about:logins, master password is not asked (either not set or recently used) and searches by specific password sequences knowing the password length... if no strong passwords are used (i.e. short or using "easy" words, one can figure out parts of the password (if not all) and then reduce the space for a brute search.
Bug: Intermittent browser/components/shell/test/browser_420786.js | Wallpaper file GSettings key is correct - Got "file:///usr/share/backgrounds/warty-final-ubuntu.png", expected "file:///builds/worker/Nightly_wallpaper.png"
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-06-06 17:38:45+00:00
Resolved: 2022-07-25 23:06:37+00:00

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

---
```
[task 2022-06-06T16:46:30.434Z] 16:46:30     INFO - TEST-PASS | browser/components/shell/test/browser_420786.js | Wallpaper was written to disk - 
[task 2022-06-06T16:46:30.434Z] 16:46:30     INFO - Buffered messages finished
[task 2022-06-06T16:46:30.434Z] 16:46:30     INFO - TEST-UNEXPECTED-FAIL | browser/components/shell/test/browser_420786.js | Wallpaper file GSettings key is correct - Got "file:///usr/share/backgrounds/warty-final-ubuntu.png", expected "file:///builds/worker/Nightly_wallpaper.png"
[task 2022-06-06T16:46:30.435Z] 16:46:30     INFO - Stack trace:
[task 2022-06-06T16:46:30.435Z] 16:46:30     INFO - chrome://mochikit/content/browser-test.js:test_is:1422
[task 2022-06-06T16:46:30.435Z] 16:46:30     INFO - chrome://mochitests/content/browser/browser/components/shell/test/browser_420786.js:checkWallpaper:71
[task 2022-06-06T16:46:30.435Z] 16:46:30     INFO - chrome://mochitests/content/browser/browser/components/shell/test/browser_420786.js:null:90
[task 2022-06-06T16:46:30.435Z] 16:46:30     INFO - resource://testing-common/BrowserTestUtils.jsm:withNewTab:150
[task 2022-06-06T16:46:30.435Z] 16:46:30     INFO - TEST-PASS | browser/components/shell/test/browser_420786.js | Wallpaper position GSettings key is correct
```
Bug: The bookmarks toolbar doesn't appear when opening a new tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-06 18:23:35+00:00
Resolved: 2022-06-07 07:04:54+00:00

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

Steps to reproduce:

I click the right mouse button on the toolbar -> Bookmarks Toolbar -> Only Show on New Tab, then set the Home -> New Windows and Tabs -> New tabs -> Blank Page setting, then open a new tab by clicking Open a new tab button


Actual results:

The bookmarks toolbar doesn't appear when I open a new tab


Expected results:

The bookmarks toolbar should appear when I open a new tab. 

It works fine when i change back Home -> New Windows and Tabs -> New tabs ->  Firefox Home (Default) and it works in the private window. New tab in private window and Firefox Home (Default) new tab in non-private contains Firefox logo and search input, looks like it doesn't work when new tab is blank
Bug: Browser history view resets to most recent upon alt tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-06 20:10:53+00:00
Resolved: 2022-06-23 14:16:16+00:00

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

Steps to reproduce:

Open browser history, scroll down to date (1 month back or so), alt tab to different window, then go back to browser history 


Actual results:

The browser history resets to most recent, instead of keeping scrolled position. 


Expected results:

This is a current phenomenon, it used to just stay at where ever you scrolled to.
Bug: Importing bookmarks from Chrome affects website
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-06-07 00:18:26+00:00
Resolved: 2022-06-09 17:33:16+00:00

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

Steps to reproduce:

See attached file for problem.


Actual results:

See attached file for problem.


Expected results:

See attached file for problem.
Bug: passwords in the about:logins menu are plain-text searchable
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-07 06:38:51+00:00
Resolved: 2022-06-07 13:50:48+00:00

Steps to reproduce:

Create new login in about:logins with arbitrary information, e.g. 
website: "https://mozilla.org",
username: "test-username",
password: "THIS-TEXT-SHOULD-NOT-BE-SEARCHABLE".



Actual results:

Enter "THIS-TEXT-SHOULD-NOT-BE-SEARCHABLE" into search menu and search query returns login that contains the password. 


Expected results:

PASSWORDS SHOULD NOT BE SEARCHED PLAINTEXT WHILE SEARCHING FOR LOGINS AS THIS PRESENTS A VECTOR FOR A BRUTE FORCE ATTACK.
Bug: File .mp2 is converted to .mpeg while downloading
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-06-07 08:18:30+00:00
Resolved: 2024-09-11 04:36:35+00:00

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

Steps to reproduce:

Download file (I did this way):
			const blob = new Blob([data], { type: 'audio/mpeg' });
			const uri = URL.createObjectURL(blob);
			var link = document.createElement("a");
			link.download = documentName;
			link.href = uri;
			document.body.appendChild(link);
			link.click();
			document.body.removeChild(link);
			URL.revokeObjectURL(objectURL);


Actual results:

File downloaded with .mpeg extension

Workaround:
Provide 'application/octet-stream' type to blob object
		const blob = new Blob([data], { type: 'application/octet-stream' });



Expected results:

The file is downloaded in original format .mp2
Bug: File .jfif is converted to .jpg  while downloading
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-06-07 08:31:51+00:00
Resolved: 2024-09-11 03:46:38+00:00

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

Steps to reproduce:

Download file (I did this way):
const blob = new Blob([data], { type: 'image/pjpeg' });
const uri = URL.createObjectURL(blob);
var link = document.createElement("a");
link.download = documentName;
link.href = uri;
document.body.appendChild(link);
link.click();
document.body.removeChild(link);
URL.revokeObjectURL(objectURL);

or using FileSaver:

const blob = new Blob([data], { type: 'image/pjpeg' });
saveAs(blob, documentName);


Actual results:

File downloaded with .jpg extension

Workaround:
Provide 'application/octet-stream' type to blob object
const blob = new Blob([data], { type: 'application/octet-stream' });


Expected results:

Expected results:

The file is downloaded in original format .jfif
Bug: pdf documents opened with external application are all saved in download folder
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-07 10:27:27+00:00
Resolved: 2022-06-10 08:30:31+00:00

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

Steps to reproduce:

Open a pdf document with external viewer like Adobe Acrobat Reader, not save. This happenes since version 98. Please fix this - we don't want to replace all the standard browsers of our customers. We liked Firefox before very much but this is a no go...


Actual results:

All documets are saved in the download folder


Expected results:

documents should not be saved
Bug: Keyboard can often be unavailable except some keys after/during using Firefox
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-06-07 11:22:36+00:00
Resolved: 2024-03-04 12:23:22+00:00

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

Steps to reproduce:

Just using Firefox to browsing some pages.
It has occurred for me many times but it doesn't seems to be affected by specific websites, other software nor controls.


Actual results:

It suddenly happens, most of keyboard functions are not working.
(Alphabet, Number, Most of special character aren't working till I restart the computer)


Expected results:

Nothing happen.
Bug: Intermittent services/sync/tests/unit/test_prefs_tracker.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-06-07 12:27:45+00:00
Resolved: 2023-02-28 17:01:32+00:00

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

---
```
[task 2022-06-07T11:58:55.285Z] 11:58:55     INFO -  TEST-START | toolkit/components/places/tests/unit/test_bookmarks_html.js
[task 2022-06-07T11:58:55.301Z] 11:58:55  WARNING -  PROCESS-CRASH | services/sync/tests/unit/test_prefs_tracker.js | application crashed [None]
[task 2022-06-07T11:58:55.302Z] 11:58:55     INFO -  Crash dump filename: C:\Users\task_1654601231\AppData\Local\Temp\xpc-other-ufw7539c\0d74c6ca-5b0c-42b0-b649-8e1cea78f36a.dmp
[task 2022-06-07T11:58:55.302Z] 11:58:55     INFO -  stderr from minidump-stackwalk:
[task 2022-06-07T11:58:55.302Z] 11:58:55     INFO -  [ERROR] MissingHeader - Error reading dump: Missing minidump header (empty minidump?)
[task 2022-06-07T11:58:55.722Z] 11:58:55     INFO -  TEST-START | toolkit/components/places/tests/unit/test_bookmarks_html_corrupt.js
```
Bug: Adaptive history logic breaks when the user 'forgets' the website and also has a bookmark of it
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-06-07 13:27:21+00:00
Resolved: 2022-06-15 09:41:17+00:00

**Affected versions**
* Fx 102.0b4
* Fx 103.0a1

**Affected platforms**
* Windows 10
* Ubuntu 20.04
* macOS

**Steps to reproduce**
1. Launch Firefox.
2. Navigate to [Reddit](www.reddit.com) and click on a post from the page.
3. Open a new tab and close the previously accessed page from step 2.
4. Type 'redd' in the address bar and choose the reddit post from the Firefox Suggest section. (at this point the adaptive history for 'redd' is created).
5. Bookmark the page.
6. Open a new tab and close the previously accessed page from step 4.
7. Open history (either library or sidebar) and use "Forget about this site" to remove the reddit post entry from history.
8. Delete the bookmark from the bookmark toolbar.

**Expected result**
* No adaptive history for autofil remains (the autofill for 'redd' no longer exists).
* No records exist when checked for in the browser console.

**Actual result**
* Adaptive history autofill triggers briefly (flickers) for every letter of the word 'redd' that is typed in the address bar.

**Regression range**
* This is not a regression.

**Additional notes**
* This seems to be because of the weird interaction between 'Forget about this site' functionality and bookmarking. 

What I mean by this is that:
- if bookmark is removed first, then the forget about this site is used, there is no adaptive history.
- if the user just DELETES the history entry and then removes the bookmark, no adaptive history entry remains.
- if an adaptive autofill entry is done on a record that exists only in history and the 'forget about this site' functionality is used on the history entry, the adaptive autofill entry is removed.
- if an adaptive autofill entry is done on a record that exists only in bookmarks and then the user deletes the bookmark, the adaptive autofill entry is removed.
Bug: UI elements use different ways of rendering tooltips
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-07 16:23:56+00:00
Resolved: 2022-06-09 20:32:26+00:00

Steps to reproduce:

Move the mouse over different Firefox UI elements to show their tooltip.


Actual results:

The tooltips are rendered in two different styles. Some of the toolbar buttons have one kind of tooltip. Other toolbar buttons have a different kind of tooltip.


Expected results:

All tooltips in Firefox should be rendered with the same visual style. Preferably one that uses the native OS theme or at least one that can be customized using 'userChrome.css'

This problem is more apparent since Firefox 101 when the OS native tooltip rendering was removed and some of the tooltips are now shown in the old yellow Windows XP way.

for example:
- The toolbar buttons for 'back', 'forward', 'Reload', 'Protections' use one kind of tooltip
- The toolbar buttons for 'Home', 'Site info', 'Bookmark', 'Overflow menu' use a different kind of tooltip.

-> Screenshots.zip
Bug: Cursor jumps to beginning of a search bar after a few seconds
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-06-07 17:05:48+00:00
Resolved: 2022-06-27 20:45:15+00:00

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

Steps to reproduce:

Go to any site (ie. Google.com) and begin typing in the search bar. After a second or two, the cursor will jump to the beginning of the search bar.


Actual results:

This happens on multiple sites:

https://giphy.com/gifs/lpYXKdKmEXbSPH2QbW


Expected results:

The cursor should not jump to the beginning of the text bar like that. It is as IF I am hitting the home key, but I am not. This does not happen in other browsers.
Bug: 'Save Full Page' Screenshot option only captures the upper-left quarter of the page
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-06-07 19:18:42+00:00
Resolved: 2022-06-15 17:13:35+00:00

Steps to reproduce:

Using macOS Monterey 12.2 and Firefox 101.0 (64-bit):
1. View a page.
2. Right-click on the page.
3. Select 'Take Screenshot'.
4. Click 'Save full page'.


Actual results:

The resulting preview shows only the upper-left quarter of the page.


Expected results:

The resulting preview should show all of the page.

This is consistent for all pages. Prior to the release of 101.0, the Screenshot function was working well. I hadn't made any changes whatsoever to display settings or browser options prior to the upgrade to 101.0.
Bug: Privacy pane scrolls horizontally in narrow windows due to unwrappable checkbox for OS auth for creditcard autofill
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-06-08 07:20:16+00:00
Resolved: 2022-10-14 15:39:54+00:00

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

Steps to reproduce:

I try it with a new Profile, but still the same


Actual results:

see screenshot


Expected results:

in about:preferences#general and the other pref-pages the resizing is working
Bug: Build failure with "ac_add_options --enable-bundled-fonts" on macOS
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-06-08 07:27:08+00:00
Resolved: 2022-06-08 07:42:50+00:00

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

Steps to reproduce:

- Bootstrapped the source code
- Added `ac_add_options --enable-bundled-fonts` to my `mozconfig`
- Run `./mach build`

As mentioned in the title, I'm using macOS.


Actual results:

The build fails with the following output:

```
53:32.12 ~/mozilla-unified/gfx/thebes/gfxPlatformMac.cpp:203:22: error: no member named 'gfx_bundled_fonts_activate_AtStartup' in namespace 'mozilla::StaticPrefs'
53:32.12     if (StaticPrefs::gfx_bundled_fonts_activate_AtStartup() != 0) {
53:32.12         ~~~~~~~~~~~~~^
53:32.74 1 error generated.
53:32.77 make[4]: *** [gfxPlatformMac.o] Error 1
53:32.77 make[4]: *** Waiting for unfinished jobs....
53:52.79 make[3]: *** [gfx/thebes/target-objects] Error 2
53:52.79 make[2]: *** [compile] Error 2
53:52.79 make[1]: *** [default] Error 2
53:52.79 make: *** [build] Error 2
53:52.82 1078 compiler warnings present.
53:53.07 /usr/local/bin/terminal-notifier -title Mozilla Build System -group mozbuild -message Build failed
```


Expected results:

The build run till the end.
Bug: firefox browser is providing less number of views as compared to google chrome
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-06-08 08:53:17+00:00
Resolved: 2023-05-31 16:23:23+00:00

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

Steps to reproduce:

i opened the firefox browser
 i searched for the themes 



Actual results:

firefox browser is providing less number of views as compared to google chrome


Expected results:

Firefox browser should provide more number of views as compared to google chrome