av9ash/GitBugs huggingface dataset:
Bug: Vertical alignment of blocked popup icon in URL bar could be improved
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-04-30 01:20:07+00:00
Resolved: 2021-06-10 21:19:24+00:00

Due to how the blocked popup icon is placed within its SVG file, it appears slightly offset vertically from other icons that can appear with it within the URL bar.

This patch uses CSS to nudge it slightly to make it more aesthetically pleasing.
Bug: line-height in about:welcome is less than font-size, thus multi-line non-Latin characters will touch each other
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-04-30 02:29:05+00:00
Resolved: 2021-05-11 10:54:24+00:00

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

Steps to reproduce:

1. Go to about:welcome
2. Change "Fire Starts Here" to "星星之火 將要燎原" (in the Inspector)



Actual results:

No line space (line-height: 92px; font-size: 104px;)


Expected results:

There should be line space. (line-height: 104px; font-size: 104px;)
Bug: Tracking protection icon is hidden on about:blank and about:newtab, but not on custom new tab/home pages
Status: NEW
Priority: P3
Created: 2021-04-30 05:30:57+00:00
Resolved: 2023-12-27 09:20:54+00:00

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

Steps to reproduce:

- Open a new tab to the default new tab page. (or type about:newtab into urlbar)
- The tracking protection icon is hidden, because the `about:` URL has `isContentPrincipal = false`
- Install an extension that overrides the new tab page, go to some webpage where the tracking protection is visible, (so a webpage or an extension page) and try opening a new tab.


Actual results:

- The tracking protection icon briefly disappears when the tab is created, (I assume the URL is `about:blank` in that moment) then reappears when the URL becomes `moz-extension://...` and `ContentBlockingAllowList.canHandle` is called on it.
- So basically the icon stutters every time a new tab is opened unless the user sticks to the default, built-in new tab page.


Expected results:

To be fair, the tracking protection icon is not useless on custom new tab pages. So I understand why it's not hidden. Clicking it will open the popup and the options and information in there will be valid. The same can't be said for the built-in new tab page. But the constant stuttering when opening a new tab is a much more serious issue, which might discourage a lot of users from installing NTP extensions.

I made a [temporary solution](https://github.com/aminomancer/uc.css.js/blob/master/script/hideTrackingProtectionIconOnCustomNewTabPage.uc.js) for myself which is easy enough to implement. Simply change `gProtectionsHandler.onLocationChange` so that, in addition to checking the principal, it also checks if the selected browser's URL matches the user's home page or new tab page URL.

That isn't a perfect solution though, because it hides the tracking protection icon under a condition where the tracking protection icon could actually be meaningfully interacted with. I've never had any cause to change the tracking protection settings on an extension page before, let alone a simple new tab/home page, but I'm sure there are edge cases where this would be an undesirable behavior.

So maybe there's another solution that someone with more knowledge than me can pull off. For example, it seems practical to stop the tracking protection icon from being hidden until content has loaded. That way it would still be visible on custom new tab pages, and would still be hidden on system pages, but it would be visible during those milliseconds when content is first loading in a browser. Just make it uninteractive but visible until there's more information about the content. Removes the icon flickering without removing the button itself.
Bug: passwords aren't syncing
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-30 08:40:04+00:00
Resolved: 2021-05-03 22:30:12+00:00

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

Steps to reproduce:

Created an account and enabled sync on two desktop Firefox instances. The first was Firefox 88 and the second was 78.8.0 ESR. Both are on Linux.

The first Firefox had everything syncing by default, so I did not touch any of its configuration. For the second only preferences were synced by default, so I had to enable passwords there.


Actual results:

Second Firefox cannot see the passwords from the first.

No idea if the opposite is true as the only passwords stored in the second Firefox also already existed in the first.

about:sync shows "Downloaded all 8 records (0 deleted)" on both browsers. The second browser has 8 stored passwords, so it would seem it has uploaded its passwords successfully. The first has 39 stored passwords.


Expected results:

Passwords from both browsers should be merged and available from either.
Bug: Cannot edit a form from the Spanish administration while it works with Chromium
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-04-30 08:51:02+00:00
Resolved: 2021-11-04 13:06:28+00:00

See attachment

If you press "Rellenar Formulario", it should move the PDF in edit mode.

With Firefox nightly, pressing the button doesn't have any action (ie I cannot edit anything) while it works with Chromium.
Bug: [Nightly only] Action after context clicking a tab can result in current tab being opened in new window
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-04-30 12:19:21+00:00
Resolved: 2021-07-22 09:09:54+00:00

With `browser.proton.enabled` set to `true`, context clicking a tab and then causing the menu to be dismissed can result in the current tab opening in a new window. It seems that the action is somehow triggering the same result as dragging the tab away from the toolbar.

I have been able to reproduce best when selecting one of the "Close Multiple Tabs" menu items, however I have also been able to reproduce by simply dismissing the context menu using the escape key on my keyboard.

Steps to reproduce:
1. Launch Firefox
2. Open a second tab
3. Open a third tab
4. Context click the second tab
5. Select Close Multiple Tabs > Close Tabs to Left

Expected result:
1. First tab is closed

Actual result:
1. First tab is closed
2. Second tab opens in new window

I am unable to reproduce with `browser.proton.enabled` set to `false`.

Application Basics
------------------
Name: Firefox
Version: 90.0a1
Build ID: 20210429214231
Distribution ID:
Update Channel: nightly
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Firefox/90.0
OS: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:02 PST 2021; root:xnu-7195.101.1~3/RELEASE_ARM64_T8101
Rosetta Translated: false
Multiprocess Windows: 1/1
Fission Windows: 0/1 Disabled by default
Remote Processes: 4
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false
Bug: New bookmark (Ctrl-D) autosaves to last used folder if dialog open for x seconds
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-30 12:36:43+00:00
Resolved: 2021-05-18 08:19:26+00:00

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

Steps to reproduce:

Press Ctrl-D to save a bookmark and wait 3+ seconds


Actual results:

The URL autosaves to the last folder I last saved a bookmark in. No wonder I kept finding links in my bookmarks in locations where they don't belong. This has been going on for several versions (months?), I only actually noticed it today. It may even be a 'feature', but I'm reporting it as a bug because it screws up peoples' bookmarks management.


Expected results:

Nothing
Bug: `Menu > Settings` button should open a new settings tab per Window
Status: NEW
Priority: P3
Created: 2021-04-30 12:45:58+00:00
Resolved: 2024-02-27 17:46:47+00:00

Currently the `Menu > Settings` either open an `about:preferences` tab or switch to the existing on if any. However, it does not check whether the existing tab is in the current Firefox window or if it is in a different one.

This behavior, combined with virtual desktops, might give the impression that `Menu > Settings` button is not working properly.

Steps to reproduce:
 - Open `Menu > Settings` in the initial window.
 - Open a new window.
 - Move the new window to another virtual desktop.
 - Switch to the virtual desktop where the other window is (desktop manager, hides the initial window which contains `about:preferences`)
 - Open `Menu > Settings` in the new window.

Seen:
 - Firefox highlight the current tab.

Expected:
 - Firefox should open the `about:preferences` tab in the new window, in addition of having it opened in the initial window.
Bug: copy link in address bar disappeared in Firefox 89
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-30 15:23:58+00:00
Resolved: 2021-05-01 02:11:43+00:00

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

Steps to reproduce:

I updated firefox developer edition from 88.0b9-1 to 89.0b4-1 on Manjaro.


Actual results:

Before, in the address bar, there was a context menu and an icon to copy links, in addition to the star to bookmark the link. I believe what was visible was customizable. Now, after updating, there is a new 'always open in container' option, but the dropdown menu and the copy link icon disappeared. The "report site" disappeared as well, but I think that was before this update, and probably intentional, given the feature.


Expected results:

I have seen issue https://bugzilla.mozilla.org/show_bug.cgi?id=1699920, so I was wondering if it was intentional? Whether or not it is, the feature cannot be added in the toolbar so I believe it should either be put in the address bar again or added to the customizable actions.
Bug: Update toolkit/themes/shared/extensions/extensionGeneric.svg
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-04-30 18:33:13+00:00
Resolved: 2021-05-05 17:03:48+00:00

`toolkit/themes/shared/extensions/extensionGeneric.svg` is used when we don't have an icon for an add-on. It's also used on AMO, so we should coordinate with the AMO team to get `https://addons.cdn.mozilla.net/static/img/addon-icons/default-*.png` replaced as well.
Bug: Some theme names have different language on RTL builds
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-04-30 19:06:23+00:00
Resolved: 2021-04-30 19:50:47+00:00

**Affected versions**
all . firefox beta 89.0b6 and Nightly 90.0a1 and Release 88

**Affected platforms**
Ubuntu 20 64bit , win10 64bit, Windows7 64bit

**Preconditions**
Intall a RTL localized version of firefox, example AR


**Steps to reproduce**
-Launch firefox
-go to hamburger menu > more tools> customize toolbar (check themes box at the bottom)


**Actual result**
On release, alpenglow appears on english, the rest in arab names
On beta and nightly: alpenglow and system theme appears in english, the rest in arab names


**Expected result**
all should be arab


note:not sure if this is proton, one of the names was already in english using release88
Bug: Insufficient contrast on action text on hover in dark mode
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-30 19:14:10+00:00
Resolved: 2023-01-21 05:13:22+00:00

UX noticed that there's not enough contrast between action text and hovered rows in the Urlbar in dark mode. Screenshot attached. They suggested using the title color for the action text on hover, like we do for keyboard-selected rows. The Figma spec has been updated to reflect this.
Bug: UITour should not iterate through all browser windows for every closed tab
Status: NEW
Priority: --
Created: 2021-04-30 19:28:55+00:00
Resolved: 2022-04-28 14:19:42+00:00

I captured a profile of closing a bit more than 300 tabs, and [UITour looping over every browser window for every "message-manager-close" observer notification](https://searchfox.org/mozilla-central/rev/1ed1bb14eed9b3f27a94513387608436ea74c247/browser/components/uitour/UITour.jsm#827,832-833) repesented about 7% of the time: https://share.firefox.dev/3nBspwF
Bug: Absence of "clear button" in toolbar search is inconsistent with Firefox UI
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-30 19:38:24+00:00
Resolved: 2021-05-05 19:20:24+00:00

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

Steps to reproduce:

Type text into toolbar search field


Actual results:

No "clear" button is displayed within the toolbar search field. Clearing the entry requires additional keyboard input.


Expected results:

In order to provide both consistency with the rest of the Firefox UI, and a satisfactory user experience, a "clear" button should be displayed, allowing the user to immediately clear the contents of the field if necessary. Once clicked, the entry should be cleared and toolbar search should become focused, ready for a new entry. This is the functionality users enjoy in many other text entry fields:

- History Sidebar search field
- Bookmarks Sidebar search field
- Synced Tabs Sidebar search field
- Library window bookmark search field
- Library window history search field
- Library window downloads search field
- Settings screen search field
- Developer tools "search HTML" field
- Developer tools "filter styles" field
- Etc..

Since modern Firefox does not permit add-ons to address this flaw, our only hope is attention from Mozilla. Thanks for all you do!
Bug: [Proton Info Bar] Hiding/Closing the Info Bar causes the webpage to move up and down
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-30 19:46:05+00:00
Resolved: 2022-05-04 19:05:11+00:00

Nightly 90.0a1 (2021-04-30) (64-Bit)
macOS 11.2.3

1.) Start Nightly
2.) When the Info Bar appears to use Nightly as your Standard Browser click on the hide/close button
3.) take a look at the webpage during the hiding animation

Actual: The Webpage moves up and down.

Expected: No move up/down of the webpage.

A screencast is attached.
Bug: [Win7/8.1] Minimize, Maximize and Close buttons are no longer visible if theme gets changed from high contrast
Status: NEW
Priority: --
Created: 2021-04-30 19:58:05+00:00
Resolved: 2022-05-03 11:54:03+00:00

**Affected versions**
all . firefox beta 89.0b6 and Nightly 90.0a1 and Release 88

**Affected platforms**
Windows7 64bit

**Preconditions**
set default theme in windows7 to "high contrast#1" before launching firefox


**Steps to reproduce**
- Launch firefox with high contrast1 already enabled
- now change win7 theme to aero Windows 7 default



**Actual result**
- the close window, maximize window button goes empty
- there is no aero, the tab area goes sold light blue
- the buttons can be clicked, its just not showing up on the screen
- if i restart the browser it gets fixed


**Expected result**
proper theme changed with buttons showingup
Bug: Fix bumpy animation in the site identity panel
Status: NEW
Priority: P3
Created: 2021-04-30 20:27:36+00:00
Resolved: 2022-07-20 20:57:17+00:00

In Bug 1706379, we landed a patch with a few CSS fixes to improve the bumpy animation.

However, the root cause seems to be that the identity-popup-security element has height during the transition and then loses it afterwards, causing a jerky experience.

We should try to get rid of that transition-only height in this bug.
Bug: TabUnloader.calculateMemoryUsage throws a TypeError exception
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-04-30 20:42:29+00:00
Resolved: 2021-05-04 13:54:09+00:00

`TabUnloader.calculateMemoryUsage` has a simple mistake, causing `TypeError: can't access property "memory", processInfo is undefined` when it's executed.
Bug: Intermittent browser/base/content/test/tabs/browser_file_to_http_script_closable.js | Test timed out - | Uncaught exception received from previously timed out test
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-04-30 21:03:43+00:00
Resolved: 2022-07-25 23:07:37+00:00

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

---
```
[task 2021-04-30T20:16:18.125Z] 20:16:18     INFO - TEST-PASS | browser/base/content/test/tabs/browser_file_to_http_script_closable.js | Tab is loaded - 
[task 2021-04-30T20:16:18.125Z] 20:16:18     INFO - waiting for it to close
[task 2021-04-30T20:16:18.125Z] 20:16:18     INFO - Buffered messages finished
[task 2021-04-30T20:16:18.126Z] 20:16:18     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_file_to_http_script_closable.js | Test timed out - 
[task 2021-04-30T20:16:18.126Z] 20:16:18     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-04-30T20:16:18.126Z] 20:16:18     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_file_to_http_script_closable.js | Uncaught exception received from previously timed out test - TabClose listener not removed before the end of test
[task 2021-04-30T20:16:18.126Z] 20:16:18     INFO - GECKO(3376) | MEMORY STAT | vsize 2104294MB | vsizeMaxContiguous 65335300MB | residentFast 299MB | heapAllocated 88MB
[task 2021-04-30T20:16:18.126Z] 20:16:18     INFO - TEST-OK | browser/base/content/test/tabs/browser_file_to_http_script_closable.js | took 90046ms
[task 2021-04-30T20:16:18.127Z] 20:16:18     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-04-30T20:16:18.127Z] 20:16:18     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_file_to_http_script_closable.js | Found a tab after previous test timed out: file:///Z:/task_1619812904/build/tests/mochitest/browser/browser/base/content/test/tabs/dummy_page.html - 
[task 2021-04-30T20:16:18.149Z] 20:16:18     INFO - GECKO(3376) | [Child 9000: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 14e5b325800 == 1 [pid = 9000] [id = 25]
[task 2021-04-30T20:16:18.149Z] 20:16:18     INFO - GECKO(3376) | [Child 9000: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 1 (14e61ad5200) [pid = 9000] [serial = 70] [outer = 0]
[task 2021-04-30T20:16:18.150Z] 20:16:18     INFO - GECKO(3376) | [Child 9000: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 2 (14e5b337800) [pid = 9000] [serial = 71] [outer = 14e61ad5200]
[task 2021-04-30T20:16:18.171Z] 20:16:18     INFO - checking window state```
Bug: Images in "Page Info" on Instagram appear broken
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-30 23:16:52+00:00
Resolved: 2021-05-28 20:21:39+00:00

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

Steps to reproduce:

When opening "Page Info" under the "Tools" option and then choosing the "Media" option, on an Instagram post, images appear broken, as if it points to an image that doesn't exist. However, if I copy the link in the "Location:" field and post it in the address bar, it will appear upon navigating to it.


Actual results:

Upgraded to version 88.0 and since then, something occurred and now all images as described above appear broken. I have disabled/uninstalled add-ons, created new profiles, downgraded to the version just prior, re-upgraded to version 88.0 and the same result continues.


Expected results:

You should have seen the image itself in the empty field in the bottom half.

Note: This seems to have only happened on Instagram's site itself. I have not seen this replicated on bugzilla for example.
Bug: Can't remove an address bar autocomplete entry
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-05-01 01:01:45+00:00
Resolved: 2021-05-11 05:39:22+00:00

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

Steps to reproduce:

typed in the first few characters of an address. I've purged the site and all related sites from my history using the "forget this site" button. I've also tried highlighting the entry in the address bar dropdown using the down button and deleting it by pressing "delete" and "shift+delete," done all of these a number of times and rebooted in between, etc.


Actual results:

the address autocomplete entry is still the first thing to come up even though I haven't visited it in a decade, haven't bookmarked it ever, haven't pinned it ever, and deleted the site using the multiple methods described above.


Expected results:

it shouldn't come up anymore, according to firefox's own help pages. People have been reporting this issue on forums since 2015. All the issues on bugzilla related to this are marked "resolved," but this is clearly not resolved.
Bug: Tab focused state is wrong colour in Dark Mode
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-05-01 03:34:04+00:00
Resolved: 2023-04-26 21:48:42+00:00

Hi, 

The tab focused state for Dark mode is using the Light mode version. It should be #00DDFF for Dark mode for all tab focused states
Bug: [http3 enabled] Wrong Site Identity Displayed in Address Bar Due to Possible Race Condition
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-05-01 06:11:54+00:00
Resolved: 2021-05-25 09:34:53+00:00

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

Steps to reproduce:

1. Open about:preferences in a tab.
2. **Very quickly** open another new tab, search for something, and hit enter.
2. Observe the site identity button.


Actual results:

The site identity button "inherits" the previously-focused tab's site identity buttons. For example, following the STR above, I'll get an incorrect `Firefox` site identity in the newly opened tab.

A look at the browser toolbox's console shows that when switching to the tab whose site identity is inherited from the previously-focused tab, a `cert is null` error is thrown in line 661 in the `chrome://browser/content/browser-siteIdentity.js` file.

An interesting observation I noticed was that this bug was reproducible in the first 6 beta releases from the 88 cycle (88.0b1 - 88.0b6) but was not reproducible in the remaining beta releases and the two release candidates (88.0b7 - 88.0b9, 88.0rc1, 88.0rc2). HOWEVER, this bug got reintroduced in 89.0b1 and is still reproducible in the current beta (89.0b6), which hints at the possibility that this bug was caused by code within the EARLY_BETA_OR_EARLIER define.


Expected results:

The site identity should correctly correspond to the currently focused tab, not "inheriting" it from the previously-focused tab.
Bug: modifing the mozilla sync request result to make the server to interact with external
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-05-01 06:42:29+00:00
Resolved: 2022-09-06 17:17:46+00:00

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

Steps to reproduce:

1:open firefox simply and intercept the request with burp
(in my case i get request like this:-
GET /direct?url=https%3A%2F%2Fpocket-image-cache.com%2F1200x%2Ffilters%3Ano_upscale%28%29%3Aformat%28jpg%29%3Aextract_cover%28%29%2Fhttps%253A%252F%252Fpocket-syndicated-images.s3.amazonaws.com%252Farticles%252F6213%252F1617941161_606fbd39a4bcc.png&resize=w450 HTTP/1.1
Host: img-getpocket.cdn.mozilla.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: null
Connection: close)
2:In this some url param get passed then i modified the url with my burp collaborator payload
3:send the request and note the burp collaborator




Actual results:

It make http and dns request to external server


Expected results:

with this issus attacker use this  server as attacking proxy...