av9ash/GitBugs huggingface dataset:
Bug: Fails to build against icu74
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-27 11:25:35+00:00
Resolved: 2024-06-27 11:26:27+00:00

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

Steps to reproduce:

ICU has been upgraded from version 73.2 to 74.2 on nixpkgs, which is when Firefox 127.0.1 started failing to build.


Actual results:

In file included from Unified_cpp_intl_lwbrk0.cpp:2:
/build/firefox-127.0.1/intl/lwbrk/LineBreaker.cpp:453:17: error: static assertion failed due to requirement 'U_LB_COUNT == mozilla::ArrayLength(sUnicodeLineBreakToClass)': Gecko vs ICU LineBreak class mismatch
  453 |   static_assert(U_LB_COUNT == mozilla::ArrayLength(sUnicodeLineBreakToClass),
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/build/firefox-127.0.1/intl/lwbrk/LineBreaker.cpp:453:28: note: expression evaluates to '48 == 43'
  453 |   static_assert(U_LB_COUNT == mozilla::ArrayLength(sUnicodeLineBreakToClass),
      |                 ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


https://cache.nixos.org/log/p86hjjg8x8qy86mnkdy6m23gmycni2la-firefox-unwrapped-127.0.1.drv


Expected results:

Ideally firefox would be compatible with icu 74.
Bug: Memory leak caused by opening and closing a panel in sidebar
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2024-06-27 14:47:03+00:00
Resolved: 2024-09-16 19:06:08+00:00

**Steps to Reproduce**
1. Open the Browser Toolbox, and switch to the "Memory" tab.
2. Take a memory snapshot.
3. Repeatedly open and close tools within the sidebar.
4. Take another memory snapshot.
5. Repeat steps 4-5 as needed.

**Expected Result**
Memory usage is stable.

**Actual Result**
Memory usage steadily increases.

I am seeing about 1-3 MB of additional usage per open/close cycle on Mac OS X, regardless of the `sidebar.revamp` pref.
Bug: [Experiment] The UI elements of the Cookie Banner Reduction CFR message are wrongly displayed for RTL builds
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-06-27 16:01:55+00:00
Resolved: 2024-07-24 14:49:24+00:00

**[Affected versions]:**
- Firefox Beta 128.0b8 - Build ID: 20240626091446

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.4
- Linux Ubuntu 20.04 x64

**[Prerequisites]:**
- Have a Firefox RTL build installed (ar, he, fa, etc).
- Have the following pref set:
`nimbus.debug` = `true`

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Copy and paste the following link in order to force enroll in the “CBB ROW Hold-back with Promo” experiment: `about:studies?optin_slug=cbb-row-hold-back-with-promo&optin_branch=treatment-a&optin_collection=nimbus-preview`
3. Restart the browser. 
4. Open a new Private Window.
5. Navigate to a website that contains a cookie banner. (e.g. bloomberg.com, cnn.com)
6. Observe the CFR message.

**[Expected result]:**
- The elements of the CFR message are correctly displayed respecting the RTL rules.

**[Actual result]:**
- The message’s arrow points to the Address Bar instead of being anchored to the "Tracking Protections" button.
- The X button, cookie icon, link, and text from the message's content are displayed in the same way as on the LTR builds.
- The X button overlaps part of the text from the message’s content.

**[Notes]:**
- Attached is a screenshot of the issue on 3 RTL builds (ar, he, fa, etc).
- This issue is probably reproducible with other RTL builds.
Bug: [Skylight] make inline CTR numbers cover the entire Infobar dashboard length
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-27 18:17:40+00:00
Resolved: 2024-07-03 14:29:21+00:00

Similar to Bug 1904389, handle the infobar dashboards so that inline CTR values show the correct value over the entire dashboard length.

Steps to take:
- Fork the infobar dashboard and update the code to point to it
- Make a similar CTR/impressions element (as seen in Bug 1904389) and add it to the forked dashboard
- Update the code to pull its data from the new summary element
- Update the code to display inline CTR data instead of showing "Dashboard"
- Add/update tests as necessary
Bug: UX updates for closing tabs remotely feature
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-06-27 18:57:04+00:00
Resolved: 2024-07-25 01:40:14+00:00

Based on the feedback from design, there are a few tweak we'll need to do around the closing tabs remotely feature.

Feedback so far:
1. Hover background-color state of close and undo button should match the hover of the tab buttons
2. Alignment of close buttons should match with chevron of inactive tabs
3. ~~Weight of undo icon is too heavy compared to close icon~~
   - Replace the undo as an icon and make it a text button
4. Close button is not square when hovered/clicked
Bug: Increase update time when updating Firefox while a DLP request is in progress or while the warning dialog is displayed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-28 08:15:25+00:00
Resolved: 2024-07-05 12:42:01+00:00

**Found in**
* 129.0a1 (2024-06-25)


**Affected versions**
* 129.0a1 (2024-06-25)

	


**Tested platforms**
* Affected platforms: Windows 10x64, Windows 11
* Unaffected platforms: macOS 13, Ubuntu

**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
* run the DLP agent in CMD using: .\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10


**Steps to reproduce**
1. Download a previous nightly build.
2. Paste "warning text" inside Wikipedia page and restart to update Firefox while the scan is in progress or when the warning dialog is displayed.

**Expected result** 
* Firefox is restarted and updated almost instantly.

**Actual result**
* Firefox is restarted and updated only after ~1min due to Firefox processes not being closed.



**Regression range**
* Not a regression. New feature.

**Additional notes**
* Attached a screen recording.
* This also reproduces with Scan in progress dialog and does not reproduce with blocked dialog.
* This also reproduces when updating Firefox from the App Menu notification, but no visual indicator is displayed (no About Firefox window), but the update performs successfully.
* This may be a duplicate of bug 1901197, please close it if necessary.
Bug: Entering a search/url into urlbar in `about:firefoxview` opens new tab, but doesn't clear urlbar when switching back to `about:firefoxview` tab
Status: NEW
Priority: P3
Created: 2024-06-28 09:49:18+00:00
Resolved: 2024-07-12 15:52:53+00:00

STR:

1. go to "Firefox View" tab
2. enter "https://example.com", press return and see new tab opening example.com
3. go back to "Firefox View" tab
4. "https://example.com" url still in url bar

Expected result: URL bar back to clean state (also reachable when pressing Esc)

Same happens when entering search terms.
Bug: When opening multiple consecutive new tabs, preloaded new tab content is flickering and tab animation is not always smooth
Status: NEW
Priority: P3
Created: 2024-06-28 15:21:28+00:00
Resolved: 2024-07-08 08:53:27+00:00

This is a follow-up to Bug 1893568.
Let me summarize what's up:

I landed bug 1848715, that among various things has removed code that was [setting the selection to 0,0 in the urlbar input field in _adjustFocusAfterTabSwitch](https://searchfox.org/mozilla-central/rev/6b17ef1f53b0bc68a0d746599c01ad8723c80880/browser/components/tabbrowser/content/tabbrowser.js#1546,1551), now we do it only if necessary.
As a consequence the new tab animation started being skipped every other time.

From my researches I found that we [set the fadein attribute on the tab in a RAF callback](https://searchfox.org/mozilla-central/rev/6b17ef1f53b0bc68a0d746599c01ad8723c80880/browser/components/tabbrowser/content/tabbrowser.js#2883) (see also Bug 850163), and that is supposed to kick-off the tab animation. When the bug happened we were setting "fadein" but the animation didn't start. Since we're ideally doing less work in _adjustFocusAfterTabSwitch, I supposed RAF may now be happening sooner? Maybe too early for the attribute to activate the animation (but why?).
Without an animation, the transitionend even is not received, and we [rely on it to call _handleNewTab](https://searchfox.org/mozilla-central/rev/6b17ef1f53b0bc68a0d746599c01ad8723c80880/browser/components/tabbrowser/content/tabs.js#214), and as a consequence we don't call [NewTabPagePreloading.maybeCreatePreloadedBrowser](https://searchfox.org/mozilla-central/rev/6b17ef1f53b0bc68a0d746599c01ad8723c80880/browser/components/tabbrowser/content/tabs.js#2069) that is what causes us to alternatively not use preloaded content.

The patch landed in Bug 1893568 delayed by a second RAF (setTimeout(0) was also fine) the attribute setting when using preloaded content, and that allowed the transition to happen consistently, and `this._createBrowserForTab` now returns true for `usingPReloadedContent` every time.

Though, the new tab is still flickering, and sometimes the animation is not super smooth.

Unfortunately I'm unable to move further, it would be great if someone from layout (ni Emilio for now) may evaluate why setting the attribute earlier was not kicking off the transition, and whether there's a better way than RAF to do it at the right time.

mconley could maybe help understanding the preloaded new tab flicker, as he's more comfortable with async tab switching.
Bug: New-tab background is partially white, with dark color-scheme and RDM
Status: NEW
Priority: P3
Created: 2024-06-28 15:36:10+00:00
Resolved: 2024-08-23 19:25:40+00:00

(Not sure if this is a graphics bug, a RDM bug, a new-tab bug, or something else. It seems to have regressed from a new-tab change, but it's possible that just revealed a preexisting bug/rough-edge.)

STR:
1. Set "website appearance" to "dark" in Firefox Preferences
2. Open a new-tab.
3. Activate Responsive Design Mode (Ctrl+Shift+M)
4. Make the RDM viewport short-and-wide.

ACTUAL RESULTS:
The bottom & right edges of the new-tab page end up with a white background, inside of the RDM viewport.

EXPECTED RESULTS:
No such white areas.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c400464776b40839926cc31272254e4e93ea8dc8&tochange=17135ba9a5bdc8b973501d571b5bfca4887c82f8

--> regression from bug 1881588
Bug: Clicking the "Notifications settings" option in the set to default guidance toast notification has no effect
Status: NEW
Priority: P3
Created: 2024-06-28 16:58:14+00:00
Resolved: 2024-07-02 19:27:44+00:00

This issue was flagged by QA while testing an upcoming experiment related to showing the set to default guidance toast notification on Windows. 
When a use clicks the "..." menu, then "Notification settings", they are returned to the current Firefox Window with no other visible effect (see attached screen recording).
Bug: Content displayed on mouseover is now impossible to capture with Screenshots
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-29 06:11:18+00:00
Resolved: 2024-07-23 14:51:20+00:00

This was reported as a issue on [connect.mozilla.org](https://connect.mozilla.org/t5/discussions/screenshot-after-127-0-upgrade/td-p/60568) where a popup details for a data point in a graph which get  revealed on hover, disappear once the Screenshots UI is opened and the mouse moves within it. The original issue was observed in paid, browser-based software but this interaction is common for canvas-based graphs and charts.

Similar STR:
- Open https://www.chartjs.org/docs/latest/samples/tooltip/interactions.html
- Hover over one of the data points to reveal the little "tooltip"
- Use the ctrl+shift+s tooltip to attempt to capture what is on-screen in a screenshot

Expected results:
- The tooltip remains visible and can be capture in a screenshot

Actual results: 
- The tooltip immediately disappears as the Screenshots UI opens.
Bug: Right-clicking on a tab and selecting "New Tab" doesn't focus the address bar if new tab is blank page (like it does when clicking the "+" button)..
Status: NEW
Priority: P3
Created: 2024-06-30 01:26:29+00:00
Resolved: 2025-01-21 00:45:50+00:00

Steps to reproduce:

When you right-click on a tab and select "New Tab", the cursor does Not show up in the address/search bar (like it does when you click the "+" to open a new tab).. 


Actual results:

When you right-click on a tab and select "New Tab", the cursor does Not show up in the address/search bar (like it does when you click the "+" to open a new tab).. 


Expected results:

When the new tab is created/opened, the cursor should be IN the address/search bar.
Bug: Firefox View opens the account login site when identity.fxaccounts.enabled is set to false
Status: RESOLVED
Priority: P3
Resolution: INCOMPLETE
Created: 2024-07-01 02:30:10+00:00
Resolved: 2025-03-03 12:30:16+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Bug: Hard to see the close button of SearchModeSwitcher in dark mode
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-01 05:03:56+00:00
Resolved: 2024-11-20 09:10:13+00:00

I found this while reviewing bug 1903145, the close button is hard to see when in the dark mode.
Please check the attachment.
Bug: Browser opens tabs for downloaded file in endless loop
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-01 08:44:12+00:00
Resolved: 2024-07-04 12:06:52+00:00

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

Steps to reproduce:

* open about:config, set pdfjs.disabled to True
* set external program for application/pdf to evince (or whatever)
* delete /usr/bin/evince (I managed to do this by reinstalling my OS but keeping $HOME)
* open a website with a PDF link
* click on the link


Actual results:

Firefox downloads the PDF to /tmp/mozilla_*/, then opens infinitely many empty tabs (until I manage to hit ^W quickly enough)


Expected results:

Firefox notices that the program doesn't exist and asks me what to do instead.
Bug: ncode.syosetu.com - Opening a PDF in Firefox shows Japanese vertical punctuation errors
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-07-01 09:35:47+00:00
Resolved: 2024-11-25 16:29:55+00:00

**Environment:**
Operating system: All Desktop
Firefox version: Firefox 127.0/Firefox 129.0a1

**Steps to reproduce:**
1. Open a downloaded PDF file from the site (provided in attachment)
2. Observe the Japanese punctuation


**Expected Behavior:**
Japanese punctuation is rendered as expected

**Actual Behavior:**
Items are misaligned

**Notes:**
- Reproduces regardless of the status of ETP
- Reproduces in Firefox Nightly, Firefox Release
- Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/138659
Bug: getpocket blue button redirects to the English website no matter what
Status: UNCONFIRMED
Priority: --
Created: 2024-07-01 10:39:02+00:00
Resolved: 2024-07-23 12:09:03+00:00

Steps to reproduce:

I pressed the Pocket button in Firefox (near the address bar), and then on the blue button. It redirected me to their website, but..


Actual results:

When I pressed the blue button, it redirected me to the English website https://getpocket.com/saves?utm_source=firefox_pocket_save_button.


Expected results:

It should have redirected me to the https://getpocket.com/de/saves?utm_source=firefox_pocket_save_button instead because I originally chose the German language at the bottom of the website.
Bug: Cannot delete entries in search field
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-01 11:19:19+00:00
Resolved: 2024-07-01 12:02:32+00:00

Can't delete entries in the search field history any more...a few versions now.
Have several entries in your search bar history. Click on an empty bar, use the down key and select one. Delete with Del or Shift-Del. Mark the text in the search field and delete it. Use down arrow on blank field: "deleted" entry is still there.
Now, don't tell me you "improved" something...
Bug: The user cannot selece the "Use custom settings for history" drop-down option from the browser preferences with keyboard navigation
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-01 11:32:12+00:00
Resolved: 2024-07-01 13:45:31+00:00

**Note**
* The user cannot choose the History dropdown option to "Use custom settings for history" using keyboard navigation.

**Found in**
* Nightly v129.0a1

**Affected versions**
* Nightly v129.0a1

**Tested platforms**
* Affected platforms: Windows 10, Ubuntu 22
* Unaffected platforms: MacOS 11

**Steps to reproduce**
Precondition: Use keyboard navigation!
1. Launch the browser.
2. Open browser preferences
3. Search for "history"
4. Tab down to the History section and select the "Nightly/Firefox will <<Remember history>>"
5.1 Press the Alt+Down hotkey to open the drop-down and attempt to select the "Use custom settings for history" option.
5.2 Press the Down arrow to select the 3rd option: "Use custom settings for history"

**Expected result**
* The user can select the "Use custom settings for history" option.

**Actual result**
* When selecting the 2nd option ("Never remember history"), a dialog to restart the browser is displayed, blocking the user from selecting the 3rd option ("Use custom settings for history").

**Regression range**
* Unknown.

**Additional notes**
* This issue occurs with and without a screen reader active.
* This issue does not occur while using mouse navigation.
* The dialog to restart should not trigger unless the user moved the focus away from the drop-down; Selection should only happen when moving the focus away from the combo-box.
* On Linux, the issue still reproduces if the user taps the DownArrow to select, but does NOT reproduce if the user manually opens the drop-down using the ALT+DOWN hotkey.
* This issue does NOT reproduce on MacOS since the drop-downs are opened by tapping DownArrow.
Bug: Repeated error 400 on admin.google.com and other Google properties
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-01 12:11:18+00:00
Resolved: 2024-07-01 12:28:58+00:00

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

Steps to reproduce:

I am logged in to a Google Workspace account in a Container Tab in Firefox. I want to change settings in the workspace, so I open https://admin.google.com/.


Actual results:

More often than not, but not quite always, when I go to https://admin.google.com/, I will be told after a few redirects that "The server cannot process the request because it is malformed. It should not be retried. That’s all we know." (HTTP Error 400)

Clearing cookies or using a private window works, but forces me to re-authenticate, which for some accounts with heightened security settings can be quite annoying.

I tried allowlisting all of google.com in uBlock Origin and tried disabling the Enhanced Tracking Protection, neither of which made a difference. Nothing seems obviously wrong with the request, nor are they particularly big (example request headers have 3.925 kB per Network tab). The request is sending several cookies that contain auth info across google properties, but none of the cookies is very long either, and they don't seem obviously corrupted.


Expected results:

The Google Workspace Admin Console should load.
Bug: [Experiment][Treatment B] The default browser OS settings page is triggered after the “Open my links with Firefox” button from the “Fox Doodle” spotlight is clicked
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-01 12:58:07+00:00
Resolved: 2024-07-02 11:09:12+00:00

**[Affected versions]:**
- Firefox build version: Firefox Beta 128.0b9 (Release channel), Build ID: 20240628091536

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

**[Prerequisites]:**
- Have the Firefox build installed on your computer.
- Firefox is not set as default.
- Have the [“times.json”](https://drive.google.com/file/d/1hSkWQWKA2rMq51NWtnB9kKLqNFxv5nTM/view?usp=sharing) file and the [“user.js”](https://drive.google.com/file/d/13bWqiIUWcdsFWUCO6UvAyCsfpMErW2hp/view?usp=sharing) file downloaded on your computer.


**[Steps to reproduce]:**
1. Create a new Firefox profile but do not open it.
2. Add the “times.json” file and “user.js” file to the profile folder.
3. Open the Firefox profile.
4. Click the “Open my links with Firefox” button from the “Fox Doodle” spotlight.
5. Observe the behavior.

**[Expected result]:**
- Firefox is set as default and the default browser OS settings page is not triggered.

**[Actual result]:**
- The default browser OS settings page is triggered after the button is clicked.

**[Notes]:**
- According to the [documentation](https://docs.google.com/document/d/1dY6smuMFfT_cf05vtUe4MaSeHvTmy88DydrGhtLLvLY/edit#heading=h.ocbey2venhyn) of the experiment for the Treatment B, the branch configuration should be 1-click only, meaning that the Firefox should be set as the default and the OS settings page should not be displayed after the primary button of the Fox Doodle spotlight is clicked.
- Attaching a screen recording of the issue.
Bug: The Setup Type screen from the installer flow is not read correctly by NVDA
Status: NEW
Priority: --
Created: 2024-07-01 13:21:05+00:00
Resolved: 2024-07-15 18:17:08+00:00

**Note**
* When the user launches the Firefox installer while using a Screen Reader and reaches the "Setup Type" screen, he will notice that the Screen Reader reads the text that is associated to the radio buttons automatically without mentioning the link to their corresponding radio button. Furthermore, when selecting either of the radio buttons, the associated text is not read along with the radio button name.

**Found in**
* Nightly v129.0a1

**Affected versions**
* Nightly v129.0a1

**Tested platforms**
* Affected platforms: Windows + NVDA
* Unaffected platforms: MacOS, Ubuntu (the installer is Windows-only)

**Steps to reproduce**
Precondition: Enable NVDA; Use keyboard navigation.
1. Launch the firefox installer.
Ex: [LINK](https://archive.mozilla.org/pub/firefox/nightly/2024/07/2024-07-01-09-45-48-mozilla-central/firefox-129.0a1.en-US.win64.installer.exe)
2. Select Next.
3. Observe how NVDA presents the screen.
**Expected result**
* NVDA reads the whole screen information, including the radio button names in association with their respective information.
**Actual result**
* NVDA does not read the radio button names in association with their respective information.
4. Navigate between the two radio buttons.
**Expected result**
* NVDA reads the radio button names and not the associated information.
**Actual result**
* NVDA reads the radio button names, but not their associated information.

**Regression range**
* Unknown.
Bug: Entire screen flashes white when find in page fails
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-01 18:16:39+00:00
Resolved: 2024-07-01 18:39:27+00:00

Steps to reproduce on MacOS:
1. Go to https://example.com/
2. Hit command-f to bring up the find in page UI.
3. Type "ex". Everything is fine.
4. With the dialogue still open, type "p". The entire screen (not just the Firefox window) briefly flashes white.

I don't know if this is intentional or not but it is very distracting.

This is on the first 129.0a1 (2024-07-01) Nightly. It was also happening on the prior Nightly, I think (the second one of June 30).