av9ash/GitBugs huggingface dataset:
Bug: Two search entries for each search made via DuckDuckGo
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-13 13:49:56+00:00
Resolved: 2025-02-03 14:39:22+00:00

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

Steps to reproduce:

Firefox version - 135.0b3 (aarch64)
OS - macOS Sequoia 15.1.1

1. Enter any text to search for in the Address bar.
2. Select Duck Duck Go from the list of search engines.
3. Press enter key, to get search results on DDG
4. Go back to Address bar and select History from the dropdown.
5. Enter the same search text as in step 1.


Actual results:

You see 2 entries on Duck Duck Go for the single search you made.


Expected results:

However only one entry is logged for the remaining search engines, as expected.
Bug: [Cards] Small card lose the contextual menu when saved to pocket
Status: NEW
Priority: P1
Created: 2025-01-13 15:47:34+00:00
Resolved: 2025-01-22 22:57:36+00:00

This was tested on Nightly 136.0a1 (2025-01-13) (64-bit)

Steps to reproduce:
1. Enable sections and the new cards UI to see small cards
2. Go to the contextual menu and click on "save to pocket"
3. Hover again the small card and the contextual menu is no longer visible.
Bug: [Sections] In the news have only 2 cards
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-13 17:04:36+00:00
Resolved: 2025-01-16 21:30:56+00:00

Bug reproduced on Nightly 136.0a1 (2025-01-13) (64-bit).

Enable sections and the new cards UI enabled, the first section of "in the news" is missing a card.
Bug: Desktop doesn't know how to handle OAuth uri from FxA
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2025-01-13 19:06:02+00:00
Resolved: 2025-02-04 18:56:14+00:00

### Prerequisite
- Ensure you are running desktop nightly with OAuth flow enabled.
- Ensure accounts.firefox.com is running on version 1.302.0 or higher (check [the version here](https://accounts.firefox.com/__version__)).
- Have an account created already with a recovery key.

### Steps to reproduce
1. Click the UI affordance to start a signin flow.
2. Click the 'Forgot password?' link instead of signing in.
3. Follow that process until you complete the password reset and get to the 'Continue to Sync' button.
4. When you get to the 'New account recovery key created', force a tab unload event (e.g. reload the page).
5. Observe the 'Your password has been reset' with the 'Continue to Sync' button.
4. Click the button.

### Expected results
- We continue onward to sync settings or account settings?

### Actual results
- We do nothing when [FxA provides](https://github.com/mozilla/fxa/blob/1ab854d3206dff82e67426a2d03b121697bbc44d/packages/fxa-settings/src/lib/constants.ts#L73) the `urn:ietf:wg:oauth:2.0:oob:oauth-redirect-webchannel`.

### Additional results
- For app services' FxA client, this might be handled differently. I can see these references to the same webchannel redirect:
  - https://searchfox.org/mozilla-mobile/rev/24ad6e8fa2533e9898ae41aec343a0e253f53876/application-services/components/fxa-client/src/internal/oauth.rs#291
  - https://searchfox.org/mozilla-mobile/rev/24ad6e8fa2533e9898ae41aec343a0e253f53876/application-services/components/fxa-client/src/internal/mod.rs#167
Bug: The New Tab page has a large horizontal scrollbar at certain screen sizes when sections are enabled
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-01-14 10:00:43+00:00
Resolved: 2025-01-22 17:49:21+00:00

**[Affected versions]:**
- Firefox Beta 135.0b3 - Build ID: 20250110123854
- Firefox Nightly 136.0a1 - Build ID: 20250113214519

**[Affected Platforms]:**
- Windows 10
- macOS 14
- Ubuntu 22.04

**[Prerequisites]:**
- Have the following prefs set in about:config in a new profile:
  - `browser.newtabpage.activity-stream.discoverystream.sections.enabled` to `true`
  - `browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled` to `true`
  - `browser.search.region` to `US`
- Use an en-US Firefox Build

**[Steps to reproduce]:**
1. Open the browser using the profile from prerequisites.
2. Open a New Tab.
3. Maximize the Firefox Window and observe the bottom part of the window.

**[Expected result]:**
- The page is only scroll-able vertically.
 
**[Actual result]:**
- The page has a a horizontal scrollbar and the page width is larger depending on the window size.

**[Regression Window]:**
- 22:34.90 INFO: Last good revision: e65e5888566ed72163ccbacecf3f78499d144ed5
- 22:34.90 INFO: First bad revision: 8205ad36ed89a6656aec466670fe24427a7e054d
- 22:34.90 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e65e5888566ed72163ccbacecf3f78499d144ed5&tochange=8205ad36ed89a6656aec466670fe24427a7e054d

**[Notes]:**
- Attached a screen recording of the issue.

@maxx, if looks like bug 1933150 caused this regression. Could you please take a look at this?
Bug: The focus is not moved to the Section Block dialog when it is triggered
Status: NEW
Priority: --
Created: 2025-01-14 10:32:59+00:00
Resolved: 2025-01-29 21:02:38+00:00

**[Affected versions]:**
- Firefox Beta 135.0b3 - Build ID: 20250110123854
- Firefox Nightly 136.0a1 - Build ID: 20250113214519

**[Affected Platforms]:**
- Windows 10
- macOS 14
- Ubuntu 22.04

**[Prerequisites]:**
- Have the following prefs set in about:config in a new profile:
  - `browser.newtabpage.activity-stream.discoverystream.sections.enabled` to `true`
  - `browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled` to `true`
  - `browser.search.region` to `US`
- Use an en-US Firefox Build

**[Steps to reproduce]:**
1. Open the browser using the profile from prerequisites.
2. Open a New Tab.
3. Using keyboard navigation reach a section context menu.
4. Press the context menu and navigate to the "Block" button.
5. Press the "Block" button.
6. Continue navigation using the "TAB" key.

**[Expected result]:**
- The focus is moved in the modal window and the first element is selected.
 
**[Actual result]:**
- The focus remains in the page and the next card is selected.

**[Notes]:**
- Attached a screen recording of the issue.
- I believe that this is also the reason why a screen reader won't automatically read the dialog box, but it can read it if the focus reaches it.
Bug: The "WNP_MOMENTS_23" page is not triggered on the Firefox 102.0esr version
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-01-14 11:03:41+00:00
Resolved: 2025-01-16 10:33:17+00:00

**[Affected versions]:**
Firefox 102.0esr - Build ID: 20220623064521

**[Affected Platforms]:**
- Windows 7
- Windows 8
- Windows 10
- Windows 11
- macOS 15.1
- Ubuntu 22.04

**[Prerequisites]:**
- Have a Firefox 102.0esr installed.
- Have any of the following Firefox locales installed: en, fr, ru, es, zh, de, pt, pl, it, ja, id, hu, cs, ar, and el.
- Have the “set MOZ_REMOTE_SETTINGS_DEVTOOLS=1” system variable set (“export” instead of “set” for macOS and Linux)
- Change the Environment to “prod-preview” (using [Remote Settings Devtools 1.7.0](https://github.com/mozilla-extensions/remote-settings-devtools/releases/download/1.7.0/remote-settings-devtools-1.7.0.xpi)).

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Change the system time to any date between the 5th of February and the 9th of March and restart the browser.
3. Restart the browser again and observe the behavior.

**[Expected result]:**
 - The "WNP_MOMENTS_23" page is successfully triggered.

**[Actual result]:**
 - The "WNP_MOMENTS_23" page is NOT triggered.

**[Notes]:**
- This issue is also reproducible for the “WNP_MOMENTS_24” page.
- This issue is NOT reproducible on Firefox 102.0.1esr or newer versions.
- I have evaluated the "version|versionCompare("102") >= 0" targeting expression in the ASRouter page while on a Firefox 102.0esr build and the result was "false". However, If we add the “esr” channel to the expression build version ("version|versionCompare("102esr") >= 0") the received result is "true".
Bug: Close tab button obstructed by system's resize window cursor when Firefox not focused
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2025-01-14 15:13:13+00:00
Resolved: 2025-01-17 19:31:30+00:00

Hey folks, loving vertical tabs so far.

I noticed that if Firefox isn't focused, my system's "resize window" icon mostly obstructs the close tab button. This is due to the button's close proximity to the left edge of the Window. See the attached video file for an example of what I mean.

I'm using Gnome with Linux, though I imagine the problem might exist on other operating systems as well. It doesn't feel like a huge issue as focusing Firefox is enough to make it go away, but figured it was worth filing.
Bug: Closed window's closed tabs do not get saved by session restore if the window has no worth-saving tabs at time of close
Status: NEW
Priority: P3
Created: 2025-01-14 17:28:56+00:00
Resolved: 2025-01-20 16:44:40+00:00

Steps to reproduce (using a new profile):

1. In `about:config`, ensure `browser.sessionstore.closedTabsFromClosedWindows` is `true`
2. Open two windows
3. In window A, open a number of tabs with "worth-saving" content (i.e. a real website, not just `about:blank`)
4. Close all the tabs you just opened in window A, such that only one tab remains (the "New Tab" that was created when the window was first opened).
5. In the top menu, go to "History > Recently Closed Tabs". Observe the list of tabs you just closed.
6. Close window A. (Window B should still be open).
7. Reopen the "History" menu.

Expected result:
The list of tabs continues to appear in the "Recently Closed Tabs" menu.

Actual result:
No recently closed tabs exist and the "Recently Closed Tabs" menu item is disabled.

Notes:
My suspicion is that on window close, session store is checking if the window has any open "worth saving" tabs, and discarding it if it does not, even though that window may have "worth saving" *closed tabs* that should be saved.
Bug: Firefox Menu button has vague accessible name of "Firefox"
Status: NEW
Priority: P3
Created: 2025-01-14 18:03:53+00:00
Resolved: 2025-01-23 17:29:52+00:00

### Prerequisites:
1. Ensure a screen reader is running, i.e. NVDA on WinOS

### STR:
1. In Firefox, locate and focus with keyboard the hamburger menu and observe the screen reader announcement
    1. you'd need to press `Tab` key until you get to the last group of toolbar controls, by default in release starting with "Save to Pocket" button, then press `Right Arrow` key to move the focus through the tools to the hamburger menu

### Expected:
1. Menu button has a clear accessible name that concisely describes the functionality of this control, i.e. "Application menu" or "Firefox menu"

### Actual:
1. `Firefox` is the label of the menu button. It has a description `Open application menu` that is often skipped and should not be relied on to provide an accessible name and communicate the functionality of the control

This is an [access-S3 issue](https://wiki.mozilla.org/Accessibility/Triage) because it relies on assistive technology users to guess what this button would do. It really is close to `access-S2` issue because at the moment the `Firefox` label is meaningless within the Firefox application.

Screen reader users in the recent user interviews (4 of 4) missed this button or did not really need what to expect in it, i.e.:
> Firefox Button - application button. I do not know what it does, honestly.

Note that while users did find an alternative ways to the actions requested via the ribbon menu, not all functionality is provided in there and could only be accessed via the main menu or a direct URI "about:" which is not widely known by users
Bug: Intermittent browser/base/content/test/general/browser_bug1299667.js | single tracking bug
Status: REOPENED
Priority: P5
Created: 2025-01-14 18:17:55+00:00
Resolved: 2025-02-17 07:18:47+00:00

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

---
```
TEST-START | browser/base/content/test/general/browser_bug1299667.js
[task 2025-01-14T17:19:39.899Z] 17:19:39     INFO - TEST-INFO | started process screenshot
[task 2025-01-14T17:19:40.073Z] 17:19:40     INFO - TEST-INFO | screenshot: exit 0
[task 2025-01-14T17:19:40.073Z] 17:19:40     INFO - Buffered messages logged at 17:18:09
[task 2025-01-14T17:19:40.074Z] 17:19:40     INFO - Entering test bound 
[task 2025-01-14T17:19:40.075Z] 17:19:40     INFO - Console message: [JavaScript Warning: "HTTPS-First Mode: Upgrading insecure speculative TCP connection �http://example.com/� to use �https�."]
[task 2025-01-14T17:19:40.075Z] 17:19:40     INFO - Buffered messages logged at 17:18:15
[task 2025-01-14T17:19:40.076Z] 17:19:40     INFO - waiting for the history menu to open
[task 2025-01-14T17:19:40.076Z] 17:19:40     INFO - Buffered messages finished
[task 2025-01-14T17:19:40.077Z] 17:19:40     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug1299667.js | Test timed out - 
[task 2025-01-14T17:19:40.078Z] 17:19:40     INFO - GECKO(6892) | Completed ShutdownLeaks collections in process 7364
[task 2025-01-14T17:19:40.078Z] 17:19:40     INFO - TEST-START | Shutdown
[task 2025-01-14T17:19:40.079Z] 17:19:40     INFO - Browser Chrome Test Summary
[task 2025-01-14T17:19:40.079Z] 17:19:40     INFO - Passed:  20
[task 2025-01-14T17:19:40.080Z] 17:19:40     INFO - Failed:  1
[task 2025-01-14T17:19:40.081Z] 17:19:40     INFO - Todo:    1
[task 2025-01-14T17:19:40.081Z] 17:19:40     INFO - Mode:    e10s
[task 2025-01-14T17:19:40.082Z] 17:19:40     INFO - *** End BrowserChrome Test Results ***
[task 2025-01-14T17:19:40.129Z] 17:19:40     INFO - GECKO(6892) | 1736875180127	Marionette	TRACE	Received observer notification quit-application
[task 2025-01-14T17:19:40.130Z] 17:19:40     INFO - GECKO(6892) | 1736875180127	Marionette	INFO	Stopped listening on port 2828
[task 2025-01-14T17:19:40.137Z] 17:19:40     INFO - GECKO(6892) | 1736875180133	Marionette	DEBUG	Marionette stopped listening
[task 2025-01-14T17:19:42.498Z] 17:19:42     INFO - TEST-INFO | Main app process: exit 0
[task 2025-01-14T17:19:42.505Z] 17:19:42     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug1299667.js | Application shut down (without crashing) in the middle of a test!
[task 2025-01-14T17:19:42.505Z] 17:19:42     INFO - TEST-INFO took 92157ms
[task 2025-01-14T17:19:42.506Z] 17:19:42     INFO - runtests.py | Application ran for: 0:02:00.840091
[task 2025-01-14T17:19:42.506Z] 17:19:42     INFO - zombiecheck | Reading PID log: C:\Users\task_173687473956132\AppData\Local\Temp\tmp_oafpgrwpidlog
```
Bug: Tab group with many tabs moves when expanding and collapsing
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-01-14 19:35:26+00:00
Resolved: 2025-01-20 09:24:06+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**
Create a tab group with many tabs inside (example has 26 tabs)
Open enough ungrouped tabs in the tab strip to have scrolling arrows appear to the left and right of the tab strip


**Expected behavior [What should have happened?]:**
I can expand and collapse a group without the tab strip scrolling to another position (if I click on the group to expanding/collapse, it should still stay in the same position or close enough to the same position so I wouldn't have to move my mouse to click on it again).


**Actual behavior [What actually happened?]:**
When expanding and collapsing a large tab group, the tab strip scrolls so the label is no longer visible on the tab strip (expanding). When collapsing the tab group the tab strip scrolls so I have to move my mouse to click on the tab group again (see video attachment).
Bug: <a target="Chapter" href="01/Chapter.htm">Book</a> is not loading "01/Chapter.htm" to the target frame Chapter with firefox 134.0.1.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-14 22:23:38+00:00
Resolved: 2025-01-14 23:00:39+00:00

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

Steps to reproduce:

<a target="Chapter" href="01/Chapter.htm">Book</a> is not loading "01/Chapter.htm" to the target frame Chapter with firefox 134.0.1.
Bug: some icons now appearing as 4 digit letters/numbers
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-01-15 08:10:53+00:00
Resolved: 2025-01-27 06:26:55+00:00

Steps to reproduce:

I went to this URL: https://www.gao.gov/products/gao-19-721t there are 4 icons that are not displaying just below the text "Published...".

These are supposed to be icons but are, instead, sets of 4 characters enclosed in tiny boxes. For example: f099


Actual results:

see above


Expected results:

I would expect the icons to be displayed and NOT these tiny boxes.
Bug: The Top Icon from the "Highlights from Recent Reviews" card is truncated
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-01-15 11:16:51+00:00
Resolved: 2025-01-17 08:52:16+00:00

**Found in**
* 136.0a1 (2025-01-15) 

**Affected versions**
* 136.0a1 (2025-01-15)

**Preconditions**
Enable the Review Checker:
browser.shopping.experience2023.enabled - true
browser.shopping.experience2023.optedIn - 1

**Affected platforms**
* all

**Steps to reproduce**
1. Reach https://www.amazon.com/Cherry-Mechanical-Keyboard-Aluminum-Switches/dp/B08YRGQSD1/ref=sr_1_1_sspa?_encoding=UTF8&content-id=amzn1.sym.12129333-2117-4490-9c17-6d31baf0582a&dib=eyJ2IjoiMSJ9.wvEBKSDQQm4qdxchORsZMYW-V79MXo8J-lGih9Sy1kjfe3-LRBnh2fo7sMVEQG8AQaeCof5IqEid_3BkRUW5QD4yyYhs5XXjf5Erd3-2tJPa2eJflNnjXj1o1sHze7rSrIw4Sjsr-lpr6Rc04_8zKx0eyU5hu1z2-jgGWD8gX3_PG8yNNcNU8_QIEZ3J59vGkpQQPPChIzdZxyMXM5CtMmADYhDfPJLlJR1YlbvHUJk._A-Mz7cq-obpUCc-7Aty0wVJ2khvo2pg1_frD4usCwY&dib_tag=se&keywords=gaming+keyboard&pd_rd_r=f128a914-40b1-46ee-b52e-9e7971542fab&pd_rd_w=p3eVB&pd_rd_wg=tZjtM&pf_rd_p=12129333-2117-4490-9c17-6d31baf0582a&pf_rd_r=EWPERJ5P4N2CAEKPWC9G&qid=1736937216&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1

**Expected result**
* The Highlights should fit on the card without any visual issues.

**Actual result**
* The top "Price" Icon is cut at the top.

**Regression range**
10:32.42 INFO: Last good revision: e2a6c575b58344f5c2549c25c8bde361ccd397ca
10:32.42 INFO: First bad revision: 5aac522e7d931ba5f025a2447a369c33989dbf2e
10:32.42 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e2a6c575b58344f5c2549c25c8bde361ccd397ca&tochange=5aac522e7d931ba5f025a2447a369c33989dbf2e
Bug: Selecting "Reopen All Tabs" from the "Recently Closed Tabs" menu opens all tabs ungrouped, even if some of them were closed by deleting a tab group
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2025-01-15 14:42:41+00:00
Resolved: 2025-02-10 08:34:57+00:00

Steps to reproduce:
1. Open some "worth-saving" tabs. Put some of them in a tab group.
2. Right click the tab group label and select "Delete group".
3. Close the rest of the ungrouped tabs.
4. From the top menu, go to "History > Recently Closed Tabs > Reopen All Tabs".

Expected result:
All tabs are reopened, and the tabs that were closed through deleting the tab group are reopened as part of a group.

Actual result:
All tabs are reopened ungrouped.
Bug: Copying complete punycode URL's from the address bar does not percent-encode them while partial URL's work fine
Status: NEW
Priority: P3
Created: 2025-01-15 18:16:11+00:00
Resolved: 2025-01-16 18:04:43+00:00

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

Steps to reproduce:

Yesterday I was reading into punycode and looking for an URL example to do some tests with it and I found something that seems not to be correct. Specifically:

1. Open the non-existent example site https://møllerriis.dk/ .
2. When Firefox tells you the site could not be loaded copy the full URL out of the address bar and paste it somewhere (like Notepad).
3. Repeat the previous step with only copying a part of the URL from the address bar (anything except the last / ).


Actual results:

Copying the full URL does not percent-encode it while copying the partial URL does percent-encode it.


Expected results:

Both copied URL's should have been percent-encoded.


Additional details:

I recall a few years ago there was an issue where copying full non-punycode URL's did percent-encode them while this did not work for partial URL's. But this got changed so that copying partial URL's from the beginning does percent-encode them as well. Now with punycode URL's the case is swaped here for some reason.
Bug: WARNING: Ignoring duplicate observer: browser.shopping.experience2023.optedIn: file modules/libpref/Preferences.cpp:2870
Status: NEW
Priority: --
Created: 2025-01-15 23:19:26+00:00
Resolved: 2025-01-30 12:09:43+00:00

I just noticed this bit of startup log-spew in my terminal when starting a local debug build:
> [Parent 2429148, Main Thread] WARNING: Ignoring duplicate observer: browser.shopping.experience2023.optedIn: file /scratch/work/builds/mozilla-central/mozilla/modules/libpref/Preferences.cpp:2870
Bug: Importing RemoteSettingsExperimentLoader has side effects
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-01-16 01:02:42+00:00
Resolved: 2025-02-24 22:35:24+00:00

Importing RemoteSettingsExperimentLoader.sys.mjs presently creates a [`new _RemoteSettingsExperimentLoader()`](https://searchfox.org/mozilla-central/rev/cbc10b90d92e10fd695cd75f966756ea28596308/toolkit/components/nimbus/lib/RemoteSettingsExperimentLoader.sys.mjs#894-895), which has the side effect of registering observers (https://searchfox.org/mozilla-central/rev/cbc10b90d92e10fd695cd75f966756ea28596308/toolkit/components/nimbus/lib/RemoteSettingsExperimentLoader.sys.mjs#144-167). Because unit tests often make their own test RemoteSettingExperimentLoaders, this means that at any given time there can be two active RSEL listening for events. This has lead to intermittent and hard to debug test failures when making seemingly innocuous changes.

IMO this is enough of a footgun to warrant refactoring and such a refactor should make it easier for non-experts to write unit tests in Nimbus.
Bug: Oversized Address Bar Results (unintended touch mode)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2025-01-16 14:31:56+00:00
Resolved: 2025-03-03 15:29:59+00:00

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

Steps to reproduce:

The address bar results are oversized after updating to Firefox 134.0

This is only affecting one Windows device (laptop) and does not occur on my desktop when logged in with the same account.

I tried a profile refresh but it did not resolve this issue.

I do not have any custom CSS settings, and I checked about:config and nothing related to this has been customized.

I uninstalled and re-installed Firefox, and deleted my profile folder, same issue. I created a new profile without logging in, same issue. Looks like a bug. I also tried with the laptop monitor and an external one, changed the DPI settings, but its just stuck like this.
Bug: PDF viewer seems to have problems displaying images correctly rotated (maybe EXIF related)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2025-01-16 14:35:13+00:00
Resolved: 2025-02-13 16:01:54+00:00

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

Steps to reproduce:

1. Open the pdf.js issue #12027 on GitHub: https://github.com/mozilla/pdf.js/issues/12027
2. Open the file "pdfjs_orientation_issue.pdf" with Firefox:
https://github.com/mozilla/pdf.js/files/4836022/pdfjs_orientation_issue.pdf
3. Open the same file with a different PDF viewer (e.g. Chrome, Edge, Acrobat Reader, etc.)


Actual results:

The image in the PDF is rotated incorrectly in Firefox.


Expected results:

The image should have the same orientation as in other PDF viewers.