av9ash/GitBugs huggingface dataset:
Bug: Tooltip text stuck when toggling proton tooltips
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-07 16:43:31+00:00
Resolved: 2023-02-23 18:07:11+00:00

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

Steps to reproduce:

Go to about:config. Type in "proton" (without quotes). Ensure all proton options are set to false. Hover over any tab in the tab bar, and it should display in a tooltip the text of that tab. Toggle browser.proton.contextmenus.enabled to true, but leave all other options as they are. Hover over any tab in the tab bar, and there will be no tooltip, but remember which tab you hovered over. Set browser.proton.contextmenus.enabled back to false. Hover over any tab in the tab bar.


Actual results:

The tooltip shows the appropriate text for the currently-hovered tab, but the tooltip also has the text for the tab that was hovered over when browser.proton.contextmenus.enabled was set to true, in the middle of the process above. This extra text is appended to the tooltip text for every tab in the current window, but not in other windows or other tooltips.


Expected results:

The tooltip contains only the text for the tab that is currently being hovered over.
Bug: WebExtension sidebar menu in menubar menu is misaligned
Status: NEW
Priority: P3
Created: 2021-06-07 18:05:34+00:00
Resolved: 2021-07-19 14:46:24+00:00

If you install an extension that has a sidebar (like https://addons.mozilla.org/en-US/firefox/addon/sidebery/) and then close the sidebar, when you go to the sidebar menu via Alt->View->Sidebar, the menuitem is misaligned.

It's aligned correctly when it is opened.
Bug: Selecting text follows link
Status: NEW
Priority: P5
Created: 2021-06-07 22:41:04+00:00
Resolved: 2024-05-21 23:47:14+00:00

What should happen: Holding alt and selecting text within a link should only select that text.

What happens: When browser.altClickSave is set (formerly the default), this action downloads the link target.

This is a security issue because when I see the link e.g. "meet hot caucasians here" I might want to select "hot caucasians" and search for that. I do not, however, want to follow the link.
Bug: setting Fx to default e-mail client doesn't persist
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-07 23:20:54+00:00
Resolved: 2021-06-25 13:06:47+00:00

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

Steps to reproduce:

I click a mailto link (not in the browser) (like in an About dlg, or use use Win+R)
Fx asks which provider (Yahoo! or Gmail), I select Gmail, select the 'always use this...' option (see image1)
proceed to e-mail
close Fx



Actual results:

repeat executing mailto link, Fx opens again and asks me what provider to use, but settings has it set (see image2)


Expected results:

Fx should not have asked me again what provider to use.
Bug: search moves from page to address bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-07 23:34:59+00:00
Resolved: 2021-06-08 00:41:34+00:00

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

Steps to reproduce:

start a new tab - observe the search box in the middle of the page
start typing in the search box


Actual results:

focus immediately moves to the URL bar


Expected results:

focus should have remained where the user started (in the search box in the page)
moving focus like that is terrible (we shouldn't have poor Chrome behavior in Fx)
Bug: Screenshot of positioned element captures only its background
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-07 23:35:16+00:00
Resolved: 2021-06-08 01:44:39+00:00

STR:

1. Go to [identified](https://www.mozilla.org/en-US/firefox/new/) page.
2. Scroll down.  A "Meet our family of products" popup shows in the bottom right.
3. Take a screenshot of that element.  (Right click, Take screenshot, click on the element, select Copy or Download)

Expected:

An image is captured that shows the content of the popup.

Actual:

An image is captured, but it contains nothing but the content of the page behind it.  In this case, the background can be pure white, but with a narrower page this element might overlap other content, which gets captured instead.

Edited to add:  If you scroll to the top of the page, the element is captured correctly, so this appears to be linked to this being a fixed positioned element; the screenshot seems to position it at the absolute top of the page and not relative to the viewport when capturing the content.
Bug: Firefox 89.0 home page Google search does not work
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-08 01:45:07+00:00
Resolved: 2021-06-08 02:29:05+00:00

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

Steps to reproduce:

Create a new tab to invoke the Firefox home page
Enter a search term in the search bar in the middle of the screen where it says "Search with Google or enter address"
eg "Search with Google or enter address" 
Text appears in the URL bar at the top! This is WRONG and 
results in an error:  "Hmm. That address doesn’t look right."


Actual results:

Text appears in the URL bar at the top! 

Possibly should have appeared in the search box at the top instead?
(But would prefer to delete the search box at the top completely, but no option for this.)





Expected results:

Should have conducted a Google search.
Bug: handoffToAwesomebar ignores "search bar in toolbar," renders newtab page search box useless
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-08 03:50:02+00:00
Resolved: 2021-06-17 08:59:38+00:00

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

Steps to reproduce:

1. Enable "add search bar in the toolbar"
2. Leave handoffToAwesomebar = true (default)
3. Type a search term into the newtab search box


Actual results:

Search is shunted into url bar. Because url bar doesn't handle searches in this configuration, result is always a 404. Newtab search box is therefore useless.


Expected results:

Search should have been shunted to search bar instead.

(Aside: I am VERY STRONGLY of the opinion that the awesomebar should not even exist in the first place, and, if it must, then handoffToAwesomebar definitely should not default to true. Attempting to handle urls and search terms via the same widget just opens up whole classes of privacy leaks and phishing vectors that don't need to exist. It also promotes confusion between urls and search among unsophisticated users.)
Bug: The focus while using keyboard navigation is almost invisible when using Dark Theme
Status: NEW
Priority: --
Created: 2021-06-08 07:10:55+00:00
Resolved: 2021-06-08 13:09:36+00:00

**Affected versions**
* Firefox 91.0a1
* Firefox 90.0b4

**Affected platforms**
* macOS 10.15

**Steps to reproduce**
1. Make sure that the Dark Theme is selected. 
2. Go to https://permission.site/.
3. Click on "Location"button. 
4. Navigate the permission panel using only the keyboard. 

**Expected result**
* The button focus can be seen.

**Actual result**
* The focus is almost invisible. 

**Regression range**
* This is not a regression. I can reproduce this issue on Firefox from 2018-06-20 and before that the keyboard navigation inside the panel wasn't possible. 

**Additional notes**
* This issue reproduces with the "System Theme", too if it's set to Dark.
* On Nightly the focus is invisible, but if the user presses Enter key, the hyperlink is opened in another window.
* On beta the focus that is used is the system highlight color.
Bug: The navigation inside the permission panels is stuck on the hyperlink
Status: NEW
Priority: --
Created: 2021-06-08 07:29:13+00:00
Resolved: 2021-06-08 07:34:01+00:00

**Affected versions**
* Firefox 91.0a1
* Firefox 90.0b4

**Affected platforms**
* macOS 10.15

**Steps to reproduce**
1. Make sure that the Dark Theme is selected. 
2. Go to https://permission.site/.
3. Click on "Location"button. 
4. Navigate the permission panel using only the keyboard. 

**Expected result**
* The navigation is possible inside the panel using the keyboard.

**Actual result**
* The focus is stuck on the "Learn more" hyperlink. 

**Regression range**
* This is not a regression. I can reproduce this issue on Firefox from 2018-06-20 and before that the keyboard navigation inside the panel wasn't possible at all.

**Additional notes**
* Windows and Ubuntu don't seem affected by this issue. 
* No matter how many times Tab is clicked, the focus remains on the hyperlink.
Bug: Firefox not able to change to main monitor
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-08 09:50:59+00:00
Resolved: 2021-06-25 07:42:23+00:00

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

Steps to reproduce:

I have 2 monitors at my desktop connectet to dockingstation using my laptop.
If Firefox is on monitor 2 and i shut down then go on the road. When i start up my laptop, then Firefox is still on monitor 2, that is not connectet.



Actual results:

Firefox is "on" a monitor thats not connectet.
Using "move" dosen't work as the cursor never get the edge of firefox, so it can be moved. Don't think that the cursor in windows can go to a screen area, that is not provided as the 2. monitor is not connected / detected.


Expected results:

1: Firefox detect what monitor is available and show Firefox on that screen.
2: Cursor with "Move" gets the edge of Firefox so it can be moved back to main screen.
Bug: Extented characters in site title will increase the height of the tab bar
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-08 12:18:25+00:00
Resolved: 2021-06-12 11:55:39+00:00

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

Steps to reproduce:

Go to https://www.tiktok.com/@mine_ja 

You might need to resolve the captcha first.


Actual results:

The height of the tab bar increases


Expected results:

The height of the tab bar should not increase.

The screenshot attached shows the bug.
Bug: White bars on select fields in preferences UI
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-06-08 12:20:06+00:00
Resolved: 2021-06-14 13:11:46+00:00

In the latest Nightly on OSX, I'm seeing white lines at the top and bottom of select elements.

STR:
- Open Firefox on Mac
- Go to the about:preferences page
- Open a select field, e.g. for the default search engine

AR: white bars at the top and bottom of the select field
ER: no white bars

Note: This is best observed when using the dark theme, though the bars are visible in other themes as well.
Bug: Fix test failures introduced by the Fission session restore work
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-08 13:40:06+00:00
Resolved: 2021-06-14 23:07:33+00:00

- browser/components/sessionstore/test/browser_async_flushes.js (disabled fission)
- browser/components/sessionstore/test/browser_async_remove_tab.js (disabled window/linux fission opt, but also previously disabled debug-only, so probably just an extremely flaky test)
- browser/components/sessionstore/test/browser_formdata.js (disabled for linux fission asan and mac fission)
- browser/components/sessionstore/test/browser_sessionHistory.js (disabled linux opt and windows fission)
Bug: Enterprise Installer SCCM Detection Method
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-08 13:55:37+00:00
Resolved: 2021-09-07 19:53:19+00:00

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

Steps to reproduce:

With most msi deployments, Microsoft's SCCM is able to verify the installation with the product code from the registry (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall). In the case of the firefox msi, this verification failed.


Actual results:

Detection Method failed to verify installation even though the product was installed. This was corrected by using the firefox.exe file version as the detection method. This works, but when setting up a new deployment application, it is far more convenient for SCCM to automatically set the product code as the detection method.  


Expected results:

Detection Method should have succeeded.
Bug: Arrow symbol for bookmarks is not needed
Status: NEW
Priority: P5
Created: 2021-06-08 16:13:58+00:00
Resolved: 2021-06-22 15:26:16+00:00

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

Steps to reproduce:

I changed the size of the window by dragging the top bar towards the left, and then adjusting the width and height with the bottom corner being dragged. Then, I made the window to take up the entire screen again.


Actual results:

The extended bookmarks icon (>>) showed up. However, all my bookmarks were already on the bookmarks bar. Clicking the icon showed nothing but a small space (the button was clickable).


Expected results:

The 'extended bookmarks' icon should not have appeared. All the bookmarks were already on the toolbar.
Bug: Some characters disappear from website titles (html/head/title) in new floating tabs in Firefox 89
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-08 17:16:59+00:00
Resolved: 2022-01-05 13:45:42+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Bug: Location Bar history search results are inconsistent
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-06-08 17:22:59+00:00
Resolved: 2021-06-11 10:22:02+00:00

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

Steps to reproduce:

Sorry if the summary is kind of vague. I'm not really sure how to best describe the behavioral change. 

After Bug 1662167 landed, history search results in the location bar have changed. Using the same search tokens now provides different results than before Bug 1662167.

The main example I have is that "https://twitter.com/ /media" now provides drastically different search results. However, if I now try "twitter.com/ /media" I get search results that match the old behavior. With older builds, both "https://twitter.com/ /media" and "twitter.com/ /media" produced the same search results.

I see the same behavior with sites that use similar path based URL structures, like:
"https://www.deviantart.com/ /gallery/" vs. "www.deviantart.com/ /gallery/"
"https://github.com/" vs. "github.com/".

Result of mozregression
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a33179f40e4643927f680e6cb1a74d343cd8bd77&tochange=6af229948e1908f648c946925fe8a073d5774be4

It's not clear to me if this is a result of a code change, or fallout from the "resultBuckets" preference migration.
Bug: Proton version cannot save Dowloads directly in NTFS partition on Ubuntu 20.04
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-08 17:26:24+00:00
Resolved: 2021-06-08 17:33:18+00:00

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

Steps to reproduce:

Tried download a file after update to 89.0 to my Download folder, which is in a NTFS partition on Ubuntu 20.04. Erased my profile folder and doesnt work too.


Actual results:

Create 0kb file and Dowload failed. Works if I change to an EXT4 partition.


Expected results:

Simple download file to the expected folder as before.
Bug: Firefox Windows Installer Local Privilege Escalation
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2021-06-08 18:00:13+00:00
Resolved: 2024-05-30 17:32:10+00:00

See the attached PDF advisory. 

For associated files, see: https://drive.google.com/drive/folders/18J--nE8_RULx9iEPbL3DqBzAW29BkFan?usp=sharing.
Bug: I can't see the borders between one tab and the next
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-08 22:12:38+00:00
Resolved: 2021-06-10 15:15:09+00:00

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

Steps to reproduce:

Open three tabs


Actual results:

I couldn't see the borders between one tab and the next


Expected results:

There should be borders between one tab and the next
Bug: Mute tab option is hidden behind a hover effect even on touch density
Status: NEW
Priority: --
Created: 2021-06-08 23:19:25+00:00
Resolved: 2021-08-23 05:53:00+00:00

Steps to reproduce:

1. Start Firefox on a machine with a touch enabled display
2. ensure Firefox is using the Touch density
3. go to youtube.com and click any non-drm encumbered video

What happens:

Firefox shows "PLAYING" text below the tab title. User must tap on the tab to make the the mute icon appear, resulting in a more awkward two-tap interaction.

Expected result:

The speaker icon is omnipresent on playing tabs to give touch users an affordance that there is a function to mute without having to tap on the tab and then tap again once the speaker icon appear. This is also not known before the tap, so users may never discover the feature on touch density. 

The design here seems optimized for mouse users who may discover functions hidden behind a hover effect, but hovers are problematic on touch displays. Indeed, MDN recommends that "web developers should make sure that content is accessible on devices with limited or non-existent hovering capabilities" - https://developer.mozilla.org/en-US/docs/Web/CSS/:hover
Bug: Session history forgets the title of pages with forms that POST to the same URL
Status: NEW
Priority: --
Created: 2021-06-09 00:39:18+00:00
Resolved: 2024-07-01 23:54:26+00:00

I have some extensions that use `browser.sessions.getRecentlyClosed()`. I've noticed that lately many (but not all) of the tabs returned have the URL in the title property instead of the title. If I open the library the pages in question have a real title.

Mostly it happens to bugzilla.mozilla.org pages, perhaps BMO does something weird to the history. I'm fairly sure I've seen it happen on other sites too, although I can't see that at the moment.
Bug: Local PDFs viewed with pdf.js are marked as notSecure by the identity handler
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-09 01:11:56+00:00
Resolved: 2021-06-21 09:17:43+00:00

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

Steps to reproduce:

- Open a local PDF file in firefox


Actual results:

- Identity box/popup show as not secure
- Comments [here](https://searchfox.org/mozilla-central/source/browser/base/content/browser-siteIdentity.js#165) seem to suggest this is intentional, but the protocol obviously isn't HTTP in this case?


Expected results:

- Shouldn't local PDFs be marked localResource like any other local file? Or at the very least it should just check for mixed content I guess
Bug: Accidentally Closing Pinned Tabs
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-09 01:31:23+00:00
Resolved: 2023-01-26 16:46:44+00:00

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

Steps to reproduce:

The new format allows a pinned tab to be closed without right clicking the tab.  When the tab is open, an 'X' is displayed.  Clicking the 'X' will close the pinned tab.  I have motor control issues and with the new version, I keep accidentally closing pinned tabs.  It is very frustrating.  Please remove this new feature.


Actual results:

See Above


Expected results:

See Above
Bug: Bookmarks > Other Bookmarks, Right Click & select "Sort By Name" ... it doesn't, never works
Status: NEW
Priority: P3
Created: 2021-06-09 02:34:45+00:00
Resolved: 2023-06-19 15:52:12+00:00

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

Steps to reproduce:

Bookmarks > Other Bookmarks, Right Click & select "Sort By Name"


Actual results:

Nothing happens, the items in "Other Bookmarks" are not getting sorted alphabetically


Expected results:

the items in "Other Bookmarks" should be sorted alphabetically when you select "Sort By Name"
Bug: opening about:preferences#home sets focus to the search field preventing hotkeys to work
Status: RESOLVED
Priority: P3
Resolution: INCOMPLETE
Created: 2021-06-09 05:51:12+00:00
Resolved: 2023-06-02 15:21:38+00:00

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

Steps to reproduce:

open about:preferences#home and try to use any of the underscored hotkeys

if you enter the page using via adressbar the focus is now on the search field,
or on the navigation bar if you use the mouse




Actual results:

using any of the underlined hotkeys does only work with shift+alt+hotkey (as already mentioned in 1200954)
or if you use the tab key to move the focus to any of the setting items. Then the plain hotkey (no alt, shift or ctrl requiered) does work.


Expected results:

hotkeys should work consistently regardless of the focus

requiring shift+alt is unexpected behaviour and I was not able to find any documentation for that (besides bugzilla).

plain hotkey (without alt) is also unexpected and does not work when the focus is on a input field.
Bug: Focus moves to the address bar and FF uses the query string as a URL
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-09 06:11:16+00:00
Resolved: 2021-06-09 13:49:15+00:00

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

Steps to reproduce:

The user starts  to type a query string  the FF start page


Actual results:

Focus has moved to the address bar and, since the user have disabled the annoying "smart mode", the query is interpreted as a URL and FF, expectingly, reports that the entered URL is not recognized


Expected results:

Focus should remain in the edit box, and the query string should be sent to the search engine instead of interpreting it.
Bug: screenshot quit without file
Status: NEW
Priority: P3
Created: 2021-06-09 07:04:47+00:00
Resolved: 2022-08-22 17:46:07+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4535.2 Safari/537.36

Steps to reproduce:

Run firefox from Windows 10 command line:
Firefox.exe --screenshot 1.png https://api.vistopia.com.cn/api/v1/web/article-content/yx5FU


Actual results:

Firefox process starts and quits. No output, nor file created.


Expected results:

A file named 1.png should be created.
Bug: Hello, in Garmin aplication, when i have to write down number of round toé perform excercise, there is 2 buttons (up and down) and adress bar where normally is a number. In other browsers, it works correctly but not iz FF. May you help me somehow?
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-09 07:05:04+00:00
Resolved: 2021-07-13 11:14:34+00:00

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

Steps to reproduce:

Got FF to the factory settings and trying it with troubleshooting mode


Actual results:

nothing


Expected results:

it should display a numbers in a adress bar (see attached photo)
Bug: new UI makes Firefox completly unsusable.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-09 07:33:35+00:00
Resolved: 2021-06-09 20:17:40+00:00

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

Steps to reproduce:

auto-update to version 89


Actual results:

new UI makes Firefox completly unsusable


Expected results:

Nothing. JUST FUCKING LEAVE THE UI AS IT WAS 5 YEARS AGO. 
Fire the idiot who makes decisions at mozilla