av9ash/GitBugs huggingface dataset:
Bug: [Experiment] The "Colorway Reminder" CFR message is NOT triggered if the "Try it" button from the "CFR_FIREFOX_VIEW" message was previously clicked
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-29 14:57:07+00:00
Resolved: 2022-12-06 10:47:30+00:00

**[Affected versions]:**
- Firefox Beta 108.0b7 - Build ID: 20221127190117

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.6
- ubuntu 20.04 x64

**[Prerequisites]:**
- Have a new Firefox profile with the "nimbus.debug" pref set to "true" in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to "about:studies?optin_slug=colorways-expiring-fx108&optin_branch=treatment-a&optin_collection=nimbus-preview".
3. Change the system date to 2 days in the future and restart the browser.
4. Open and close 3 tabs.
5. Click the "Try it" button from the "CFR_FIREFOX_VIEW" message.
6. Change the system time to 20th December 2022.
7. Restart the browser and navigate to a website (e.g. cats.com).
8. Observe the behavior.

**[Expected result]:**
- The "Colorway Reminder" CFR message is triggered.

**[Actual result]:**
- The "Colorway Reminder" CFR message is **NOT** triggered.

**[Additional Notes]:**
- This issue is not reproducible if the "CFR_FIREFOX_VIEW" message is dismissed instead of clicking the "Try it" button.
- Attached a screen recording of the issue.
Bug: "Nightly is damaged" message on first run after upgrade to macos 13.0.1, but works fine on second try
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-29 15:00:09+00:00
Resolved: 2023-01-03 16:07:20+00:00

I upgraded from macos 13.0 to 13.0.1 today. I'm on a 2021 16" Apple Silicon MBP.

After restarting, I observed the following weird sequence of events when trying to open the (whoops, apparently rather stale build!) Nightly 108.0a1 (2022-11-14) (64-bit):

1. clicked on the Nightly app icon in the deck, saw the little dot under the deck icon  appear indicating the app was starting, but no dock bouncing animation. Then the dot went away and Nightly didn't start. No error message.

2. clicked the deck Nightly app icon again, the deck icon was replaced with the broken app icon, Nightly failed to start, and I got an OS warning dialog: "Nightly is damaged or broken"

3. clicked the formerly-Nightly broken app icon in the deck a third time, and Nightly started normally, and the icon went back to its normal appearance.

After going through these steps once, Nightly is now starting normally.

I'm not sure how to diagnose further, but it appears the 13.0.1 Ventura update was a security fix for some libxml2 bugs[1], so maybe that's related? Let me know if there are any startup logs I could attach to help us understand what is going on with macos here.

[1] https://support.apple.com/en-us/HT213504
Bug: Convert session restore JSMs to esm
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-11-29 16:14:22+00:00
Resolved: 2022-12-07 12:26:50+00:00

It's just over a dozen JSMs:

```
browser/components/sessionstore/GlobalState.jsm
browser/components/sessionstore/SessionStore.jsm
browser/components/sessionstore/SessionCookies.jsm
browser/components/sessionstore/StartupPerformance.jsm
browser/components/sessionstore/SessionSaver.jsm
browser/components/sessionstore/TabState.jsm
browser/components/sessionstore/SessionWriter.jsm
browser/components/sessionstore/TabAttributes.jsm
browser/components/sessionstore/RunState.jsm
browser/components/sessionstore/TabStateCache.jsm
browser/components/sessionstore/TabStateFlusher.jsm
browser/components/sessionstore/SessionMigration.jsm
browser/components/sessionstore/RecentlyClosedTabsAndWindowsMenuUtils.jsm
browser/components/sessionstore/SessionFile.jsm
browser/components/sessionstore/SessionStartup.jsm
browser/components/sessionstore/ContentRestore.jsm
browser/components/sessionstore/ContentSessionStore.jsm
```
Bug: [Linux] Chromium not displayed in the Import Wizard despite being installed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-29 16:51:34+00:00
Resolved: 2022-12-14 03:59:46+00:00

**Found in**
* Firefox 108.0b7

**Affected versions**
*  Firefox 108.0b7

**Tested platforms**
* Affected platforms: Ubuntu 22.04
* Unaffected platforms: other OS (Windows 10, MacOS 13 etc.)

**Preconditions**
* Create the folder "distribution" in the Firefox installer folder, write the code below in a distribution.ini file and save it inside the folder "distribution" (/firefox/distribution/distribution.ini):

[Global]
id=mozilla-no-automigrate
version=1.0
about=QA test

[Preferences]
browser.migrate.automigrate.enabled=false
* Chromium is installed and closed
* Save bookmarks and create browsing history in Chromium

**Steps to reproduce**
1. Launch Firefox
2. Select to import bookmarks from another browser (from Library or Import bookmarks from Toolbar)

**Expected result**
* Chromium is not shown as an option in the Import Wizard.

**Actual result**
*  Chromium should as an option in the Import Wizard.

**Regression range**
* I wasn't able to find any corresponding regression range, but the issue is reproduceable in older builds from 2021.
Bug: Crash in [@ mozilla::ipc::IProtocol::ChannelSend | mozilla::layers::PWebRenderBridgeChild::SendSetDisplayList | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList]
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-11-29 17:34:49+00:00
Resolved: 2022-11-29 17:36:46+00:00

Crash report: https://crash-stats.mozilla.org/report/index/0d1e31c1-cf2f-4186-97d6-8371b0221129

MOZ_CRASH Reason: ```MOZ_CRASH(IPC message size is too large)```

Top 10 frames of crashing thread:
```
0  xul.dll  mozilla::ipc::IProtocol::ChannelSend  ipc/glue/ProtocolUtils.cpp:493
1  xul.dll  mozilla::layers::PWebRenderBridgeChild::SendSetDisplayList  ipc/ipdl/PWebRenderBridgeChild.cpp:311
2  xul.dll  mozilla::layers::WebRenderBridgeChild::EndTransaction  gfx/layers/wr/WebRenderBridgeChild.cpp:127
3  xul.dll  mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer  gfx/layers/wr/WebRenderLayerManager.cpp:458
4  xul.dll  mozilla::nsDisplayList::PaintRoot  layout/painting/nsDisplayList.cpp:2289
5  xul.dll  static nsLayoutUtils::PaintFrame  layout/base/nsLayoutUtils.cpp:3459
6  xul.dll  mozilla::PresShell::PaintInternal  layout/base/PresShell.cpp:6440
7  xul.dll  nsViewManager::ProcessPendingUpdatesPaint  view/nsViewManager.cpp:440
8  xul.dll  nsViewManager::ProcessPendingUpdatesForView  view/nsViewManager.cpp:375
9  xul.dll  nsViewManager::ProcessPendingUpdates  view/nsViewManager.cpp:948
```
Bug: tooltips are illegible in private-browsing (white text on pale yellow)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-29 17:42:46+00:00
Resolved: 2023-10-02 12:23:26+00:00

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

Steps to reproduce:

1. Go into private browsing mode.
2. Hover mouse over any element which has a "title" attribute, and which should show a tooltip.
3. Attempt to read the tooltip - but fail because its so low contrast.


Actual results:

The tooltip text is white, on a pale yellow background, which is nearly impossible to read. 
(In normal, non-private mode, it's black text on pale yellow)


Expected results:

The dark theme that Firefox uses in private mode should not invert the color of the tooltip text, OR it should also invert the background.
Bug: sessionrestore tests were accidentally disabled on Linux
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-11-29 17:56:50+00:00
Resolved: 2024-09-09 10:11:37+00:00

In bug 1776212, an annotation skipping sessionrestore mochitests under the condition `skip-if = os == 'linux' && !e10s` was incorrectly simplified to `os == 'linux'`, meaning that these tests are now unconditionally skipped on linux platforms. https://searchfox.org/mozilla-central/diff/5bf232d7af87f9840cd2d88ac2d957d367865492/browser/components/sessionstore/test/browser.ini#11

We should re-enable these tests on Linux and make sure to fix any tests which have started failing over the last 5 months.
Bug: [Downloads Panel] Regression? Flicker appears when hovering over an item during a download
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-29 18:42:37+00:00
Resolved: 2022-11-29 21:06:49+00:00

Nightly 109.0a1 (2022-11-29) (64-Bit)
macOS 12.6.1

1.) Download something
2.) Open the Downloads Panel Menu and hover over the item during the download

Actual: Flicker appears

Expected: Not to see a flicker.

I think this is a regression.

A screencast is attached.

Thanks for checking.
Bug: Drop the resize param from the image URL for spocs topsites
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-11-29 20:21:35+00:00
Resolved: 2022-11-30 16:13:12+00:00

The Pocket proxy server currently always uses the `resize=w96-h96` query param in the image URL, but this is not needed for SPOCS topsites and will make the image rendered mistakenly.
Bug: Download of .pdf ignores path requirement with website generated download
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-29 21:24:47+00:00
Resolved: 2023-01-20 16:16:26+00:00

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

Steps to reproduce:

1. Configure Firefox to always ask for for download directory and file name.
2. Go to any website for instance Citibank.com and download a charge card statement
3. It will just download. It will not bring up the dialog to choose a directory


Actual results:

.pdf got downloaded to default location (desktop) instead of where I wanted it to go as I did not get a dialogue to supply path or filename.


Expected results:

Dialogue should have appeared allowing me to choose destination folder and filename.
Bug: Home key sometimes goes to the end of the page instead of the top of the page
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-11-30 00:07:39+00:00
Resolved: 2022-12-05 22:53:49+00:00

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

Steps to reproduce:

On https://fr.wikipedia.org/wiki/Discussion_Wikip%C3%A9dia:Conventions_typographiques#Capitalisation_d'un_titre_compos%C3%A9_d'un_ou_plusieurs_pronoms_possessifs type various keys among PageUp, PageDown, Home and End.


Actual results:

The Home key goes to the end of the page, and the other keys behave as expected, except that at the end of the page, a first PageUp doesn't have any effect.


Expected results:

The Home key should go to the top of the page.

This happened for several minutes. But I can currently no longer reproduce this issue (after testing the arrow keys), while I did not reload the page.
Bug: No CFR ASRouter message impression is recorded when primary CTA is clicked
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-11-30 00:39:24+00:00
Resolved: 2022-12-02 22:05:36+00:00

When the primary action button in [this CFR message](https://searchfox.org/mozilla-central/source/browser/components/newtab/lib/OnboardingMessageProvider.jsm#85) is clicked, it result in switching to the Firefox View tab. No ASRouter message impression is recorded for the CFR, but one _is_ recorded for the Spotlight modal that appears at the start of the feature tour triggered when Firefox View is opened for the first time. If the user selects the secondary action button to dismiss the CFR (thus not opening the Firefox View tab), the CFR impression _is_ recorded.

Even if the Firefox View tour is completed before launching the CFR (so no Spotlight modal is shown in the Firefox View tab), and `browser.firefox-view.view-count` is reset to `0`, the CFR impression is still not recorded with the primary action.
Bug: Close multiple tabs incorrectly shown for Firefox View
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-30 13:31:32+00:00
Resolved: 2022-11-30 16:42:44+00:00

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

Steps to reproduce:

1. Open a new window
2. Click the "Firefox View" icon
3. Click the close X on the only open tab


Actual results:

Dialog opens stating "Confirm before closing multiple tabs".


Expected results:

Window should have closed without any dialog.
Bug: When choosing custom icons for top sites, the icon is not being displayed.
Status: NEW
Priority: --
Created: 2022-11-30 16:59:20+00:00
Resolved: 2022-12-06 13:53:10+00:00

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

Steps to reproduce:

Because my Firefox is set up to automatically delete the browsing history, favicons for pinned top sites are not being displayed. So instead I opted for editing the pinned sites by attaching a custom icon URL for each of them, which I find by going to the website`s media attachment and choosing an icon like "https://github.com/fluidicon.png", e.g. (this, BTW, also happens, when Firefox is set to not automatically delete the browsing history)


Actual results:

When editing the pinned top site and previewing the icon everything seems to be working as expected, but the moment I close the window, the icon disappears and the pinned top site is blank. The issue seems to stem form the fact, that in the about:newtab (and to the same extent about:home) HTML-File the custom URL is not embedded into the Icon-Wrapper-Div, so the attribute "style="background-image: url("")" is empty.


Expected results:

Upon editing the Div manually, i.e "style=background-image: url("https://github.com/fluidicon.png")", the icon is visible again. The custom URL should probably be embedded automatically into the relevant HTML.
Bug: Firefox will not honor prefs.js default download folder updated with user.js
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-30 17:43:56+00:00
Resolved: 2023-10-03 12:04:17+00:00

Steps to reproduce:

Begin with a fresh install of Firefox 102.5-107. Go to ~/mozilla/firefox/[random-ascii].default-default and create a new file user.js with just one line:
user_pref("browser.download.dir","/data_local/firefox_downloads");

Save and close the file. Start Firefox and go to about:preferences.


Actual results:

On about:preferences, the previous default downloads directory, /home/user/Downloads, is still observed. Viewing prefs.js shows the line from user.js has been correctly added by Firefox upon starting. Searching about:config for "browser.download.dir" also shows the updated path.


Expected results:

Everything happened correctly except that about:preferences did not update the browser download directory using prefs.js, rendering the change ineffective. Interestingly, if you manually configure the download directory in about:preferences to be any other folder, then restart Firefox, the changes from user.js will start taking effect. However, this defeats the purpose of creating the user.js file to automate the process.
Bug: Pocket newtab topsite drag n drop can cause replaced topsites to appear and disappear.
Status: NEW
Priority: P1
Created: 2022-11-30 18:40:38+00:00
Resolved: 2023-06-06 21:56:57+00:00

If you drag a topsite to the left or right of a Pocket sponsored topsite, you can see topsites changing.

This is because it's replacing the dragged topsite with the replaced topsite and not the left/right most topsite.
Bug: Accessibility issue : Voice Over + Firefox : Cursor is not able move out of Pie Chart by clicking CTRL + OPT + Left or Right Arrows
Status: NEW
Priority: --
Created: 2022-11-30 21:17:00+00:00
Resolved: 2023-01-23 16:10:26+00:00

Steps to reproduce:

Live demo with steps to reproduce

Go to Highcharts accessible pie demo page
https://www.highcharts.com/demo/accessible-pie

Run voice over on mac and step over into reading the pie chart.


HighCharts GitHub Issue Tracker Link https://github.com/highcharts/highcharts/issues/17864


Actual results:

Once user enters into pie chart reading, user is not able to move to the next element by clicking ctrl + option + (left/right) arrow buttons in Firefox.



Expected results:

User should able to move forward or backward by clicking ctrl + option  + arrow(left/right) in and out of pie chart reading.

This issue does not exist using Voice Over in Chrome.
Bug: 107.0.1 regression: Fx becomes unresponsive for multiple seconds when switching to it from a vmware workstation 16.2.4 window
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-11-30 22:30:41+00:00
Resolved: 2023-05-17 19:24:29+00:00

Win11 22H2 (22621.819, 22621.900)

Bug 1798098 seems related, possibly the cause.

After spending some time (30 secs seems enough to repro) in vmware, switch focus with a mouse to a Fx window. Fx remains unresponsive for several seconds. Reverting to 107.0.0 resolved this problem.
Bug: Long tables are rendered wrong
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-12-01 07:59:40+00:00
Resolved: 2022-12-02 13:41:48+00:00

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

Steps to reproduce:

Read a long table


Actual results:

In some old version you rendered tables OK. MS-IE does not and this is a very old bug. It is still in Edge.
Somehow you have - very myseriously - inherited that bug - how has that happened?

The bug: 
Long tables are rendered wrong - in a very narrow column. the limit for 'long' is between 200 and 270, mayhap 256?

Example: 
http://danbbs.dk/%7Estst/slaegt_adelsvaaben/0_adelsvaaben.htm#R
  There is one table pr letter in the alphabeth, 
  ony letter S goes wrong - being the longest. 
  Alle tables are the same html, created in one run with a program.

Classification: Severe. Permanent.
Bug: Firefox  accepts <img> tag accepting loading non-image links, leaking IPs to the links without users click on
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-12-01 12:23:07+00:00
Resolved: 2024-05-30 18:02:52+00:00

Steps to reproduce:

(1) Go to https://iplogger.org/, create a tracking IP link, for example: https://iplogger.com/2bNCN4 and the dashboard link to view tracked IPs, for example: https://iplogger.org/logger/0YWY3vyjV8Cn/.

(2) Create a .html file with one line in it: 

<img src="the tracking IP link />, for example: <img src="https://iplogger.com/2bNCN4" />

(3) I tested on macOS Ventura 13.0.1 on a MacBook Air with M1 chip laptop: open Firefox version 107.0.1 (64-bit), open the .html file above, don't click on anything.

(4) Go to the dashboard link to view tracked IPs, for example: https://iplogger.org/logger/0YWY3vyjV8Cn/, you will see your visit is tracked as the <img> tag loads the link although this is a non-image link.
Bug: built-in pdf viewer ignores download-directory config and keeps creating Download
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-12-01 15:44:49+00:00
Resolved: 2023-01-20 16:18:50+00:00

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

Steps to reproduce:

* in firefox settings change the download directory to somewhere else than default (my linux home in my case)
* open a pdf from the web
* when it's opened click on the download button
* file-save dialog opens, save the file


Actual results:

while i can navigate to wherever i wanted to save the file, it's extremely annoying that the pdf viewer (internal pdf.js?) actually created the "Downloads" directory in my home, irrespective of my wish for something else.


Expected results:

no default directory "Downloads" should be created since the download directory in firefox config is clearly present, writable, and exists.
Bug: Add context to the "Learn more" links in about:preferences
Status: NEW
Priority: P3
Created: 2022-12-01 16:18:51+00:00
Resolved: 2023-11-07 20:58:41+00:00

I'm not sure the best way to track this so I'll file a bug for now.

Based on [my previous paraphrasing/summary on Bug 1770447](https://bugzilla.mozilla.org/show_bug.cgi?id=1770447#c2), the "Learn more" links in about:preferences will probably need new strings to help better convey context. Since the `moz-support-link` reusable component is driven by Fluent anyway, the component shouldn't be concerned with the actual content of the Fluent string. In other words, this appears to be primarily a content and UX/UI design problem with engineering needing to update Fluent IDs (if that's the solution we're going with, there may be other ways to fix the context issue of these links).
Bug: Attempting to pin to taskbar crashes Nightly on MacOS
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-12-01 21:40:11+00:00
Resolved: 2022-12-02 21:38:13+00:00

Stack trace:
```
Assertion failure: aAppPath != aAppToReplacePath || !aAppPath.IsEmpty(), at /Users/emcminn/mozilla-unified/widget/cocoa/nsMacDockSupport.mm:310
#01: nsMacDockSupport::EnsureAppIsPinnedToDock(nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, bool*)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x486c3bf]
#02: NS_InvokeByIndex[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x35344e]
#03: CallMethodHelper::Call()[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0xe4055c]
#04: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0xe40159]
#05: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0xe41ff4]
#06: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x65f79f1]
#07: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x65f7271]
#08: Interpret(JSContext*, js::RunState&)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x65edc16]
#09: js::RunScript(JSContext*, js::RunState&)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x65e4cab]
#10: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x65f71a6]
#11: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x65f8653]
#12: js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x69455b2]
#13: js::jit::InterpretResume(JSContext*, JS::Handle<JSObject*>, JS::Value*, JS::MutableHandle<JS::Value>)[/Users/emcminn/mozilla-unified/obj-backend/toolkit/library/build/XUL +0x7017cd3]
```
Bug: Checkbox labels for the selection page flex to fill the whole wizard space rather than shrinkwrapping around the label text
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-12-01 21:52:01+00:00
Resolved: 2023-03-08 10:21:28+00:00

STR:

1. Open the new migration wizard, either in the built-in dialog or in storybook
2. Hover your mouse over one of the labels for the checkboxes in the selector, but past the end of the text label

ER:

The checkbox should not get the hover state applied to it when the mouse is not over top of the checkbox or label.

AR:

The checkbox gets the hover state even farrrrrr after the end of the label. See screenshot.
Bug: MacOS monterey firefox bookmark menu dimensions small
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-12-02 00:38:11+00:00
Resolved: 2023-01-05 03:07:54+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36

Steps to reproduce:

Firefox 102.5.0esr (64b)

Opened bookmark library though the hamburger icon, and attempted to create a bookmark by right clicking on the folder i wanted the bookmark in.  The menu that appears cuts off the save button but is an incorrect dimensions which appears to inherit from 'add bookmark' found by right clicking in a browers page



Actual results:

box dimensions are small


Expected results:

box dimensions should be larger