av9ash/GitBugs huggingface dataset:
Bug: Intermittent TV browser/components/urlbar/tests/browser/browser_autocomplete_a11y_label.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-03-05 13:09:25+00:00
Resolved: 2020-03-31 17:04:07+00:00

**Filed by:** aciure [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=291802811&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MfP-CR6wST-ZhD8VbcsWdA/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MfP-CR6wST-ZhD8VbcsWdA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---

[task 2020-03-05T12:21:23.123Z] 12:21:23     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_autocomplete_a11y_label.js
[task 2020-03-05T12:22:08.254Z] 12:22:08     INFO - TEST-INFO | started process screentopng
[task 2020-03-05T12:22:08.485Z] 12:22:08     INFO - TEST-INFO | screentopng: exit 0
[task 2020-03-05T12:22:08.486Z] 12:22:08     INFO - Buffered messages logged at 12:21:23
[task 2020-03-05T12:22:08.487Z] 12:22:08     INFO - Entering test bound switchToTab
[task 2020-03-05T12:22:08.488Z] 12:22:08     INFO - Buffered messages finished
[task 2020-03-05T12:22:08.490Z] 12:22:08     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_autocomplete_a11y_label.js | Test timed out - 
[task 2020-03-05T12:22:08.491Z] 12:22:08     INFO - GECKO(9169) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2020-03-05T12:22:08.492Z] 12:22:08     INFO - GECKO(9169) | MEMORY STAT | vsize 2977MB | residentFast 279MB | heapAllocated 106MB
[task 2020-03-05T12:22:08.493Z] 12:22:08     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_autocomplete_a11y_label.js | took 45132ms
[task 2020-03-05T12:22:08.495Z] 12:22:08     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-03-05T12:22:08.495Z] 12:22:08     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_autocomplete_a11y_label.js | Found a tab after previous test timed out: about:robots - 
[task 2020-03-05T12:22:08.497Z] 12:22:08     INFO - checking window state
[task 2020-03-05T12:22:09.665Z] 12:22:09     INFO - GECKO(9169) | Completed ShutdownLeaks collections in process 9355
[task 2020-03-05T12:22:09.681Z] 12:22:09     INFO - GECKO(9169) | Completed ShutdownLeaks collections in process 9323
[task 2020-03-05T12:22:09.701Z] 12:22:09     INFO - GECKO(9169) | Completed ShutdownLeaks collections in process 9246
[task 2020-03-05T12:22:09.721Z] 12:22:09     INFO - GECKO(9169) | Completed ShutdownLeaks collections in process 9229
[task 2020-03-05T12:22:10.010Z] 12:22:10     INFO - GECKO(9169) | Completed ShutdownLeaks collections in process 9169
Bug: Crop urls in the middle in the results panel
Status: NEW
Priority: P5
Created: 2020-03-05 13:17:48+00:00
Resolved: 2025-03-02 14:54:26+00:00

Being able to quickly and efficiently search one's history for specific pages was one of the strongest features of the urlbar.
For this, one needs to be able to see the relevant parts of the URL and/or title directly in the results.
Comically short truncation of URLs and titles in the design update means this will, in many cases become a super tedious task of tooltipping or cycling through many results instead of a single look, zero effort operation.

It is especially troubling, that this functionality now directly depends on the amount of UI elements competing for space against the urlbar (breaking web-search out into its own bar for more/better history-search results in the urlbar dropdown makes those same results less useful!).

It's clear that no amount of stripping www or http(s), shifting weights between titles and URLs will alleviate this considerably in the available amount of space.

From other bugs it is clear you are unwilling to change the default horizontal size of the dropdown for the sake of it becoming a single but rather useless widget in this configuration and that there is an automatically triggered 2-line mode for ultra-slim window sizes beyond use which thus ends up giving equally short results.

Two reasonable solutions which should remove everyone's gripes about the changes jump to mind:
1. Resizable urlbar dropdown
Optionally a drag handle for discoverability, it would give users a choice, when they feel the extra space for useful results would outweigh the developers wish for this widget to be visually one consistent thing in width.
_Default configuration users who don't care one way or the other will see no difference to your current implementation._

2. Give a pref to force enable 2-line mode manually.
IIRC back then this was default, the need for a super wide dropown only came about the then equally controversial decision to put URLs and titles on one line. It's already implemented, let users have the choice.
_Again, no impact on default configuration users._

Would these still collide with your design goals?
Bug: The "Firefox Accouns" sign in page is no longer opened after the "Sign in to Sync" card button is clicked from the simplified "about:welcome" page
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-03-05 13:47:44+00:00
Resolved: 2020-03-06 10:10:32+00:00

**[Affected versions]:**
- Firefox Nightly 75.0a1 - Build ID: 20200305095541

**[Affected Platforms]:**
- Windows 10 x64
- Mac 10.15.3
- Ubuntu 18.04 x64

**[Prerequisites]:**
- Have a Firefox profile with the "browser.aboutwelcome.enabled" pref set to "true" in the "about:config" page:

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the "about:welcome" page.
3. Click the "Sign in to Sync" button from the "Take Your Settings with You" card.
4. Observe the behavior.

**[Expected result]:**
- The "Firefox Accounts" sign-in page is opened in a new tab.

**[Actual result]:**
- Nothing happens.

**[Regression window]:**
- Considering the fact that this issue is not reproducible with the Firefox Nightly build from 03/05/2020, using the Mozregression tool I have managed to find the following regression window:
Last good revision: 583ce79ba23238cbf221d0861b328ceb2d79280c
First bad revision: 20a86a3e73298195aa242fb45d131cc1154c72b4
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=583ce79ba23238cbf221d0861b328ceb2d79280c&tochange=20a86a3e73298195aa242fb45d131cc1154c72b4

From the pushlog, it seems that bug 1616371 has caused this behavior.

**[Notes]:**
- This issue is not reproducible if the "Sign in to Sync" card button is clicked from the "about:newtab" page.
- This issue is not reproducible with the existing "about:welcome" page.
- Attached a screen recording of the issue.
Bug: No telemetry ping is displayed in the "Browser Console" if the "Start Browsing" button from the simplified "about:welcome" page is clicked
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-03-05 14:23:19+00:00
Resolved: 2020-04-27 10:49:19+00:00

**[Affected versions]:**
- Firefox Nightly 75.0a1 - Build ID: 20200305095541

**[Affected Platforms]:**
- Windows 10 x64
- Mac 10.15.3
- Ubuntu 18.04 x64

**[Prerequisites]:**
- Have a Firefox profile with the following prefs in the "about:config" page:
	- "browser.aboutwelcome.enabled" set to "true";
	- "browser.ping-centre.log" set to "true"

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the "about:welcome" page.
3. Click the "Start Browsing" button and focus the "Browser Console".
4. Observe the displayed telemetry ping.

**[Expected result]:**
- An "about:welcome" click telemetry ping is displayed.

**[Actual result]:**
- There is no telemetry ping displayed.

**[Notes]:**
- This "impression" and cards "click" events are successfully displayed in the "Browser Console".
- Attached a screen recording of the issue.
Bug: The “Collections Promo” section is redisplayed on a new tab after it was previously dismissed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-05 15:41:52+00:00
Resolved: 2020-03-09 16:09:35+00:00

**[Affected versions]:**
Firefox Nightly 75.0a1 Build ID: 20200305095541

**[Affected Platforms]:**
- Windows 10 x64
- macOS 10.15
- Ubuntu Linux 18.04 x64

**[Prerequisites]:**
- Have the value of the pref `browser.newtabpage.activity-stream.discoverystream.spocs-endpoint` set to `https://spocs.getpocket.com/spocs?site=1116390`.
- Have the value of the pref `browser.newtabpage.activity-stream.discoverystream.isCollectionDismissible` set to `true`.
- Have the value of the pref` browser.search.region` set to `US`.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites and open a new tab.
2. Press the “Dismiss” button from the “Collections Promo” section.
3. Open a new tab and observe the page.

**[Expected result]:**
- The “Collections Promo” section is no longer displayed.

**[Actual result]:**
- The “Collections Promo” section is redisplayed with 3 new cards.

**[Notes]:**
- The issue is also reproducible after dismissing, saving to Pocket, or deleting from Pocket.
- Attached a screen recording of the issue.
Bug: URLBar Interventions should honor policy (and be able to be disabled by policy)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-05 16:29:36+00:00
Resolved: 2020-03-26 15:31:38+00:00

Currently URLBar Interventions tells users they can refresh Firefox, but if refresh has been turned off by policy, they cannot.

The same is true of the update policy. If update is turned off, that policy should not show.

Any interventions that intersect with policy should check policy to see if they should be displayed.

In addition, we should provide a policy to completely turn off interventions. This can go in the new "UserMessaging" section of policy.
Bug: Close X does not work if on current tab. have to go to another tab and click on X to close tab
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-03-05 18:51:50+00:00
Resolved: 2020-04-02 10:19:13+00:00

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

Steps to reproduce:

Clicking X to close tab does not work if on current tab. have to go to another tab and click on X to close tab


Actual results:

Clicking X to close tab does not work if on current tab. have to go to another tab and click on X to close tab


Expected results:

Clicking X should close tab
Bug: Element h2 not allowed as child of element span in this context
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2020-03-05 18:59:54+00:00
Resolved: 2020-06-05 15:41:51+00:00

I copy/pasted the generated source (via inspect element and copying the outer <html> tag's content) into https://validator.w3.org/nu/#textarea and got a few of these messages:

Error: Element h2 not allowed as child of element span in this context. (Suppressing further errors from this subtree.)
Error: Element p not allowed as child of element span in this context. (Suppressing further errors from this subtree.)
Bug: Context menu hotkeys don't work with locale en-us
Status: NEW
Priority: --
Created: 2020-03-05 19:19:00+00:00
Resolved: 2022-10-12 00:02:24+00:00

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

Steps to reproduce:

Attempting to use shortcut keys of the right-click context menu while the Firefox localization is different from the keyboard language.


Actual results:

Nothing


Expected results:

Сontext menu items should work regardless of the language layout of the user keyboard.

Details:
The Firefox context menu (right-clicking on a page) in different language localizations only works if the browser language matches the language layout of the keyboard.

This causes the following problems:
* hot keys only work if the correct keyboard layout is selected (very inconvenient when there are many language layouts on the computer).
* many add-ons usually have their own hotkeys in English only (for example, Open Image In New Tab https://addons.mozilla.org/en/firefox/addon/open-image-in-new-tab-new/).
In this case, part of the context menu items work with one language keyboard layout, part with another one.
* some add-on hotkeys conflict with built-in hotkeys in Firefox or hotkeys from other add-ons.
In case of conflict with Firefox, the hotkey just doesn't work.
Bug: flexible space is too narrow in the navbar in customize mode
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-03-05 21:26:18+00:00
Resolved: 2020-03-13 09:49:54+00:00

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

Steps to reproduce:

add spacers to the left of the "previous page" button (left of URL bar)


Actual results:

tiny spacers appear in customization-view.


Expected results:

should appear just as wide in customization-view as they appear in bookmark-bar.
Bug: about:logins - have [Sort by] button share the same width as the dropdown menu
Status: RESOLVED
Priority: P5
Resolution: WONTFIX
Created: 2020-03-06 09:05:22+00:00
Resolved: 2020-04-08 19:30:16+00:00

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

**Affected platforms**
* Windows 10, macOS 10.15, Ubuntu 19.04; 

**Steps to reproduce**
1. Launch Firefox, access about:logins
2. Input any dummy_logins if none added in the list;
3. Click on the [Sort by] button;

**Expected result / Enhancement suggestion**
* dropdwn menu is of the same width as the button;

**Actual result**
* dropdown menu width is greater than the button;

**Regression range**
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2c268d869bc48dc4d5e8ff036cac82375ecf507a&tochange=993cf82f6bbf09537f4cec8144cb69bfdf26bff3);
* Potential regressor: 1576029

**Additional notes**
* attached screenshot with the issue;
Bug: Quantumbar design update 1 - dropdown on focus for already open tab
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-03-06 09:24:27+00:00
Resolved: 2020-03-06 12:40:18+00:00

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

Steps to reproduce:

Go to any Url, focus on a URL-bar


Actual results:

After focusing on URL bar, apart from selecting/highlighting current URL, a megabar dropDown results opens.
This behavior doesn't match with current Release implementation.
On Release if you focus/mouseclick on a URL bar that has an URL address, it becomes selected/highlighted.
Only if you continue modifying it (add/delete characters), a dropDown appears.
There are situations when user doesn't have intentions to actually modify URL address and still he clicks on URLbar. In such cases megabar dropDown results are needless and occupy visual space due to its presence.


Expected results:

After a simple Focus on a Url bar that has an URL address no dropDown should be present.
Only a selection/highlighting of current URL should be initiated


This behavior was present in Nightly few days ago. but was gone yesterday
Bug: "Import from another browser" menu adds noise and scroll bar to the app menu
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-03-06 09:39:30+00:00
Resolved: 2020-03-30 15:30:07+00:00

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

Steps to reproduce:

Recently a new button "Import from another browser" was added to the root of App/Hamburger button.



Expected results:

An additional button in the root of the menu makes it too crowded. Taking into account that this functionality is not used daily, moving it to "Help"  sub-menu
Bug: [68.6.0esr] Address bar is closed when using scroll mouse button
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-06 12:21:05+00:00
Resolved: 2020-03-16 20:17:51+00:00

**Affected versions**
* Firefox 68.6.0esr (20190702220624)


**Affected platforms**
* Windows 7x64



**Steps to reproduce**
1. Launch Firefox and type something in the address bar.
2. Hover over outside the browser and use the scroll mouse wheel (up/down). 


**Expected result**
* Nothing happens.

**Actual result**
* Address bar is closed.

**Regression Range**
* The issue is reproducible on 68.4.2esr (20200117153614).I will search for one ASAP.

**Additional Notes**
* The issue is not reproducible on Windows 10x64, macOS 10.15 or Ubuntu 18.04.
* Firefox 74.0 and Nightly are not affected.
* Attached a screen recording with the issue.
Bug: Wrong Region For Search Engines (when in austria)
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-03-06 12:53:21+00:00
Resolved: 2021-06-17 15:34: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:

My Firefox browser is in English (UK), the "browser.search.region" is set to "AT" (for Austria) and so is my Windows 10 region.


Actual results:

My default search engines are for the UK, e.g. amazon.co.uk and chambers (UK).


Expected results:

My default search engines should be for Austria, e.g. amazon.de or wikipedia.at
Bug: UrlbarProviderSearchTips.jsm triggers main thread I/O to updates.xml to fetch the updateCount
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-03-06 13:19:52+00:00
Resolved: 2024-03-20 19:00:41+00:00

The `lastBrowserUpdateDate` function in UrlbarProviderSearchTips.jsm is async so it looks like it was meant to not block the main thread, but calling updateManager.updateCount at https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/browser/components/urlbar/UrlbarProviderSearchTips.jsm#464 triggers main thread I/O to updates.xml. See this profile: https://perfht.ml/2vIUtI3

This code is from bug 1606909 and just got enabled in bug 1617029.
Bug: Pop-up blocked Storage access policy in Firefox Nightly
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-03-06 13:33:49+00:00
Resolved: 2020-04-07 00:48:17+00:00

I have question about work with Storage Access API.
I'm call 'requestStorageAccess' after user's click in my app that comes in an iframe. If requestStorageAccess return was granted, we open the window.
This works well in Firefox, but in Firefox Nightly after requestStorageAccess firefox is blocking my window. 
Why does Firefox Nightly behave like this? How I can fix it?

I use the Firefox 73.0.1 (64-bit) and Firefox Nightly - 75.0a1 (2020-03-06) (64-bit).
Bug: aboutwelcome.css has changes after npm run bundle
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-03-06 13:38:38+00:00
Resolved: 2020-04-27 10:49:19+00:00

Right now there are changes to this file when running `npm run bundle`:

```diff
diff --git a/browser/components/newtab/aboutwelcome/content/aboutwelcome.css b/browser/components/newtab/aboutwelcome/content/aboutwelcome.css
index 74953be4dfe0..121795c9b396 100644
--- a/browser/components/newtab/aboutwelcome/content/aboutwelcome.css
+++ b/browser/components/newtab/aboutwelcome/content/aboutwelcome.css
@@ -49,7 +49,6 @@ body {
   background-color: var(--trailhead-cards-background-color);
   font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Ubuntu', 'Helvetica Neue', sans-serif;
   font-size: 16px;
-  min-height: 100vh;
   position: relative; }

 .trailheadCardGrid {
```
Bug: Jaws + aria-atomic on Input crashes Firefox on Windows
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-03-06 17:02:32+00:00
Resolved: 2020-03-06 17:08:20+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36

Steps to reproduce:

1. Open Windows 10
2. Open JAWS
3. Add aria-atomic to Input field on web page
4. Open page in Firefox


Actual results:

Firefox crashes


Expected results:

Firefox doesn't crash
Bug: Extra argument passed to loadProcessScript in MainProcessSingleton.jsm
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-03-07 01:49:28+00:00
Resolved: 2020-03-10 21:49:29+00:00

https://searchfox.org/mozilla-central/rev/e7fc3314b0dfcc61fb7dc7a09f9555660a2eafc5/toolkit/components/processsingleton/MainProcessSingleton.jsm#34-38 passes three args to `loadProcessScript`, but that function only takes two args.
Bug: Black Dialog Boxes and Sidebars with Hardware Acceleration Enabled on Mac
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-07 02:45:43+00:00
Resolved: 2020-03-08 06:18:09+00:00

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

Steps to reproduce:

1. Ensure hardware acceleration is enabled
2. Open full history, full downloads, or try to close a tab that warns you about not saving


Actual results:

The sidebar of the window is black and the dialog boxes are black and unreadable.


Expected results:

It should match the light/dark theme and not be completely black on hardware acceleration.
Bug: Logging into an account can imply sync without explicit confirmation
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-03-07 03:31:21+00:00
Resolved: 2020-04-01 06:38:38+00:00

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

Steps to reproduce:

Tried to send a tab from my desktop Firefox to my laptop. 

1. Read help for "send to device"

2. Sign up for an Firefox account on the desktop. 

3. Log into the new account on the laptop. 

4. "Send to device" in the context menu of the tab. 


Actual results:

Firefox syncs automatically bookmarks, addons and likely history without any warning. This is a potential privacy problem, in my case I have now additional Manjaro bookmarks in my bookmarks toolbar on the desktop, however synced information appearing on a work laptop may be more problematic, e.g. if private search keywords appear during a work meeting. 


Expected results:

The "send to device" should have queried for the sync preferences, or at least given a warning that it will sync even though the user only requested an action on a specific tab.
Bug: sync kills bookmarks
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-03-07 09:38:44+00:00
Resolved: 2020-07-03 07:45:46+00:00

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

Steps to reproduce:

multi devices with many bookmarks, sub folders was cleared.
bug are exiting since some years

my bookmarks are about 20000 entrys

problem with sync mobil --- only 5000 bookmarks

sync fails, only way to clear delete acount and create new