av9ash/GitBugs huggingface dataset:
Bug: whenever i use firefox i have a typing line on anything like i can delete it or type something
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-01 17:21:35+00:00
Resolved: 2023-04-29 20:10:03+00:00

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

Steps to reproduce:

i clicked on something and a typing line appeared but i cant do anything with it


Actual results:

i was on the homepage and i clicked on something and the line appeared


Expected results:

nothing
Bug: [Experiment] Re-launch Import Bookmarks Experiments: New & Existing Users Copy Optimization
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-03-01 18:46:23+00:00
Resolved: 2023-03-02 17:15:25+00:00

The control group of the original experiment was failing schema validation and causing low enrolment rates. We're relaunching this experiment with the passing control group schema validation.

+++ This bug was initially created as a clone of Bug #1804084 +++

"To increase QCDOU, the Firefox Velocity Team has experimented with various Emotive Onboarding experiences targeted towards infrequent, casual, and regular Firefox users. We ran a previous experiment which targeted Infrequent Firefox Users (0-6 Days of Use) with the call to action of Importing Bookmarks from a different browser. We saw an increase in Days Of Use in the experiment and are in the process of running another experiment and rollout it out in Fx107."

This specific follow-up experiments explores updated copy with the original image assets for new and existing user segments. We'll likely want to use the `import-spotlights` message group to ensure these messages don't show within 56 days of another import bookmarks spotlight.

This experiment is en-* only.

[Jira Ticket](https://mozilla-hub.atlassian.net/browse/FXE-87)
[Spec](https://docs.google.com/document/d/1vzFn2k13YwzH-rw8pu0ie4d6u9RnBu6-hRgxAxhZReU/edit#)
Bug: Status bar not aligned correctly to the right
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-01 19:45:39+00:00
Resolved: 2023-04-14 09:11:32+00:00

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

Steps to reproduce:

If the cursor is at the bottom left of the window causing the Status bar move to the right while a page is loading, the Status bar is not aligned to the right leaving an empty space.

Mozregression returned:
Bug 1789892 - Simplify statuspanel a bit. r=dao

I'm a bit baffled about bug 1789877. My best theory so far is that we're
inserting the element a bit deeper in the DOM and that causes us to
reflow slightly more stuff when tab-switching, but...

In any case while going through the code the status panel can be
simplified a bit now, so do that.

Differential Revision: https://phabricator.services.mozilla.com/D156876

pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b84775bfccf2243f664b1c15ca987a05c54a95e2&tochange=6fbacc7bb20a65608b74e3ea09cb71af0439cb07


Actual results:

Status bar not aligned correctly


Expected results:

Status bar aligned correctly
Bug: Crash in [@ alloc::string::String::truncate]
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-03-01 19:54:38+00:00
Resolved: 2023-03-02 18:08:13+00:00

Crash report: https://crash-stats.mozilla.org/report/index/a570ac60-3856-4fa6-b6c6-f80b70230301

MOZ_CRASH Reason: ```assertion failed: self.is_char_boundary(new_len)```

Top 10 frames of crashing thread:
```
0  xul.dll  MOZ_Crash  mfbt/Assertions.h:261
0  xul.dll  RustMozCrash  mozglue/static/rust/wrappers.cpp:17
1  xul.dll  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:91
2  xul.dll  core::ops::function::Fn::call<void   /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/ops/function.rs:337
3  xul.dll  alloc::boxed::impl$47::call  library/alloc/src/boxed.rs:2032
3  xul.dll  std::panicking::rust_panic_with_hook  library/std/src/panicking.rs:692
4  xul.dll  std::panicking::begin_panic_handler::closure$0  library/std/src/panicking.rs:577
5  xul.dll  std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0, never$>  library/std/src/sys_common/backtrace.rs:137
6  xul.dll  std::panicking::begin_panic_handler  library/std/src/panicking.rs:575
7  xul.dll  core::panicking::panic_fmt  library/core/src/panicking.rs:64
```
Bug: Dragging and dropping the identity box to the desktop to create a .url shortcut is broken (creates .url.download instead of .url)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-01 21:59:27+00:00
Resolved: 2023-03-31 17:00:46+00:00

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

Steps to reproduce:

Mouse right click on the padlock symbol and release the mouse button on the Windows Explorer file area. 


Actual results:

Firefox 112.0a1 Build-ID 20230301093735: 
A shortcut file was created, but instead of type ".url" now as "url.download".
Windows can't work with the type ".download".


Expected results:

Create a shortcut file of type ".url" like in the version before. 
Windows can open the shortcut in Firefox Nightly (my standard browser) again.
Bug: Bookmark Toolbar icons will not dock to the left
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-02 01:09:33+00:00
Resolved: 2023-03-13 14:37:41+00:00

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

Steps to reproduce:

Firefox performed an auto-update.  03/01/2023


Actual results:

Bookmark Toolbar icons will not dock flush to the left.  They are horizontally offset to the first third of the screen, floating as if they were spaced over using the 'TAB key' in a word processing program.


Expected results:

They should be flush against the left side of the browser window.
Bug: Always private mode stores website data and writes to disk
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-02 09:35:11+00:00
Resolved: 2023-10-30 19:14:32+00:00

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

Steps to reproduce:

Hi, I use current firefox 110.01 on a macbook.

It is configured to always use private mode.

I noticed that some sites seem to be able to break out of private mode.




Actual results:

It shows few sites in the "cookies and site data"  -> "manage data" dialog.
They have 0 cookies and few kilobytes of storage.

This data survives a browser restart, despite the browser is configured to always use private mode.

There is also data written to the profile:

.../storage/default/https+++www.youtube.com^privateBrowsingId=1&partitionKey=%28https%2Cgelachtwird.net%29

I had some exchange with a ff developer before and it was guessed this relates to cookie isolation. I use the second cookie option from the top, i.e. "cross-site tracking cookies, and isolate other cross site cookies"




Expected results:

Data is deleted when browser is closed, because of always private mode.
Bug: Contexct menu item (open link in new tab) cannot be selected
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-02 11:41:22+00:00
Resolved: 2023-03-02 13:47:21+00:00

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

Steps to reproduce:

Firefox is running as snap in Ubuntu 22.04.2 LTS.
I got to a web site, e.g. Youtube.com in this example, then right-click into a video item for opening it in a new tab.


Actual results:

If the conect menu is touching the upper screen border then the most top item (open link in new tab) cannot be selected.


Expected results:

The menu item should be able to get selected independently of the menu position on screen.
Bug: Firefox uses wrong language in Google searches
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-02 12:16:47+00:00
Resolved: 2023-03-02 14:05:03+00:00

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

Steps to reproduce:

I live in Belgium, and speak Dutch.
My Firefox language is set to Dutch.  Everything is shown in Dutch.
So far so good.

When I launch a new Google search query through the address bar, all results and google.com are shown in German.
This is not correct.  Google is using the wrong language.


Actual results:

Google.com incorrectly returned German result.


Expected results:

Google.com should return Dutch results.
Bug: Bookmarks in toolbar are not shown anymore after the system returns from Sleep
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2023-03-02 17:14:24+00:00
Resolved: 2023-12-03 10:55:49+00:00

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

Steps to reproduce:

Using latest Firefox in Windows 11.


Actual results:

Many times all bookmarks from a toolbar vanish, while toolbar itself remains, but it's empty.

Restarting Firefox fixes this.
However, this started to be very frequent.


Expected results:

All bookmarks should remain.
Bug: 110.0.1 misplaced icons in toolbars with no "Bookmark toolbar items"
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-02 18:22:32+00:00
Resolved: 2023-03-13 14:37:41+00:00

Steps to reproduce:

Users who had removed the `Bookmark toolbar items` element from their toolbars are reporting that their custom icons are misplaced after updating to Firefox 110.0.1:

https://old.reddit.com/r/firefox/comments/11evixz
https://old.reddit.com/r/firefox/comments/11fgnlc
https://old.reddit.com/r/firefox/comments/11g98xd
Bug: Screenshot fails for specific tweet with `screenshots.browser.component.enabled`
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-02 18:42:09+00:00
Resolved: 2023-03-09 02:45:01+00:00

### Steps to reproduce

1. Set `screenshots.browser.component.enabled` pref = `true`.
2. Load https://twitter.com/Scriffey/status/1493389985579417603
3. Try to "Take Screenshot" of the page or an element on the page and "Download".

### Expected result

The screenshot should be saved to a file.

### Actual result

The screenshot download appears in the downloads menu, but stops with a "Failed" message.

I can reproduce this bug in a clean profile in old builds from 2022, so this is not an add-on problem or a recent regression. I'm testing on Windows 11.

The problem seems to be specific to that tweet https://twitter.com/Scriffey/status/1493389985579417603. If I click to focus any reply tweets or other tweets, I can successfully take and download screenshots of those tweets.
Bug: Keyboard navigation between Screenshot's panel, overlay and content document is not possible (component)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-02 20:13:09+00:00
Resolved: 2024-10-24 01:12:45+00:00

With `screenshots.browser.component.enabled` set to `true`:
We need to enable keyboard navigation between:
* the popup panel (with "capture visible" | "full page" and "copy" | "download" buttons)
* the overlay UI (with the region drag handles, element picker and associated "copy" | "download" buttons) 
* the content document - to allow the user to scroll/navigate within the document to get the correct stuff in the viewport

I'm leaving P1 - as this is our next priority for Screenshots, but S3 as this WIP version is still behind a pref and the default extension implementation does currently allow you to tab from the Screenshot buttons toolbar back out to the location bar and through to the content document. I'm not able to get to the any of the rest of the overlay content however.
Bug: Quick Actions not disabling when you try to fully disable it, like, it still activates "Actions" when you type ">", even when you tried disabling it
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-02 22:08:25+00:00
Resolved: 2023-09-06 20:52:36+00:00

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

Steps to reproduce:

I tried to disable this crappy feature by going into about:config, typing `browser.urlbar.quickactions.enabled`, it was already false, but I tried deleting it, and it brought me to no avail, only to bring a little bit more lag, so I "recovered" the value by adding it again and it's back to normal, I tried going into preferences > search and then unticking the Actions thing, obviously didn't work, I tried going into "Privacy & Security" and unchecking EVERYTHING in the Address Bar section, also brought me to no avail.


Actual results:

I tried disabling the stuff above, didn't work, so when I type something like, for example, "> lorem ipsum maths related search", it's then being replaced by "[Actions] lorem ipsum maths", which is really bugging me as that limits my control and use over Firefox's super essential Address Bar feature.


Expected results:

What should happen, is if I untick that search shortcut, it should also disable the assigned key, so life wouldn't be so f*cking painful anymore as it is right now.
Bug: Some providers happen error when paste-and-go and drag-and-go
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-03 04:42:36+00:00
Resolved: 2023-04-04 07:16:05+00:00

This is regressed by bug 1817155.
When paste-and-go or drop-and-go on the urlbar, the following errors happen.
```
console.error: (new TypeError("can't access property \"view\", queryContext is undefined", "resource:///modules/UrlbarProviderQuickActions.sys.mjs", 278))
console.error: (new TypeError("can't access property \"view\", queryContext is undefined", "resource:///modules/UrlbarProviderQuickSuggest.sys.mjs", 371))
console.error: (new TypeError("can't access property \"view\", queryContext is undefined", "resource:///modules/UrlbarProviderWeather.sys.mjs", 433))
```
We cleared `UrlbarController.sys._lastQueryContextWrapper` when both actions, but that we are touching its context in their providers is the reason.

* paste-and-go https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.sys.mjs#2811
* drop-and-go https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.sys.mjs#3643

We need to fix it.
Bug: Webpage "save as, complete" retry should retry as complete, not HTML only
Status: NEW
Priority: P3
Created: 2023-03-03 05:00:39+00:00
Resolved: 2024-05-02 12:32:10+00:00

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

Steps to reproduce:

Firefox (currently 110.0.1) has many problems with saving modern webpages, causing missing pictures.

The most annoying flaw is that saving a page with much embedded content (ads etc.) falsely displays at the download icon a small orange arrow, despite the downloaded page usually works ok.

Much worse is because this arrow normally indicates a failed download, it encourages the user to click in the download menu the circular arrow next to that page name to redownload it, which (despite this makes the arrow go away!) makes it worse! I.e. it will replace the correct HTML file of the page with a *faulty* version (identical with "Web page, HTML only") that can not display the downloaded pictures from its "-files" directory anymore, because it is the original HTML page source without modified links pointing to it. 

The fact that naturally clicking redownload because of arrow makes it worse is counter-intuitive and very confusing to novices. Please prevent the orange arrow when saving as "Web page, complete" (unless it really failed to write the HTML file), or at least do not turn the redownload into the original HTML version of the page. 

If the arrow was meant to inform about an "inaccurate" download (e.g. missing an embedded part), give it a different colour and display a message when the user clicks redownload in the download manager or its dropdown menu.

example: https://www.monopol-magazin.de/11-kunstfilme-die-sich-im-maerz-lohnen



Actual results:

After saving complete page, false orange arrow lead user to click on redownload, which overwrites the correct with a faulty HTML page.


Expected results:

Show no orange arrow, or clicking redownload should display an info message instead.
Bug: Downloads icon in toolbar still slows download operations down a lot with >100 windows open.
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2023-03-03 05:51:15+00:00
Resolved: 2023-03-07 13:09:12+00:00

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

Steps to reproduce:

Open 119 firefox windows with a few tabs each (or just 35 if that's all you care to do; becomes much more likely to happen if you save sessions for restarts).  Leave downloads button enabled in toolbar.  Try to save a download - be it a webpage or an image.  Best to try download a file that will take a long time to download, to best demonstrate the problem.  The storage you're saving to doesn't appear to matter - I was saving to a fast enterprise class SSD.

Now remove that download icon from toolbar, clear cache if necessary (or just download a different object), and download and save an object.


Actual results:

Firefox becomes extremely unresponsive for duration that download is in progress, if there is a download icon present in the toolbar.   You'll notice the download icon changes to a progress meter.  You'll notice each of the other windows are also displaying each and every update to that toolbar icon (and obviously most of your 118 other windows aren't even visible on the screen, but they're obviously also updating their download progress icon).  If you're downloading a 1GB movie file, you can expect the entire firefox session to be unusable for the entire duration of that download.  Other browsers with similar numbers of windows open do not have this problem.

Whereas once you remove the download icon from the toolbars, save becomes nearly instantaneous again, just like on a fresh profile.


Expected results:

I wouldn't expect even updating 119 icons would be a particularly expensive mechanism on a modern computer, but given everything is javascript, some effort could be made to ensure that only a reasonable number of these icons are being updated at a single time rather than all of them, including on undisplayed windows.  Perhaps only update the 5 most recently displayed windows (or maybe even only on the window who "owns" the download).  Perhaps only update them a maximum of once every 1 second, not continuously for the entire duration of the download.
Bug: JavaScript error: resource://gre/modules/AsyncShutdown.sys.mjs, line 727: Error: Phase "IOUtils: waiting for profileBeforeChange IO to complete" is finished, it is too late [..] "JSON store: writing data for 'shieldpreferenceexperiments'
Status: NEW
Priority: P3
Created: 2023-03-03 08:15:48+00:00
Resolved: 2023-03-20 13:59:05+00:00

The PreferenceExperiments.jsm is getting initialized during shutdown, when it's not necessary. This has been seen in a Marionette test that quickly requests quitting Firefox  once it finished startup:

Here the appropriate excerpt from the log:

https://treeherder.mozilla.org/logviewer?job_id=407440882&repo=autoland&lineNumber=46252

```
[task 2023-03-01T15:47:13.741Z] 15:47:13     INFO -  JavaScript error: resource://gre/modules/AsyncShutdown.sys.mjs, line 727: Error: Phase "IOUtils: waiting for profileBeforeChange IO to complete" is finished, it is too late to register completion condition "JSON store: writing data for 'shieldpreferenceexperiments'"
```

For details also see bug 1819671 comment 5.
Bug: [macOS 13] xattr signing is not outputting a valid result
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-03 08:42:57+00:00
Resolved: 2023-03-08 14:54:51+00:00

**Found in**
- Firefox 111.0b8

**Affected versions**
- Firefox 111.0b8
- Firefox 112.0a1

**Tested platforms**
- Affected platforms: macOS 13.2.1
- Unaffected platforms: older macOS versions

**Steps to reproduce**
1. Have an Firefox.app on desktop from a .dmg package
2. Run xattr -l Firefox.app in the terminal window (xattr -l /Users/*username*/Desktop/Firefox.app - when Firefox.app is on Desktop)

**Expected result**
- The output should be something like this: com.apple.quarantine: 01c1;5ba3927d;Chrome;A3C1EFF8-A91D-40A8-B513-F35222FAB04A.

**Actual result**
- The output looks like this: M???appl/??2?G?^?B?l??  S?
                      ?

**Regression range**
- Will see if there is a regression

**Additional notes**
- The output on macOS 13.2.1 can be seen in the attachment
- Older macOS are not affected
Bug: [macOS 13] No prompt to install Firefox or open in temporary session is shown when launching it from the dock
Status: NEW
Priority: --
Created: 2023-03-03 09:19:04+00:00
Resolved: 2024-02-27 16:34:25+00:00

**Found in**
- Firefox 111.0b8

**Affected versions**
- Firefox 111.0b8
- Firefox 112.0a1

**Tested platforms**
- Affected platforms: macOS 13.2.1
- Unaffected platforms: older macOS

**Steps to reproduce**
1. Mount firefox.dmg
2. Double click on Firefox.app in the mounted image
3. Select Don't install on the prompt
4. Close Firefox completely
5. Drag Firefox.app from the mounted image to the dock
6. Eject the mounted image and then click on Firefox.app from the dock
7. Select a profile (if profile manager is used)

**Expected result**
- A prompt is shown to let the user install Firefox or open it in a temporary session

**Actual result**
- No prompt is shown and Firefox is launched automatically

**Regression range**
- Will see if there is a regression

**Additional notes**
- The issue can be seen in the [following attachment](https://drive.google.com/file/d/1KIUWDrkqsdSnM_wYZdf_5dUneAtnewGo/view?usp=share_link)
- This happens only if Firefox is launched from the dock. If it is launched from the mounted image, the prompt will always appear.
- This happens with or without profile manager
- Older macOS will have this prompt after step 7, it happens only on macOS 13.2.1
Bug: Awesome Bar result menu icon doesn't respect design for hover and selected states
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-03-03 11:46:58+00:00
Resolved: 2023-03-03 14:01:41+00:00

+++ This bug was initially created as a clone of Bug #1820114 +++

**Found in**
* 112.0a1 (2023-03-02)

**Affected versions**
* 112.0a1 (2023-03-02)

**Tested platforms**
* Affected platforms: Windows 11, macOS 13, Ubuntu 22
* Unaffected platforms: none

**Preconditions**
* Have Firefox opened in Dark theme
* Have a profile with some browsing history.

**Steps to reproduce**
1. Launch Firefox.
2. Input a history string in the address bar (anything that will generate a Firefox Suggest entry).
3. Go to Firefox Suggest section.
4. Hover any entry  with mouse pointer
5. Select the entries by keyboard
6. Change Firefox theme to Light and repeat the above steps

**Expected result**
*Hover and select state follows [Figma](https://www.figma.com/file/qJedYfkPtjy4FuJVsTURho/Individual-Search-Suggestion-Control?node-id=3%3A6352&t=QXh7n3lrBJjZVlPg-0) design

**Actual result**
* The hover and select state are different than the Figma design (I'm attaching the dark mode design)
Bug: Close, minimize button appearing in firefox fullscreen in window manager
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-03 14:19:23+00:00
Resolved: 2023-07-11 11:28:09+00:00

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

Steps to reproduce:

Open firefox on any window manger. I used dwm, press f11 to enter fullscreen mode. 


Actual results:

List all tabs button will move towards left side and blank space appears. This space act as maximize, minimize button.


Expected results:

List all tabs should not move and no space should appear.
Bug: Integer Preferences getting converted to boolean values in preferences policy
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-03-03 15:20:31+00:00
Resolved: 2023-03-30 01:09:10+00:00

See:

https://github.com/mozilla/policy-templates/issues/1003

With a Preferences value of 

```
{
  "pdfjs.cursorToolOnLoad": {
    "Value": 1,
    "Status": "user"
  },
  "pdfjs.sidebarViewOnLoad": {
    "Value": 0,
    "Status": "user"
  }
}
```

You end up with booleans in about:config.

1. This shouldn't happen.
2. This shouldn't be possible because these prefs already exist as default values with ints.