av9ash/GitBugs huggingface dataset:
Bug: Bookmark Menu OK, Bookmark Sidebar empty
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-10 16:23:30+00:00
Resolved: 2020-01-11 19:09:16+00:00

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

Steps to reproduce:

I simply updated Firefox


Actual results:

The Bookmarks Sidebar is empty. (Bookmarks in Menu and Toolbar are shown like they should!)
The Bookmark Sidebar is showing a scrollbar on the wrong side.
(This scrollbar isnt movable.)

This also happens in Safe Mode.


Expected results:

Well, we all know how a Bookmark Sidebar should behave.
Bug: User pref "browser.messaging-system.whatsNewPanel.enabled" ignored FF72
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-10 18:44:05+00:00
Resolved: 2020-01-10 20:04:49+00:00

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

Steps to reproduce:

When the "What's New" toolbar icon and menu entry was recently introduced in FF70 I added "user_pref("browser.messaging-system.whatsNewPanel.enabled", false);" to my user.js.  This was successfully incorporated into prefs.js and suppressed the unwanted pop-up notifcation.  Now FF72 has been released, this pref is ignored/over-ridden.


Actual results:

With the release of FF72 the user pref is ignored/over-ridden and the unwanted toolbar icon and hamburger menu entry is back.


Expected results:

The user pref should be honoured and suppress the toolbar icon and hamburger menu entry.
Bug: Cannot give a new folder a different name in the create bookmark popup
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-10 19:01:22+00:00
Resolved: 2020-01-13 10:41:25+00:00

1. Click the star to bookmark a page.
2. in the popup click the arrow next to the folder to expand the folder list.
3. Click to create a new folder.

Expected:

A new folder is created and the name selected for editing and can be changed.

Actual:

A new folder is created and the name is selected for editing but loses focus after less than a second.
Bug: Clear cookies and site data dialog missing buttons
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-01-10 20:24:56+00:00
Resolved: 2020-02-07 11:22:06+00:00

Steps to reproduce:

1. Navigate to a site that sets cookies.
2. Open site identity panel and click "Clear Cookies and Site Data..."

What happens:

Dialog appears without visible buttons.

Expected result:

Buttons should be visible without resizing dialog. 

15:06.55 INFO: No more inbound revisions, bisection finished.
15:06.55 INFO: Last good revision: 88b25807638231dcf403d8f0b597fc770f1d24a4
15:06.55 INFO: First bad revision: e183cbb4983cfb3aecf97ab18fad916b91f89e7e
15:06.55 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=88b25807638231dcf403d8f0b597fc770f1d24a4&tochange=e183cbb4983cfb3aecf97ab18fad916b91f89e7e
Bug: Opening a new tab in the same container doesn't work
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-01-10 20:46:58+00:00
Resolved: 2020-01-19 18:03:08+00:00

In the last couple of days when I am in a non default container and I open a new tab using Cmd-Click on the new tab button (+) the tab gets the correct container indicator, but the page opens with the credentials in my default container. My typical use case is with GDocs, but I notice it with other sites, too.
Bug: Firefox: Unable to initially Access on-screen Controls with the Keyboard after Changing Search Bar Settings from within a New Profile
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-01-10 21:07:49+00:00
Resolved: 2020-03-17 07:05:43+00:00

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

Steps to reproduce:

To reproduce - this assumes that a fresh Firefox profile is being used and that NVDA 2019.2.1 is running:

1. Open Firefox, and navigate to Tools/Options - ensure that NVDA's Focus Mode is enabled at this point

2. Open the "Search" panel, and either tab or shift + tab out of the Options in this panel and to the other visible controls on the screen - including the address bar and other tab-able items. The idea here is to prove that NVDA is able to navigate to these at this stage

3. Navigate back to the available options from within the Search panel, and in the selection of radio buttons that controls how the search box is selected, change this selection to "Add search bar in toolbar"

4. Finally, as before, either tab or shift + tab out of the Search settings, and into the on-screen controls


Actual results:

After changing this setting to force the Search Bar to appear separately to the Address Bar, on-screen controls should still be tab-able - which isn't initially the case after changing the above setting. It's worth noting that if Firefox is then closed and the same profile re-opened, these controls can then be tabbed to as expected. It's also worth mentioning that this isn't a new bug as such, and has been present since at least Firefox 71.


Expected results:

N/A
Bug: Can not syncronize full of my personal sync-data (pw's) between two devices with FF sync
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-10 21:41:57+00:00
Resolved: 2020-01-23 11:36:42+00:00

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

Steps to reproduce:

I am a Firefox Sync user from beginning on.
I logged in some months ago into my android, I validated the login and I gave a different pw as masterpassword for the pw-manager for android. I tried severell times to sync betweend the devices


Actual results:

I can't see all of my pw's from windows device on the phone. It seems that it stopped working syncing the pw from some time on. The tabs and bookmarks are mirrored.


Expected results:

Get the complete pw's from Windows Firefox onto the Android device , too.
Bug: [Nudges] Top sites will conflict with the nudges/tips experiment on 74
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-01-11 00:38:37+00:00
Resolved: 2020-02-21 02:25:33+00:00

Top sites and quantumbar update1 are scheduled to ship on release in 74, if I'm not mistaken. 74 is also the final release where the nudges/tips experiment will run: https://experimenter.services.mozilla.com/experiments/search-tips-aka-nudges/

That's a problem because both top sites and nudges use restricting providers, and right now we only support one restricting provider at a time. The result is that when the experiment opens the quantumbar view to show a tip on 74, the top sites are also shown (at best) or only the top sites are shown, with no tip at all (at worst).

So we need to fix this for 74 somehow. We might fix it by fixing bug 1607797, and if so, this bug is just a dupe of that bug. I can also imagine a wallpaper/quick fix that isn't blocked on fixing that larger bug.
Bug: [Nudges] Urlbar input isn't cleared after clicking the redirect tip's "Okay, Got It" button
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-01-11 01:22:18+00:00
Resolved: 2020-01-15 02:11:22+00:00

This is a last-minute nudges/tips bug that Harry found today. It's a problem on 72 and later versions. I don't think it's a show stopper -- we could ship the extension with it -- but I also think we should fix it. We should able to do it entirely from the add-on without landing any production code in m-c, but it will require an experiment API addition.

When the redirect tip is shown (for example on google.com), the input correctly is empty, but when you then click the tip's "Okay, Got It" button, the input's value is set to the page's URL. So you have to clear the input before you can search. It should remain empty when you click the button.

Harry found this while porting the extension in bug 1606909. The value is set to the URL by the handleRevert call here: https://searchfox.org/mozilla-central/rev/d4d6f81e0ab479cde192453bae83d5e3edfb39d6/browser/components/urlbar/UrlbarInput.jsm#615

The stack is:

    _setValue (UrlbarInput.jsm#1076)
    value (UrlbarInput.jsm#941)
    URLBarSetURI (browser.js#3390)
    handleRevert (UrlbarInput.jsm#434)
    pickElement (UrlbarInput.jsm#615)
    _on_mouseup (UrlbarView.jsm#1424)
    handleEvent (UrlbarView.jsm#499)
Bug: Multi-select tabs: closing tab with X button should only affect the target tab.
Status: NEW
Priority: P2
Created: 2020-01-11 02:23:00+00:00
Resolved: 2023-12-20 08:05:37+00:00

As stated by Jared [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1578131#c2), clicking on the X button of a multi-selected tab should only close that one tab to maintain parity with Chrome. 

Note:
Triggering Ctrl-W should still remove the whole selection.
Bug: Crash in [@ nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures]
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-11 07:14:11+00:00
Resolved: 2020-01-15 14:29:22+00:00

This bug is for crash report bp-9984720f-ff23-442c-b227-41f590200111.

```
Top 10 frames of crashing thread:

0 xul.dll nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures toolkit/components/url-classifier/nsUrlClassifierDBService.cpp:2534
1 xul.dll XPTC__InvokebyIndex 
2  @0x20036039c7f 
3 xul.dll trunc 
4 xul.dll trunc 
5 xul.dll trunc 
6 xul.dll static XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1150
7 xul.dll XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:948
8 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:544
9 xul.dll Interpret js/src/vm/Interpreter.cpp:3038

```
Bug: File handler open with problems
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-11 13:45:25+00:00
Resolved: 2020-01-14 12:38:35+00:00

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

Steps to reproduce:

1. Click to download a file
2. Choose to open with appliction
3. Try to open file in that application


Actual results:

There is no list of my chosen apps to open specific file. I have to search for it everytime I choose "open with" option. In addition, the selected application indicates that the file does not exist when trying to open the file (a space in the file name breaks the line). This means that Firefox does not pass the variable with the file path in quotation marks.


Expected results:

A list of previously selected applications should appear. After launching the selected application, the file should open normally.
Bug: pocket has only one row on new pageand no option to change
Status: UNCONFIRMED
Priority: P3
Created: 2020-01-11 19:48:55+00:00
Resolved: 2024-01-18 22:40:59+00:00

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

Steps to reproduce:

update from firefox 71.0 to 72.0.1


Actual results:

pocket has only one row on new page and the option to change it disappered.
the value browser.newtabpage.activity-stream.topSitesRows=4 is still present in about:config


Expected results:

pocket has four rows on new page
Bug: Nightly does not restore all pinned tabs lately
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-12 01:21:09+00:00
Resolved: 2020-01-12 07:54:41+00:00

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

Steps to reproduce:

* Allow Nightly to update itself.
* Observe that not all pinned tabs are restore.


Actual results:

I keep three pinned tabs: Gmail, Twitter, Feedly. I noticed a few days ago -- maybe 1/8/2020 -- that after Nightly updated itself and restarted, only one pinned tab was open and pinned: Twitter. The other two appear to have been closed or not restored.

I opened and pinned new tabs for each, then noticed today that Gmail and Feedly pinned tabs had not been restored.


Expected results:

Restore all tabs, don't forget pinned tabs.

Sidenote: I still have the Conex extension loaded. It was an attempt to manage tab groups. Firefox has dropped that ball which is another matter for another time.
Bug: Master password prompt gives the appearance of a security check, but can be bypassed once it was already unlocked
Status: NEW
Priority: P5
Created: 2020-01-12 12:40:23+00:00
Resolved: 2024-05-30 17:06:19+00:00

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

Steps to reproduce:

1. Start Firefox (with a set up Master Password)
2. User enters the master password because he is forced by Firefox to enter it once initially at start
3. User uses his browser as usual
4. Attacker opens 'about:logins' and can reveal all saved passwords


Actual results:

The prompt for masterpassword makes the appearance that the passwords within 'about:logins' are somekind of protected. 
But you can without entering the masterpassword and by not clicking on the "View Password"-Buttons do the following things: 
- You can search for passwords with the search field.
- You can access the javascript object from Developer Console.
- You can change type=password to type=text with Inspector to reveal plain-text passwords.


Expected results:

The prompt for master password when clicking on "Show password" gives the appearance of a security check that is obviously easy to bypass. I would have expected a different level of protection or at least not one that gives the appearance of being one.
Bug: Impossible to provide a name for newly created bookmark folders
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-12 14:08:14+00:00
Resolved: 2020-01-13 10:40:29+00:00

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

Steps to reproduce:

1. Bookmark a site with ctrl+d
2. In the opened bookmark details box click on Folder/Choose
3. Click on the "New Folder" button



Actual results:

You get a "New Folder" and you cannot type in the name for it. The result is a "New Folder" that can be renamed only in the bookmark manager.


Expected results:

You should get a New Folder with the label waiting for user input for the name of the folder.
Bug: Layout for Icons of One-Click Search Engines Sometimes become messed up
Status: NEW
Priority: P3
Created: 2020-01-12 15:54:57+00:00
Resolved: 2022-10-11 23:50:05+00:00

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

Steps to reproduce:

I browsed internet like a normal person.  


Actual results:

It just become like this after some time of use. You can fix it by changing the engines in setting and everything goes back to normal, but after a while it become messed up again. I do not know what trigger it.


Expected results:

It should not be messed up.
Bug: Session restore during startup loses pages' URLs if proxy server responds with HTTP/403
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-12 16:09:50+00:00
Resolved: 2020-06-02 16:48:51+00:00

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

Steps to reproduce:

Firefox 72.0.1, Windows 7 x64, addons disabled, configured to restore previous session. Internet connection through HTTP proxy server (Squid)

Session restore during Firefox startup, but HTTP proxy server responds with HTTP/403 code (temporary Access Denied, e.g. due to some misconfiguration),
 




Actual results:

Firefox loses URL addresses of pages/tabs (address bar is blank, page contains usual "connection failed" information)
Reload button is inactive, i.e. cannot just reload after internet connection problem is resolved.

This only happens for pages that are not in cache, tested with
https://refreshyourcache.com/en/cache-test/

(If page is cached, then its restore does not depend on broken internet connectivity and works as expected)

If Firefox is restarted after proxy issue is resolved, saved URLs (which were blank) are often restored, but there are some edge cases when URLs are lost permanently (happened during Firefox upgrade, cannot reproduce this with just restarting). Also affects addons like Tab Session Manager (it saves such tabs as blank)




Expected results:

Address bar should contain restored URL from previous session, even if internet connectivity is temporarily broken.
(this worked before Firefox version 72)
Bug: No respect of menu option (in french : Paramètres / Paramètres de l'appareil)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-12 17:25:55+00:00
Resolved: 2020-01-13 21:32:52+00:00

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

Steps to reproduce:

Menus are in French:
Compte / Paramètres / Paramètres de l'appareil
Modifications in synchro options for sync are not for this computer, but for all computers...


Actual results:

I use Syc with 3 PC. On 2 PC Iwant synchronize bookmarks, password and preferences.
For 1 PC, I don't want synchronize Bookmarks, so I uncheck this option in the configuration menu for this computer.


Expected results:

This options (bookmarks unchecked) is propagated to all PC.
So all bookmarks can't be synchro beetween my 2 PC.
It's not an option for a computer, but for all PC. 
Options of sync must be different beetween all machines and synchro only for parameters what are checked locally.
Thanks
Bug: Captive portal login tab should setTRRMode(Ci.nsIRequest.TRR_DISABLED_MODE)
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-01-12 19:50:15+00:00
Resolved: 2020-02-07 09:05:39+00:00

In Bug 1552176 we added a mechanism to nsIRequest to have a different TRR mode for each individual HTTP request.
This should prove useful for people running TRR in mode3, but who connect to a WiFi network that requires login and is hosted on a domain such as `captive.domain.com` instead of a network ip `10.0.5.2`.

While for an IP we don't need to resolve a domain name, if the captive portal server is hosted on a certain domain (even if it's located in the local network but requires DNS), what would happen is that the captive portal detector sees a captive portal, we open a new tab to the captive portal endpoint, but since the new tab uses a regular channel with TRR mode 3 it will fail to resolve.

So we need that the tab that is specifically opened for the captive portal login to be in TRR mode 0. I initially designed the API so that we could `setTRRMode` on all necessary channels but it seems to me that it's easier just to set the `nsIDocShell.defaultLoadFlags |= 1 << 3` (maybe I should add a named constant for this in the IDL) and it should be applied to all requests within the docshell.

Nihanth, what do you think?
Bug: Top Sites - wrong position
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-12 20:58:55+00:00
Resolved: 2020-01-22 03:51:55+00:00

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

Steps to reproduce:

Just like that my Top Sites are not centered but located at the top of firefox screen. It happens cca week ago, no settings changed, it happened "just like that"...


Actual results:

Just like that my Top Sites are not centered but located at the top of firefox screen. It happens cca week ago, no settings changed, it happened "just like that"...


Expected results:

Aligned to the center of the window.
Bug: Intermittent browser/extensions/doh-rollout/test/browser/browser_doorhangerUserReject.js | Uncaught exception - undefined - timed out after 50 tries.
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-01-13 01:56:02+00:00
Resolved: 2020-02-18 17:00:26+00:00

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

---

[task 2020-01-12T23:47:44.143Z] 23:47:44     INFO - TEST-START | browser/extensions/doh-rollout/test/browser/browser_doorhangerUserReject.js
[task 2020-01-12T23:47:49.259Z] 23:47:49     INFO - TEST-INFO | started process screentopng
[task 2020-01-12T23:47:49.677Z] 23:47:49     INFO - TEST-INFO | screentopng: exit 0
[task 2020-01-12T23:47:49.678Z] 23:47:49     INFO - Buffered messages logged at 23:47:44
[task 2020-01-12T23:47:49.678Z] 23:47:49     INFO - Entering test bound testDoorhangerUserReject
[task 2020-01-12T23:47:49.678Z] 23:47:49     INFO - Buffered messages finished
[task 2020-01-12T23:47:49.678Z] 23:47:49     INFO - TEST-UNEXPECTED-FAIL | browser/extensions/doh-rollout/test/browser/browser_doorhangerUserReject.js | Uncaught exception - undefined - timed out after 50 tries.
[task 2020-01-12T23:47:49.678Z] 23:47:49     INFO - Leaving test bound testDoorhangerUserReject
[task 2020-01-12T23:47:49.679Z] 23:47:49     INFO - GECKO(7384) | MEMORY STAT | vsize 2899MB | residentFast 293MB | heapAllocated 101MB
[task 2020-01-12T23:47:49.679Z] 23:47:49     INFO - TEST-OK | browser/extensions/doh-rollout/test/browser/browser_doorhangerUserReject.js | took 5134ms
Bug: Google.com keep appear in suggestion
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-01-13 03:07:01+00:00
Resolved: 2020-07-07 05:27:16+00:00

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

Steps to reproduce:

Type g in the location url


Actual results:

Show google.com in first place


Expected results:

Show bookmark starting with g, but not google.com !

Since i've removed google.com from search engine, since i completely disabled browsing history, why google.com keep being appear in first place when i type the g letter ?

He not come from browsing history (private mode by default) or bookmark, so, where does he come from ?
Bug: openViewOnFocus breaks most common pattern for quickly navigating toolbars with the keyboard
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-01-13 09:01:47+00:00
Resolved: 2020-03-06 16:12:58+00:00

Bug 1603778 enabled browser.urlbar.openViewOnFocus by default in Nightly. Unfortunately, this breaks the most common (and [officially documented on Mozilla support](https://support.mozilla.org/en-US/kb/access-toolbar-functions-using-keyboard)) pattern for quickly navigating toolbars with the keyboard:

1. Users press alt+d or control+l.
2. They would then generally press tab or shift+tab to begin navigating to other toolbar controls.

With openViewOnFocus enabled, pressing tab or shift+tab (step 2) moves through address bar suggestions instead of moving to the next or previous toolbar control.

The tricky issue here is that this behaviour appears to be by design. I don't know what the product goal is, but we clearly want users to see the suggestion list when they focus the address bar. If that's what we want for mouse users, it follows that it's also what we want for keyboard users... but currently, that's in direct conflict with toolbar keyboard navigation.

There are three possible solutions:

1. Don't do openViewOnFocus for keyboard users. But that means keyboard users get a different UX.
2. Stop tab/shift+tab from navigating suggestions, either always or only if openViewOnFocus triggered. There's bug 1437524 for getting rid of this always, but there's a lot of controversy concerning that.
3. Add another keystroke to focus the toolbar for quick toolbar keyboard navigation which doesn't trigger openViewOnFocus. That means we have to come up with yet another keyboard command and means users have to re-train something they do reflexively (and potentially hundreds/thousands of times a day).
Bug: Text in permission management list in about:preferences is spread across 2 lines instead of 1
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-01-13 12:27:14+00:00
Resolved: 2020-02-12 16:09:06+00:00

STR:
1. Open about:preferences#privacy
2. Scroll to the Permissions section, see the permission name is in a new line after its icon
3. Same goes to the "Allow Nightly to send technical and interaction data to Mozilla" checkbox in the Data Collection section

Regressed by bug 1606130.