av9ash/GitBugs huggingface dataset:
Bug: After switching off Free VPN Proxy extension, pinned tabs show error without URL for pages
Status: UNCONFIRMED
Priority: --
Created: 2023-01-15 09:40:34+00:00
Resolved: 2023-02-09 14:42:32+00:00

Steps to reproduce:

i am from Iran and many sites are closed to us.there is a plugin named Free VPN Proxy which we use to open this sites.then i pinned 4 or 5 tabs and closed Firefox.


Actual results:

when i opened Firefox since this plugin is off at start pinned tabs become "cannot find file" and no trace of link or address is available.i lost more than 20 tabs this way.
i know this is not most likely your responsibility but there is no harm in reporting it.thank you for all the hard work for such a good product.sorry for my awfull English.
Bug: Bookmarks toolbar not showing on all new tabs
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-15 15:36:07+00:00
Resolved: 2023-01-16 14:20:17+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

Steps to reproduce:

I have chosen the option for the bookmarks toolbar to show on new tabs.

It does not.




Actual results:

I have a homepage set. When I open a new window, the homepage shows. This is still a new page.  I do not get the bookmarks toolbar. I have to open a new tab to force it to appear.

A new window contains one tab. That is a new tab. But if there is a homepage, Firefox  thinks that is content, and doesn't show it.


Expected results:

I want to see the bookmarks toolbar on new tabs, always. Even if there is a homepage loaded. Even if the new tab is in a new window. I do not care where the tab is, I do not care how many tabs there are, or how many windows, or if they are private.

If it is new, and if "show the bookmarks toolbar in new tabs" is on, SHOW IT.

Where the tab is is irrelevant. If there are pinned tabs is irrelevant. Please just show it.
Bug: PiP captions stop updating if the tab containing the video is focused but the browser window is not
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-16 01:17:34+00:00
Resolved: 2023-01-17 09:24:03+00:00

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

Steps to reproduce:

1. Open a youtube video with captions (auto-generated captions are better because they update for each word, but manually created captions also work).
2. Enable PiP for that video.
3. Switch to a different window (with alt+tab or just clicking it). This window can be another firefox window or a separate program, but it seems like it needs to be maximized.
4. Observe that the captions slow down.


(I tried doing this in a separate nightly window and didn't reproduce as-is; I'm guessing that it's also necessary to have a lot of additional tabs open, or possibly multiple browser windows; I have probably 20 tabs each open in a regular window and a private browsing window, and have `browser.privateWindowSeparation.enabled` set to false. If needed I can try to find more specific steps.)

This doesn't happen if the tab is not focused (i.e. things behave just fine if you switch to a different tab in that browser window, even if the browser window is no longer focused). Also, this doesn't happen if the tab is visible e.g. when hovering over the firefox icon in the taskbar or in the alt+tab preview. It only seems to happen if the tab is the selected tab, but the window containing that tab is not visible.


Actual results:

The captions start appearing more slowly, only updating every few words instead of every word, and then start falling behind for whole sentences, and then appear to stop updating entirely. This is the same symptom as #1755748.


Expected results:

The captions should have continued updating in real time.
Bug: "Underline Links" Doesn't
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-16 06:02:37+00:00
Resolved: 2023-04-03 15:59:00+00:00

Steps to reproduce:

Firefox preferences include an option to "Underline Links."


Actual results:

This option does not work. I've tried with "Always" and "Never" override page colors, and it doesn't apply either way.


Expected results:

This should work. Unless users pick contrasting lnk and text colors, and always override site colors, it can be hard to diustinguish these without the underline.

Mozregression doesn't work with older versions, but this has been broken since at least 2016.
Bug: Firefoy@Windows only: Ghostscript 9.56+ processed PDFs have broken characters
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-16 10:09:08+00:00
Resolved: 2023-01-16 10:41:18+00:00

Steps to reproduce:

The described issue happens with many PDFs and on different Windows machines. For this report I took a public sample PDF from gnu.org:
https://www.gnu.org/licenses/quick-guide-gplv3.pdf

In addition to the original, prepare two PDFs from it that are processed by Ghost 9.55 and 9.56, respectively:

GHOST 9.55
------------

$ docker run -it --rm -v "$(pwd)/":/pdf alpine:3.15
/ # apk add ghostscript
...
(28/28) Installing ghostscript (9.55.0-r0)
...
/ # cd /pdf
/pdf # gs -o ghostscript-9.55.0_quick-guide-gplv3.pdf -sDEVICE=pdfwrite quick-guide-gplv3.pdf
GPL Ghostscript 9.55.0 (2021-09-27)
...
Processing pages 1 through 6.
Page 1
...
/pdf #

***

GHOST 9.56
------------

$ docker run -it --rm -v "$(pwd)/":/pdf alpine:3.16
/ # apk add ghostscript
...
(27/27) Installing ghostscript (9.56.1-r0)
...
9.56.1
/ # cd /pdf/
/pdf # gs -o ghostscript-9.56.1_quick-guide-gplv3.pdf -sDEVICE=pdfwrite quick-guide-gplv3.pdf
GPL Ghostscript 9.56.1 (2022-04-04)
...
Processing pages 1 through 6.
Page 1
...
/pdf #

***



Actual results:

Open the three PDFs in different browsers, they all looks fine and the same in e.g. Chrome on Win/Mac/Linux/iOS/Android, Firefox on Mac/Linux, Safari on Mac, Acrobat Reader on Mac/Windows, Preview on Mac etc.

But in Firefox on Windows the PDF processes with Ghostscript 9.56 has broken characters on all pages as seen in the attached screenshot.

The issue can also be confirmed with the most recent Ghostscript 10.0+ - only Firefox on Windows renders shows the broken characters.

For now I'd consider it rather an issue in FF than Ghostscript as the PDFs render well in all other PDF viewers, including Firefox on non-Windows machines.

PS: only one attachment allowed here, so it's the screenshot showing the issue, the PDFs I can't add.


Expected results:

The PDF processes with Ghostscript 9.56+ should also look fine on Firefox for Windows.
Bug: Linux + Wayland | Cannot Copy Address Bar Content
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-16 10:42:13+00:00
Resolved: 2023-03-24 18:14:58+00:00

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

Steps to reproduce:

1. Start the computer (Linux + KDE + Wayland)
2. Start Firefox
3. Enter the URL of a website or any other string
4. Try to copy the content of the address bar


Actual results:

The content of the address bar is not in the clipboard.


Expected results:

The content of the address bar is in the clipboard.
Bug: Orphaned temp directories and files from downloads
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-16 10:47:14+00:00
Resolved: 2023-01-16 18:26:54+00:00

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

Steps to reproduce:

1. I pick a PDF file to download from a website.
2. Ubuntu Studio 22.04 creates a temporary directory under /run/user/<userid>/doc with a creation date of 1970-01-01.
3. I pick a different directory to download to.


Actual results:

Temporary directory remains.


Expected results:

1. Temp. directory should be created with a meaningful time stamp.
2. Temp. directory should be deleted afterwards.
Bug: Open Dialog has OK Cancel options outside of window
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-16 12:50:52+00:00
Resolved: 2023-01-18 15:54:39+00:00

Steps to reproduce:

Tried to open a PDF file (just downloaded) with Firefox


Actual results:

The Firefox Open dialog shows up but there are no OK or Cancel options visible.
If i press Enter, the OK option is assumed (tab enables cancel, naturally)
If i force the window to maximize the buttons OR and Cancel are present.


Expected results:

OK and Cancel should not be outside of the window and should be visible at all times
Bug: [Experiment] A validation error is displayed in the "Browser Console" when trying to enroll in the "Import experiment: Image (new users)" experiments on Firefox 100 to 103 versions
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-01-16 13:04:00+00:00
Resolved: 2023-03-10 14:59:28+00:00

**[Notes]:**
- The following validation error is displayed in the "Browser Console": [Error](https://drive.google.com/file/d/1Y_p3xLGqWYsDMP2YDqxiW5aHNQSS34sw/view?usp=share_link)

**[Affected versions]:**
- Firefox Release  100.0.2 - Build ID: 20220519220738
- Firefox Release  101.0.1 - Build ID: 20220608170832
- Firefox Release  102.0.1 - Build ID: 20220705093820
- Firefox Release  103.0.2 - Build ID: 20220808125904

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.6.1
- Linux Mint 20.2

**[Prerequisites]:**
- Have a Firefox en-* locale installed.
- Have a Firefox profile betwen 7 and 28 days old.
- Have the "[user.js](https://drive.google.com/file/d/1Smyn7FOByDTtgFWGsdgV_dOywUfgqTXx/view?usp=share_link" file saved to disk.

**[Steps to reproduce]:**
1. Navigate to the profile folder from prerequisites and paste the "user.js" file.
2. Open the browser using the profile from the prerequisites.
3. Navigate to the "about:studies" page and observe the listed experiments.

**[Expected result]:**
- The "import-bookmarks-image-and-segmentation-en" experiment is displayed.
    
**[Actual result]:**
- The "import-bookmarks-image-and-segmentation-en" experiment is **NOT** displayed.

**[Additional Notes]:**
- This issue is also reproducible with the import experiments for the [DE](https://experimenter.services.mozilla.com/nimbus/import-bookmarks-image-and-segmentation-de/) and [FR](https://experimenter.services.mozilla.com/nimbus/import-bookmarks-image-and-segmentation-fr/) regions.
- This issue is no longer reproducible on Firefox 104 and above versions.
- Attached is a screen recording of the issue:
Bug: Dll icons don't change automatically when unblocking them from Initial list (when loading about page) and restarting later
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-01-16 14:46:23+00:00
Resolved: 2023-01-23 10:30:49+00:00

**Found in**
* Nightly 110.0a1

**Affected versions**
*  Nightly 110.0a1

**Tested platforms**
* Affected platforms: Windows 10, Windows 11, Windows 7
* Unaffected platforms: macOS, Linux

**Preconditions**
* Have Google Drive for desktop (https://www.google.com/drive/download/) or TortoiseGit (https://tortoisegit.org/) installed.

**Steps to reproduce**
1. Visit about:third-party
2. Hit CTRL + O and dismiss the File Menu
3. Click the black minus icon for any DLL showing in the list eg. `drivefsext.dll`
4. Click Restart now
5. Refresh the page
6. Click the red X icon
7. Click Restart Later
8. Refresh the about page

**Expected result**
* The DLL from step 3 has the unblocked icon (black minus icon).

**Actual result**
* The DLL from step 3 has the same blocked icon (red X icon). This 

**Regression range**
* Not a regression since this also exists in a build before this feature was turned on (2022-12-31), but it worked a bit differently by having the "Blocked by Nightly" icon instead.

**Additional notes**
* This is also reproducible while in troubleshoot mode or by having the `--disableDynamicBlocklist` 
* If I have all the dlls displayed and block one dll and hit restart later + refresh about page, the dll will have the icon changed to the correct one (a restart is still needed for the action to take place but the icon is changed correctly).
Bug: All block icons from all DLL flicker once one is changed from unblock to block state or vice versa
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-01-16 15:03:43+00:00
Resolved: 2023-01-20 14:34:30+00:00

**Found in**
* Nightly 110.0a1

**Affected versions**
* Nightly 110.0a1

**Tested platforms**
* Affected platforms: Windows 10, Windows 11, Windows 7
* Unaffected platforms: macOS, Linux

**Preconditions**
* Have Google Drive for desktop (https://www.google.com/drive/download/) or TortoiseGit (https://tortoisegit.org/) installed.

**Steps to reproduce**
1. Visit `about:third-party`
2. Hit CTRL + O and dismiss the File Menu
3. Refresh the about page
4. Click the black minus icon for any DLL showing in the list eg. `drivefsext.dll`
5. Click Restart Later
6. Click the red X button from the same DLL as step 4.
7. Click Restart Later
8. If needed repeat steps 4-7 a few times.
 
**Expected result**
* Icon is correctly changed from black to red for the selected DLL and no other changes are seen on other DLL icons.

**Actual result**
* All the other black minus icons (from other DLLs) flicker when the one focused is changed.

**Regression range**
* Not a regression since this is reproducible since this feature was turned on (2022-12-31)
Bug: Update down/up arrow and tab key behavior for the address bar's one off buttons
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-16 16:39:18+00:00
Resolved: 2023-02-03 13:25:13+00:00

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

Tab key handling is currently disabled for the address bar's one off buttons, while arrow down/up move through the buttons. This is pretty much the reverse of how result selection works after bug 1801298, so we should probably update this, i.e. enable tab key handling and not have arrow down/up move through each one off button.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_hideHeuristic.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-01-16 17:29:48+00:00
Resolved: 2024-08-05 12:02:37+00:00

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

---
```
[task 2023-01-16T16:06:10.057Z] 16:06:10     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_hideHeuristic.js | Sanity check: Heuristic and first results have different URLs - "http://example.com/" != "http://example.com/foo/9" - 
[task 2023-01-16T16:06:10.058Z] 16:06:10     INFO - Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use �<!DOCTYPE html>�." {file: "http://example.com/foo/9" line: 0}]
[task 2023-01-16T16:06:10.058Z] 16:06:10     INFO - Console message: [JavaScript Warning: "Unknown category for SetEventRecordingEnabled: page_load"]
[task 2023-01-16T16:06:10.059Z] 16:06:10     INFO - Leaving test bound pickNonHeuristic
[task 2023-01-16T16:06:10.059Z] 16:06:10     INFO - Console message: 1673885169673	addons.xpi	WARN	Attempted to remove example@tests.mozilla.org from app-profile but it was already gone
[task 2023-01-16T16:06:10.060Z] 16:06:10     INFO - Console message: 1673885169688	addons.xpi	WARN	Attempted to remove example@tests.mozilla.org from app-profile but it was already gone
[task 2023-01-16T16:06:10.060Z] 16:06:10     INFO - Buffered messages finished
[task 2023-01-16T16:06:10.061Z] 16:06:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_hideHeuristic.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2023-01-16T16:06:10.061Z] 16:06:10     INFO - GECKO(3840) | MEMORY STAT | vsize 2104785MB | vsizeMaxContiguous 65081087MB | residentFast 548MB | heapAllocated 151MB
[task 2023-01-16T16:06:10.062Z] 16:06:10     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_hideHeuristic.js | took 51599ms
[task 2023-01-16T16:06:10.062Z] 16:06:10     INFO - checking window state
[task 2023-01-16T16:06:10.062Z] 16:06:10     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_ime_composition.js
```
Bug: Extremely long loading times when trying to search the web or open websites
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-01-16 22:17:40+00:00
Resolved: 2023-10-28 22:16:29+00:00

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

Steps to reproduce:

I opened firefox then proceded to open both reddit and facebook (this is a recurring bug it's not something that happens only to facebook or reddit it also happens to discord, google, youtube and even the homepage)


Actual results:

it kept showing a grey spnning in a white background for 5+ minutes

Here's a link to a youtube video demonstrating what happened (it seems the video is too large to be send here so i uploaded it to youtube) https://youtu.be/fOwx3oKzL7w 


Expected results:

it should've loaded both websites as fast as possible.
Bug: Garbled text when opening Firefox
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-16 22:40:00+00:00
Resolved: 2023-02-09 17:03:54+00:00

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

Steps to reproduce:

Note this is reported in 452831. It is not invalid as you have listed. 
1. Open Firefox on first use - see gibberish/foreign language
2. Quit Firefox
3. Reopen Firefox and use normally


Actual results:

When I open Firefox on an initial opening, I usually get foreign(?)/gibberish letters around the screen (screen shot provided). I quit and reopen and all is correct so it is clearly not my language or location settings. Cropped screenshots provided of 1st opening. Would have provided 2nd opening but I think I can only share one picture


Expected results:

Should be English every time.
Note I have gone through steps previously spotted on the web but it's still happening
I am on Mac M1 using Moneterey 12.6.2
Bug: Update feature_callout_second_screen_positioned_left_of_element for the new screen it's testing
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-01-17 03:45:01+00:00
Resolved: 2023-01-20 04:56:36+00:00

The test [feature_callout_second_screen_positioned_left_of_element](https://searchfox.org/mozilla-central/rev/d39a17381a14606032f7b8e82789bf281beb1241/browser/components/firefoxview/tests/browser/browser_feature_callout_position.js#42-72) was originally written to test `arrow_position: "end"` but with the Colorways callouts removed, there are no messages with that position. So it's actually testing a screen with `arrow_position: "bottom"` but it's still comparing the left positions of the callout and parent, and still using the parent selector for the old tour screen 3 (the colorways card, which is now hidden). We should update this and maybe add another test that artificially sets `arrow_position: "end"` so it can be tested, while such messages are absent from the tree.
Bug: All addons in `More tools...` dropdown(overflow menu) moves `Extention` button without any feedback
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-17 05:48:02+00:00
Resolved: 2023-01-17 13:27:01+00:00

Existing user confused!

Steps to Reproduce:
1. Start old Firefox108.0
2. Install a couple of addons
3. Move addon's toolbutton to `Overflow Menu`
4. Optionally, Move built-in toolbutton to `Overflow Menu`
5. Update Firefox to 109.0

Actual results:
Addon are missing in `Overflow Menu`.
However, built-in toolbutton are stay in `Overflow Menu`.  

This is annoying. User confuse.


Expected Results:
Toolbutton should be stay in `Overflow Menu`.
Bug: Perma TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_feature_callout_position.js | Feature Callout is positioned left of parent element when callout is configured at end of callout - when Gecko 111 merges to Beta on 2023-02-13
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-01-17 12:30:11+00:00
Resolved: 2023-01-23 06:28:57+00:00

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

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

[Failure log](https://treeherder.mozilla.org/logviewer?job_id=402637248&repo=try)

```
[task 2023-01-17T11:59:57.889Z] 11:59:57     INFO - TEST-PASS | browser/components/firefoxview/tests/browser/browser_feature_callout_position.js | Feature Callout is positioned below parent element when callout is configured to point from the top - 
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - Leaving test bound feature_callout_first_screen_positioned_below_element
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - Entering test bound feature_callout_second_screen_positioned_left_of_element
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - Buffered messages finished
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_feature_callout_position.js | Feature Callout is positioned left of parent element when callout is configured at end of callout - 
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - Stack trace:
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - chrome://mochikit/content/browser-test.js:test_ok:1449
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - chrome://mochitests/content/browser/browser/components/firefoxview/tests/browser/browser_feature_callout_position.js:feature_callout_second_screen_positioned_left_of_element/<:64
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - Leaving test bound feature_callout_second_screen_positioned_left_of_element
[task 2023-01-17T11:59:57.890Z] 11:59:57     INFO - Entering test bound feature_callout_third_screen_position_respects_RTL_layouts
[task 2023-01-17T12:00:00.610Z] 12:00:00     INFO - TEST-PASS | browser/components/firefoxview/tests/browser/browser_feature_callout_position.js | Feature Callout is positioned right of parent element when callout is configured at end of callout in right to left layouts - 
```
Bug: Firefox hangs on Linux when connecting to dbus
Status: UNCONFIRMED
Priority: P3
Created: 2023-01-17 13:37:41+00:00
Resolved: 2023-07-12 07:24:17+00:00

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

Steps to reproduce:

When a mail site attempts to report a new incoming mail, Firefox shows a two-choice Allow / Deny notifications. After clicking Allow, Firefox hangs. 


Actual results:

It remains unresponsive for about 15 seconds or so. No click inside the Firefox window has any effect. It also doesn't do any window updates. This is on Linux with X11. After the waiting period, a dbus notification message appears with a snippet of the incoming mail.


Expected results:

Firefox should have remained responsive all along. This is unexpected and frustrating.