av9ash/GitBugs huggingface dataset:
Bug: In product documentation to do desktop => ios is lacking a step
Status: ASSIGNED
Priority: P2
Created: 2024-07-17 21:27:39+00:00
Resolved: 2024-08-02 18:50:38+00:00

I just plugged Firefox for sync from Desktop => ios.
Seems that the in product doc to do it isn't up to date. 

it state that the sync option is directly available in the menu when, actually, it is in parameters
Bug: virus
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-18 02:52:17+00:00
Resolved: 2024-07-18 19:10:04+00:00

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

Steps to reproduce:

Hello, Recently, i have download Firefox from https://www.mozilla.org to my computer include 2 types: Firefox & Firefox Developer Edition.


Actual results:

Avast Premium Security in my PC scan and alert have Trojan Horse, threat name: Win64:Evo-gen [Trj]. Result is Firefox not can run because Avast delete file.


Expected results:

Please guide me fix. Thanks.
Bug: Frequent OS X browser/base/content/test/keyboard/browser_toolbarKeyNav.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-07-18 03:40:11+00:00
Resolved: 2024-08-05 06:02:56+00:00

**Filed by:** sstanca [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=466837733&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/D0tAXI0DSB-9qSyz_9Bofg/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2024-07-18T02:34:08.259Z] 02:34:08     INFO - TEST-PASS | browser/base/content/test/keyboard/browser_toolbarKeyNav.js | save-to-pocket-button focused after Tab pressed - 
[task 2024-07-18T02:34:08.259Z] 02:34:08     INFO - Listening on item 
[task 2024-07-18T02:34:08.259Z] 02:34:08     INFO - Buffered messages finished
[task 2024-07-18T02:34:08.260Z] 02:34:08     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/keyboard/browser_toolbarKeyNav.js | Test timed out - 
[task 2024-07-18T02:34:08.260Z] 02:34:08     INFO - GECKO(782) | Completed ShutdownLeaks collections in process 782
[task 2024-07-18T02:34:08.261Z] 02:34:08     INFO - TEST-START | Shutdown
[task 2024-07-18T02:34:08.261Z] 02:34:08     INFO - Browser Chrome Test Summary
[task 2024-07-18T02:34:08.261Z] 02:34:08     INFO - Passed:  81
[task 2024-07-18T02:34:08.262Z] 02:34:08     INFO - Failed:  1
[task 2024-07-18T02:34:08.262Z] 02:34:08     INFO - Todo:    0
[task 2024-07-18T02:34:08.262Z] 02:34:08     INFO - Mode:    e10s
[task 2024-07-18T02:34:08.263Z] 02:34:08     INFO - *** End BrowserChrome Test Results ***
[task 2024-07-18T02:34:08.263Z] 02:34:08     INFO - GECKO(782) | Exiting due to channel error.
[task 2024-07-18T02:34:08.263Z] 02:34:08     INFO - GECKO(782) | Exiting due to channel error.
[task 2024-07-18T02:34:08.264Z] 02:34:08     INFO - GECKO(782) | Exiting due to channel error.
[task 2024-07-18T02:34:08.264Z] 02:34:08     INFO - GECKO(782) | Exiting due to channel error.
[task 2024-07-18T02:34:08.264Z] 02:34:08     INFO - TEST-INFO | Main app process: exit 0
```
Bug: Firefox autostarts in the background even when disabled in settings
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-18 05:57:15+00:00
Resolved: 2024-07-25 13:01:48+00:00

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

Steps to reproduce:

1. Install Firefox without the Mozilla Maintenance Service (if this is still a thing today).
2. In about:preferences#general make sure the checkbox to open Firefox automatically is disabled.
3. Check your taskmanager (or alternatively system settings) that no autostart entry for Firefox is present/enabled.
4. Check that no services for Firefox exist/autostart (e.g. via msconfig and filtering for non-Microsoft services and/or checking that services.msc has no Firefox/Mozilla services).


Actual results:

On a reboot (first 1-2 minutes) I noticed that at least 2 Firefox processes were running in the background for a short amount of time until they vanished.


Expected results:

No autostart of Firefox should have happened (imagine every installed application silently autostarts now in secret - that would be a very significant boot delay on HDD's (and possibly SSD's)).


Additional details:

I'm actually wondering if this is related to the recent autostart setting in about:preferences#general and if that autostart actually checks for the user preference to open the browser in the foreground then. But if this guess is true I'm wondering why Firefox does not utilize the operating systems (here Windows 10) mechanism for doing this. Maybe it would require an elevated prompt on toggling the setting in about:preferences#general then? But even then it should not be an issue. At least Firefox should not try that hard to hide its (non-deactivateable?) autostart. Unless this theory is false, then just ignore it.
Bug: User-created custom search shortcuts for extension-provided search engines do not survive the addon being disabled
Status: NEW
Priority: P3
Created: 2024-07-18 08:35:24+00:00
Resolved: 2024-07-22 15:34:36+00:00

I encountered some site compatibility issues, so I tried narrowing down the issue by disabling all my extensions one by one and checking the site. When I re-enabled my extensions, I found that my custom search shortcuts (the keyboard aliases) were gone for all my extension-provided engines.

Losing data associated with an addon when that addon is removed might be a reasonable thing to expect, but if it's at all possible to avoid, I think we should. Other things about these engines _are_ persistent. For example, if you rearrange the engines in the tree in about:preferences, it will change the order of engine search one-off buttons. This order seems to persist, which makes me optimistic that custom keyboard aliases can be made persistent as well.

And most addon data in general seems persistent. Toolbar customization state for example - the placement of addon browser actions in toolbars survives the addons being removed. Addon local storage (e.g. for settings and other things) survives too (not sure if it's indefinite, maybe it behaves like site local storage, I'm not sure). So I think it would be fair for users to assume that a search shortcut will survive addon removal, especially if they're not actually removing the addon but simply disabling it with the intention of re-enabling it. I know the addon is different from the search engine it provides, but it's not an obvious distinction for users.

Not sure whether search shortcuts for engines provided by other sources should be persistent in the same way, but I do feel like at least with addons they should be persistent if possible, since it's reasonable to expect that disabling an addon is more like temporarily turning it off rather than deleting it.
Bug: Tab hover preview still visible with context menu opened in certain conditions
Status: REOPENED
Priority: P3
Created: 2024-07-18 13:50:14+00:00
Resolved: 2024-07-30 19:06:46+00:00

**Found in**
* Latest Nightly 130.0a1

**Affected versions**
* Latest Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11 and Ubuntu 22.04
* Unaffected platforms: MacOS 13.6

**Preconditions**
* Set `browser.tabs.hoverPreview.enabled` as `true` if not already set.

**Steps to reproduce**
1. Open a few tabs
2. Restart the browser
3. Right click on the pocket button and hover over the tabs

**Expected result**
* The preview is not shown when context menu is opened

**Actual result**
* The tab hover preview is shown 

**Regression range**
* Not sure yet if this is a regression or not, will check ASAP.

**Additional notes**
* I noticed that this only happens only once after the browser starts/restarts, I was not able to reproduce it in the same session more than once.
Bug: Desktop telemetry for whether the account has a mobile device does not count tablets.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-07-18 14:31:25+00:00
Resolved: 2024-07-26 04:00:39+00:00

With my ipad connected to my account I see the following desktop log:

> 1721312740445   Sync.Engine.Clients     WARN    Unexpected deviceType "tablet" recording device telemetry.

This ends up meaning that when reporting desktop telemetry, this device is not being counted as a "mobile" device. Thus, any analysis of desktop telemetry to try and work out how many devices are connected will be wrong - it will not be counted at all, so both the "connected devices" count will be wrong and the "does this account have a mobile device connected" will also be wrong.
Bug: Icons for local search appear in the chiclet are not dynamic to theming
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-07-18 17:27:05+00:00
Resolved: 2025-01-23 12:21:06+00:00

Expected outcome:
1. User opens Firefox in dark mode.
2. User selects a local search like bookmarks or tabs
3. That local search Icon and Title appear in the chiclet to the left side of the address bar.
4. The local search icon is default icon color for dark mode.

Actual outcome:
1. User opens Firefox in dark mode.
2. User selects a local search like bookmarks or tabs
3. That local search Icon and Title appear in the chiclet to the left side of the address bar.
4. The local search icon is NOT default icon color for dark mode.
Bug: Fakespot suggestion title sometimes not shown
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-07-18 19:03:37+00:00
Resolved: 2024-08-06 12:14:41+00:00

STR

1. Type "experi"
2. Verify "The Great Simulator" Fakespot suggestion is shown
3. Continue typing "experimen" (no T at the end)
4. Verify the suggestion goes away for some reason
5. Finish typing "experiment"

The suggestion comes back but its title isn't shown.

This is a front-end urlbar problem, not a Rust Suggest problem. The Fakespot urlbar provider relies on UrlbarView setting the title element's text content [here](https://searchfox.org/mozilla-central/rev/b220e40ff2ee3d10ce68e07d8a8a577d5558e2a2/browser/components/urlbar/UrlbarView.sys.mjs#2120-2137). That works fine as long as the title has highlights, i.e., as long as the search string is present in the title. If it's not, then there are no highlights, so that code doesn't set the title at all, and since the provider's view update doesn't include the title either, it's never set.
Bug: Intermittent browser/components/asrouter/tests/browser/browser_asrouter_cfr.js | single tracking bug
Status: REOPENED
Priority: P3
Created: 2024-07-18 19:35:56+00:00
Resolved: 2025-02-24 06:43:15+00:00

**Filed by:** tszentpeteri [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=466927457&repo=mozilla-esr128
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HTVz7dJARdOo8_ZnZyzTIg/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2024-07-18T16:34:46.614Z] 16:34:46     INFO - TEST-PASS | browser/components/asrouter/tests/browser/browser_asrouter_cfr.js | Should return false if second call did not add the message - false == false - 
[task 2024-07-18T16:34:46.614Z] 16:34:46     INFO - Buffered messages finished
[task 2024-07-18T16:34:46.615Z] 16:34:46     INFO - TEST-UNEXPECTED-FAIL | browser/components/asrouter/tests/browser/browser_asrouter_cfr.js | Test timed out - 
[task 2024-07-18T16:34:46.615Z] 16:34:46     INFO - GECKO(4496) | Completed ShutdownLeaks collections in process 3460
[task 2024-07-18T16:34:46.616Z] 16:34:46     INFO - TEST-START | Shutdown
```
Bug: Magnet link not opening instead displays blank page with magnet in address bar Windows 10 V.128.0 (64-bit)  18-7-2024
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-18 21:17:44+00:00
Resolved: 2024-07-27 19:50:10+00:00

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

Steps to reproduce:

After updating to Firefox 128.0 (64-bit) on Windows 10. When i click on a magnet link the link just opens a blank page, with the magnet link in the address bar. 


Actual results:

If i select the address bar and hit enter, it now opens. Before this update it worked fine.
I have tried to use Clonezilla to revert back to an old version, and tested it several times. It is only the update to Firefox that is causing this issue. I have tried to reset Firefox, it still does not work. 

I have also tried to use regedit and enter the path to the torrent program. Not working either.

In Firefox settings, magnet is set to open the Transmission client by default. However the logo has disappeared, so I am questioning if maybe firefox can no longer find the app. But as there are no changes or updates to the Transmission client or path, that seems strange. 


Expected results:

The magnet link should open the default torrent program, in this case Transmission and either request the torrent to start or just start downloading.
Bug: Intermittent [TV] browser/components/urlbar/tests/quicksuggest/browser/browser_quicksuggest_fakespot.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-07-18 22:42:22+00:00
Resolved: 2024-08-15 12:45:45+00:00

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

---
```
[task 2024-07-18T21:20:01.531Z] 21:20:01     INFO - TEST-PASS | browser/components/urlbar/tests/quicksuggest/browser/browser_quicksuggest_fakespot.js | "" == "" - 
[task 2024-07-18T21:20:01.531Z] 21:20:01     INFO - Leaving test bound icons
[task 2024-07-18T21:20:01.532Z] 21:20:01     INFO - Closing the view directly
[task 2024-07-18T21:20:01.532Z] 21:20:01     INFO - Waiting for the view to close
[task 2024-07-18T21:20:01.532Z] 21:20:01     INFO - Urlbar view closed
[task 2024-07-18T21:20:01.533Z] 21:20:01     INFO - Buffered messages finished
[task 2024-07-18T21:20:01.533Z] 21:20:01     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/quicksuggest/browser/browser_quicksuggest_fakespot.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2024-07-18T21:20:01.534Z] 21:20:01     INFO - GECKO(1022) | MEMORY STAT | vsize 16286MB | residentFast 329MB | heapAllocated 151MB
[task 2024-07-18T21:20:01.534Z] 21:20:01     INFO - TEST-OK | browser/components/urlbar/tests/quicksuggest/browser/browser_quicksuggest_fakespot.js | took 51453ms
[task 2024-07-18T21:20:01.534Z] 21:20:01     INFO - checking window state
[task 2024-07-18T21:20:01.548Z] 21:20:01     INFO - GECKO(1022) | Completed ShutdownLeaks collections in process 1022
[task 2024-07-18T21:20:01.548Z] 21:20:01     INFO - TEST-START | Shutdown
```
Bug: Make "search-header" behaviour automatic
Status: NEW
Priority: P2
Created: 2024-07-18 23:01:53+00:00
Resolved: 2024-07-29 22:17:30+00:00

Right now when the "find in page" settings UI functionality finds items, it somehow relies on `h2` headers with a specific class. I _think_ this is because the `h1` headers look too big if shown in the search pane? Regardless, this is:

- resulting in duplicate markup that is annoying to keep up-to-date and to ensure the same text only appears once (which became an issue in the Firefox Labs / Nightly Experiments pane at some point)
- easy to forget - there are probably cases in settings right now where checkboxes appear without the context of their section, and/or where the section header cannot be found using find-in-page.
- a footgun for new code: when the above means that searching for the header does not show the entire section (which was what happened in bug 1907709), it can be misconstrued as an intentional thing, when in fact it's just a bug/quirk in how the find in page code works.

We should come up with a more structural solution to this problem.

Mark, do you think there's anything we can do about this before the settings redesign is in full swing and swaps us to cards, or something? How hard would it be for the find in page code to also check `h1` settings (though note also bug 1845411), or to switch over to using `h2` more consistently?
Bug: input of type datetime-local is not displaying time selector
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-19 09:45:09+00:00
Resolved: 2024-07-19 10:03:37+00:00

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

Steps to reproduce:

I used the official documentation (https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/datetime-local) to implement an input with the 'datetime-local 'type, which is supposed to be supported in the latest versions of Firefox (I tested on 115.13.0esr and 126).


Actual results:

When opening the overlay to select a date and time, the time is not displayed, so I can't select a time; I can only type it manually.


Expected results:

I should be able to select a time through the overlay when opening the date popup. This functionality works correctly in Chrome.
Bug: [win] Sometimes NVDA says "Alert" when hovering over tabs
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-07-19 11:52:46+00:00
Resolved: 2024-08-20 08:35:03+00:00

**Found in**
* 129.0.b5

**Affected versions**
* 130.0a1 (2024-07-18)
* 129.0b5

    


**Tested platforms**
* Affected platforms: Windows 11
* Unaffected platforms: macOS, Ubuntu

**Preconditions**
* tab hover enabled
* NVDA enabled

**Steps to reproduce**
1. Open multiple tabs with random web pages.
2. Hover over tabs.



**Expected result**
* The names of the tabs are read by NVDA.

**Actual result**
* Sometimes `Alert` and the name of the tabs are read by NVDA.



**Regression range**
* Reproducible with Firefox 124.0a1 (2024-02-02). Most likely not a regression.

**Additional notes**
* Attached a screen recording.
Bug: Pinned tab rendering issue
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-07-19 11:54:50+00:00
Resolved: 2024-07-23 14:40:40+00:00

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

Steps to reproduce:

Open multiple multiple tabs. The issue happens the moment the tabs overflow. This bug was introduced in the last ESR update.


Actual results:

Pinned tabs compressed and a rendering issue appears where the scroll button overlaps with pinned tabs.


Expected results:

Pinned tabs remain the same with. Number of opened tabs shoud not affect the presentation or behavior of pinned tabs.
Bug: Lower scrolling speed on sidebar than on webpage
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-07-19 13:15:29+00:00
Resolved: 2025-02-01 03:08:26+00:00

Attached the video. On sidebar one scroll action (scroll the wheel as much as you can at once) scrolls as much as 8-tab, but on webpage it scrolls much more than that (it scrolls as much as the whole screen).
Bug: Sidebar size resets after re-starting firefox
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-07-19 13:33:43+00:00
Resolved: 2024-10-24 10:48:40+00:00

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

Steps to reproduce:

open the sidebar, resize it, then close the sidebar.
Then restart firefox.


Actual results:

after restarting firefox, when opening sidebar again, its size is reset.

Note that if the sidebar is kept open before quitting firefox, its size does not reset.


Expected results:

the custom size should have stayed.

I think this bug has been happening since the last update.
Bug: The default or selected search engine icon looks to be a 16px icon, should be 24.
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2024-07-19 14:26:46+00:00
Resolved: 2024-09-03 20:28:31+00:00

Expected outcome:
1. Default or selected search engine icon is 24px

Actual outcome:
1. Default or selected search engine icon is 16px
Bug: Layout of dedicated button has extra space and incorrect icon behaviour
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-07-19 14:29:02+00:00
Resolved: 2024-12-19 11:41:10+00:00

Expected outcome:
1. In state when URL bar is focused, but dropdown is closed, the Dedicated search button is snug against left side of URL bar.

Actual outcome:
1. In state when URL bar is focused, but dropdown is closed, the Dedicated search button has a small gap between left side of URL bar.
Bug: Dedicated search button not aligned to hover state of list items in URL bar dropdown
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-07-19 14:31:44+00:00
Resolved: 2024-09-24 12:30:17+00:00

Expected outcome:
1. In state when URL bar is focused, and dropdown is open, the Dedicated search button aligns with the left edge of list items in a hover state

Actual outcome:
1. In state when URL bar is focused, and dropdown is open, the Dedicated search button is a few pixels to the right of the left edge of list items in a hover state
Bug: [Experiment] The Embedded Import Spotlight is wrongly displayed at browser first-startup
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-07-19 14:32:41+00:00
Resolved: 2024-10-17 11:42:58+00:00

[Affected versions]:
- Firefox Release 126.0, BUILD ID: 20240509170740.
- Firefox Release 127.0, BUILD ID: 20240606181944.
- Firefox Release 128.0, BUILD ID:20240704121409.

[Affected Platforms]:
- Windows 10 x64.
- Windows 11 x64.

[Prerequisites]:
- Have the [user.js](https://drive.google.com/file/d/1AXPDN9gj-Cfmqq0XCjdUvsFkBOspDO_z/view?usp=sharing) file downloaded on your computer.
- Create a new Firefox profile using the `--first-startup` flag but don’t open it.

[Steps to reproduce]:
1. Navigate to the profile folder and paste the user.js from prerequisites.
2. Launch the browser using the profile from the prerequisites.
3. Observe the behavior.

[Expected result]:
- The “Embedded Import” spotlight is not displayed at first-startup.

[Actual result]:
- The “Embedded Import” spotlight is displayed.

[Notes]:
- This issue is reproducible with both Existing and Early Day Users experiments.
Bug: Heuristic suggestion default search engine favicon is now redundant to the icon in the Unified search button
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-07-19 14:38:55+00:00
Resolved: 2025-02-03 09:30:56+00:00

Expected outcome:
1. Unified Search Engine is on
2. User clicks into the URL bar and types a query like "test"
3. Heuristic result has a search (magnifying glass) icon

Actual outcome:
1. Unified Search Engine is on
2. User clicks into the URL bar and types a query like "test"
3. Heuristic result has favicon for selected search engine