av9ash/GitBugs huggingface dataset:
Bug: firefox in windows does not work correctly with the Ctrl+Enter in the url field
Status: NEW
Priority: P3
Created: 2022-09-23 18:50:31+00:00
Resolved: 2022-10-20 02:04:20+00:00

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

Steps to reproduce:

1 clear all history
2 in the url field enter         https://thefirstlook.com/
3 hit enter
4 make a bookmark
5 clear all history
6 click on a new tab 
7 in the url field enter         thefirst
8 hit Ctrl+Enter   on your keyboard 
9 (it fills in thefirstlook    but when you have not finished typing that and you just want to goto the shorter url (https://www.thefirst.com)



Actual results:

It brought me to 	https://thefirstlook.com/ 


Expected results:

It should have brought me to 	https://www.thefirst.com

But if you do it again after you click on the end of the url field and type it again it works correctly till you clear the history then it won’t work.
Bug: Regression: New Application/Dock Icon looks/feels too small
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-23 18:52:00+00:00
Resolved: 2022-10-06 17:25:22+00:00

Nightly 107.0a1 (2022-09-23) (64-Bit)
macOS

The design of the new Application/Dock Icon looks too small. Especially with the dark background of the icon and in Dark Mode with a dark wallpaper. The old icon was more present and much better for recognition. I think the new icon is a regression in accessibility. Please bring back the large icon.

Thanks!
Bug: An Update Intervention that initiates an update check always prompts the user to reinstall
Status: NEW
Priority: P3
Created: 2022-09-23 22:38:40+00:00
Resolved: 2022-09-23 22:42:19+00:00

I was looking over [the Update Intervention](https://searchfox.org/mozilla-central/rev/a26af613a476fafe6c3eba05a81bef63dff3c9f1/browser/components/urlbar/UrlbarProviderInterventions.sys.mjs#542-641) code, and I believe that I have spotted a problem.

I'm not particularly familiar with how some of these functions are called, but from what I can pick up from the context, it appears that the intended flow looks like this. Let's assume that we have not yet checked for an update this session.

 1. [`_setCurrentTipFromAppUpdaterStatus`](https://searchfox.org/mozilla-central/rev/a26af613a476fafe6c3eba05a81bef63dff3c9f1/browser/components/urlbar/UrlbarProviderInterventions.sys.mjs#542) starts an update check via `AppUpdater`.
 2. `currentTip` is set to `TIPS.UPDATE_CHECKING`.
 3. [`startQuery`](https://searchfox.org/mozilla-central/rev/a26af613a476fafe6c3eba05a81bef63dff3c9f1/browser/components/urlbar/UrlbarProviderInterventions.sys.mjs#599) waits for `AppUpdater` to notify its listeners of any status change, then re-invokes `_setCurrentTipFromAppUpdaterStatus` to set a new `currentTip`.
 4. `currentTip` is then used to pick what Update Intervention UI is shown.

The problem that I see is that, in a typical update check, the state after `AppUpdater.STATUS.CHECKING` (and thus the state that we would get in step 3, above) is `AppUpdater.STATUS.DOWNLOADING`. There is no tip corresponding directly to this state, so we get the `default` update tip which is to prompt the user to reinstall.

I didn't check super thoroughly, so it may be that there is a race condition that allows a very fast download to slip through before the tip gets set, allowing the "Restart to Install Update" tip to be shown.

I decided to check this out by downloading a version of Firefox old enough to need a complete MAR (just in case a partial MAR is small enough to trigger the aforementioned race condition) and try out this interface a couple of times. Using version 100, I tested Update Interventions 10 times. On all 10, I got the tip that prompts the user to reinstall.

---

There is another potential issue here that seems worth mentioning. The way that this interface currently functions is dependent on internal `AppUpdater` implementation details. For example, it's not unreasonable to imagine that we might change `AppUpdater` to add `await lazy.UpdateUtils.getAppUpdateAutoEnabled();` early in `AppUpdater.check()`. This would likely cause `_setCurrentTipFromAppUpdaterStatus` to unexpectedly get a different state instead of `AppUpdater.STATUS.CHECKING`.
Bug: Update Intervention should open the update UI if an update is in-progress
Status: NEW
Priority: P3
Created: 2022-09-23 22:42:19+00:00
Resolved: 2024-10-10 08:22:44+00:00

I have found a number of bugs in the Update Intervention UI (linked via "See Also"). It is my belief that the underlying problem here is that we are trying to use a static interface to quickly convey information that may be changing.

Given that we have 2 other fully functional update UIs, I'm not sure that it is necessary to have an additional fully functional update UI in a place that doesn't seem well suited to it. Thus, I propose these changes:

 1. If an update is still in-progress (i.e. checking for updates or downloading an update), offer a button that says something like "Update Firefox", which will open one of the full fledged update UIs, probably the About dialog.
 2. I'd like to fix Bug 1688080 by having that button download the update and _not_ automatically restart afterwards. If we feel it's appropriate, we can disable the normal update-ready badge/doorhanger delay in this case so that the user is immediately notified that their update is ready.
 3. As is the case in the other update interfaces, this one should only show the reinstall prompt if the built in updater has failed.

I'd be happy to do this work when I have time for it. I might have some time for it very soon, depending on how some other things work out.
Bug: Fix prefers-contrast media queries in aboutwelcome.scss
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-09-23 23:08:18+00:00
Resolved: 2022-10-10 21:49:13+00:00

Firefox [generally uses](https://searchfox.org/mozilla-central/search?q=%40media+(prefers-contrast)) `@media (prefers-contrast)` for HCM related styles, but we have [some rules](https://searchfox.org/mozilla-central/search?q=%40media+(prefers-contrast%3A+more)) in aboutwelcome.scss that read `@media (prefers-contrast: more)`. I'm not sure how often this matters, but at least in theory, the HCM styles from common/common-shared.css will be applying to the surfaces that load aboutwelcome.css when `prefers-contrast: less` or `prefers-contrast: custom`.

Also, in bug 1790396 Emily added `@media (prefers-contrast)` rules to _feature-callout.scss, since the rules on Firefox View use that query. So to make sure all these rules are applying under exactly the same conditions, we should use the same query in all cases (unless we end up adding rules for very specific contrast themes, but there don't seem to be any instances of that in the Firefox code, not counting test cases)
Bug: In Library, "Show in Folder" leaves the focused bookmark outside the visible area
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-09-24 04:04:07+00:00
Resolved: 2023-06-27 14:32:15+00:00

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

Steps to reproduce:

1. Use the search field of the Library window to search for a bookmark which is inside a folder with enough bookmarks that scrolling is needed to see them all.
2. Right-click on it and select "Show in Folder".


Actual results:

At step 2, the Library focuses on the containing folder and the bookmark is selected, but you have to scroll down to see it.


Expected results:

This is a regression from Bug 1786518.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2f9e4f4b41314d9d9d12ee4588087f766f29259b&tochange=31865a7b9f1bcb9211eb2d47fd88f7b168aedca8
Bug: Sidebar doesn't correctly reflow when resized
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-24 04:18:28+00:00
Resolved: 2022-10-21 08:33:56+00:00

### Steps to Reproduce
1. Open any sidebar, for example Bookmarks panel with Ctrl+B.
2. Resize the sidebar to the left or right.
3. Observe the content of the sidebar.

### Actual result
The sidebar content is stuck to the initial layout regardless of the space available.

### Expected result
The sidebar content should adapt to the size of the sidebar like before.

### Regression range
mozregression points to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dd74d4159c5dfa4307f663df24cf64766a4d5781&tochange=61cde6b6f2737eee00c49fb75390aff3d814f677, which is bug 1789168.

#### Notes
- As you can see from the video, the sidebar no longer has a minimum or maximum width. This could be a plus for some people if they want an even smaller or bigger sidebar.
- This impacts vertical tabs extensions like TreeStyleTabs, Sidebery etc
Bug: Can't expand the list in the History sidebar on 107.0a1 (20220923212151)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-24 06:06:44+00:00
Resolved: 2022-09-24 06:08:20+00:00

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

Steps to reproduce:

Expand the History sidebar to the right.


Actual results:

The list of items doesn't expand to the right and the scrollbar doesn't move to the right


Expected results:

The text of the items should have been revealed more and the scrollbar should have moved with the expanding sidebar to the right
Bug: Ctrl+Enter doesn't canonize url if ctrl is not released after a Ctrl+V paste
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-09-24 06:55:30+00:00
Resolved: 2022-10-10 16:32:17+00:00

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

Steps to reproduce:

Follow these steps to reproduce the issue:
- Copy the word: example
- Hold down the Ctrl key, and don't release it.
- Press Ctrl+L
- Then press Ctrl+V
- Then press Ctrl+Enter



Actual results:

It searches the word "example" in Google.
This is the URL it opens:
https://www.google.com/search?client=firefox-b-d&q=example


Expected results:

It should have opened the URL: https://www.example.com

Normally, when you press Ctrl+Enter in the address bar, it adds "https://www." and ".com".
But, if you're already holding the Ctrl Key from another action (eg Ctrl+V), then the Ctrl+Enter isn't working.
Bug: firefox ignores the Search Suggestions settings
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-09-24 09:44:17+00:00
Resolved: 2022-09-25 06:37:36+00:00

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

Steps to reproduce:

My settings show unchecked the "Provide search suggestions" and all subfields. I do have checked address barL 

When using the address bar, suggest
Browsing history
Bookmarks
Open tabs



Actual results:

As I type in the address bar, it still shows a "Firefox suggests" rows from various search engines, they are definitely not from open tabs, bookmarks or browsing history.


Expected results:

No suggestions from google, wikipedia.. whatever.
Bug: Sidebar content does not shrink/stretch, no longer remembers its width on restart
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-24 13:01:40+00:00
Resolved: 2022-09-29 11:05:17+00:00

Recent changes have caused the sidebar to behave incorrectly.

* When changing the width of the sidebar with the mouse, the content does not stretch or shrink to follow the increase or decrease in width
* Sidebar no longer remembers its width and always opens with the default width when the browser is restarted

This bug looks like a regression of bug1792028.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Bug: New squircle macOS icon is out of place on pre-big sur macOS
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-09-24 16:16:39+00:00
Resolved: 2022-09-28 01:49:00+00:00

Noticed that the new macOS icon is out of place on pre-big sur macOS. You can see this from the attached dock screenshot - there aren't squircle icons, even from apple apps. 

I am running macOS 1.15.18 in the screenshot.
Bug: Firefox-view remembering history when using "always use private browsing mode"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-09-24 17:54:34+00:00
Resolved: 2022-09-28 01:46:15+00:00

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

Steps to reproduce:

Click the FireFox-View button lop left hand corner of the screen.


Actual results:

There is a page displayed that shows Recently Closed Tabs list.


Expected results:

If the settings  "always use private browsing mode" is enabled, there should be no trace of tabs opened or closed stored, shouldn't this be considered as browser history? otherwise the history is leaking this way.
Bug: Firefox 105.0.1 downloads the wrong file
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-09-24 21:29:53+00:00
Resolved: 2022-10-14 14:35:15+00:00

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

Steps to reproduce:

After clearing Firefox's cache (prefs\privacy\cookies & site data\clear data) , I got this file with Firefox 105.0.1 and also got it with MSEDGE.

https://jpsoft.com/downloads/beta/tcmd29.exe


Actual results:

Firefox got the wrong (3-day old) version of the file.

MSEDGE got the correct version.


Expected results:

Firefox should have gotten the newer (and correct) version of the file.
Bug: Choose What To Sync window cutoff
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-24 23:39:42+00:00
Resolved: 2022-10-21 10:03:13+00:00

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

Steps to reproduce:

1. Go to about:preferences#sync
2. Click "Change..."
Popup window buttons are cutoff
Bug: Potential Autofill Bug when isTrusted should be False
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-25 15:14:02+00:00
Resolved: 2024-05-30 18:00:53+00:00

Scenario: Visiting a (legit) website with a login form. By entering (correct) credentials a user is able to store them in the FF password manager. The next time a user visits the login page, FF (when configured accordingly to autofill data) will automatically fill the fields necessary for the login. According to the property isTrusted https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted it shouldn't be possible to retrieve these values programmatically via JavaScript UNTIL a user interacts with the website in any way. (https://stackoverflow.com/questions/37468400/javascript-cant-read-chromes-auto-fill-password-field-until-the-page-is-intera or https://stackoverflow.com/questions/69113304/perform-istrustedtrue-event-in-browser). 
However it seems to be possible to access the data anyways.
Proof of Concept is attached.
This was tested on 105.0.1 (64-Bit) and Windows 10 Pro 21H2 19044.2006
E.g. Google Chrome 105.0.5195.127 disallows the access of the data until a user e.g. clicks into the site, according to its specification. 

I have been pentesting a website which seems to have a persistent XSS vulnerability. So as it is possible to inject code, one can copy/rebuild the login form of the website, drop the original and insert the malicious one. The script then that waits until FF filled in the fields and sends it to the server. (Usually a well-configured CORS will prevent the sending part, however in this case the website allowed to access Amazon S3 buckets (for loading some of their content). So one can send the data to an attacker owned bucket without conflicting with the config.)

I'm unsure if this is also a bug by the Firefox Browser that accessing the data is allowed without even interacting with the website or the responsibility lies mainly by the website owner to disallow any further interaction.

Kind regards
Tobias
Bug: Link opened in New Window - New Window does not survive restart
Status: UNCONFIRMED
Priority: --
Created: 2022-09-25 21:15:35+00:00
Resolved: 2022-11-02 21:04:12+00:00

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

Steps to reproduce:

RE: bug 1777712 comment 65

If I open a link in a new window and use 'Quit' in that window, the new window survives a restart.
However, If I open a link in a new window and use 'Quit' in a different window, the new window does not survive a restart.


Actual results:

If I open a link in a new window and use 'Quit' in that window, the new window survives a restart.
However, If I open a link in a new window and use 'Quit' in a different window, the new window does not survive a restart.


Expected results:

If I open a link in a new window and use 'Quit' in that window, the new window survives a restart.
However, If I open a link in a new window and use 'Quit' in a different window, the new window does not survive a restart.
Bug: nafplioholidays.com isn't redirecting to mobile site on Firefox OS
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-09-26 01:03:25+00:00
Resolved: 2022-09-26 01:05:08+00:00

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

Steps to reproduce:

Site: http://www.nafplioholidays.com/
nafplioholidays.com isn't redirecting to mobile site on Firefox OS

:: Steps To Reproduce

1.Open Firefox browser
2.Enter makemytrip.com


:: Expected Result

http://www.nafplioholidays.com/

:: Actual Result

http://www.nafplioholidays.com/
Bug: Hidden-but-selected tabs (e.g. the Firefox View tab) should count as visible for ctrlTab panel
Status: ASSIGNED
Priority: P1
Created: 2022-09-26 03:25:03+00:00
Resolved: 2022-12-28 12:06:34+00:00

### STR
1. Set `browser.ctrlTab.sortByRecentlyUsed` to true
2. Have a single regular tab open
3. Open Firefox View using the toolbar button
4. There are now two tabs open, technically
5. Hit ctrl+tab

### Expected
ctrlTab panel should open with two tabs visible, the selected Firefox View tab and the regular tab. Releasing should switch to the regular tab, and pressing ctrl+tab again should do nothing, since Firefox View should not be navigable through ctrl+tab unless it's selected. This would be consistent with the behavior when you have, for example, 5 tabs + Firefox View open.

### Actual
Firefox View is not navigable through ctrl+tab at all. The panel never opens because it thinks there's only one "visible tab" (the regular tab). Although the Fx View tab can be added to the list, first it checks the number of visible tabs. If there are more than 2 visible tabs, it opens the panel. If there are 2 visible tabs, it immediately switches to the other visible tab without opening the panel. If there is only 1 visible tab, it does nothing.

The cause is a [subtle issue](https://searchfox.org/mozilla-central/rev/5dd1f5147d3ffffb0dbd1c8cc9262887bec58014/browser/base/content/browser-ctrlTab.js#484-490) with the ctrl+tab keydown logic. In bug 1791298, we prevented the Firefox View tab from being added to the ctrlTab panel except when it's selected. Normally "hidden-but-selected" tabs were never an issue since selecting a tab ordinarily unhides it, but Firefox View implements some special behavior to prevent its tab from being shown. So we added a check where hidden tabs are added to the ctrlTab list only if they are selected.

But in addition to determining whether a tab is added to the ctrlTab list, a tab's hidden state also determines whether it is a member of `gBrowser.visibleTabs`. And that is the array we use to determine whether the ctrlTab panel should be opened or cycling through tabs is possible (because it was previously a valid proxy for the number of CYCLE_TABS-eligible tabs). So, instead of using `gBrowser.visibleTabs` we should make our own array of "eligible" tabs, for example:
```
gBrowser.tabs.filter(tab => !(tab.closing || (tab.hidden && !tab.selected)))
```
Similarly, I think we also want to change `!tab.hidden` [here](https://searchfox.org/mozilla-central/rev/5dd1f5147d3ffffb0dbd1c8cc9262887bec58014/browser/base/content/browser-ctrlTab.js#667) to `!(tab.hidden && !tab.selected)`. This should rarely matter but it's worth just making all of this consistent with the general rule "hidden tabs are not shown unless they are selected."
Bug: System auto theme doesn't change for Private Browsing
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-09-26 05:07:00+00:00
Resolved: 2022-10-12 14:41:50+00:00

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

Steps to reproduce:

Switch system theme.


Actual results:

The theme doesn't follow the system theme and stays on Dark.

(Please see the attached video). As you can see the Toolbar and context menu don't switch to the light theme and stay on dark.


Expected results:

Switch with the system, as it does in Normal (non-Private) mode.
Bug: [Experiment] The VPN Promo is not displayed on the next eligible new tab after dismissing the Focus/Klar Promo
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-09-26 11:47:00+00:00
Resolved: 2022-10-03 16:02:08+00:00

**[Affected versions]:**
- Firefox Release 105.0.1 - Build ID: 20220922151854

**[Affected Platforms]:**
- Windows 10
- macOS 12.5.1
- Ubuntu 22.04

**[Prerequisites]:**
- Have a clean new Firefox profile.
- Be enrolled in the [PBnewtab VPN Cross Promo](https://experimenter.services.mozilla.com/nimbus/pbnewtab-vpn-cross-promo/details) experiment.

**[Steps to reproduce]:**
1. Open the Browser with the profile from prerequisites.
2. Open a New Private Window.
3. Dismiss the Focus Promo.
4. Open a New Private Window and observe the page.

**[Expected result]:**
- The VPN promo is displayed.
 
**[Actual result]:**
- No message is displayed.

**[Notes]:**
- The VPN Promo is displayed on the 2nd new tab opened after dismissing the Focus Promo.
- The issue is reproducible on both variants.
- Attached a screen recording of the issue.
Bug: Dragging a PDF page while the Hand Tool and Draw tool are active will draw lines on the page
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-09-26 12:19:12+00:00
Resolved: 2024-10-08 08:32:53+00:00



**Found in**
* 106.0b4 (20220925185751)

**Affected versions**
* 106.0b4 (20220925185751)
* 107.0a1 (20220925213821)




**Tested platforms**
* Affected platforms: Windows 10x64, macOS 11, Ubuntu 21.04, Windows 7x64
* Unnafected platforms: none
 
**Steps to reproduce**
1. Open a random PDF (http://www.pdf995.com/samples/pdf.pdf) and select the Draw tool from the PDF toolbar.
2. Open Tools menu and select Hand Tool.
3. Drag the page up and down.

**Expected result**
*  No lines are drawn when dragging the page.

**Actual result**
* Dragging the page will also draw lines on the PDF page.

**Regression range**
*  Will search for one ASAP if there is one.

**Additional notes**
* Attached a screen recording.
Bug: Bookmarks in folder rearranged into wrong order after restart
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-09-26 12:20:13+00:00
Resolved: 2022-10-27 14:08:46+00:00

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

Steps to reproduce:

1. Create a bookmark of a site in a folder on the Bookmarks Toolbar
2. The newly-added bookmark appears at the bottom of the folder
3. Restart Firefox


Actual results:

After a restart, the most recently-added bookmarks have been relocated from the bottom of the folder, to somewhere near the top of the folder. They remain in this position. If you try to move them to the correct place, Firefox moves them back again later.

Note that this bug has persisted for a couple of years.

Also note:
1. My method for creating bookmarks is to drag the padlock icon (on the Address Bar) into the relevant folder or sub-folder.
2. I use a separate Search Bar and Address Bar
3. I have tens of thousands of bookmarks, organized in a large number of folders and sub-folders.