av9ash/GitBugs huggingface dataset:
Bug: Intermittent browser/components/urlbar/tests/browser/browser_urlbar_telemetry_zeroPrefix.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-04-24 15:14:12+00:00
Resolved: 2023-07-28 12:01:59+00:00

**Filed by:** smolnar [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=413573721&repo=mozilla-beta
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NnzP6aQ2RC-o3-fhzY_5rg/runs/0/artifacts/public/logs/live_backing.log

---
```
INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_urlbar_telemetry_zeroPrefix.js | Dwell histogram should be updated - [1] deepEqual [1] - 
[task 2023-04-24T14:22:29.812Z] 14:22:29     INFO - Leaving test bound searches
[task 2023-04-24T14:22:29.813Z] 14:22:29     INFO - Entering test bound notZeroPrefix_engagement
[task 2023-04-24T14:22:29.813Z] 14:22:29     INFO - Awaiting for the urlbar panel to open
[task 2023-04-24T14:22:29.814Z] 14:22:29     INFO - Urlbar panel opened
[task 2023-04-24T14:22:29.814Z] 14:22:29     INFO - Buffered messages finished
[task 2023-04-24T14:22:29.815Z] 14:22:29     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_urlbar_telemetry_zeroPrefix.js | Test timed out - 
[task 2023-04-24T14:22:29.862Z] 14:22:29     INFO - GECKO(4341) | MEMORY STAT | vsize 20977053MB | residentFast 2777MB
[task 2023-04-24T14:22:29.863Z] 14:22:29     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_urlbar_telemetry_zeroPrefix.js | took 90457ms
[task 2023-04-24T14:22:29.865Z] 14:22:29     INFO - Not taking screenshot here: see the one that was previously logged
[task 2023-04-24T14:22:29.866Z] 14:22:29     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_urlbar_telemetry_zeroPrefix.js | Found a tab after previous test timed out: about:blank - 
[task 2023-04-24T14:22:29.956Z] 14:22:29     INFO - checking window state
[task 2023-04-24T14:22:30.015Z] 14:22:30     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_userTypedValue.js
[task 2023-04-24T14:22:31.489Z] 14:22:31     INFO - GECKO(4341) | -----------------------------------------------------
[task 2023-04-24T14:22:31.490Z] 14:22:31     INFO - GECKO(4341) | Suppressions used:
[task 2023-04-24T14:22:31.491Z] 14:22:31     INFO - GECKO(4341) |   count      bytes template
[task 2023-04-24T14:22:31.491Z] 14:22:31     INFO - GECKO(4341) |       2        288 libfontconfig.so
[task 2023-04-24T14:22:31.491Z] 14:22:31     INFO - GECKO(4341) | -----------------------------------------------------
[task 2023-04-24T14:22:31.605Z] 14:22:31     INFO - GECKO(4341) | MEMORY STAT | vsize 20977046MB | residentFast 2807MB
[task 2023-04-24T14:22:31.607Z] 14:22:31     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_userTypedValue.js | took 1590ms
```
Bug: When dragging a tab to create a new windows, firefox freezes
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-04-24 18:36:52+00:00
Resolved: 2023-05-08 12:00:10+00:00

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

Steps to reproduce:

Firefox open with 2 tabs. Drag 1 tab out of firefox.


Actual results:

Firefox freezes (continues to playback any sound)
Requires task manager shutdown and reboot of firefox.


Expected results:

New window should be created.
Bug: The query entered in search field of the browser landing page appears in URL, instead of the search field
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-04-24 22:02:50+00:00
Resolved: 2023-05-08 13:25:17+00:00

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

Steps to reproduce:

1. Launch the Firefox browser
2. Start typing the search string with curser in the search field

 


Actual results:

The cursor appears in the URL field of the browser and the search string appears in the address bar. 
The autocomplete predictions cover the original search field.



Expected results:

The search string entered in the search field should appear in the very search field instead of the address bar.
Bug: Firefox Sync forgets devices after some time without contact
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-04-25 07:07:40+00:00
Resolved: 2023-04-25 21:09:46+00:00

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

Steps to reproduce:

1. Connect a device to Firefox Sync
2. See it show up on other devices
3. Don't use the device for a couple of weeks


Actual results:

The device disappears from the "Synced tabs" list, and the "Send Tab to Device" menus, but is still listed under "Connected services" on https://accounts.firefox.com/settings


Expected results:

Devices should stay visible as long as they're connected.
Bug: Firefox keeps deleting downloaded PDF files in a private window after closing it
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-04-25 10:44:54+00:00
Resolved: 2023-05-25 15:09:45+00:00

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

Steps to reproduce:

Video: https://www.youtube.com/watch?v=erg5ef6KGeE

Example steps to reproduce:
1. Launch Firefox and open a private window
2. Go to https://filesamples.com/formats/pdf, agree to the cookies and click on the Download button next to sample3.pdf file


Actual results:

If you didn't change the setting that decides what Firefox does with PDF files, the downloaded file should automatically open in a new [private] tab; also you should be able to find it (with the Read-only attribute set) in Windows' Downloads folder. Now when you exit the opened private window you should find that the downloaded PDF file got removed from the Downloads folder.


Expected results:

The downloaded PDF files shouldn't be deleted when you close the private browsing session (also don't add “Read-only” attribute to files [Since they are being saved to the Downloads folder, not the %Temp% folder]?).
Bug: Firefox (pocket) ignore settings when you are offline
Status: UNCONFIRMED
Priority: --
Created: 2023-04-25 13:48:26+00:00
Resolved: 2023-10-24 08:38:43+00:00

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

Steps to reproduce:

Launch Firefox(German) offline.
Create a new tab , right side "Personalize new tab", disable preselected settings.

Go to the menu settings, home,  and disable all "Firefox Home Content". Close your firefox. Go online and start firefox.


Actual results:

Firefox starts with
In German.
"Empfohlen von Pocket

Besondere Inhalte ausgewählt von Pocket, Teil der Firefox-Familie
Gesponserte Inhalte"


Expected results:

Firefox should not ignore my settings when I am offline and selfactivate "pocket".
Bug: Clear the browser from browserContentSourceMap after its source has been used
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-04-25 14:19:33+00:00
Resolved: 2023-04-26 17:14:20+00:00

We should be clearing the `browser` from `browserContentSourceMap` once we've assigned the source to an impression, or else the browser will be cached and if the user uses the same browser object to do another search and triggers an `unknown` source type, we could end up re-using the wrong source.
Bug: [Linux] The Import Wizard design doesn’t adapt to the new size of the window after resizing it
Status: NEW
Priority: P3
Created: 2023-04-25 14:58:49+00:00
Resolved: 2023-05-01 15:22:00+00:00

**[Affected versions]:**
- Firefox Beta 113.0b7 (Build ID: 20230423180101)
- Firefox Nightly 114.0a1 (Build ID: 20230425093238)

**[Affected Platforms]:**
- Linux Ubuntu 20.04 x64
- Linux Ubuntu 22.04 x64
- Linux MINT Cinnamon 21.1

**[Prerequisites]:**
- Have the Firefox Beta 113.0b7 build installed.
- Have the `nimbus.debug` pref set to `true`.

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Copy and paste the following link in a new tab: 
`about:studies?optin_slug=new-import-interface-firefox-113&optin_branch=treatment-f&optin_collection=nimbus-preview`
3. Focus the “about:welcome” tab. 
4. Navigate through the "about:welcome" screens until the "Import Data" one is displayed.
5. Click the "Import from [previous browser]" button.
6. Click and hold one of the Import Wizard edges.
7. Move the mouse and observe the behavior.

**[Expected result]:**
- The elements from the Import Wizard adapt to the new size of the window.

**[Actual result]:**
- The elements remain fixed inside the window and don’t respond in any way to the new window size. 

**[Notes]:**
- This issue is reproducible with the `treatment C` and `treatment F` branches of the [“New Import Interface in about welcome: Firefox 113 (new users), QA version”](https://experimenter.services.mozilla.com/nimbus/new-import-interface-firefox-113/summary) experiment.
- This issue is reproducible with the `treatment C` branch of the [“dmose-test-new-import”](https://experimenter.services.mozilla.com/nimbus/dmose-test-new-import/summary) experiment.
- The Import Wizard is reset to its default size when opening/closing the “Import all available data” section.
- This issue is also reproducible with the old Import Wizard. 
- This issue is not reproducible on Windows and macOS.
- [Here](https://drive.google.com/file/d/1enpK2uZ0NZYUFqpcVUjF6ltWmuGjGQ9S/view?usp=sharing) is the screen recording of the issue.
Bug: Pocket newtab new feeds are incorrectly being fetched for localeListConfig locales in nightly
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-04-25 16:33:40+00:00
Resolved: 2023-04-27 09:52:46+00:00

Friday we turned on the new feed but preffed off.

It looks like there is another pref, localeListConfig, that can get around the off status of this for nightly only.

We should ensure the new feeds know to not make these requests, and instead make the old requests, for locales in localeListConfig.
Bug: broken link to automated testing page
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-04-26 02:10:12+00:00
Resolved: 2023-04-28 12:35:16+00:00

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

Steps to reproduce:

Accessed the Get Involved page here: https://quality.mozilla.org/get-involved/, and then clicked on the link to "get started with automation."


Actual results:

The page does not exist.  Clicking on the link returns a "page not found" error.  This was tested in both Nightly and production (stable release) browsers.


Expected results:

Should be able to access the page.
Bug: Make DoH fallback warning page look nice
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-04-26 09:15:01+00:00
Resolved: 2023-05-09 14:23:58+00:00

It seems we forgot to apply the correct CSS to the fallback warning page, so it's not displaying the box around the error message as the mode3 error page is doing.
Bug: fixed bug invalid
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-04-26 10:44:55+00:00
Resolved: 2023-04-26 11:02:58+00:00

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

Steps to reproduce:

i tried to log into Gmail. Received message that it needs javascript. Am unable to log into Gmail.
In privacy settings i have "strict" selected and "delete cache and cookies when FF closes"
I also have NoScript, but allow as usual gmail and gstatic.
I tried to change privacy settings to "Standard" but did not change anything.





Actual results:

upon attempt to log into Gmail I receive message that can not log in Gmail, requires Javascript. (i did not modify any settings lately)


Expected results:

normal page with username then password
Bug: Nimbus integration with Search Service should have protection for invalid values
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-04-26 11:25:38+00:00
Resolved: 2023-06-19 21:34:29+00:00

I set up a test Nimbus experiment with incorrect extra parameter values. These caused the code to throw and stop initialisation of the search service.

Due to the level of QA that we have I think it would be unlikely to happen in reality. However, I would still be concerned that something could get changed in newer versions of Firefox, and the impacts not realised for older versions.

I think we should have protections in place so that a broken Nimbus experiment cannot stop initialisation/use of the search service.

We should review all Nimbus points, to make sure that we handle exceptions appropriately, and maybe see if there's a way to report back via Nimbus about the experiment not being applied (maybe unenroll with a flag?)

The incorrect branch value was: 
```
{
  "extraParams": {
      "google_channel_row" : "bar"
    }
  ]
}
``` 
This should have been:
```
{
  "extraParams": [
    {
      "key": "google_channel_row",
      "value": "bar"
    }
  ]
}
```

This caused this [function to throw](https://searchfox.org/mozilla-central/rev/8329a650e3b4f866176ae54016702eb35fb8b0d6/toolkit/components/search/SearchEngine.sys.mjs#143-149), which then stopped the search service initialising.
Bug: Nimbus integration with Search Service can to set up experiments before the search service has initialised
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-04-26 12:21:03+00:00
Resolved: 2025-01-23 11:58:09+00:00

I had a test experiment applied which was setting extra parameters on engines. When restarting with the experiment enabled I noticed the error below on the console.

This doesn't break initialisation, but looks like it could break the experimentation set-up around the default private engine work.

```
Error: Something tried to use the search service before it's been properly intialized. Please examine the stack trace to figure out what and where to fix it:
#ensureInitialized@resource://gre/modules/SearchService.sys.mjs:1255:15
get defaultPrivateEngine@resource://gre/modules/SearchService.sys.mjs:189:28
#checkNimbusPrefs@resource://gre/modules/SearchService.sys.mjs:3225:34
#nimbusSearchUpdated@resource://gre/modules/SearchService.sys.mjs:3198:27
_onFeatureUpdate@resource://nimbus/lib/ExperimentStore.sys.mjs:390:17
onUpdate@resource://nimbus/ExperimentAPI.sys.mjs:472:26
#addObservers@resource://gre/modules/SearchService.sys.mjs:3274:32
#init@resource://gre/modules/SearchService.sys.mjs:1332:25
async*init@resource://gre/modules/SearchService.sys.mjs:366:23
getDefault@resource://gre/modules/SearchService.sys.mjs:205:16
_updateURLBarPlaceholderFromDefaultEngine@chrome://browser/content/browser.js:3836:31
delayedStartupInit@chrome://browser/content/browser.js:3696:10
_delayedStartup@chrome://browser/content/browser.js:1871:19
EventListener.handleEvent*onLoad@chrome://browser/content/browser.js:1773:12
EventHandlerNonNull*@chrome://browser/content/browser.xhtml:116:39
```
Bug: Can't open correctly formed URIs with non-codified schemas from GUI.
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-04-26 12:52:28+00:00
Resolved: 2023-10-23 17:17:50+00:00

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

Steps to reproduce:

I tried to input [`remote:/`](remote:/) and [`applications:/`]() into `firefox`'s URL bar via its GUI.


Actual results:

`firefox` did not attempt to display the content of either URI, despite being adherent to the relevant RFCs.


Expected results:

This should work. Although URLs necessitate two slashes, more general URIs do not: they can be identified as merely a schema and subsequent purpose-specific data. It's not like I'm proposing that `firefox` uselessly interpret URNs - these examples perform specific applications that I want `firefox` to interact with. The attached pictures demonstrate this.

https://bugzilla.mozilla.org/show_bug.cgi?id=1162372 is the cause?
Bug: "Take Screenshot" fails on very long pages.
Status: NEW
Priority: P2
Created: 2023-04-26 14:17:33+00:00
Resolved: 2024-12-19 06:51:13+00:00

This actually got reported as an Issue of one of my Add-ons but it can be reproduced in the Firefox built-in screenshot tool.

Open this page:
https://de.aliexpress.com/item/1005005020611782.html

Scroll to the very end (which makes the page load more stuff) and make the window a bit narrower so the page gets "really long".

Now use the Firefox built-in "Take Screenshot" feature and try to capture the whole page.

Result: Nothing happens

Expected result: At least some "accepted region" should have been captured.
Bug: Trending predictions flickers when persisted search term is present in addressbar
Status: NEW
Priority: P3
Created: 2023-04-26 16:27:50+00:00
Resolved: 2023-10-23 15:22:57+00:00

**Found in**
* 114.0a1 (2023-04-26)

**Affected versions**
* 114.0a1

**Tested platforms**
* Affected platforms:
         - Windows 10
         - Mac 13.2.1
 


**Preconditions**
* Have VPN connected to CA/US.
* Google as default search engine.
* browser.search.region set to CA/US
* browser.urlbar.trending.featureGate set to true
* browser.urlbar.trending.requireSearchMode set to false


**Steps to reproduce**
1. Open address bar.
2. Select a google trending prediction / perform a simple search (idea is to have the persisted search term in the address bar)
3. Click the address bar.

**Expected result**
The persist search term is selected, suggestions with the persisted search term are displayed.

**Actual result**
Before the persisted search termin suggestions are displayed there is a small flicker with trending predictions

**Regression range**
* N/A -> New feature interaction with persistent search.

**Notes**
- Having the persistent search feature turned off - either by pref or enabling search bar will not generate the above flicker since the trending predictions will be displayed as default on selecting the address bar -> with full url displayed.
- The reload of the GTP from bug 1825751 can be also noticed in the first 2s of the attachment.
Bug: "Firefox suggests" search suggestions despite suggestions being turned off in settings
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-04-26 16:56:24+00:00
Resolved: 2023-06-14 13:57:26+00:00

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

Steps to reproduce:

I open Firefox
I check my settings:
- Under 'search'
- All search suggestions are disabled
I type something in the search bar


Actual results:

"Firefox suggests" related search results


Expected results:

I expect Firefox to not show me related search results when it is explicitly instructed not to
Bug: Ensure language tag correctness
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-04-26 21:25:26+00:00
Resolved: 2023-05-03 09:10:42+00:00

The language tags returned by fastText language detection are codes from the ISO639-3 specification:

https://iso639-3.sil.org/code_tables/639/data

The language tags that we use internally in Firefox are from the BCP47 specification:

https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

We should ensure that all of the possible mappings from fastText are valid. 

Secondly, the existing code has been created with the notion that language tags are two characters. This is true of all of the languages that Firefox Translations currently supports, however BCP47 language tags can be more than two characters long. 

We should ensure that the code can support language tags of any length.
Bug: 2 pixels wide horizontal no-invoking area appearing when dragging tab into bookmark-toolbar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-04-27 00:24:59+00:00
Resolved: 2023-04-27 09:39:16+00:00

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

Steps to reproduce:

1. Set bookmarks-toolbar to "always visible"
2. open 2 random websites (will refer to them as A and B)
3. add both websites to the bookmarks-toolbar
4. open a 3rd website (refering to as C)
5. drag that website-tab into the bookmarks-toolbar and do not release the mouse
6. now hover the C bookmark right in between both A and B bookmark-icons, do not release mouse and slowly move left and right


Actual results:

there is a 2-pixel wide horizontal zone between A and B icons in which the blue pin/bar icon (indicating "save bookmark in this spot") will disappear, and when releasing the mouse-button in that area, the bookmark does not appear in that spot in the bookmark toolbar, but all the way to the right at the end of the toolbar, or even invisible on the toolbar if you have the entire toolbar filled with bookmarks.


Expected results:

the blue pin/bar icon (indicating "save bookmark in this spot") should not disappear at all when slowly moving the mouse left and right between two existing bookmarks while holding the mousebutton and dragging a new bookmark
Bug: The Bookmarks Toolbar has stopped working, it no longer shows any website links.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-04-27 00:52:50+00:00
Resolved: 2023-06-19 06:55:38+00:00

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

Steps to reproduce:

I allowed Firefox to update to the latest version.


Actual results:

the bookmarks toolbar went blank. it has no items in it, even though the items are present in the bookmarks toolbar section of the Manage Bookmarks window (menu/manage bookmarks/bookmarks toolbar)


Expected results:

the bookmarks toolbar should have bookmarks in it. it does not.
Bug: the menu choice "History/Clear Recent History" has stopped working
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-04-27 01:00:11+00:00
Resolved: 2023-06-19 06:55:44+00:00

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

Steps to reproduce:

I allowed Firefox to update to the latest version


Actual results:

the menu choice "History/Clear Recent History" has stopped working. it no longer clears the History


Expected results:

it should have cleared the history menu of all bookmark items.
I now have to clear them manually by opening the history menu and deleting the history folders.
Bug: Wrong screen impression sent after switching locale and reload of about:welcome
Status: NEW
Priority: P2
Created: 2023-04-27 02:36:54+00:00
Resolved: 2023-05-22 16:06:43+00:00

Followup of https://bugzilla.mozilla.org/show_bug.cgi?id=1823779 fix tracking below edge case

STR:
1. Open about:welcome with Language Switcher flow
2. Switch locale on Language switcher screen
3. Hit Reload or complete onboarding by navigating to about:home and hit back button
4. Screen impression in telemetry ping are incorrect

This only happens on about:welcome reloads due to explicit click of refresh or  back navigation from about:home to about:welcome due to filtering out `AW_LANGUAGE_MISMATCH` screen in useLanguageSwitcher custom hook and updating screen index , while useEffect hook that sends impression ping still using upcomingScreens from defaultScreens to get filteredScreens

https://searchfox.org/mozilla-release/rev/a2c0963d8de08c70624a8869461435b45490a42a/browser/components/newtab/content-src/aboutwelcome/components/LanguageSwitcher.jsx#134


    let upcomingScreens = defaultScreens.filter(
        s => !screensVisited.find(v => v.id === s.id)
      );

      let filteredScreens = screensVisited.concat(
        (await window.AWEvaluateScreenTargeting(upcomingScreens)) ??
          upcomingScreens
      );
`

One option to fix is maintaining ` defaultLanguageModifiedScreens `   state thats gets updated if  `useLanguageSwitcher` custom hook  filter  `AW_LANGUAGE_MISMATCH` and using that instead of defaultScreens.

https://phabricator.services.mozilla.com/D174044#5820568