av9ash/GitBugs huggingface dataset:
Bug: The width of the DLP dialogs is narrower than usual
Status: NEW
Priority: --
Created: 2024-12-10 09:47:05+00:00
Resolved: 2025-01-23 04:19:11+00:00

**Found in**
* 135.0a1 (2024-12-09)

**Affected versions**
* 135.0a1

**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

**Tested platforms**
* Affected platforms: Windows 10/11

**Steps to reproduce**
1. Go to any random webpage (e.g. wikipedia.org) 
2. Paste “123456789” text inside the Search field
3. Observe the width of the “Scan in progress” and “You’re not permitted to paste this content” dialog

**Expected result**
*  DLP dialogs have the usual width (it used to have approx 410px)

**Actual result**
*  DLP dialogs have the width narrower than usual - approx 345 px 

**Regression range**
* Mozregression points to bug 1933568

**Additional notes**
* See the attached ss
* Reproducing for the Warning dialog as well
Bug: Intermittent browser/base/content/test/sync/browser_appmenu_signin_cta_variants.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-12-10 11:29:04+00:00
Resolved: 2025-02-24 12:06:13+00:00

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

---
```
[task 2024-12-10T10:17:46.390Z] 10:17:46     INFO - TEST-START | browser/base/content/test/sync/browser_appmenu_signin_cta_variants.js
[task 2024-12-10T10:19:16.799Z] 10:19:16     INFO - TEST-INFO | started process screenshot
[task 2024-12-10T10:19:16.956Z] 10:19:16     INFO - TEST-INFO | screenshot: exit 0
[task 2024-12-10T10:19:16.968Z] 10:19:16     INFO - Buffered messages logged at 10:17:46
[task 2024-12-10T10:19:16.969Z] 10:19:16     INFO - TEST-PASS | browser/base/content/test/sync/browser_appmenu_signin_cta_variants.js | Sanity check the temporary file doesn't exist. - true == true - 
[task 2024-12-10T10:19:16.970Z] 10:19:16     INFO - Entering setup bound 
[task 2024-12-10T10:19:16.971Z] 10:19:16     INFO - Leaving setup bound 
[task 2024-12-10T10:19:16.971Z] 10:19:16     INFO - Entering test bound test_default
[task 2024-12-10T10:19:16.972Z] 10:19:16     INFO - TEST-PASS | browser/base/content/test/sync/browser_appmenu_signin_cta_variants.js | Should not start with a NimbusFeature set for the CTA copy. - "undefined" == "undefined" - 
[task 2024-12-10T10:19:16.972Z] 10:19:16     INFO - Buffered messages finished
[task 2024-12-10T10:19:16.973Z] 10:19:16     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/sync/browser_appmenu_signin_cta_variants.js | Test timed out - 
[task 2024-12-10T10:19:16.973Z] 10:19:16     INFO - GECKO(8652) | Completed ShutdownLeaks collections in process 3744
[task 2024-12-10T10:19:16.974Z] 10:19:16     INFO - TEST-START | Shutdown
[task 2024-12-10T10:19:16.974Z] 10:19:16     INFO - Browser Chrome Test Summary
[task 2024-12-10T10:19:16.974Z] 10:19:16     INFO - Passed:  2
[task 2024-12-10T10:19:16.975Z] 10:19:16     INFO - Failed:  1
[task 2024-12-10T10:19:16.976Z] 10:19:16     INFO - Todo:    0
[task 2024-12-10T10:19:16.976Z] 10:19:16     INFO - Mode:    e10s
[task 2024-12-10T10:19:16.977Z] 10:19:16     INFO - *** End BrowserChrome Test Results ***
```
Bug: Firefox nightly made switching search engines harder
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-12-10 11:47:26+00:00
Resolved: 2024-12-17 17:57:52+00:00

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

Steps to reproduce:

Enter something in the omnibar
Try to switch search engines using arrow keys - fail
Try to click the search engines - fail


Actual results:

I now have to click two times to change my search engine
1) on the magnifying glass
2) on the search engine in the list


Expected results:

I should have been able to select the search engine from the omnibar using my keyboard or using one click of my mouse.
I _actually_ selete search engines on a regular basis and this makes the workflow so much worse that I actually created an account here to make a bug report...

Since this is a rollback of a change I will mark it as a defect - I hope that is ok...
Bug: Intermittent browser/components/translations/tests/browser/browser_translations_about_preferences_settings_always_translate_languages.js (finished) | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-12-10 12:18:48+00:00
Resolved: 2025-01-08 12:06:42+00:00

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

---
```
[task 2024-12-10T11:57:14.420Z] 11:57:14     INFO - TEST-START | browser/components/translations/tests/browser/browser_translations_about_preferences_settings_always_translate_languages.js
[task 2024-12-10T11:57:14.754Z] 11:57:14     INFO - GECKO(4097) | console.log: Translations: "Mocking RemoteSettings for the translations engine."
[task 2024-12-10T11:57:15.053Z] 11:57:15     INFO - GECKO(4097) | console.log: Translations: "Getting remote language models."
[task 2024-12-10T11:57:15.173Z] 11:57:15     INFO - GECKO(4097) | console.log: Translations: "Remote language models loaded in 0.119 seconds." ({})
[task 2024-12-10T11:57:15.532Z] 11:57:15     INFO - GECKO(4097) | console.log: Translations: "Removing RemoteSettings mock for the translations engine."
[task 2024-12-10T11:57:16.061Z] 11:57:16     INFO - GECKO(4097) | MEMORY STAT | vsize 11547MB | residentFast 692MB | heapAllocated 356MB
[task 2024-12-10T11:57:16.062Z] 11:57:16     INFO - TEST-OK | browser/components/translations/tests/browser/browser_translations_about_preferences_settings_always_translate_languages.js | took 1642ms
[task 2024-12-10T11:57:16.081Z] 11:57:16     INFO - checking window state
[task 2024-12-10T11:57:16.081Z] 11:57:16     INFO - GECKO(4097) | must wait for focus
[task 2024-12-10T12:03:26.081Z] 12:03:26     INFO - TEST-UNEXPECTED-TIMEOUT | browser/components/translations/tests/browser/browser_translations_about_preferences_settings_always_translate_languages.js (finished) | application timed out after 370 seconds with no output
[task 2024-12-10T12:03:26.082Z] 12:03:26     INFO - TEST-INFO 
[task 2024-12-10T12:03:26.082Z] 12:03:26     INFO - Buffered messages finished
[task 2024-12-10T12:03:26.083Z] 12:03:26  WARNING - Force-terminating active process(es).
```
Bug: Search mode is dismissed when blurring the urlbar
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-12-10 13:14:05+00:00
Resolved: 2025-01-04 06:46:02+00:00

**Note**
* Reproducible without performing a search.

**Found in**
* Nightly 135.0a1 2024-12-09

**Affected versions**
* Nightly 135.0a1 2024-12-09

**Tested platforms**
* Affected platforms: Win 11 64-bit, macOS 14, Ubuntu 22 64-bit
* Unaffected platforms: -

**Steps to reproduce**
1. Open a new tab and select any search engine from Unified Search Button.
2. Click inside the webpage.
3. Redo the first step, but this time select any search restrict (Bookmarks, History, Tabs, Actions).
4. Click outside the address bar (bellow the toolbar)

**Expected result**
* Search mode persists in the address bar.

**Actual result**
* Search mode chiclet is removed from the address bar.

**Regression range**
* First bad: 2024-12-07
* Last good: 2024-12-06
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=618505b0336f811d1f53201a25151a5d440957dd&tochange=fca189a166ea652ba3d7556ae3fc95174a5f4546
* Potentially regressed by: Bug 1919549 - Quit actions search mode after using quick actions in new tab page. r=urlbar-reviewers,jteow
Bug: Unnamed Tab Group is created from List All Tabs
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-12-10 13:27:06+00:00
Resolved: 2025-02-10 15:28:42+00:00

**Affected versions**
* Firefox 135.0a1

**Affected platforms**
* Windows 10 x64, macOS 14, Ubuntu

**Preconditions**
* Set browser.tabs.groups.enabled true
* browser.tabs.groups.dragOverThresholdPercent    20
* Have a few tabs opened.
* Have an already tab group created


**Steps to reproduce**
1. Click on the List All Tabs button from the browser toolbar
2. Select and right-click on a tab
3. Click Add new Tab Group 

**Expected result**
* Create Tab Group panel is opened

**Actual result**
* Create Tab Group panel is not opened, unnamed group is created with default colour

**Regression range**
* New feature

**Additional notes**
* See attached gif
Bug: Recently Closed Tabs from a Deleted Group cannot be opened from the Firefox View page
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-12-10 13:40:53+00:00
Resolved: 2025-02-20 14:11:47+00:00

**Found in**
* 135.0a1 (2024-12-10) 

**Affected versions**
* 135.0a1 (2024-12-10)

**Preconditions**
Set browser.tabs.groups.enabled	true

**Affected platforms**
* all

**Steps to reproduce**
1. Have a Few Tabs Groups on the TabStrip.
2. Right Click and Delete the Tab Group.
3. Reach Firefox View and double click on one of the Recently Closed Tabs from the Group.

**Expected result**
The user should be able to reopen a Tab by Clicking it.

**Actual result**
* Clicking or Double clicking on a closed Tab from the previously deleted Tab group does not work.

**Regression range**
Not a Regression.
Bug: Unified Search Button becomes active when opening the search engines main page using USB shortcuts
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-12-10 14:27:23+00:00
Resolved: 2024-12-27 10:30:54+00:00

**Note**
* The main issue here is that the USB button will become active on each opened tab until address bar interaction.

**Found in**
* Nightly 135.0a1 2024-12-09

**Affected versions**
* Nightly 135.0a1 2024-12-09

**Tested platforms**
* Affected platforms: Win 11 64-bit, macOS 14, Ubuntu 22 64-bit
* Unaffected platforms: -

**Steps to reproduce**
1. Have a random website in the first tab and open a new tab.
2. Click on the Unified Search button on the second tab.
3. Shift+Click / Tab+Shift+Enter on one of the search engines.
4. Open the first tab.

**Expected result**
* The search engine main page is opened in the current tab, there is no USB in the address bar.

**Actual result**
3. 4. USB is shown on both tabs and will remain there until address bar enters edit mode on any tab.

**Regression range**
* Not a regression, maybe a follow-up from bug 1928132.
Bug: The Tab Group Vertical Color Line is too close to the edge of the Browser Window
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-12-10 15:08:06+00:00
Resolved: 2024-12-18 08:36:38+00:00

**Found in**
* 135.0a1 (2024-12-10) 

**Affected versions**
* 135.0a1 (2024-12-10)

**Preconditions**
Set browser.tabs.groups.enabled	true
Enable the Vertical Sidebar

**Affected platforms**
* all

**Steps to reproduce**
1. Have a Few Tabs Groups expanded on the Vertical TabStrip.

**Expected result**
The Group Colored line should be a pixel away from the Edge of the Browser.
There should be some space between the Edge of the browser and the Actual Group Line, according to FIGMA.

**Actual result**
* The Colored Group line is right at the edge of the Browser window.
* Darker Colors are harder to see on the Edge of the screen. 

**Regression range**
Not a Regression.
Bug: "Open All Tabs" option was removed in sidebar revamp
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2024-12-10 15:31:23+00:00
Resolved: 2025-02-25 16:50:32+00:00

In the "old" synced-tabs sidebar there was an "open all" option - eg, see https://support.mozilla.org/mk/questions/1413287

synced tabs in the new sidebar does not have that option, meaning people can't reasonably open a large number of tabs.
Bug: Unable to reach the First Collapsed group if the Tab strip is full of other Collapsed tab Groups
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-12-10 15:32:17+00:00
Resolved: 2024-12-10 17:06:39+00:00

**Found in**
* 135.0a1 (2024-12-10) 

**Affected versions**
* 135.0a1 (2024-12-10)

**Preconditions**
Set browser.tabs.groups.enabled	true

**Affected platforms**
* all

**Steps to reproduce**
1. Have at least 10 Tabs Groups collapsed on the Tab strip.
2. Use the Scroll Arrows from the Tab Strip to navigate to the first Collapsed Group.

**Expected result**
User should be able to scroll through all collapsed Tab groups.

**Actual result**
* User is forced to view the first free tab from the Tab strip.
* User is unable to reach the First Tab group.

**Regression range**
Not a Regression.
Bug: Test failure in `browser_asrouter_experimentsAPILoader.js` and other tests
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-12-10 15:50:58+00:00
Resolved: 2024-12-11 10:08:39+00:00

In the ASRouter tests, `browser_asrouter_experimentLoaderAPI` is failing with `Glean.nimbusTargetingEnvironment.prefValues is undefined - stack: recordPrefValues@resource://nimbus/lib/TargetingContextRecorder.sys.mjs:328:`. Failure is also happening in `toolkit/components/normandy`, see [treeherder](https://treeherder.mozilla.org/jobs?repo=try&revision=aaeb164f872b0b4e70dcd565545f5ef6c68bf10f&selectedTaskRun=TT5zyrwVSJK1YgOkiOzKCw.0)
Bug: RemoteSettingsExperimentLoader does not filter out invalid recipes
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-12-10 16:47:44+00:00
Resolved: 2024-12-13 18:28:10+00:00

The refactors in bug 1934698 led to a bug where we now call onRecipe for invalid recipes. This does not enroll them because the status will not match the expected TARGETING_MATCH, but opt-ins will not be filtered out.
Bug: Firefox Labs Opt-Ins unenroll on next update
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-12-10 16:50:38+00:00
Resolved: 2024-12-13 18:28:10+00:00

Because Firefox Labs opt-ins are not added to the "sessions" object in ExperimentManager, on the next update any opt-in will be unenrolled.
Bug: Pinning the first tab in the leftmost tab group pins the tab inside the group.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-12-10 18:34:25+00:00
Resolved: 2025-01-31 15:47:20+00:00

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

Steps to reproduce:

1) Create one or more tab groups.
2) In the leftmost tab group, pin the first (leftmost) tab in the group.


Actual results:

The tab is pinned inside the group.  Note, selecting multiple tabs inside the first group including the first tab and then pinning them will pin all selected tabs inside the group.


Expected results:

The tab is pinned outside the group.  Pinning other tabs inside a group besides the first tab in the leftmost group worked correctly.
Bug: Firefox View button keeps getting re-added to end of tab strip
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-10 19:00:19+00:00
Resolved: 2024-12-10 19:15:21+00:00

Recently, after each Nightly update, the Firefox View icon keeps getting re-added to the end of the tab strip. I had removed it from my toolbar a while ago, but now each time I remove it, when Nightly updates, it comes back, at the end of the tab strip (not its default position).

I haven't had time to run this through mozregression but I will try to do that later tonight, just wanted to get this bug noted.
Bug: Downloads dialogue in Firefox not labelled "Downloads" instead labelled "Library" confusing from a User Interface Design aspect.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-10 19:39:29+00:00
Resolved: 2024-12-20 10:21:02+00:00

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

Steps to reproduce:

Pressed CTRL+J to open "Downloads" window.


Actual results:

Downloads dialogue opens with "Library" as the title.


Expected results:

Expected Downloads dialogue to appear with "Downloads" as the window name, as per the name in the menu, however, the window is labelled "Library" which is wholly confusing.  When providing support to a remote individual, the individual was unable to confirm they had the "Downloads" dialogue open as it's not named correctly!  This seems like a fundamental oversight in user-interface design.
Bug: pdf viewer shows all blank pages
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-10 22:22:29+00:00
Resolved: 2025-01-06 21:48:59+00:00

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

Steps to reproduce:

I downloaded a PDF from  here https://api.kbharkiv.dk/asset/8202 .
This is just an example all PDF s from this site are displayed with all blank pages.


Actual results:

Blank pages


Expected results:

The text and pictures should have been displayed as the do other browser like Google Chrome
Bug: New Tab and Firefox View buttons keep coming back
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-10 23:10:50+00:00
Resolved: 2024-12-11 00:07:43+00:00

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

Steps to reproduce:

Use the customize option to remove the New Tab, List All Tabs, and Firefox View buttons from the toolbar. Then close and reopen Firefox.


Actual results:

The buttons get re-added to the toolbar (at the end after other stuff I have positioned there).


Expected results:

They should stay gone if they were removed from the toolbar.
Bug: Yelp ML suggestions are disabled if nonsponsored suggestions are disabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-12-10 23:16:12+00:00
Resolved: 2024-12-16 11:23:28+00:00

Chidam noticed that `browser.urlbar.suggest.quicksuggest.nonsponsored` has to be true to show Yelp ML suggestions even when the `sponsored` pref is true. I'm not sure if I broke this recently or it never worked right.

The `sponsored` pref works correctly, it's just the `nonsponsored` pref.
Bug: Failures observed while running browser_dragDrop_after_opening_fxViewTab.js in non-headless mode
Status: REOPENED
Priority: --
Created: 2024-12-11 03:22:18+00:00
Resolved: 2024-12-25 12:10:34+00:00

The test [browser_dragDrop_after_opening_fxViewTab.js](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/tests/browser/browser_dragDrop_after_opening_fxViewTab.js) fails consistently in non-headless mode on Windows/macOS/Linux.

**Steps to Reproduce:**
Run `./mach test browser/components/firefoxview/tests/browser/browser_dragDrop_after_opening_fxViewTab.js`

**Actual results:**
Unexpected Results
browser/components/firefoxview/tests/browser/browser_dragDrop_after_opening_fxViewTab.js
**FAIL** Dragged link should positioned at new index - Got 2, expected 1
Stack trace:
chrome://mochikit/content/browser-test.js:test_is:1627
chrome://mochitests/content/browser/browser/components/firefoxview/tests/browser/browser_dragDrop_after_opening_fxViewTab.js:null:108
chrome://mochikit/content/browser-test.js:handleTask:1147
chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1219
chrome://mochikit/content/browser-test.js:Tester_execTest:1360
chrome://mochikit/content/browser-test.js:nextTest/<:1136
chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
**FAIL** Test tab should be to the left of dragged tab - Got 1, expected 2
Stack trace:
chrome://mochikit/content/browser-test.js:test_is:1627
chrome://mochitests/content/browser/browser/components/firefoxview/tests/browser/browser_dragDrop_after_opening_fxViewTab.js:null:113
chrome://mochikit/content/browser-test.js:handleTask:1147
chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1219
chrome://mochikit/content/browser-test.js:Tester_execTest:1360
chrome://mochikit/content/browser-test.js:nextTest/<:1136
chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058

**Expected results:**
All test should pass
Bug: Firefox in LXQt uses libfm-qt dialog only once after opening
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-11 03:49:13+00:00
Resolved: 2024-12-11 05:26:56+00:00

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

Steps to reproduce:

1. Ensure that xdg-desktop-portal 1.18.4 and xdg-desktop-portal-lxqt 1.1.0 are installed.
2. In about:config, ensure that "widget.use-xdg-desktop-portal.file-picker" and "widget.use-xdg-desktop-portal.mime-handler" are both set to 1 and that the other three "widget.use-xdg-desktop-portal" settings ("widget.use-xdg-desktop-portal.location", "widget.use-xdg-desktop-portal.open-uri", and "widget.use-xdg-desktop-portal.settings") are all set to 2.
3. Close all Firefox windows if any settings in the previous step were changed.
4. Open Firefox to any webpage (such as duckduckgo.com).
5. Press Ctrl+S. libfm-qt should appear as the save dialog, like expected (it'll look similar to PCMaFM-Qt).
6. Close the libfm-qt save dialog (no need to save the webpage).
7. Press Ctrl+S again. The GTK dialog appears instead.
8. Close the GTK save dialog.
9. Repeat step 8-9 however many times you'd like. The GTK dialog will always appear until all Firefox windows are closed and a new window is opened, starting a new Firefox session. The same thing will happen with this new session (the first time Ctrl+S is used, PCManFM-Qt is used for the dialog, but the GTK dialog is used every time after that).

This issue also occurs with Ctrl+O and also occurs with Thunderbird 128.4.2esr. I thought it was an issue with xdg-desktop-portal-lxqt, so I reported this on their GitHub (https://github.com/lxqt/xdg-desktop-portal-lxqt/issues/48), but the dev wasn't able to reproduce it. Maybe it's a Firefox & Thunderbird-side issue since I couldn't reproduce this on my non-Mozilla apps.

I should note that running Firefox using GTK_USE_PORTAL=1 ("GTK_USE_PORTAL=1 firefox" in a terminal) seems to "fix" this issue. I put "fix" in quotes because I consider it to be more of a workaround, but at least it uses libfm-qt for the save/open dialogs every time during the whole session when run like that from terminal. This "fix"/workaround also works for Thunderbird.

LXQt 2.1.0
Qt 6.7.2
Xorg 7.6
xdg-desktop-portal 1.18.4
xdg-desktop-portal-lxqt 1.1.0
Firefox 133.0.3 (NON-FLATPAK)
Thunderbird 128.4.2esr (NON-FLATPAK)


Actual results:

libfm-qt file chooser dialog opens only the first time Ctrl+S or Ctrl+O is pressed. Afterwards, every time either of those two shortcuts are activated, the GTK file choose dialog opens instead.


Expected results:

libfm-qt file chooser dialog opens every time Ctrl+S or Ctrl+O is pressed.
Bug: Gravatar avatar not showing on about:logins due to CSP policy
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-12-11 03:49:15+00:00
Resolved: 2024-12-15 13:15:42+00:00

After signing in with a Firefox Account, if you have an avatar defined using Gravatar (which I'm guessing is the default functionality if you don't upload a custom avatar), the avatar doesn't render in the top-right corner of the [about:logins](about:logins) page; there's a blank spot where it should be. The following message appears in the console for me:

`Content-Security-Policy: The page’s settings blocked the loading of a resource (img-src) at https://secure.gravatar.com/avatar/bdbbf654dea1a22f3e1e955ea187f26e?s=600 because it violates the following directive: “img-src data: blob: https://firefoxusercontent.com https://profile.accounts.firefox.com”`

This appears to be due to [this line](https://searchfox.org/mozilla-central/source/browser/components/aboutlogins/content/aboutLogins.html#9), which only allows image blobs or those served by https://firefoxusercontent.com and https://profile.accounts.firefox.com.