av9ash/GitBugs huggingface dataset:
Bug: Setting Firefox to not suggest 'Browsing History' seems to affect 'Adaptive History'
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-15 23:49:21+00:00
Resolved: 2021-08-17 00:08:05+00:00

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

Steps to reproduce:

I'm mostly trying to describe the issue I had filed bug 1718989 for, but hopefully a bit better this time.

1) On a clean Firefox profile, 'teach' Firefox that you want the `blog.nightly.mozilla.org` bookmark when you type the letter `z` in the address bar. You do this by simply typing `z` in the address bar (without quotes), and picking the `blog.nightly.mozilla.org` bookmark. On a clean profile, doing this once should be enough to make this the top suggestion when you type `z` in the address bar again.

2) Now, head to about:preferences#privacy, scroll down to the Address bar section, and under `about:preferences#privacy`, uncheck `Browsing History.`

3) Type `z` into the address bar again.


Actual results:

`blog.nightly.mozilla.org` is no longer the first suggestion. See attached gif.


Expected results:

It should have continued being the first suggestion because:

1) All the suggestions for `z` are bookmarks. Their order should be independent of whether or not I have `browsing history` set to show.

2) The description on https://firefox-source-docs.mozilla.org/browser/urlbar/nontechnical-overview.html#adaptive-history says "[the adaptive history] mechanism is mostly independent of frecency. URLs in the adaptive history database have their own sorting score based on how many times they have been used in the past."

3) This 'expected result' is how I recall Firefox has worked since long, and the behaviour changed only recently. I will try to find the regression range. (I did run moz-regression once, but it pointed at bug 1718815 which seems to be irrelevant.)
Bug: All the saved logins are no longer sorted when selecting the “Username(A-Z)” and the “Username(Z-A)” options from the “Sort by:” drop-down
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-08-16 05:49:51+00:00
Resolved: 2021-08-20 18:29:16+00:00

[Affected versions]:
- Firefox Nightly 93.0a1 (Build ID: 20210815094823)

[Affected Platforms]:
- Mac 11.5.1
- Windows 10 x64
- Ubuntu 20.04 x64

[Prerequisites]:
- Have the latest Firefox Nightly browser installed.
- Have a Firefox profile with multiple logins saved.


[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to the “about:logins” page.
3. Click on the “Sort by:” dropdown menu.
4. Select the “Username(A-Z)” or the “Username(Z-A)” option.
5. Observe the Login LIst.

[Expected result]:
- All the saved logins are correctly sorted.

[Actual result]:
- Nothing happens.

[Regression]
- The issue is not reproducible with older Nightly 93.0a1 builds. Considering this using mozregression tools I have found the regression range. Here are the results:
 Last good revision: d97a050c677e87913002d60f92d811a175e022d4
 First bad revision: 6bb6be51f4fa1ad7f5741e98cc0749c76f4126b3
 Pushlog: [link](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d97a050c677e87913002d60f92d811a175e022d4&tochange=6bb6be51f4fa1ad7f5741e98cc0749c76f4126b3)

From this pushlog I think the patch for Bug 1592682 introduced this behavior.

[Notes]:
- Attached is a screen recording of the issue.
Bug: pdfs open in browser regardless of settings
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-16 06:38:30+00:00
Resolved: 2021-10-15 13:24:34+00:00

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

Steps to reproduce:

As usual, I clicked on a link to a pdf document.  That normally gives me the option to open with a pdf viewer or save the file (and the option to cancel the request).


Actual results:

The pdf document opened in that tab (not a new tab, in spite of target=blank) in the browser.  Issue also reported by two Windows users on the support site.
https://support.mozilla.org/en-US/questions/1346985
https://support.mozilla.org/en-US/questions/1346989


Expected results:

The setting "Always ask" on the General page of settings should have resulted in a dialog giving me the option to open the document in a pdf viewer of my choice or save the file and I could have cancelled the request.
Bug: Add Bookmark dialog is missing button around disclosure chevron
Status: NEW
Priority: P3
Created: 2021-08-16 06:47:23+00:00
Resolved: 2024-02-05 16:35:35+00:00

Steps to reproduce:

1. Open Library (Ctrl-shift-o)
2. Context click on "Bookmarks Toolbar" and select "Add Bookmark..."

What happens:

The disclosure chevron is missing  the button decoration around it. 

Expected result:

The disclosure chevron should have a button decoration around it, like prior to bug 1703716.

Note: When finding the regression range for this bug, I marked several builds where the button was present, but the chevron was missing. In the current nightly, the chevron is present (and working), but the button is missing. 

13:02.17 INFO: Last good revision: 0b713a5fada84a4b8f3e79e10e3b213064c0690e
13:02.17 INFO: First bad revision: 44916257e3052502b8d9465b73be4d5a8c4919e7
13:02.17 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0b713a5fada84a4b8f3e79e10e3b213064c0690e&tochange=44916257e3052502b8d9465b73be4d5a8c4919e7
Bug: bitwarden autofill not working on nightly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-16 11:22:28+00:00
Resolved: 2021-08-17 11:26:55+00:00

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

Steps to reproduce:

Hello,
when you use bitwarden password manager on firefox nightly, auto-fill does not work. CTRL+SHIFT+L does not autofill passwords. It is not problem of extensions - same extensions which I have on my Dev edition, do not cause the problem.


Actual results:

I am unable to use bitwarden's autofill


Expected results:

Bitwarden autofill working
Bug: The "Empty" bookmark folder label is no longer greyed out in the Bookmarks Toolbar and in the Other Bookmarks
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-08-16 11:53:13+00:00
Resolved: 2021-11-29 11:37:57+00:00

##### [Environment:]
Mac 10.15
Ubuntu 20.04
Windows 10 x64

Firefox 92 beta 4
Nightly 93.0a1

##### [Steps:]
1. Open Firefox.
2. Open the Library window and create a new folder for each of the locations: Bookmarks Toolbar, Bookmarks menu, Other Bookmarks - leave it empty
3. Open Application Menu -> More Tools ->Customize toolbar...-> place the Bookmarks menu near the URL Bar.
4. Go to each of the newly created folders, click on them and observe the "Empty" bookmark folder label.

##### [Actual Result:]
The "Empty" bookmark folder label is only greyed out in the Bookmarks Menu. 

##### [Expected Result:]
The "Empty" bookmark folder label should be greyed out in the Bookmarks Menu, Bookmarks Toolbar, and Other Bookmarks.

##### [Notes:]
This issue is not reproducible on Firefox 91.

Found commit message:
Bug 1703051, apply proton panel styling to other bookmarks dropdown and overflow menu in bookmarks toolbar r=desktop-theme-reviewers,mconley,jaws,harry
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1e8ff38398ac6a98d0a0b5668a598206ed084688&tochange=9e5ec8c60805229571fb0b1a2b59f1fc53100cf2
Bug: cookie exceptions do not sync
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-16 12:22:47+00:00
Resolved: 2021-08-22 13:44:37+00:00

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

Steps to reproduce:

* Sync enabled between two laptops and a tablet.
* Sync of Settings is on.
* Enable "Delete cookies and site data when Firefox is closed".
* Add sites to "Manage Exceptions..."




Actual results:

The enable "Delete cookies and site data when Firefox is closed" appears on the 2nd laptop, however the list of Manage Exceptions is not synced with the 2nd laptop 


Expected results:

List of cookie domain exceptions should match on 2nd laptop.
Bug: The “Create New Login” mode is not dismissed after clicking the “Save” button if any of the “Username” sort is active
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-08-16 13:27:58+00:00
Resolved: 2021-08-20 18:29:28+00:00

[Affected versions]:
- Firefox Nightly 93.0a1 (Build ID: 20210815094823)

[Affected Platforms]:
- Mac 11.5.1
- Windows 10 x64
- Ubuntu 20.04 x64

[Prerequisites]:
- Have the latest Firefox Nightly browser installed.
- Have a Firefox profile with multiple logins saved.


[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to the “about:logins” page.
3. Click on the “Sort by:” dropdown menu.
4. Select the “Username(A-Z)” or the “Username(Z-A)” option.
5. Create a new login and click on the “Save” button.
6. Observe what happens.

[Expected result]:
- The created login is successfully created and displayed on the Login List.

[Actual result]:
- Nothing happens. 

[Regression]
- The issue is not reproducible with older Nightly 93.0a1 builds. Considering this using mozregression tools I have found the regression range. Here are the results:
 Last good revision: d97a050c677e87913002d60f92d811a175e022d4
 First bad revision: 6bb6be51f4fa1ad7f5741e98cc0749c76f4126b3
 Pushlog: [link](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d97a050c677e87913002d60f92d811a175e022d4&tochange=6bb6be51f4fa1ad7f5741e98cc0749c76f4126b3)

From this pushlog I think the patch for Bug 1592682 introduced this behavior.

[Notes]:
- The login is correctly saved, but the “Create New Login” modal is not dismissed, only after refreshing the page.
- After clicking the second time on the “Save” button the newly created login is recognized as a duplicate.
- Attached is a screen recording of the issue.
Bug: The bookmark submenu is too big for single folders or empty label
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-16 14:06:12+00:00
Resolved: 2021-11-29 11:38:02+00:00

##### [Environment:]
Mac 10.15
Ubuntu 20.04
Windows 10 x64

Firefox 92 beta 4
Nightly 93.0a1

##### [Steps:]
1. Open Firefox.
2. Create a new folder on the Bookmarks Toolbar.
3. Click on the created folder and observe its size.

##### [Actual Result:]
The bookmark submenu is too big.

##### [Expected Result:]
The size of the bookmark submenu shouldn't be that big.

##### [Notes:]
This issue is not reproducible on Firefox 91.

Found commit message:
Bug 1703051, apply proton panel styling to other bookmarks dropdown and overflow menu in bookmarks toolbar r=desktop-theme-reviewers,mconley,jaws,harry
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1e8ff38398ac6a98d0a0b5668a598206ed084688&tochange=9e5ec8c60805229571fb0b1a2b59f1fc53100cf2
Bug: Context menu text is too dark with dark theme on Linux
Status: UNCONFIRMED
Priority: --
Created: 2021-08-16 16:03:57+00:00
Resolved: 2021-11-04 23:55:39+00:00

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

Steps to reproduce:

Running Firefox on Debian on ChromeOS

1. Set theme to dark
2. Right-click on web page. 


Actual results:

The context menu shows as dark grey text on black. Image attached


Expected results:

Expect white text on black

The context menu displays ok when setting the theme to white or system.
Bug: Firefox colors are very wrong
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-08-16 17:51:01+00:00
Resolved: 2021-08-26 14:17:29+00:00

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

Steps to reproduce:

 - Tried both Firefox 91 and 92-beta
 - Running MacBook Air (M1, 2020), MacOS 11.5.2
 - Issue came after updating to MacOS 11.5.2
 - No other browsers have this issue
 - Tried changing both the System color theme, as well as the Firefox color themes


Actual results:

Blacks are white, all text colors are blue, UI in the settings menu and different websites is sometimes unreadable. Almost everything in Firefox has the wrong colors.


Expected results:

Firefix should show the correct colors.
Bug: When displaying a certificate's validity period and DST will change during this period, Firefox displays the wrong timezone description.
Status: UNCONFIRMED
Priority: --
Created: 2021-08-16 19:28:36+00:00
Resolved: 2021-12-29 01:48:53+00:00

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

Steps to reproduce:

Visit an https website with a certificate with notBefore during DST and notAfter when DST is no longer in effect, e.g. (currently) https://opsi.scc.kit.edu/
Select Tools / Page Info / Security / View Certificate

I'm using firefox-esr 78.13.0esr-1~deb10u1 on Debian 10.10


Actual results:

Certificate is show with e.g. this validity period (currently, from the afforementioned site):

Validity
Not Before 8/16/2021, 12:04:35 AM (Central European Summer Time)
Not After 11/13/2021, 11:04:33 PM (Central European Summer Time)


Expected results:

The actual dates on this certificate, as shown by OpenSSL, are:
notBefore=Aug 15 22:04:35 2021 GMT
notAfter=Nov 13 22:04:33 2021 GMT

so the conversion to localtime strings is actually correct (I know the locale issues with about:certificate) and the notAfter time shown takes into account that DST will have ended then; however, the textual timezone still suggests DST being in effect then. I would have expected something like

Not After 11/13/2021, 11:04:33 PM (Central European Time)
Bug: View Certificate link not operable by keyboard
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-08-16 19:52:15+00:00
Resolved: 2023-06-02 15:22:04+00:00

#### Steps:

  1. Launch the browser and go to https://wrong.host.badssl.com
  2. Click Advanced and using the keyboard navigate through the new opened section. 
  3. Tab to "View Certificate"
  4. Press space or enter

#### Actual result:

Page scrolls slightly

#### Expected result:

New tab should open with certificate info.
Bug: browser_certificateTabLink.js has unexpected uses of comma operator
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-08-16 21:08:26+00:00
Resolved: 2021-10-04 21:56:51+00:00

I'm looking to update ESLint, and it is picking up an instance of a unexpected comma operator:

toolkit/components/certviewer/tests/browser/browser_certificateTabLink.js
  40:66  error  Unexpected use of comma operator.  no-sequences (eslint)
  51:62  error  Unexpected use of comma operator.  no-sequences (eslint)

This was introduced by bug 1573143. The code in question is:

https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/toolkit/components/certviewer/tests/browser/browser_certificateTabLink.js#39-42,50-53

Both instances look like:

```
        await ContentTaskUtils.waitForCondition(() => {
          return (
            certificateTabs[i + 1].classList.contains("selected"),
            "Clicking link should select new tab."
          );
        });
```

I'm not sure if these are meant to be tested within the content task, or if the value should be returned or not.

Johann, could you take a look please?
Bug: Cannot see FF Container tab underline
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-16 23:13:33+00:00
Resolved: 2021-08-17 15:27:36+00:00

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

Steps to reproduce:

FF just updated to v91 and wiped out all the reversals 
I'd done to restore my (beloved) look after v89 came out.

FF version 91 is now worse than ever.

I use Firefox Multi-Account Containers.

In pre-FF-version-89-tabs, when opening a tab in its container, 
the tab would be a dark color, and there would be a colored 
underline at the bottom of the tab.  The underline's color would 
be according to what I'd set for that container.  All tabs opened 
from that container would also have the same colored underline.

If, say, I open 5 GMail containers, all using the same GMail 
account, they would all have the same colored underline.

If I opened another of my GMail accounts in another, different, 
colored container, it would have this different colored underline 
and all tabs created from this container would be likewise 
same-colored.

Scanning over my tabs I would know, by sight, what is what.

That's all gone now.

I cannot see the colored underline in the tab's bottom.

However, In the URL field the container's name and its color 
IS seen, but this is ONLY visible WHEN that tab is ACTIVE.

This is a problem because I need to see the colored underlines; 
they orient me and keep me organized as I routinely keep dozens 
of tabs and windows open.

So . . . 

1) How to restore FF containers putting a visible, colored, underline in the tabs?

2) How to control the colors of FF tabs?

Thanks!


Actual results:

In pre-FF-version-89-tabs, when opening a tab in its container, 
the tab would be a dark color, and there would be a colored 
underline at the bottom of the tab.  The underline's color would 
be according to what I'd set for that container.  All tabs opened 
from that container would also have the same colored underline.

If, say, I open 5 GMail containers, all using the same GMail 
account, they would all have the same colored underline.

If I opened another of my GMail accounts in another, different, 
colored container, it would have this different colored underline 
and all tabs created from this container would be likewise 
same-colored.

Scanning over my tabs I would know, by sight, what is what.

That's all gone now.



Expected results:

I should be able to see the FF Container's underlined color in the bottom of the tab.
Bug: Firefox sometimes, but not always, fails to display hover title text
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-08-17 04:16:40+00:00
Resolved: 2021-09-03 13:07:05+00:00

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

Steps to reproduce:

Firefox 91.0 (and many previous versions)
Xubuntu 20.04

I have local images as well as remote site images that do not display the title text when hovering, while others do.  Two comic sites as examples:

#1:  https://xkcd.com/2502/

No hover text displays and yet page source shows:

<img src="//imgs.xkcd.com/comics/every_data_table.png" title="I&#39;m hoping 2022 is relatively normal because I don&#39;t know what symbol comes after the asterisk and the dagger." alt="Every Data Table" srcset="//imgs.xkcd.com/comics/every_data_table_2x.png 2x" style="image-orientation:none" />

The title text displays in Chromium, Opera and Brave.

#2:  https://www.smbc-comics.com/comic/disgust

Hover text does display in Firefox and page source is:

<img title="Now lions... lions can just DO each other." src="https://www.smbc-comics.com/comics/1629126094-20210816.png" id="cc-comic" />

Same thing on my local system.  I have some pictures in HTML documents where the title text will not display:

<img border="2" src="images/wa_scenes.jpg"  width="125" height="188"  title="WA Sights" \>

although it does in display Chromium, Opera and Brave, and others where it does work in Firefox:

<img border="0" src="thumb/thumb_02.jpg"  width="125" height="83"
 title="Rock on Pacific NW Trail at Bowman Bay"
 alt="Rock on Pacific NW Trail at Bowman Bay:
Deception Pass State Park, WA" />

I can find no rhyme or reason for when it works and when it doesn't.


Actual results:

Sometimes title text displays, other times it doesn't on hovering.


Expected results:

It should always display.
Bug: "Send tab to device" is very slow after waking up PC from sleep/hibernation
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-08-17 07:15:49+00:00
Resolved: 2021-08-19 06:18:43+00:00

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

Steps to reproduce:

Using 2 devices signed it into same account.
1) put one device to sleep
2)  use second device to send tab to the first device
3) wake up the first device and measure how long it takes to receive the send tab


Actual results:

It can take 23 minutes (!!!) to receive the tab, even if it was send yesterday.
It can be less, but probably also more.


Expected results:

After waking up PC, it should sync right away, with 0 minutes delay.

This bug a bit random but if you use this feature often, you notice it a lot.
I guess the problem may be missing internet access few seconds after PC wakes up from sleep. However the common approach in such cases is simply retry with longer and longer delay (Google chat used to do that if you went offline).
Bug: Firefox 91 Proton spacing activated on bookmarks
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-17 10:04:04+00:00
Resolved: 2021-11-29 11:38:18+00:00

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

Steps to reproduce:

1) Switch browser.proton.enabled to false
2) Clic on "Visualize Bookmarks" icon on tool bar



Actual results:

Firefox 91 : Even if I switch browser.proton.enabled to false, the pop-up menu of bookmarks use too big spacing of Proton. 
Ok on Firefox 90.


Expected results:

Have the same spacing than before
Bug: Word "Playing..." on the tab messes up window sizes
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-08-17 11:59:11+00:00
Resolved: 2021-09-28 13:48:53+00:00

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

Steps to reproduce:

Open a page where an audio is playing.
* try on youtube.com:
Start the video, than pause it for a few seconds. Then unpause it.
* even better, try on lichess.org and try to play a game of chess, expanding enlarging a board a bit


Actual results:

Word "Playing" appears under the tab title. 
When you hit pause the word disappears and the whole video jumps up a bit. 
When unpaused, it jumps again
This is very annoying, but tolerable on youtube. On lichess.com it's impossible to tolerate because the chess boards is shrinking and expanding 
It is mos 


Expected results:

The height of the tab should not change when audio is playing (word playing should fit in the existing height of the tab's title).
Alternatevely, there should be an option to disable that behaviour. In fact in previous version it was possible to disable switching of "proton".  In version 91.0 this does not work.
Bug: Various Mac issues
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-08-17 12:53:47+00:00
Resolved: 2021-08-18 08:54:02+00:00

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

Steps to reproduce:

15" 2018 Macbook Pro 10.15.7 Catalina
Firefox 91.0 (64-bit) 
-------------
I have a whole host of display issues, mainly cookie popups.
Usually the cookie popup simply refuses to go.

Also https://tinyurl.com/app shows a blank screen.

I attach a list of urls which failed.  I had to use Safari.
-----------
Viewing source (command U) works first time.
However if the same link loads different data, <command U> source doesn't change.
The only way to display is to zap cached data.
-----------
It usually fails to display page source of RSS xml. I have to use Safari.
-----------
I have used Firefox since the year dot, mainly as my mind is programmed to it, and all the shortcut keys.
Oh yes - one shortcut now is hard.
<rightclick a> used to copy links.
Now it is <rightclick c enter>
A real pain when I am copying hundreds sometimes in a days work.
I use it all the time for my work, where I view page source particularly a very great deal.
However I will have to abandon it if these serious bugs are not sorted.
These issues happened in previous versions.

I have a 12" travel laptop with a very old Firefox, and it works perfectly.
Too small though for day to day use!


Actual results:

See above


Expected results:

See above