av9ash/GitBugs huggingface dataset:
Bug: Enable the new recently-closed tab sessionstore prefs by default, ensuring our tests will pass once 119 becomes beta
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-09-07 15:48:19+00:00
Resolved: 2023-09-29 03:20:09+00:00

[Tracking Requested - why for this release]:

[Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=0ed64f3af4ed16738fdcb7881bb0e7199d4d1d94&selectedTaskRun=aC8sgZukSj2cfHb8JlEmrA.0)

[How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)

[Failure log](https://treeherder.mozilla.org/logviewer?job_id=428282871&repo=try&lineNumber=8816)
Bug: All my tabs keep reloading every hour or so automatically, and I do not have any automatic tab reloading enabled in any extensions
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-09-07 15:51:57+00:00
Resolved: 2024-05-06 12:22:07+00:00

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

Steps to reproduce:

I just use firefox, and every hour or so, all of my tabs on every window reload without prompting anything. I don't have any extensions that could reload my tabs automatically


Actual results:

Every tab reloads and takes a long time to load back up


Expected results:

Nothing, I should have been able to keep using the tab I was on
Bug: Toggling Recent Activity in the settings panel does not cause the Recent Activity section to appear in the cached about:home document
Status: NEW
Priority: P3
Created: 2023-09-07 17:57:29+00:00
Resolved: 2023-09-13 21:20:55+00:00

STR:

1. Ensure that Recent Activity is disabled in about:newtab, and that Firefox is configured to load about:home in a single tab after restart
2. Restart the browser
3. Ensure that the loaded about:home page loaded from the cache (you can do this by viewing the page source, and looking for a comment above the <body> element, like:

```lang=html
<!-- Cached: Thu, 07 Sep 2023 17:54:42 GMT -->
```
4. Open the settings pane on about:home, and turn on Recent Activity

ER:

Recent Activity should appear at the bottom of the page.

AR:

Recent Activity does not appear. It probably shows and hides in any subsequently loaded about:newtab documents.
Bug: Typing search keywords really fast in settings UI (or pasting them) may result in missing results
Status: NEW
Priority: P3
Created: 2023-09-07 18:14:43+00:00
Resolved: 2023-09-18 15:15:06+00:00

The patch on bug 1850243 only works if you type "telemetry" sedately. If you type quickly or your computer is having A Day or if you paste the word into the search box in `about:preferences`, then we get the current behaviour of "telemetry" returning no results.
Bug: Firefox translations can't load the translation engine
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-09-07 18:19:19+00:00
Resolved: 2023-09-25 12:50:19+00:00

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

Steps to reproduce:

- I open any Web page like 'https://bugzilla.mozilla.org/'.
- I click on the Firefox Translations icon from the address bar.
- The Firefox Translations bar opens.
- I select 'English' or other as source language (nothing is selected by default), 'French' is already selected as my native language.
- I click on the 'Translate' button.




Actual results:

After a few seconds, I get the message in the Firefox Translations bar: Impossible de trouver le moteur de traduction à télécharger. (Unable to find the translation engine to download).


Expected results:

The translation engine should be loaded and translate the current page.
Bug: Intermittent browser/base/content/test/permissions/browser_temporary_permissions_tabs.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-09-07 18:58:03+00:00
Resolved: 2025-03-03 12:04:36+00:00

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

---
```
[task 2023-09-07T18:03:08.630Z] 18:03:08     INFO - TEST-PASS | browser/base/content/test/permissions/browser_temporary_permissions_tabs.js | Temporary permission map should be empty initially. - 
[task 2023-09-07T18:03:08.631Z] 18:03:08     INFO - Buffered messages logged at 18:01:42
[task 2023-09-07T18:03:08.632Z] 18:03:08     INFO - Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "https://example.com/" line: 0}]
[task 2023-09-07T18:03:08.633Z] 18:03:08     INFO - Buffered messages finished
[task 2023-09-07T18:03:08.634Z] 18:03:08     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/permissions/browser_temporary_permissions_tabs.js | Test timed out - 
[task 2023-09-07T18:03:08.634Z] 18:03:08     INFO - GECKO(1558) | MEMORY STAT | vsize 11908MB | residentFast 639MB | heapAllocated 365MB
[task 2023-09-07T18:03:08.635Z] 18:03:08     INFO - TEST-OK | browser/base/content/test/permissions/browser_temporary_permissions_tabs.js | took 90131ms
```
Bug: Consider removing position:fixed from the shopping-container.
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2023-09-07 19:33:14+00:00
Resolved: 2023-10-04 16:12:07+00:00

See discussion in bug 1851657. 

Removing this will require at least fixing bug 1851834 to set the bg color on the body/root rather than the individual element. I'm not sure if it'd break anything else, especially wrt the stickiness of the header and/or the injected onboarding UI.
Bug: Switch Open Tabs card layout to 2 columns on narrow viewports
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-09-07 20:20:02+00:00
Resolved: 2023-09-23 21:53:04+00:00

On the Open Tabs page of Firefox View, we need to switch to a 2-column layout for the cards when the viewport width is below 1366px. When the viewport is too narrow, and we're still applying a 3-column layout, the tab titles are truncated beyond being of much use to the user.

We can resolve this by adding a media query in `view-opentabs.css` for when the window width is a max of 1365px (we may want to convert this to rem actually), then redefine the `.three-column` styles to match the `.two-column` styles.
Bug: Page jumps back to top when new Element is appended to body via Javascript
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-09-07 22:46:30+00:00
Resolved: 2023-09-14 07:16:32+00:00

Steps to reproduce:

- I opened a page which loads images in the upper part of the layout via javascript.
- I scroll down to the bottom of the page to read some text.


Actual results:

- Whenever a new image is appended on the top part (out of view), the page jumps back to top and I can't read the text on the bottom of the page.


Expected results:

- Images appended to top of page should not change the scroll position of the document unless the actual height of the document is changed.

I tried Firefox Version 81 and below. The issue was supposed to be solved with Firefox 66, but reappeared in Version 82 and is still present in version 117.

See also

https://www.zdnet.com/article/firefox-will-finally-fix-annoying-page-jumps/
https://forum.zorin.com/t/a-page-scrolled-down-in-firefox-jumps-back-to-the-top/22861
Bug: App Menu keyboard shortcuts are not readable with Dark system theme
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-09-08 06:14:45+00:00
Resolved: 2023-10-04 10:27:03+00:00

**Found in**
* 119.0a1 (2023-09-07)


**Affected versions**
* 119.0a1 (2023-09-07)






**Tested platforms**
* Affected platforms:macOS 12,  Windows 10x64
* Unaffected platforms:  Ubuntu 20

**Preconditions**
* System theme set to dark
* Firefox set to system theme

**Steps to reproduce**
1. Open the App Menu.
2. Observe the keyboard shortcuts.

**Expected result** 
* The keyboard shortcuts are readable.

**Actual result**
* The keyboard shortcuts are not readable.



**Regression range**
* Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=751ce10ffa95f4706e709666d45db519e48786c7&tochange=85ed967e285f304f7709461aec0d33ca72805791







**Additional notes**
* Attached a screenshot.
Bug: Search directly from the address bar string is not visible with dark system theme
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-09-08 07:17:38+00:00
Resolved: 2023-10-04 10:39:58+00:00

**Found in**
* 119.0a1 (2023-09-07)


**Affected versions**
* 119.0a1 (2023-09-07)






**Tested platforms**
* Affected platforms:macOS 12,  Windows 10x64
* Unaffected platforms: Ubuntu 20

**Preconditions**
* system theme set to dark
* Firefox set to system theme

**Steps to reproduce**
1. Open Firefox with a new profile
2. Open the Address Bar and type Amazon
3. Observe the results.

**Expected result** 
* The `Search directly from the address bar string` is visible

**Actual result**
* The `Search directly from the address bar string` is visible



**Regression range**
* Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=751ce10ffa95f4706e709666d45db519e48786c7&tochange=85ed967e285f304f7709461aec0d33ca72805791







**Additional notes**
* Attached a screen recording.
Bug: Regression: awesome bar is less accurate now
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-09-08 08:39:37+00:00
Resolved: 2023-09-14 07:26:10+00:00

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

Steps to reproduce:

I'm very used to using the awesome bar effectively. Recently, after some update, it lost some valuable features.


Actual results:

In my browsing history, I visit https://gitlab.com/moduon/mrchef a lot.

If I write "mrchef" in the awesomebar, that link appears as a suggestion.

But if I write "mrchef gitlab", it doesn't appear.

Also, if I write "git", it doesn't auto-suggest my most visited site starting with that word.


Expected results:

Just like it was happening some weeks ago:

- If I write "mrchef gitlab", https://gitlab.com/moduon/mrchef should be the 1st suggestion.
- If I write "git", FF should autocomplete the rest of the host.
Bug: Fix spacing between synced devices on Recent Browsing
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-09-08 09:37:34+00:00
Resolved: 2023-09-21 03:25:31+00:00

There should be spacing between the device headers per the [spec](https://www.figma.com/file/wP9MY9KJn9xqPf140lTvTv/Fx-View-Specs-2023?type=design&node-id=6465-203645&mode=design&t=OWwrUbBQGv4KJoNs-0) (note: the spec shows different layouts depending on the number of devices but that is out of scope for 119 so it should be referenced for the spacing between device headers).
Bug: The "Translate this page?" pop-up appears in front of the "default browser" pop-up, but the focus goes to the "default browser" pop-up
Status: NEW
Priority: P3
Created: 2023-09-08 09:41:29+00:00
Resolved: 2023-11-16 14:25:21+00:00

**Note**
* When the user launches the browser and both the default browser and Translate this page modals get displayed, the default browser modal has the focus even if the other one is in front of it.

**Found in**
* Beta v118.0b6

**Affected versions**
* Beta v118.0b6

**Tested platforms**
* Affected platforms: Windows 10
* Unaffected platforms: ?

**Steps to reproduce**
1. Open a new profile
2. Load a page that has another default language than the browser
(This would cause the "Translate this page?" modal to be displayed)
3. Close the browser and reopen the same user profile.
4. When the browser reopens, it will display both the "Translate this page" modal and the "default browser" modal.

**Expected result**
* The pop-up that is displayed in front should have the focus to interact with it.

**Actual result**
* The "Translate this page?" pop-up appears in front of the "default browser" pop-up, but the focus goes to the "default browser" pop-up.

**Regression range**
* appears to be an issue since the implementation of the "Translate this page?" modal.

**Additional notes**
* additional_note1
Bug: New logins added manually from about:logins page are not synced
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-09-08 10:19:50+00:00
Resolved: 2023-09-29 10:51:49+00:00

**Notes**
* about:sync log file attached.
* [Screen recording.](https://drive.google.com/file/d/1NHKhntskJpa9ZO64f2PRnOfQ5t7wQBGC/view?usp=drive_link)

**Found in**
* Firefox 118.0b6;

**Affected versions**
* Firefox 118.0b6;
* Nightly 119.0a1;

**Tested platforms**
* macOS 12;
* Windows 10;
* Ubuntu 22;


**Affected platforms**
* macOS 12;
* Windows 10;
* Ubuntu 22;



**Unaffected platforms**
* N/A; 

**Preconditions** 
- Valid credentials for an  Fx Account. 

**Steps to reproduce**
1. Create a new profile, for example profile A.
2. Navigate to about:logins.
3. Log into the Fx account. ( It’s easier to test if the login page is empty, or has fewer logins)
4. Manually add one or two new logins from the about:logins page.
5. Sync Now on profile A.
6. Create a new profile, for example profile B.
7. Navigate to about:logins on profile B.
8. Login with the same account from step 3 on profile B.
9. Sync Now on profile B.

**Expected result**
* The newly added logins in Step 4 from profile A should be synced onto profile B.

**Actual result**
* Logins do not sync. 

**Regression range**
* Mozregression points to: 
* last good: 2023-08-14
* first bad: 2023-08-15
* pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=88ec6682eab1c5c36cb839c8db0156446559a1cb&tochange=2125dc1611bef4236c0d3c89e79040a8ece7b8e1
* Potentially regressed by: bug 1846036
Bug: More to consider card is no longer displayed (even with recommendation/ad turned on)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-09-08 13:02:01+00:00
Resolved: 2023-09-27 12:15:06+00:00

**Found in**
* 119.0a1 (2023-09-08)


**Affected versions**
* 119.0a1 (2023-09-08)






**Tested platforms**
* Affected platforms:macOS 12,  Windows 10x64, Ubuntu 20
* Unaffected platforms: 

**Preconditions**
* browser.shopping.experience2023.enabled: true
* browser.shopping.experience2023.optedIn: 1
* browser.shopping.experience2023.ads.userEnabled:true
* browser.shopping.experience2023.ads.enabled: true

**Steps to reproduce**
1. Open the following [Amazon product](https://www.amazon.com/dp/B08D73C9FH?th=1).
2. Observe the Fakespot sidebar.

**Expected result** 
* The `More to consider` card is displayed.

**Actual result**
* The `More to consider card` is not displayed.



**Regression range**
* Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=56afdfd6da8e432bf4527289fece560dbaad4396&tochange=da9790fe139e5d380eb17b1b1b9051e95430e34f







**Additional notes**
* Attached a screenshot.
Bug: Address Bar result menu glitches after an Add-on recommendation is dismissed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-09-08 16:08:53+00:00
Resolved: 2023-09-14 08:58:36+00:00

**Notes**
* Screencast of the issue attached;

**Found in**
* Nightly 119.0a1;

**Affected versions**
* Nightly 119.0a1;

**Tested platforms**
* macOS 12;
* Windows 10;
* Ubuntu 22;


**Affected platforms**
* macOS 12;
* Windows 10;
* Ubuntu 22;



**Unaffected platforms**
* N/A; 

**Preconditions**
* browser.urlbar.quicksuggest.enabled set to true 
* browser.urlbar.addons.featureGate set to true 
* browser.search.region set to US 

**Steps to reproduce**
1. Launch Firefox with the profile from the preconditions.
2. In the Address Bar type a keyword that would trigger an add-on recommendation, such as  ‘tts’ , ‘adblock’ , ‘videos’.
3. Once the Add-on recommendation is shown, click on the ‘Feedback’ button.
4. Choose Don’t show this -> Not relevant. 
5. Open a new tab. 
6. Navigate back to the tab from step 2( The one where  the add-on recommendation was dismissed from earlier).

**Expected result**
* No glitches.

**Actual result**
* There’s a split second glitch of the dismissed add-on after switching tabs. 

**Regression range**
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=360d86fdb97bfa02c4fb847059da51c90db14014&tochange=c8b40099127c273a58ba6defbe045c55752f0f64 
Potentially regressed by: bug 1851942
Bug: Shopping sidebar loading state width is too narrow
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-09-08 16:13:26+00:00
Resolved: 2023-10-25 11:24:34+00:00

This is especially obvious in bug 1852274 with the permanent loading state for offline mode, but you can also see it briefly in the "normal" loading state.

I think this is a recent regression, possibly to do with the header changes?

Addressing bug 1852141 (ie removing `position: fixed`) fixes this but causes other issues with the header...
Bug: Fix ads not appearing with `adsEnabledByUser: true` due to markup
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-09-08 18:34:31+00:00
Resolved: 2023-09-12 18:48:02+00:00

There's a [small markup error](https://searchfox.org/mozilla-central/rev/7fe1954b761abeff36122b4a6ac74619704ee787/browser/components/shopping/content/shopping-container.mjs#131) with `analysis-explainer` that causes any available ads to not render when a user enables them. We render the ad by calling `this.recommendationTemplate`, but it does not currently function due to the markup error.
Bug: Make Nightly Default Browser Not Working When Done Via about:preferences
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-09-08 19:17:56+00:00
Resolved: 2023-09-14 08:40:23+00:00

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

Steps to reproduce:

Go into about:preferences
Click "Make Default" to make Nightly the default browser
Observe what happens (which on my end is nothing)



Actual results:

I got "Always check if Nightly is your default browser" to get Check marked. However, after opening up a .html file that I have, it opens in Stable Firefox. Not nightly. 


Expected results:

Firefox nightly should have been made my default browser when I clicked it in about:preferences

To note. I am running Windows Insiders. I am on the Dev branch. Not sure if that has anything to do with it. I don't have a "Stable" windows version to test. Short of spinning up a VM.
Bug: Translation isn't done in some dynamic menu
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2023-09-08 19:20:34+00:00
Resolved: 2023-10-23 18:06:57+00:00

On https://www.leroymerlin.es/

1. translate into a language
2. Click on the hamburger menu of the website (top left)
3 => it gets translated
4. Click on an item (Tools for example)

=> No translation in the menu
Bug: Saved passwords can be revealed via "Search Logins"
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-09-08 19:57:58+00:00
Resolved: 2023-09-08 20:13:33+00:00

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

Steps to reproduce:

Go to Menu => Passwords
Enter Primary Password to unlock database (if prompted)
Enter some password in "Search Logins"


Actual results:

Passwords are searchable via "Search Logins" edit box, which makes possible to reveal stored passwords with brute force, bypassing second prompt for Primary Password to view the passwords (for example, if someone lefts PC unlocked).


Expected results:

Passwords should not be shown in search results
Bug: For addon and Pocket suggestions, the “Show less frequently” option is not removed from the Feedback menu if the Address Bar panel is not closed after reaching the frequency cap
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-09-08 21:50:47+00:00
Resolved: 2024-02-20 16:22:03+00:00

If you keep clicking "Show less frequently" on an addon suggestion until the cap is reached without closing the urlbar panel, the command should disappear from the menu but it doesn't. This bug isn't possible to trigger right now due to the fact there is no cap (bug 1852353).

This is the same as bug 1832826 except for addon suggestions, and the fix is the same.
Bug: Firefox is not blocking subrequests prohibited on policies.json's WebsiteFilter rules
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-09-08 23:06:50+00:00
Resolved: 2024-07-18 18:23:15+00:00

User Agent: Firefox 115.2.0 ESR

Steps to reproduce:

1. Create policies.json with "WebsiteFilter": {"Block": ["*://*.example.com/*"]}
2. Open website example.net, which has <img>,<video> tag points to example.com


Actual results:

Firefox load resource from example.com


Expected results:

Firefox MUST NOT load resource from example.com at all because it is blocked by corporate policy. Currently only opening example.com directly in new tab get blocked. This feature is useless because we want to enforce policy.
Bug: MerinoTestUtils.initWeather() doesn't play well with pushPrefEnv()
Status: NEW
Priority: P3
Created: 2023-09-09 02:36:25+00:00
Resolved: 2023-09-11 07:55:46+00:00

In Slack today Marco and I were discussing a problem with `MerinoTestUtils.initWeather()`. A TV test was hanging on `await fetchPromise` [here](https://searchfox.org/mozilla-central/rev/7fe1954b761abeff36122b4a6ac74619704ee787/browser/components/urlbar/tests/quicksuggest/MerinoTestUtils.sys.mjs#330) because the weather feature was already initialized, so setting the weather prefs to true again didn't retrigger a fetch.

The problem turned out to be a couple later tasks in the test used `pushPrefEnv()` to set `weather.featureGate` to false. That created this scenario (copy-pasted from Slack):

1. When those `pushPrefEnv` calls run, `weather.featureGate` is true because of the weather task [the one task in the file that enabled the weather feature]
2. When the test ends, first MerinoTestUtil’s cleanup function runs and clears that pref, resetting it to false
3. But then the pref env is popped by the test harness, setting the pref back to true. So the weather feature ends up being enabled when it shouldn’t be

I'm not sure of the best fix but it ought to be harmless for a test to `pushPrefEnv` the weather prefs at any time. Ideas off the top of my head:

* `MerinoTestUtils.initWeather()` should check to see if the feature is already enabled. But this wouldn't fix the underlying problem where the pref gets into an unexpected state in the first place.
* Maybe add a `MerinoTestUtils.uninitWeather()` that consumers would be expected to call when they’re totally done with it. Then consumers would not be relying on MerinoTestUtils’s cleanup function to disable weather.
* `MerinoTestUtils` itself maybe should use `pushPrefEnv`? Not clear if that would fix anything
Bug: Fullpage translation: Paragraph vanishes after translating
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-09-09 05:48:24+00:00
Resolved: 2024-07-19 19:19:58+00:00

I noticed that a certain paragraph on a certain website vanishes after translating it.

Steps to reproduce:
1. Go to https://www.legion-etrangere.com/mdl/pages.php?id=40&titre=Le-coin-des-Anciens

2. Click the Translate button and select French as the source and German as the target.

Notice that the text under the second paragraph "Le Bureau des anciens" vanishes completely.