av9ash/GitBugs huggingface dataset:
Bug: Intermittent [tier 2] toolkit/components/certviewer/tests/browser/browser_checkMissingCommonName.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-03-07 04:25:40+00:00
Resolved: 2024-08-19 14:14:58+00:00

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

---
```
[task 2023-03-07T03:42:43.260Z] 03:42:43     INFO - TEST-PASS | toolkit/components/certviewer/tests/browser/browser_checkMissingCommonName.js | "undefined" != "certificate-viewer-unknown-group-label" - 
[task 2023-03-07T03:42:43.260Z] 03:42:43     INFO - Leaving test bound test_check_missing_common_name
[task 2023-03-07T03:42:43.261Z] 03:42:43     INFO - Buffered messages finished
[task 2023-03-07T03:42:43.263Z] 03:42:43     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/certviewer/tests/browser/browser_checkMissingCommonName.js | waiting for vsync to be disabled - timed out after 50 tries. - false == true - {"filename":"chrome://mochikit/content/browser-test.js","name":"ensureVsyncDisabled","sourceId":530,"lineNumber":587,"columnNumber":19,"sourceLine":"","asyncCause":null,"asyncCaller":null,"caller":null,"formattedStack":"ensureVsyncDisabled@chrome://mochikit/content/browser-test.js:587:19\n","nativeSavedFrame":{}}
[task 2023-03-07T03:42:43.263Z] 03:42:43     INFO - Stack trace:
[task 2023-03-07T03:42:43.263Z] 03:42:43     INFO - chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:587
[task 2023-03-07T03:42:43.263Z] 03:42:43     INFO - Not taking screenshot here: see the one that was previously logged
[task 2023-03-07T03:42:43.265Z] 03:42:43     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/certviewer/tests/browser/browser_checkMissingCommonName.js | vsync remained enabled at the end of the test. Is there an animation still running? Consider talking to the performance team for tips to solve this. - false == true - {"filename":"chrome://mochikit/content/browser-test.js","name":"ensureVsyncDisabled","sourceId":530,"lineNumber":588,"columnNumber":19,"sourceLine":"","asyncCause":null,"asyncCaller":null,"caller":null,"formattedStack":"ensureVsyncDisabled@chrome://mochikit/content/browser-test.js:588:19\n","nativeSavedFrame":{}}
[task 2023-03-07T03:42:43.265Z] 03:42:43     INFO - Stack trace:
[task 2023-03-07T03:42:43.265Z] 03:42:43     INFO - chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:588
[task 2023-03-07T03:42:43.265Z] 03:42:43     INFO - GECKO(7368) | MEMORY STAT | vsize 2104161MB | vsizeMaxContiguous 66029842MB | residentFast 231MB | heapAllocated 92MB
[task 2023-03-07T03:42:43.266Z] 03:42:43     INFO - TEST-OK | toolkit/components/certviewer/tests/browser/browser_checkMissingCommonName.js | took 5951ms
```
Bug: [Experiment] The "Set Firefox as default browser" option is not correctly aligned on Firefox locales with long strings (es-ES)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-07 11:09:47+00:00
Resolved: 2024-01-09 15:44:43+00:00

**[Affected versions]:**
- Firefox Beta 111.0 - Build ID: 20230306162820

**[Affected Platforms]:**
- Windows 10 x64
- Windows 11 x64

**[Prerequisites]:**
- Have a Firefox 111.0 es-ES locale installed.
- Have the "nimbus.debug" pref set to "true" in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to "about:studies?optin_slug=first-run-easy-set-up-fx111&optin_branch=treatment-a&optin_collection=nimbus-preview".
3. Navigate to the "about:welcome" page and observe the "Set Firefox as default browser" option.

**[Expected result]:**
- The "Set Firefox as default browser" option is correctly aligned.
    
**[Actual result]:**
- The "Set Firefox as default browser" option is NOT aligned with the rest of the page elements.

**[Additional Notes]:**
- This issue might be reproducible on other Firefox locales besides es-ES, however, I have not found them yet.
- Attached is a screenshot of the issue:
Bug: Cannot browse role="document" panels (anti-tracking and site information) with Orca
Status: NEW
Priority: --
Created: 2023-03-07 12:48:15+00:00
Resolved: 2024-10-22 17:51:57+00:00

Orca recently fixed a issue with the anti-tracking and site information panels, which use `role="document"`. Before, pressing the arrow keys with focus within the panel would cause Orca to navigate and read the web page document. See https://gitlab.gnome.org/GNOME/orca/-/issues/293.

With the latest development tip, Orca will now no longer browse the web page document, and instead all arrow key events will pass to firefox instead. So it is possible to move within the panels as if in "focus mode".

However, it is still not possible to navigate the panels in "browse mode".

As [detailed in the Orca bug](https://gitlab.gnome.org/GNOME/orca/-/issues/293#note_1690886):

> if Mozilla wants something to be browse-mode-able in Orca:
>
> 1. It needs to have the DOCUMENT_WEB role rather than the DOCUMENT_FRAME role.
> 2. The AtkRelation set of the FRAME will need to point to that popup as the embedded document; not the actual, displayed web page.

## Steps to Reproduce

With Orca's current development tip:

1. Enable Orca screen reader.
2. Open firefox.
3. Enter https://example.org.
4. Navigate to the "anti-tracking" button prior to the URL entry (F6, Shift+Tab).
5. Press Enter to open popup panel.
6. Enter "browse mode".
7. Press an arrow key.

## Result

The anti-tracking panel is not navigated as in browse mode. The work around to read the non-focusable components is to use read-all or flat review.

## Expect

To be able to navigate the anti-tracking panel in browse mode like in NVDA.

NOTE: Other panels that do *not* use `role="document"`, like the bookmarks panel, are not browe-mode-able, but this is expected and the same in Orca as NVDA.
Bug: Address bar drop-down flickers if maxRichResults pref is set to 0
Status: NEW
Priority: P5
Created: 2023-03-07 15:49:04+00:00
Resolved: 2023-11-20 16:20:07+00:00

**Found in**
* Fx 112.0a1

**Affected versions**
* Fx 112.0a1
* Fx 111.0

**Affected platforms**
* all

**Steps to reproduce**
1. Launch Firefox.
2. Go to about:config and set *browser.urlbar.maxRichResults* to 0.
3. Open a new tab and click inside the address bar.

**Expected result**
* Nothing happens and text input indicator is correctly displayed for the address bar.

**Actual result**
* The address bar flickers, displaying for a brief time the topsites(shortcuts).

**Regression range**
* Looking into a regression is proving difficult, as none of the builds downloaded by the tool exhibit this issue. Will try and narrow it down manually if necessary.

**Additional notes**
* Please note that this issue occurs if the user inputs some text and then clicks the address bar. In this case, the flicker only displays the search engines from the bottom of the 'regular' address bar dropdown.
* In Fx 103.0a1 only this last part of the issue occurs (the one described in notes), not the one described in the steps - meaning that clicking the address bar with no input, does not cause the entire address bar drop-down to be briefly displayed.
Bug: File origin field in the download prompt no longer shows the https:// prefix
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-03-07 16:41:46+00:00
Resolved: 2023-03-09 13:21:30+00:00

Tested in 110.0.1.

Prerequisites:

Flip `browser.download.always_ask_before_handling_new_types` to true and potentially anything in the _Applications_ section in `about:preferences` to Always Ask.

STR:

Download anything on `https://ftp.mozilla.org/` that can trigger a download prompt.

Expected Behavior:

The file origin field in the Download prompt shows the `https://` prefix when downloading from a https source.

Actual Behavior:

The file origin field in the Download prompt does not show the `https://` prefix when downloading from a https source, even when the user have explicitly set `browser.urlbar.trimURLs` to false.


Mozregression returned

Last good revision: f64ced63685430042f38b89efc60214e031b415e
First bad revision: 34beebb41264b5bafedc9f6c2508bf9094b06f27
Pushlog : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f64ced63685430042f38b89efc60214e031b415e&tochange=34beebb41264b5bafedc9f6c2508bf9094b06f27
Bug: File origin field in the download prompt no longer shows the moz-extension:// prefix
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-07 16:44:06+00:00
Resolved: 2023-04-26 13:57:16+00:00

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

Tested in 110.0.1.

Prerequisites:

Flip `browser.download.always_ask_before_handling_new_types` to true and potentially anything in the _Applications_ section in `about:preferences` to Always Ask.

STR:

1. Install [Extension source viewer](https://addons.mozilla.org/en-US/firefox/addon/crxviewer/).
2. Visit `https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin`.
3. Click on Extension source viewer's pageAction and select _View source_.
4. Click either on the _Download_ or _CRX_ text at the top right of the new page.

Expected Behavior:

The file origin field in the Download prompt shows the `moz-extension://` prefix and the whole line should read `from: moz-extension://[crx-viewer-webext-uuid]`.

Actual Behavior:

The file origin field in the Download prompt does not show the `moz-extension://` prefix and the whole line was `from: [crx-viewer-webext-uuid]`.


Mozregression returned

Last good revision: f64ced63685430042f38b89efc60214e031b415e
First bad revision: 34beebb41264b5bafedc9f6c2508bf9094b06f27
Pushlog : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f64ced63685430042f38b89efc60214e031b415e&tochange=34beebb41264b5bafedc9f6c2508bf9094b06f27
Bug: Intermittent browser/components/preferences/tests/browser_pdf_disabled.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-03-07 18:14:09+00:00
Resolved: 2025-03-03 12:12:17+00:00

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

---
```
INFO - TEST-START | browser/components/preferences/tests/browser_pdf_disabled.js
[task 2023-03-07T17:44:42.327Z] 17:44:42     INFO - TEST-INFO | started process screentopng
[task 2023-03-07T17:44:42.703Z] 17:44:42     INFO - TEST-INFO | screentopng: exit 0
[task 2023-03-07T17:44:42.704Z] 17:44:42     INFO - Buffered messages logged at 17:44:41
[task 2023-03-07T17:44:42.705Z] 17:44:42     INFO - Entering test bound pdfIsAlwaysPresent
[task 2023-03-07T17:44:42.706Z] 17:44:42     INFO - Buffered messages finished
[task 2023-03-07T17:44:42.707Z] 17:44:42     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_pdf_disabled.js | pdfItem is present in handlersView when enabled - null == true - {"filename":"chrome://mochitests/content/browser/browser/components/preferences/tests/browser_pdf_disabled.js","name":"pdfIsAlwaysPresent","sourceId":4973,"lineNumber":24,"columnNumber":12,"sourceLine":"","asyncCause":null,"asyncCaller":null,"caller":null,"formattedStack":"pdfIsAlwaysPresent@chrome://mochitests/content/browser/browser/components/preferences/tests/browser_pdf_disabled.js:24:12\n","nativeSavedFrame":{}}
[task 2023-03-07T17:44:42.707Z] 17:44:42     INFO - Stack trace:
[task 2023-03-07T17:44:42.707Z] 17:44:42     INFO - chrome://mochitests/content/browser/browser/components/preferences/tests/browser_pdf_disabled.js:pdfIsAlwaysPresent:24
[task 2023-03-07T17:44:43.322Z] 17:44:43     INFO - TEST-PASS | browser/components/preferences/tests/browser_pdf_disabled.js | pdfItem is present in handlersView when disabled - {"selectedByMouseOver":false} == true -
```
Bug: Highlight has wrong position when searching in PDF
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-08 00:17:34+00:00
Resolved: 2023-03-29 05:47:32+00:00

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

Steps to reproduce:

1. Go to https://www.unicode.org/charts/PDF/U31350.pdf
1. Search for some random codepoints


Actual results:

The highlights are mispositioned. Even, for some codepoints, the highlight is invisible at all, thus I cannot locate the matched text.


Expected results:

Not so.
Bug: Tab drop indicator can appear at the end of the tabbar when dragging into just before 1st tab
Status: ASSIGNED
Priority: --
Created: 2023-03-08 00:31:45+00:00
Resolved: 2023-06-18 00:31:08+00:00

1. Open a window with few tabs, so that they don't overflow
2. Make sure there is some button before the tabbar, e.g. Firefox View is there by default.
3. Load http://example.com/
4. Select some text and drag it into just before 1st tab

**Expected** the tab drop indicator appears before the 1st tab
**Actual** the tab drop indicator appears after the last tab
Bug: Pocket newtab Discovery Stream topsites image issues
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-03-08 03:34:36+00:00
Resolved: 2023-03-16 12:41:02+00:00

Seems there are issues with the image from Discovery Stream.

There are a few layers, but the 2 main ones are:
1. Moving the DIscovery Stream topsites to load early exposed some processing to the url because it was set as a `customScreenshotURL` previously it would skip the extra processing because it was inserted later. Fix is to not use `customScreenshotURL` and instead use favicon.
2. Favicon has a parsing issues because the quote usage was a bit wonky, but wasn't hard to fix it when we setup the favicon by adding the right quotes to ensure it can be parsed properly.
Bug: Text is misaligned for multi-select checkboxes for easy setup screen
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-08 15:18:20+00:00
Resolved: 2023-03-20 14:55:28+00:00

We have an offtrain  fix for the following bug by resizing the checkbox text but an on train fix would be better to handle the text alignment for the multi-select checkboxes for longer text/locales.

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

**[Affected versions]:**
- Firefox Beta 111.0 - Build ID: 20230306162820

**[Affected Platforms]:**
- Windows 10 x64
- Windows 11 x64

**[Prerequisites]:**
- Have a Firefox 111.0 es-ES locale installed.
- Have the "nimbus.debug" pref set to "true" in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Navigate to "about:studies?optin_slug=first-run-easy-set-up-fx111&optin_branch=treatment-a&optin_collection=nimbus-preview".
3. Navigate to the "about:welcome" page and observe the "Set Firefox as default browser" option.

**[Expected result]:**
- The "Set Firefox as default browser" option is correctly aligned.
    
**[Actual result]:**
- The "Set Firefox as default browser" option is NOT aligned with the rest of the page elements.

**[Additional Notes]:**
- This issue might be reproducible on other Firefox locales besides es-ES, however, I have not found them yet.
- Attached is a screenshot of the issue:
Bug: Pinned tabs didn't restore on update to Nightly 20230306094520
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-08 16:38:07+00:00
Resolved: 2024-04-29 15:53:56+00:00

I updated my Nightly today to a staged `20230306094520`. It restarted and restored only the non-pinned tabs.

I checked the Browser Console for session restore related logs, but there was only a bunch of `ASRouter` stuff (probably from debugging a different issue some months ago).

I've turned on `browser.sessionstore.debug` in case it happens again.
Bug: QuickSuggest may be bypassing maxRichResults?
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-03-08 17:29:31+00:00
Resolved: 2024-01-17 15:00:54+00:00

We were debugging a case where an employee was getting no results from the urlbar today, and we discovered the problem was maxRichResults being set to 0.

Though one of the screenshots clearly showed a QuickSuggest Wikipedia result, that should not have been there.
about:studies didn't show anything active.
Bug: Bookmarks Library window overlaps `right side pane tree` and `detail pane` when reduce the height
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-03-08 18:23:22+00:00
Resolved: 2023-03-16 12:43:50+00:00

STR:
1. Open Library(Ctrl+Shift+O)
2. Select a bookmark
3. Reduce the height 

Actual results:
Overlaps  `right side pane tree` and `detail pane`.

Expected results:
Should not overlap.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7b4afe21a178843c4e1a7a2ba8c2047021bd35de&tochange=5ac5b687f0f3a2147e8a0d6c31f0d807caba92f9
Bug: After continues usage of 3 hours, Firefox get lag and asking force quit
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-03-08 18:26:55+00:00
Resolved: 2023-04-12 14:46:20+00:00

open Firefox browser,
use some website,
After long time make your PC sleep,
then reopen that some times its asked force quit.
Bug: After continues usage of 3 hours, Firefox get lag and asking force quit
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-08 18:27:26+00:00
Resolved: 2023-03-08 19:05:50+00:00

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

open Firefox browser,
use some website,
After long time make your PC sleep,
then reopen that some times its asked force quit.
Bug: Firefox first-run experience sometimes shows two stacked modal clickthrough dialogs
Status: REOPENED
Priority: P3
Created: 2023-03-08 21:12:17+00:00
Resolved: 2023-09-11 19:09:40+00:00

See attached screenshot. When launching Firefox release on Ubuntu just now[1], I was presented with two modal-looking dialogs (the foreground one being truly modal and preventing me from opening tabs/windows/etc until I clicked through it).

This dual-messaging / multiple-popups-before-you-can-do-anything sort of thing is not a great user-experience, and probably worth avoiding. 

I'm using Firefox 110.0.1 (64-bit) on Ubuntu 22.04, installed via the OS (i.e. the snap).

[1] (this was just after removing & reinstalling the Firefox snap, if that matters. I think that clobbered my profile data as well, so this is probably/potentially the ~first-run experience for some users. [EDIT: see below, this actually isn't quite first-run; it requires your profile to have a particular type of `times.json` in your profile.]
Bug: about:studies does not show rollouts
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-03-08 21:51:12+00:00
Resolved: 2023-09-13 09:27:54+00:00

Which can be misleading/confusing when diagnosing issues with `about:studies`.

From bug 1821157 comment 3, 

> You can view enrolled "true" rollouts from `about:telemetry#environment-data-tab_experiments` (but not from `about:studies`)

From a UX standpoint, this seems like a bug.
Bug: "Always Ask" microphone permission asks only until refused once when global permission is blocked
Status: NEW
Priority: P3
Created: 2023-03-09 00:19:20+00:00
Resolved: 2023-03-20 19:23:42+00:00

1. Ensure a microphone is connected.
2. Load about:preferences#privacy
3. Click "Settings..." for "Microphone".
4. Check "Block new requests asking to access your microphone" then "Save changes".
5. In a new tab, load https://bug1799822.bmoattachments.org/attachment.cgi?id=9302646
6. Click padlock "Verified by: Let's Encryt" beside url, "Connection Secure", "More information", "Permissions".
7. Under "Use the microphone", uncheck "Use Default" and select "Always Ask".
8. In content, click "getUserMedia".  Prompt appears with "Remember this decision" unchecked.
9. In prompt, "click "Block".

In Page Info dialog Permissions tab:
Actual: "Use the microphone" has reverted to "Use Default", "Block".
Expected: no change.

10. In another new tab, load https://bug1799822.bmoattachments.org/attachment.cgi?id=9302646
11. In content, click "getUserMedia".

Expected: prompt.
Actual: "NotAllowedError: The request is not allowed by the user agent or the platform in the current context."
Bug: fix schema defect related to recent experiment restart
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-03-09 04:04:39+00:00
Resolved: 2023-03-20 13:59:17+00:00

https://docs.google.com/document/d/16eD-3xLqdge-pulycazJtAy87LOzaj0Y9zM8lFfTw7g/edit has the general context.  I believe Barret has more specific context and a fix in mind...
Bug: Firefox 107 Final create high DPC Latency 1500us, rise 500us
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-09 08:12:54+00:00
Resolved: 2023-03-09 18:00:27+00:00

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

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

Steps to reproduce:

Simple use Firefox 107 64bit on windows 11 pro 64 22h2 latest build combine with dpc latency checker 1.4.0 and you will see without firefox 107 in process the dpc latency is lower by 500us

I tested with other browser chrome, opera no issues the dpc latency did not pass 990us


Actual results:

after the upgrade from firefox 106 


Expected results:

the latency should not bump
Bug: Remove weird providerName != "UrlbarProviderTopSites" check from UrlbarController::typeFromElement
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-03-09 14:55:56+00:00
Resolved: 2023-03-09 21:47:57+00:00

I don't understand why we're guarding this code with that `providerName != "UrlbarProviderTopSites"` check: https://hg.mozilla.org/integration/autoland/rev/4e06f5ee4dd4#l2.65

This doesn't seem useful in any way. The line goes back to https://hg.mozilla.org/mozilla-central/rev/74ed02c503d16d2b9fc21072d1ef949697485aba#l1.207 but it didn't even seem useful back then.
Bug: [MSIX] Pinning private window to the Taskbar is broken
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-09 15:32:26+00:00
Resolved: 2023-03-09 18:20:21+00:00

**Found in**
* Firefox 111.0b8

**Affected versions**
* Firefox 111.0b8
* Firefox 110.0.1
* Nightly 112.0a1

**Tested platforms**
* Affected platforms: Windows 10 and Windows 11.

**Preconditions**
* Install an MSIX build from the Microsoft Store.

**Steps to reproduce**
1. Open a New private window.
2. Pin the private window to the Taskbar.
3. Unpin the window.
4. Pin the private window again.

**Expected result**
* The user should be able to pin and unpin a private window and the pinned window should have the Private Window icon.

**Actual result**
* The Pinned Private window has the Normal Firefox icon and the user can only pin the private window once - after the pinning is not allowed.

**Regression range**
Not a regression, the private window pinning was not a feature in Firefox 102.

**Additional notes**
To confirm the issue is reproducible on a Nightly build, I used the installer downloaded from: 
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-112.0a1.multi.win64.installer.msix
Bug: SVG filters aren't working correctly in the pdf builtin viewer
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-09 17:09:01+00:00
Resolved: 2023-04-30 14:49:38+00:00

In nightly, the image on the right isn't rendered correctly because the SVG filters aren't applied.
If you open the pdf in https://mozilla.github.io/pdf.js/web/viewer.html then it works as expected.

The code we've in both viewers is almost exactly the same.
The code to create the svg node and the filter is:
https://github.com/mozilla/pdf.js/blob/a0ef5a4ae1ff7a5ed225d1ecac78695f10b3348b/src/display/display_utils.js#L68-L160

then we return `url(#transfer_map_0)` which is used here:
https://github.com/mozilla/pdf.js/blob/a0ef5a4ae1ff7a5ed225d1ecac78695f10b3348b/src/display/canvas.js#L3056-L3058

I added a console.log here:
https://searchfox.org/mozilla-central/rev/cd2121e7d83af1b421c95e8c923db70e692dab5f/toolkit/components/pdfjs/content/build/pdf.js#6787

to check that the filter is ok and it's.
So it looks like the filter is not applied or found.