FS#80236 - [qutebrowser] new pdfjs version breaks pdf viewing

Attached to Project: Arch Linux
Opened by merlock (merlock) - Saturday, 11 November 2023, 23:23 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:21 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Morten Linderud (Foxboron)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: Upgrading pdfjs (also manifests in pdfjs-legacy) causes Qutebrowser to stop displaying pdf files in browser.


Additional info:
* package version(s) 4.0.189-1

Steps to reproduce: Upgrade pdfjs. Open any pdf file in qutebrowser; a good test URL: https://s29.q4cdn.com/175625835/files/doc_downloads/test.pdf.

See resulting error page.

Downgrade pdfjs and everything is back to normal.

**NOTE**

Looking at the version information for qutebrowser, I see this line:

*pdf.js: 3.11.174 (/usr/share/pdf.js/build/pdf.js)

And for 4.0.189-1:

*pdf.js: no

Directory listing for 3.11.174-1:

/usr/share/pdf.js/build

drwxr-xr-x 2 root root 4096 Nov 11 17:55 .
drwxr-xr-x 4 root root 4096 Nov 11 17:55 ..
-rw-r--r-- 1 root root 568294 Sep 25 03:39 pdf.js
-rw-r--r-- 1 root root 1434098 Sep 25 03:39 pdf.js.map
-rw-r--r-- 1 root root 637132 Sep 25 03:39 pdf.sandbox.js
-rw-r--r-- 1 root root 553585 Sep 25 03:39 pdf.sandbox.js.map
-rw-r--r-- 1 root root 1981637 Sep 25 03:39 pdf.worker.js
-rw-r--r-- 1 root root 4971937 Sep 25 03:39 pdf.worker.js.map

And, the directory listing for 4.0.189-1:

/usr/share/pdf.js/build

drwxr-xr-x 2 root root 4096 Nov 11 18:00 .
drwxr-xr-x 4 root root 4096 Nov 11 18:00 ..
-rw-r--r-- 1 root root 708119 Nov 7 04:32 pdf.mjs
-rw-r--r-- 1 root root 1652518 Nov 7 04:32 pdf.mjs.map
-rw-r--r-- 1 root root 822740 Nov 7 04:32 pdf.sandbox.mjs
-rw-r--r-- 1 root root 806718 Nov 7 04:32 pdf.sandbox.mjs.map
-rw-r--r-- 1 root root 2006247 Nov 7 04:32 pdf.worker.mjs
-rw-r--r-- 1 root root 5253423 Nov 7 04:32 pdf.worker.mjs.map

I would guess that's why qutebrowser cant find pdf.js.

I'm going to cross-file for pdfjs-legacy as well.






This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:21 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/qutebrowser/issues/1
Comment by merlock (merlock) - Saturday, 11 November 2023, 23:30 GMT
Cross-reference to  FS#80237 
Comment by loqs (loqs) - Saturday, 11 November 2023, 23:44 GMT
Looks related to upstream qutebrowser pull request 7992 [1].

[1]: https://github.com/qutebrowser/qutebrowser/pull/7992
Comment by loqs (loqs) - Sunday, 12 November 2023, 00:15 GMT
@merlock if you rebuild qutebrowser with the attached diff applied does that resolve the issue?
Comment by merlock (merlock) - Sunday, 12 November 2023, 02:43 GMT
@loqs - I'm running the `git` version of qutebrowser.

I saw the PR you referenced...looks like it has a bit of work left before it's ready for prime time.

Also, I'm not seeing test.patch.
Comment by Robin Candau (Antiz) - Sunday, 12 November 2023, 08:54 GMT
The latest pdfsj version is a major release introducing multiple significant changes: https://github.com/mozilla/pdf.js/releases/tag/v4.0.189

I guess I pushed it without realizing qutebrowser wasn't ready for it yet... Sorry about that.
A simple solution could be to "epoch" back pdfjs to v3.11.174 while waiting for qutebrowser to be compatible with pdfjs v4 (https://github.com/qutebrowser/qutebrowser/pull/7992).

Any thoughts?
Comment by loqs (loqs) - Sunday, 12 November 2023, 10:39 GMT
> Also, I'm not seeing test.patch.
I missed including it as part of PKGBUILD.diff. I tested it with the none -git package and it is working for me. I only tested that test.patch applies cleanly on the -git package.
Comment by merlock (merlock) - Sunday, 12 November 2023, 15:28 GMT
@loqs - patch worked, thanks!

@Antiz - I'm not knowledgeable enough to say either way about introducing an epoch.

ETA: Opening a pdf file (post-patching) introduces the following errors, but doesn't seem to affect the overall operation:

10:53:00 ERROR message message:error:63 JS: [qute://pdfjs/web/viewer.mjs:13562] Fetch API cannot load qute://pdfjs/web/locale/locale.json. URL scheme "qute" is not supported.

10:53:00 ERROR message message:error:63 JS: [qute://pdfjs/web/viewer.mjs:13562] Uncaught (in promise) TypeError: Failed to fetch
Comment by Robin Candau (Antiz) - Sunday, 12 November 2023, 15:41 GMT
Well, if the patch works, then we'll see if qutebrowser's maintainers are willing to apply it. Otherwise I can force pdfjs downgrade with an epoch for the time being.

Let's wait for @lfleischer or @Foxboron input.
Comment by loqs (loqs) - Sunday, 12 November 2023, 19:20 GMT
10:53:00 ERROR message message:error:63 JS: [qute://pdfjs/web/viewer.mjs:13562] Fetch API cannot load qute://pdfjs/web/locale/locale.json. URL scheme "qute" is not supported.
10:53:00 ERROR message message:error:63 JS: [qute://pdfjs/web/viewer.mjs:13562] Uncaught (in promise) TypeError: Failed to fetch

I produced the same errors applying the upstream merge request to qutebrowser-git. So I suspect that needs to be raised with upstream and possibly addressed in a follow up merge request.

Does manuskript have any issues with the pdfjs update?
Comment by Florian Bruhin (The-Compiler) - Monday, 13 November 2023, 13:33 GMT
Upstream here, got this on my radar. Planning to take a look at those issues this week and possibly release qb v3.1.0, but no hard promises because I'm a bit swamped with dayjob stuff currently.

If the problem is just the rename, a temporary fix might be for the pdfjs package to copy/symlink pdf.mjs <-> pdf.js.

As for the Fetch issue, the Fetch API won't work with how qutebrowser integrates pdf.js. qutebrowser has a hack to fix that:
https://github.com/qutebrowser/qutebrowser/blob/main/qutebrowser/browser/pdfjs.py#L63-L68

But possibly something changed which broke that. Could be an easy fix, could be a pain to fix. Since Qt 6.6, there is also a flag to allow the Fetch API on third-party URL schemes, but that still won't be a trivial fix.

Loading...