av9ash/GitBugs huggingface dataset:
Bug: Improve Select Translations panel announcements for screen readers
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-07 20:27:14+00:00
Resolved: 2024-06-21 19:13:25+00:00

Build on the bug 1894098 work and ensure:
1. When panel opens, it is announced as `Translations Beta` (while Beta is present, both via `aria-labelledby`) and additionally `Manage translation settings` is also announced (via `aria-describedby`).
    1. Note: VoiceOver may announce only the description. - this is likely a VO bug (will investigate), but programmatically in the Accessibility tree the label and descriptions should be as described (could be confirmed via Dev Tools > Accessibility Inspector with settings > "Disable Popup Auto-hide" option of dev tools being checked)
1. The `<textarea>` with translation output is labelled - and the label could be both the To/From languages, i.e. `From English to French` via `aria-labelledby`)
Bug: Tracking protection pop-up issue when some tracker types have been allowed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-08 08:31:59+00:00
Resolved: 2024-07-12 06:09:41+00:00

Steps to reproduce:

Tracking protection select "custom", cookie select "All cross-site cookies"


Actual results:

Tracking protection pop-up always show cookie is "Blocked" or "Allowed" (When tracking protection has been disabled)


Expected results:

It should show as "None detected" instead when not detected. By the way, in this situation, tracker types which haven't enabled should classify as "Disabled", not "None detected".
Bug: Break-before example on mdn web docs not working
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-08 14:13:58+00:00
Resolved: 2024-06-08 14:15:37+00:00

Steps to reproduce:

1. Open https://developer.mozilla.org/en-US/docs/Web/CSS/break-before
2. Click 'Show print preview'.
3. Notice that no page break is inserted, although Firefox support is listed.


Actual results:

No page break is inserted, although support for Firefox is listed.


Expected results:

A page break should be inserted in the print preview.
Bug: Crash in [@ OOM | large | NS_ABORT_OOM | nsTArray_Impl<T>::AppendElementInternal<T> | nsTArray<T>::AppendElement<T> | mozilla::a11y::NotificationController::ScheduleTextUpdate]
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-06-08 21:30:06+00:00
Resolved: 2024-06-11 12:04:06+00:00

Crash report: https://crash-stats.mozilla.org/report/index/657b6bdc-ad7a-408c-8829-a69070240608

MOZ_CRASH Reason: ```MOZ_CRASH(OOM)```

Top 10 frames:
```
0  XUL  NS_ABORT_OOM(unsigned long)  xpcom/base/nsDebugImpl.cpp:673
1  XUL  nsTArrayInfallibleAllocator::SizeTooBig(unsigned long)  xpcom/ds/nsTArray.h:262
2  XUL  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::E...  xpcom/ds/nsTArray-inl.h:165
3  XUL  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::E...  xpcom/ds/nsTArray.h:430
3  XUL  nsTArray_Impl<nsCOMPtr<nsIContent>, nsTArrayInfallibleAllocator>::AppendEleme...  xpcom/ds/nsTArray.h:2688
4  XUL  nsTArray<nsCOMPtr<nsIContent> >::AppendElement<nsIContent*&>(nsIContent*&)  xpcom/ds/nsTArray.h:2832
4  XUL  mozilla::a11y::NotificationController::ScheduleTextUpdate(nsIContent*)  accessible/base/NotificationController.h:145
4  XUL  mozilla::a11y::DocAccessible::UpdateText(nsIContent*)  accessible/generic/DocAccessible-inl.h:79
4  XUL  nsAccessibilityService::UpdateText(mozilla::PresShell*, nsIContent*)  accessible/base/nsAccessibilityService.cpp:789
5  XUL  ReflowTextA11yNotifier::~ReflowTextA11yNotifier()  layout/generic/nsTextFrame.cpp:9295
```
Bug: It seems that the last Firefox update has broke Metamask extension
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-06-08 21:31:36+00:00
Resolved: 2024-07-28 04:47:36+00:00

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

Steps to reproduce:

Since the last Firefox update 126.0.1, I cannot login anymore on Metamask as it keeps spinning and spinning with no end. This happening on my PC - desktop/Windows 10.
However, I have a full system bakcup of my main "C" Windows 10 drive, and on this backup I still have Firefox 124.0.1 installed. And on this version of Firefox I can login in Metamask as usual, with no problem at all.  
So, there is much chance that something in the last Firefox update did broke with Metamask.. Can you have a look at it ?... I  would not like to reinstall/reset Metamask !
Or may I could tried to install one of the a next Firefox beta version and  see it it solve the problem ?
Bug: "browser.tabs.loadBookmarksInBackground" does not work when clicking on "Open All in Tabs" in the bookmarks menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-09 15:56:19+00:00
Resolved: 2024-06-10 09:50:09+00:00

Steps to reproduce:

I set the values:

«browser.bookmarks.openInTabClosesMenu» → «false».
«browser.tabs.loadBookmarksInBackground» → «true».

But when you click on "Open All in Tabs" in the bookmarks menu, it redirects to the first tab to open, that is, the value "browser.tabs.loadBookmarksInBackground" does not work.


Actual results:

When you click on "Open All in Tabs" in the bookmarks menu, it redirects to the first tab to open, that is, the value "browser.tabs.loadBookmarksInBackground" does not work.


Expected results:

if you click "Open all in tabs", then the value "browser.tabs.loadBookmarksInBackground" should work and the behavior changes to "Open all in tabs".
Bug: "browser.tabs.loadBookmarksInBackground" does not work when clicking on "Open All in Tabs" in the bookmarks menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-09 15:57:26+00:00
Resolved: 2024-06-09 16:22:23+00:00

Steps to reproduce:

I set the values:

«browser.bookmarks.openInTabClosesMenu» → «false».
«browser.tabs.loadBookmarksInBackground» → «true».

But when you click on "Open All in Tabs" in the bookmarks menu, it redirects to the first tab to open, that is, the value "browser.tabs.loadBookmarksInBackground" does not work.


Actual results:

When you click on "Open All in Tabs" in the bookmarks menu, it redirects to the first tab to open, that is, the value "browser.tabs.loadBookmarksInBackground" does not work.


Expected results:

if you click "Open all in tabs", then the value "browser.tabs.loadBookmarksInBackground" should work and the behavior changes to "Open all in tabs".
Bug: -private-window <URL1> <URL2> and -private-window <URL1> -new-tab <URL2> does not work
Status: NEW
Priority: --
Created: 2024-06-09 16:16:31+00:00
Resolved: 2024-07-11 10:02:52+00:00

Steps to reproduce:

1) -private-window <URL1> <URL2>

2) -private-window <URL1> -new-tab <URL2>


Actual results:

1) The first <URL1> opens in incognito mode. <URL2> opens in normally mode in another window.

2) Opens in incognito mode, but in two different windows.


Expected results:

1) The first <URL1> opens in incognito mode. <URL2> opens in incognito mode in the same window.

2) Opens in incognito mode in the same window in different tabs.
Bug: lag in Nightly, hitting network after 17 second pause
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-06-09 22:18:23+00:00
Resolved: 2024-08-30 16:34:52+00:00

I am running Nightly 128.0a1 (2024-06-06) (64-bit).

Might there be a reason that there is a delay in loading pages? I opened a fresh page. I opened up the "Inspect" and when to the network console bit. I put a full URL into the Location bar.  I hit return.

The first network message came 17 seconds later. This seems ... not good, yes?

I see lots of perf tools but is there one I can use to characterize this?
Bug: No translation offered for Reddit page full of French comments
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-06-10 04:13:39+00:00
Resolved: 2025-02-03 14:46:52+00:00

Steps to reproduce:

Go to https://old.reddit.com/r/france/comments/1dc1d9n/dissolution_de_lassembl%C3%A9e_nationale/


Actual results:

No Firefox Translations popup.


Expected results:

Firefox should offer to translate the page from French.
Bug: leparisien.fr - Translation doesn't affect overlay element
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-10 04:20:13+00:00
Resolved: 2024-07-18 14:24:22+00:00

Steps to reproduce:

* Go to https://www.leparisien.fr/
* Allow Firefox to translate it from French


Actual results:

The overlay/modal/"popup" element about cookies isn't translated.

I don't know what the French will do to me if I click on `Accepter`.


Expected results:

Firefox should protect me from the French.
Bug: "Never translate English" option is always disabled
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-10 10:03:01+00:00
Resolved: 2024-08-09 06:53:37+00:00

Version: 128.0a1 (2024-06-09) (64-bit)

Steps to reproduce:
1. Go to https://developer.mozilla.org/en-US/
2. Click on the Firefox Translate icon.
3. Click on the Settings icon.
4. Notice that "Never translate English" is disabled.

I started noticing this issue these days, possibly after changing my browser language to "German (Germany)" without including English, but after adding "English" back, the option is still disabled.
Bug: The "Learn more" link in about:home redirects to the pocket home page where I don't learn more
Status: NEW
Priority: P3
Created: 2024-06-10 10:59:07+00:00
Resolved: 2024-07-01 17:06:17+00:00

about:home contains a section labeled "Thought-provoking stories" with a "Learn more" link pointing to https://getpocket.com/firefox/new_tab_learn_more which redirects to https://getpocket.com/about where I don't learn anything about why Firefox is showing me these "Thought-provoking stories".

- about:home doesn't mention the word "Pocket" a single time.
- https://getpocket.com/about doesn't contain the word "Firefox" a single time. It contains the word "Mozilla" once, hidden behind the cookie banner.

This gives the weird impression that I ended up on the wrong page.
Bug: [Experiment] Nothing happens if clicking "Extensions success" link from the "Data Import Complete Success" screen of the "Embedded Import Spotlight"
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-06-10 11:58:42+00:00
Resolved: 2024-06-20 08:43:08+00:00

**[Affected versions]:**
- Firefox Nightly 128.0a1 (Build ID: )

**[Affected Platforms]:**
- Windows 10
- Windows 11

**[Prerequisites]:**
- Have a non Firefox browser installed and make sure that you have at least one compatible add-on installed.
- Have the following prefs in the "about:config" page:
  - nimbus.debug set to true
  - browser.newtabpage.activity-stream.asrouter.devtoolsEnabled set to true
  
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to "about:asrouter".
3. In the "Messages" section copy any of the messages from the treatment branches of [this experiment](https://experimenter.services.mozilla.com/nimbus/embedded-import-spotlight-existing-users/summary).
4. Click the "Modify" button.
5. Click the "Import to Firefox" button.
6. Click the "x of x extensions" link.
7. Observe the behavior.

**[Expected result]:**
- The "about:addons" page is opened in a new tab in the background.

**[Actual result]:**
- Nothing happens. 

**[ Notes]:**
- The issue is NOT reproducible if the Import modal is triggered from "about:preferences#general" or "about:logins" page.
- Here is the error displayed in the browser console when the link is clicked:
 - `TypeError: can't access property "ownerGlobal", browser is null         MigrationWizardParent.sys.mjs:845:18`
- Attached is a screen recording of the issue.
Bug: After update, the Find things faster introduction popup is displayed even in kiosk mode
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-10 12:13:18+00:00
Resolved: 2024-07-24 08:12:55+00:00

Steps to reproduce:

A Ubuntu 22.04 LTS system is configured to display an application UI from localhost using Firefox as the UI for a local "kiosk" user account. On a regular basis, updates to all installed packages are installed. Along those updates, Firefox was updated to the most recent version that features the "Find things faster" update: https://blog.mozilla.org/ux/2014/11/find-it-faster/


Actual results:

When the kiosk user was automatically logged in, the Firefox pop-up advertising the new "Find things faster" feature / change was displayed on top of the page, covering elements of the UI and confusing the user ("Where did that come from?").


Expected results:

In kiosk mode, such notifications about new features should not be displayed. Shouldn't there be a common base implementation for similar popups that would include, among other things, a check for kiosk mode?
Bug: The "Pin" icon is not clearly distinguishable from the highlight's background if a "Top Site" is hovered
Status: NEW
Priority: --
Created: 2024-06-10 12:53:09+00:00
Resolved: 2024-06-10 12:53:09+00:00

**[Affected versions]:**
- Firefox Nightly 128.0a1 - Build ID: 20240609205151

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

**[Prerequisites]:**
- Have the following prefs in the "about:config" page:
	- `browser.newtabpage.activity-stream.newtabWallpapers.enabled` set to `true`
	- `browser.newtabpage.activity-stream.newtabWallpapers.v2.enabled` set to `true`
- Have the "Light" browser theme set from the "Themes" section of the "about:addons" page.
- Have at least one "Top Site" pinned.
  
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Open a New Tab and click the "Personalize" button from the top-right part of the page.
3. Select a dark color wallpaper.
4. Hover any pinned website and observe the "pin" icon.

**[Expected result]:**
- The "Pin" icon is not clearly distinguishable from the highlight's background.
    
**[Actual result]:**
- The "Pin" icon is clearly distinguishable.

**[Additional Notes]:**
- The issue is also reproducible using the "Dark" browser theme and a light wallpaper.
- Attached a screen recording of the issue.
Bug: Returning profiles should a differentiated about:welcome flow after refreshing their profile via the Windows stub installer
Status: NEW
Priority: P2
Created: 2024-06-10 14:26:08+00:00
Resolved: 2024-09-26 13:14:00+00:00

This bug captures the investigation and any corresponding on-train work to enable the ability to differentiate the about:welcome flow for users who have reinstalled Firefox and refreshed their profile via the stub installer. This may include identifying and/or implementing a method for targeting these users in about:welcome. We can tap into the existing capability to use screen-level targeting for customizing which cards are shown to the user during the about:welcome flow.

----------------------
This bug is was initially created to investigate why users who refresh their profile in the Windows stub installer are still taken to the first run flow in about:welcome after reinstall. See notes from previous bug below:

[Bug 1898609](https://bugzilla.mozilla.org/show_bug.cgi?id=1898609) surfaced a bug on Windows that occurs when Firefox is installed via the stub installer and a user opts in to "refreshing" Firefox. These users are taken to about:welcome, despite [refresh logic intended to prevent this](https://searchfox.org/mozilla-central/rev/fc76676f61ee37b4c5420649cad6677164a29405/browser/components/migration/FirefoxProfileMigrator.sys.mjs#226-240). They also currently see an infobar in about:welcome asking them to refresh, even if they already opted in to doing so using the stub installer checkbox.

:pdahiya noted that this refresh logic isn't being executed for the restore profile flow and suggested investigating whether [MOZ_RESET_PROFILE_MIGRATE_SESSION](https://searchfox.org/mozilla-central/source/browser/components/migration/FirefoxProfileMigrator.sys.mjs#194) gets set in time. 

Also see :aminomancer's  [comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1898609#c9) suggesting a check for `trailhead.firstrun.didSeeAboutWelcome` in BrowserContentHandler where we determine whether `about:welcome` is going to show.
Bug: Feature callout type issues on Windows with ClearType disabled
Status: NEW
Priority: P2
Created: 2024-06-10 16:36:50+00:00
Resolved: 2024-07-08 17:15:11+00:00

We think this is caused by the use of `letter-spacing` in aboutwelcome.scss. It may also be compounded by weird font sizes in feature callout, which are the result of em units. We should remove `letter-spacing` from aboutwelcome.scss, and in _feature-callout.scss we should change all existing font-size rules to use px. And where aboutwelcome.scss uses em units, I don't feel confident about changing those just yet, so override them in _feature-callout.scss instead of changing them in aboutwelcome.scss. I'm not entirely sure if the font sizes are an issue, because we're using 0.813em to try and reach 13px via em units. But we should change them to 13px just to be safe. [See the Figma spec](https://www.figma.com/design/2ruSnPauajQGprFy6K333u/Desktop-Components?m=auto&node-id=8934-3539&t=jYzh5q7ZvTyiEnrU-1).

We should briefly discuss in triage whether it's appropriate to switch to px units in about:welcome as well. I think it should be - Firefox has used CSS pixel scaling for zoom for a long time. There isn't really another advantage in using em values, especially when your UI is based on a Figma spec with integer pixel font sizes.
Bug: "Show in Folder" button opens two Downloads folder instead of one in Manjaro Linux
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-10 18:10:15+00:00
Resolved: 2024-07-18 12:12:11+00:00

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

Steps to reproduce:

I single clicked the "Show in Folder" button on the Downloads mini window.


Actual results:

My file explorer (Nautilus) opened two windows in the Downloads folder.


Expected results:

The file explorer (Nautilus) should have opened only one windows in the Downloads folder.
Bug: In full-screen mode, hovering to reveal top toolbar causes jank from resizing the viewports of any tabs whose titles that you happen to hover (all of which resize to accomodate the space that the toolbar is briefly occupying)
Status: NEW
Priority: P3
Created: 2024-06-10 18:42:24+00:00
Resolved: 2024-06-19 12:46:06+00:00

tl;dr: it seems we've got an optimization to defer browser-viewport-resizes for background tabs, but it's not getting properly applied when you're in fullscreen mode (F11)

STR:
1. Open a Firefox window with 10 copies of `testcase 1 part A (expensive-to-resize)` in background tabs, and one copy of `testcase 1 part B (snappy to resize)` in foreground tab.
2. Try resizing your window. Note that the foreground tab is snappy to respond (updating its resize-count and redrawing its viewport-border in a responsive way)
3. Now hit F11 to fullscreen the window.
4. Hover/unhover the top part of your screen, to reveal/hide the top toolbar.  Compare the responsiveness to step 2.

ACTUAL RESULTS:
The viewport-resizes in step 4 (from hovering/unhovering the top of your screen) are much jankier than those in step 2.  My hand-wavy guess at an explanation is that we're deferring the viewport-resizes for background tabs in step 2, but we're handling them synchronously in step 4 (at the cost of responsiveness in the foreground tab).

I'm using Firefox Nightly 128.0a1 (2024-06-09) (64-bit) 

(Note: I'm spinning this off from bug 1528638 comment 5, for some jank that I can reproduce that I think matches what the user was describing there.)
Bug: There's no way to make new tabs default to the user-selected home page.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-11 00:14:29+00:00
Resolved: 2024-06-11 19:11:24+00:00

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

Steps to reproduce:

Tried to specify the home page as the default page for new tabs.


Actual results:

The only option is to show the Firefox home page. 


Expected results:

Just as you can select the home page as default for new windows, you should be able to select it as the default for a new tab. This is an expected option, present on every other browser I've tried.
Bug: Intermittent services/fxaccounts/tests/xpcshell/test_commands_closetab.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-06-11 01:55:08+00:00
Resolved: 2024-06-24 06:02:27+00:00

**Filed by:** tszentpeteri [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=461764723&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/RcWdLMlSRzmHKDASrPHOkQ/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/RcWdLMlSRzmHKDASrPHOkQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2024-06-10T23:06:06.344Z] 23:06:06     INFO -  TEST-START | services/fxaccounts/tests/xpcshell/test_commands_closetab.js
[task 2024-06-10T23:06:06.979Z] 23:06:06  WARNING -  TEST-UNEXPECTED-FAIL | services/fxaccounts/tests/xpcshell/test_commands_closetab.js | xpcshell return code: 0
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  TEST-INFO took 627ms
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  >>>>>>>
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  PID 5328 | *** You are running in chaos test mode. See ChaosMode.h. ***
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  PID 5328 | [Parent 5328, Main Thread] WARNING: Couldn't get the user appdata directory. Crash events may not be produced.: file /builds/worker/checkouts/gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2888
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  (xpcshell/head.js) | test run_next_test 0 pending (2)
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  running event loop
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  services/fxaccounts/tests/xpcshell/test_commands_closetab.js | Starting test_closetab_isDeviceCompatible
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  (xpcshell/head.js) | test test_closetab_isDeviceCompatible pending (2)
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  PID 5328 | 1718060766642	FirefoxAccounts	TRACE	CloseRemoteTab observer created
[task 2024-06-10T23:06:06.979Z] 23:06:06     INFO -  TEST-PASS | services/fxaccounts/tests/xpcshell/test_commands_closetab.js | test_closetab_isDeviceCompatible - [test_closetab_isDeviceCompatible : 50] true == true
```
Bug: Bookmarks do not sync correctly across devices.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-11 03:15:38+00:00
Resolved: 2024-11-18 14:49:28+00:00

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

Steps to reproduce:

Create bookmarks on one device. Use the sync function in the settings.


Actual results:

Firefox will not sync bookmarks correctly across multiple devices. Multiple of the same bookmarks will generate and have to be deleted. This is an everyday problem. I use the same account for all my devices. I only use Firefox on Windows computers. I never use the devices at the same time so they should have time to sync before the next session of using the browsers on other devices.


Expected results:

Bookmarks should be the same on all devices under the same account.