av9ash/GitBugs huggingface dataset:
Bug: Address bar layout is broken when changing UI density while in DOM fullscreen mode
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-24 05:15:42+00:00
Resolved: 2020-05-11 12:24:47+00:00

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

Steps to reproduce:

A 2 in 1 Windows 10 laptop is needed to easily reproduce this issue. 

1. Start with desktop mode.
2. Navigate to any video on YouTube and watch it in fullscreen.
3. Switch from desktop mode to tablet mode while in fullscreen. 
4. Switch back to desktop mode from tablet mode while in fullscreen.
5. Exit fullscreen.
6. Click on the search bar.

My device: HP Spectre x360
This issue could be reproduced in a new profile.
The problem can be reproduced using the latest Nightly build.


Actual results:

The search bar is shifted upwards by a few pixels such that there is no top margin and the bottom margin is doubled. When focused, the text is shifted upwards even further and is barely visible. Only the suggestions are visible. Please see the attached image file.


Expected results:

The search bar should not have shifted and input text should be fully visible when focused.
Bug: Loading a web page then about:logins in the same tab fails to show logins due to remoteType mismatch
Status: RESOLVED
Priority: P1
Resolution: INVALID
Created: 2020-04-24 05:47:56+00:00
Resolved: 2020-04-29 19:24:07+00:00

In the Browser Console this message is shown:
AboutLoginsParent: Received AboutLogins:Subscribe message the remote type didn't match expectations: web == privilegedabout

STR:
Using m-c revision 3f7b8c984869
Open a new tab (Tab A)
Visit about:logins in tab A
See text/content in the page and no error message in the Browser Console
Open a new tab (Tab B)
Visit mozilla.org in tab B
Visit about:logins in tab B

ER:
Same text/content in tab B as in tab A

AR:
No text/content in tab B and error message in Browser Console

@mconley, has anything changed recently regarding remoteType and privilegedabout?
Bug: Crash trying to view-source for about:welcome
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-24 06:56:29+00:00
Resolved: 2020-04-24 17:36:22+00:00

Instant crash when you try to view source on about:welcome on Nightly. Beta and Release are fine. It's an intentional MOZ_CRASH() but no reason given.

STR:
1. open [about:welcome](about:welcome)
2. Ctrl/Cmd-U or dig deep into the Tools menu

or open a tab and go directly to `view-source:about:welcome` (view-source links don't work, but the URLs work in the address bar).

bp-eef99f2e-1e35-4961-93ff-b53d30200424
Bug: The checkbox background color changes when clicked
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-24 08:17:46+00:00
Resolved: 2020-06-11 19:21:48+00:00

**Affected versions**
* Fx77.0a1

**Affected platforms**
* Windows

**Preconditions**
* Firefox is already installed through Stub installer and the browser was ran at least once.

**Steps to reproduce**
1. Uninstall the Firefox copy from the preconditions.
2. Launch the stub installer.
3. Click inside the displayed checkbox.

**Expected result**
* The checkbox doesn't change color.

**Actual result**
* The checkbox box inherits the color of the background.

**Additional notes**
* I am not sure if this is a feature(just new behavior) or an actual bug. In the previous stub, the checkbox didn't change color when clicked.
Bug: Installer Progress Bar is stuck while the installation window is moved around the screen
Status: NEW
Priority: P2
Created: 2020-04-24 08:18:16+00:00
Resolved: 2021-10-07 21:57:56+00:00

**Affected versions**
* 77.0a1 (20200423214309)

**Affected platforms**
* Windows 10 x64
* Windows 8.1 x64

**Steps to reproduce**
1. Download and run the Stub Installer.
2. Click ->hold-> and move the installation window around the screen.

**Expected result**
* The installation progress is correctly displayed while the installation window is moved around the screen. 

**Actual result**
* The Progress Bar is stuck while the installation window is moved around the screen. When the installation window is released, the progress is correctly displayed. 

**Regression range**
* I will search for one ASAP if there is one. 
* On Firefox 71 stub installer, the installation progress is correctly displayed while the installation window is moved around the screen.  

**Notes**
* Attached a screen recording.
* This occurs for all the stub installer windows (install, reinstall, update).
Bug: Dialog to change bookmark no longer remembers size (regression)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-24 09:02:39+00:00
Resolved: 2020-04-24 12:02:42+00:00

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

Steps to reproduce:

Change properties of a bookmark.


Actual results:

Until some time ago firefox remembered the size of the dialog which opens when I modify a bookmark entry.

Now it always opens this dialog with the same extremely small size, so that each time when changing a bookmark entry you first have to resize the dialog to see the full URL and then it can be edited.

Same happens on different profiles and machines, so I doubt it's an issue with my profile.


Expected results:

Either the dialog should be much bigger (it is 368x338 on a 1960x1240 firefox window, that's microscopic) or it again should remember the previous used values.
Bug: Autoscrolling cursor becomes a blank square
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-24 09:55:47+00:00
Resolved: 2020-04-24 10:00:49+00:00

Steps:
1. enable autoscrolling
2. middle click a page

Expected result:
see the autoscrolling cursor

Actual result:
see a blank square


(I believe it's a very recent regression)
Bug: Canceling the OS auth dialog is wrongly counted as an invalid login attempt
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-24 10:11:51+00:00
Resolved: 2020-05-12 03:33:25+00:00

[Affected versions]:
- Nightly 77.0a1;
- Beta 76.0b8;

[Affected Platforms]:
- Windows 10 x64;
- Windows 7 x64;
- Windows 8.1 x32;

[Prerequisites]:
- Have an OS password set.
- Have at least one login saved.
- Have an account lockout policy set to 5 invalid logon attempts. 

[Steps to reproduce]:
1. Open the latest Nightly Firefox browser.
2. Navigate to the "about:logins" page and select a saved login.
3. Click on the "Show Password" button.
4. Click the "Cancel" button of the OS auth dialog.
5. Repeat 4 more times the step 3 and 4.
6. Click again the "Show Password" button.
7. In the OS auth dialog enter the valid password.
8. Observe the behavior.

[Expected result]:
- The password is shown.

[Actual result]:
- "The referenced account is currently locked out and may not be logged on to." message is displayed and the password is not shown.

[Notes]:
- Also, the "`pwmgr 	reauthenticate 	os_auth  fail`" telemetry event is registered when the OS auth dialog is canceled. This telemetry event is also sent on Mac OS when the auth dialog is canceled.
- Attached a screen recording with the issue.
Bug: Page info window strings don't update properly
Status: NEW
Priority: P3
Created: 2020-04-24 11:06:59+00:00
Resolved: 2020-05-13 15:23:26+00:00

From https://phabricator.services.mozilla.com/D71928#inline-423841 :

The pattern here that does:

```
if (value)
  document.l10n.setAttributes(element, ...);
else
  setItemValue(elementid, null);
```

will break if the Page Info dialog is first loaded for a case where the element will be hidden, and then reloaded through the resetPageInfo code path, as nothing will unhide the element.

This applies to some other occurrences that were converted to Fluent in pageinfo related code.
Bug: ModalPrompter falls back to window prompts for subframe BrowsingContexts
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2020-04-24 11:35:07+00:00
Resolved: 2020-08-21 19:35:01+00:00

Currently, when prompting with a BC of a subframe, `ModalPrompter` will fail to get the window actor and fallback to a window prompt.


For example, running this on a page with an iframe will result in a window prompt:
```
Services.prompt.alertBC(gBrowser.selectedBrowser.browsingContext.children[0], Services.prompt.MODAL_TYPE_TAB, 'title', 'body')
```

Using the top browsing context [here](https://searchfox.org/mozilla-central/rev/41c3ea3ee8eab9ce7b82932257cb80b703cbba67/toolkit/components/prompts/src/Prompter.jsm#490) probably fixes this.
Bug: [Windows 7] Stub Installer cannot be installed on a clean environment
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-24 11:45:31+00:00
Resolved: 2020-04-28 07:33:59+00:00

**Affected versions**
* 77.0a1(2020-04-24)

**Affected platforms**
* Windows 7x86

**Steps to reproduce**
1. Download the targeted Firefox Stub Installer.
2. Run Firefox Stub Installer.
3. Click "Yes" on the UAC Prompt.

**Expected result**
* The Installation starts.

**Actual result**
* An error message is displayed saying that “Firefox Nightly Installer has stopped working”

**Regression range**
* Don’t think this is a regression since it is part of the new feature.

**Additional notes**
* I used a clean environment for this (all mozilla appdata and registries were emptied before running the stub installer)
* A Stub Installer 74 version works fine.
* See the attached screenshot with the error message.
Bug: The "Re-Install"/"Update" button is highlighted in High Contrast mode when the checkbox's associated text is selected
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-04-24 12:55:32+00:00
Resolved: 2020-06-11 19:34:25+00:00

**Affected versions**
* 77.0a1 (20200423214309)

**Affected platforms**
* Windows 10 x64

**Preconditions**
* High Contrast mode activated.
* Firefox "Re-install"/"Update" web based stub installer opened.

**Steps to reproduce**
1. Click on the checkbox's associated text ("Restore default settings and remove old add-ons for optimal performance"). 

**Expected result**
* The "Re-Install"/"Update" button is not highlighted. 

**Actual result**
* The "Re-Install"/"Update" button is highlighted. 

**Additional notes**
* Attached a screen recording.
Bug: [Wayland] Firefox Nightly 77a1 freezes
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-24 14:39:22+00:00
Resolved: 2020-04-30 15:06:33+00:00

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

Steps to reproduce:

Scrolling up and down on pages makes firefox 77a1 freeze for 2-3 seconds when you change scroll direction. 
The Firefox drop down menu is also acting very weird, it doesn't render/update properly.

It seem to do the same thing with both basic renderer and webrender.


Actual results:

I've noticed those freezes in other situations as well but it's very apparent when scrolling or watching videos.


Expected results:

A few days ago firefox wasn't like this so it's probably a recent commit that's causing this. I'm pretty sure the issue doesn't exist in Firefox Nightly from 2020-04-10.

Arch Linux - KDE Wayland 5.18.4.
Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
Integrated Intel Graphics
Haswell-ULT Integrated Graphics Controller
Bug: Keyboard actions on the pref toggle checkbox close the WNPanel
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2020-04-24 16:07:25+00:00
Resolved: 2020-05-27 17:38:39+00:00

We should update handling of keyboard actions so that their behaviour imitates the click behaviour (Panel remains open when the checkbox is toggled) .
Bug: The upper part of letters is cut off on Facebook.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-24 16:43:38+00:00
Resolved: 2020-11-16 09:10:04+00:00

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



Actual results:

The lower "POLSATNEWS.PL" is cut off at the top. This is error on Ubuntu MATE 20.04.
Bug: Measure a more optimal 2-lines wrapping threshold based on average url/title length
Status: NEW
Priority: P3
Created: 2020-04-24 17:14:16+00:00
Resolved: 2020-05-13 13:42:20+00:00

Unfortunately Nightly had a startup crash yesterday which prevents a full bisection:
 3:00.33 INFO: Last good revision: 03626342f6e659ac6699a21e30423e2267c1971f
 3:00.33 INFO: First bad revision: ff7eec7be698cd21d92755d709e08897100fa9c8

The Megabar now puts URLs and titles on two lines, despite there being plenty of room to fit. This results in the popup being a mostly empty white square, with a tiny bit of text on the left.

Expanding it very slightly returns to the previous behavior, but also makes it clear there was still plenty of headroom to fit everything on one line (see second screenshot). Looks like some size calculation is off?
Bug: There are no search engines by default in the new version  77.0a1(24-04-2020) 64 bits
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-04-24 17:22:34+00:00
Resolved: 2020-05-12 19:08:05+00:00

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

Steps to reproduce:

There is no pôssiblity to add search engine/ no search engine by default in the new version of Firefox 77.0a1 nightly.


Actual results:

impossible to search anything


Expected results:

at minimum, a search engine openned, and results with...
Bug: First keyboard input in URL bar is sluggish due to what appears to be synchronous IO by way of the updater service
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-24 17:27:24+00:00
Resolved: 2020-05-08 13:37:28+00:00

Here's a profile: https://perfht.ml/2VTGlot

There's about half a second of jank here when I pressed a keyboard button for the first time in this session.

Here's the important stack:

```
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
getElevationRequired
aus_gCSUS
get
getCanStageUpdates
get canStageUpdates
XPCWrappedJS method call
get updateStagingEnabled
get isReadyForRestart
check
checkForBrowserUpdate
isActive
tryMethod
InterpretGeneratorResume
AsyncFunctionNext
promise callback
```

This is from a local build with a relatively new profile, built from https://hg.mozilla.org/mozilla-central/rev/47426d145e24.
Bug: Intermittent browser/base/content/test/general/browser_bug763468_perwindowpb.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-04-24 19:19:50+00:00
Resolved: 2023-10-13 12:03:41+00:00

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

---

[task 2020-04-24T17:05:32.059Z] 17:05:32     INFO - TEST-PASS | browser/base/content/test/general/browser_bug763468_perwindowpb.js | URL of NewTab should be about:newtab in normal mode - 
[task 2020-04-24T17:05:32.059Z] 17:05:32     INFO - Buffered messages finished
[task 2020-04-24T17:05:32.063Z] 17:05:32     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug763468_perwindowpb.js | Test timed out - 
[task 2020-04-24T17:05:32.063Z] 17:05:32     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-04-24T17:05:32.063Z] 17:05:32     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug763468_perwindowpb.js | Uncaught exception received from previously timed out test - 
[task 2020-04-24T17:05:32.063Z] 17:05:32     INFO - GECKO(4265) | MEMORY STAT | vsize 3482MB | residentFast 372MB | heapAllocated 118MB
Bug: Firefox Sync Rewrites/Loses Contents of Bookmark Folders with Identical Names
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2020-04-24 19:38:46+00:00
Resolved: 2020-08-18 06:33:55+00:00

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

Steps to reproduce:

This occurs on Firefox on Windows 10.

Unfortunately I've had issues reliably reproducing this issue, but it typically occurs when I'm reorganizing a large number of bookmarks. I've had a similar issue delete a massive number of bookmarks back when Sync was relatively new, but hoped/assumed it had been fixed until I ran into the same issue again recently.


Actual results:

If I create folders with identical names under differently named hierarchies such as:

* Folder1/SubFolder1/Instructions/
* Folder2/SubFolder2/Instructions/

...Firefox Sync will oftentimes mix-up the contents of the two folders, or the bookmarks within will disappear or return to their original location if I moved them from another folder.

I have found that renaming the folders so that they are truly globally unique helps, but I'm often adding an abbreviation of the hierarchy to the ends of folder names, which feels unnecessary and tedious. I'm also concerned about losing a massive amount of bookmarks again as the automated backups from sync do not seem to capture bookmarks moved or created in this instance.


Expected results:

I expected that the contents of each matching folder name with different parental hierarchies remain consistent with where I place/create/move them. Bookmarks should not be lost or restored to their original location if moved.
Bug: Web stub: Focus rectangle is visible on "Now installing..." text on Win7
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-04-24 19:50:06+00:00
Resolved: 2020-05-19 14:41:22+00:00

This focus rectangle is due to the screen reader workaround which required a focus on the page (see bug 1596812 comment 26). However I had thought it would be invisible, as the focused div is not a control, until the user started tabbing through the page; this is the case on Win 10. But with the fix for bug 1632807 allowing it to run on Win 7, the focus rectangle is immediately visible.

I'll try to make this invisible with CSS.
Bug: The message-group provider is causing 404 error for RemoteSettings
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-24 21:18:25+00:00
Resolved: 2020-05-28 14:09:16+00:00

RS client is complaining about `Unknown Collection "main/message-groups" RemoteSettingsClient.jsm:137`. We should create this collection on RS if we wanted to use it, if not, perhaps disable this provider for now.
Bug: "Search with Google" sometimes gets prepended to URLs in autocomplete suggestions (i.e. history matches are displayed as if they were searches)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-24 22:25:31+00:00
Resolved: 2020-06-03 12:30:13+00:00

I don't have reliable STR for this, but I managed to get a screenshot (see attached).

The bug: sometimes when I'm typing a search query into my address bar, and I also have history matches for it, and I hit "downarrow", then:
 - "Search with Google" label suddenly gets at the start of the URL for my history matches
 - The icon for these history matches changes to a magnifying glass, as if they were a suggested search rather than a match in my history.

This seems to happen if I hit downarrow **precisely at the same time** as I type a character in my search term. E.g. in the attached screenshot, I was in the process of typing "fpn proxy" and I pressed downarrow and "x" simultaneously which resulted in the broken rendering that I captured here.
Bug: Beta 76 pull-factor test-run experiment enrolled too many invalid users
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-24 23:06:35+00:00
Resolved: 2020-10-27 01:11:11+00:00

* Type of issue: Targeting expression result did not match intent.
* Result: Too many users were enrolled in the experiment that never saw about:welcome.
* Cause: We didn't include profile age filtering in the targeting expression. We identified this during review as a possible issue, but decided to go ahead to see if it would be ok without it since this was a beta dry run – and since we suspected there might be issues with accessing the ASRouter `profileDateCreated` from disk
* Impact to experiment: We will need to restart. No impact to the actual product goals here since this was a test run.
Bug: Falsche Farbe bei unbesuchten Links wenn ausgewählte Farben 'IMMER' benutzen steht
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-24 23:06:36+00:00
Resolved: 2020-07-09 12:04:22+00:00

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

Steps to reproduce:

Nichts geändert, dummerweise neues Firefox Release runtergeladen und
installieren lassen.


Actual results:

Unbesuchte Links werden jetzt in Textfarbe (schwarz) anstatt in der Farbe der
unbesuchten Links (grün) dargestellt, aber nicht auf allen Webseiten.
Begonnen hat der Blödsinn in etwas abgewandelter Form bereits beim letzen oder
vorletzen Update (da wurde etwas an den Farben geändert); seitdem wurden unbesuchte Links nicht mehr als besuchte Links markiert, wenn man diese besucht hat, aber nur auf einigen Webseiten.
Als Einstellung ist 'Benutze IMMER ausgewählte Farben' gesetzt, war seit mindestens zwei Jahren so und ist es noch immer.
Die Funktionen die vom vorgegebenen Installations-Standard abweichen scheint niemand mehr ernsthaft zu testen (wenn überhaupt).
Ich benutze Firefox schon über 4 Jahre aber solche Bugs hat es bisher in der Form nicht gegeben.



Expected results:

Das was seit Jahr und Tag gemacht wurde und bis jetzt stets funktioniert hat!
Wenn ich als Farben die benutzerdefinierten wähle und 'IMMER' setze, erwarte
ich auch daß diese Farben auch weiterhin so benutzt werden. Warum denkt Ihr,
daß ich die Farben auf benutzerdefiniert gesetzt habe, wenn ich jetzt besuchte
Seiten nicht mehr von unbesuchten Seiten unterscheiden kann, geschweige denn
sehen kann, daß das Links sind und kein normaler Text?
Und erzählt mir nicht, daß das kein Bug sondern ein Feature ist!
Bug: Remember that a Windows accounts has no password to limit future failed authentication attempts
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-25 02:50:42+00:00
Resolved: 2020-05-26 15:05:41+00:00

As part of authenticating against the OS when providing access to stored passwords in about:logins, we attempt to check if the user has no password on their account. This will register as a login attempt, and can count against a users allowed number of failed login attempts.

We should cache if the user has no password so we can skip this step in the future. We can use https://docs.microsoft.com/en-us/windows/win32/api/lmaccess/ns-lmaccess-user_info_1 to check the password age and re-attempt if the password has been changed.
Bug: Doesn't save default browser setting in preferences
Status: UNCONFIRMED
Priority: P5
Created: 2020-04-25 09:43:28+00:00
Resolved: 2020-05-15 20:00:28+00:00

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

Steps to reproduce:

KDE Neon 5.18 - Firefox 75

Set Firefox as default browser in Preferences


Actual results:

Firefox doesn't save my setting, so it continue to show the message "Not default browser" every time I open it.
If I change other settings at the same time, it saves also the default browser one.


Expected results:

Fifefox should save the default browser setting in Preferences also without other change
Bug: Alt + A is show as mapped to a menu, but selects all
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-25 15:45:23+00:00
Resolved: 2020-04-27 08:58:40+00:00

Hello,

In the French version of Firefox _View_ is translated to _Affichage_ and the `A` is underlined suggesting that Alt + A is a binding to open the view menu, but instead it selects everything making it impossible to open the view menu using keyboard navigation.

https://bugzilla.mozilla.org/show_bug.cgi?id=1376091 and https://bugzilla.mozilla.org/show_bug.cgi?id=1308726 are the same issue, but for other languages and other menus.