pdf.js - the button images are missing #7904
Labels
priority: 1 - middle
Issues which should be done at some point, but aren't that important.
Comments
The-Compiler
added
status: can't reproduce
|
This sounds like an issue with your setup. What does |
|
how did you install pdf.js?
I have really no idea what's wrong here. Maybe |
|
Looks like a Debian packaging bug which is already reported there: #989889 - libjs-pdf: Icons not displayed when using pdf.js in qutebrowser - Debian Bug report logs |
|
The solution: just copy images to |
|
Btw. I didn't understand the error message |
The-Compiler
added
priority: 1 - middle
|
Ah, looks like Debian splits them into pdf.js-common. We already account for that and look there too, but apparently that only contains some images... No idea why. |
|
FYI, the locale is also missing in the package and the file should be copied manually to |
|
This solves the following err. msg.: |
toofar
added a commit
to toofar/qutebrowser
that referenced
this issue
May 15, 2024
On CI I'm seeing errors like:
07:37:36.107 ERROR network webenginequtescheme:requestStarted:99 NotFoundError while handling qute://* URL: Can't find pdfjs resource 'web/images/toolbarButton-zoomIn.svg'
1942
07:37:36.108 WARNING misc qutescheme:qute_pdfjs:552 pdfjs resource requested but not found: web/images/toolbarButton-menuArrow.svg
1943
07:37:36.108 ERROR network webenginequtescheme:requestStarted:99 NotFoundError while handling qute://* URL: Can't find pdfjs resource 'web/images/toolbarButton-menuArrow.svg'
1944
07:37:36.153 WARNING misc qutescheme:qute_pdfjs:552 pdfjs resource requested but not found: web/locale/en-US/viewer.properties
It seems debian doesn't package many pdf.js asset files, I can't figure
out why. There is a bug case about it here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989889
But there's no response. pdf.js-common has very few files in it: https://packages.debian.org/sid/all/pdf.js-common/filelist
Not sure why,maybe something they are doing with the gulp file?
Ignore these for now so I can test if the js errors are detected on CI,
then decide what to do. Keep ignoring these messages (but a better way),
only install pdf.js in docker, or install from git all the time.
This has been reported to us before: qutebrowser#7904
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: installed - from source as that's what we do when building a release *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')`
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: installed - from source as that's what we do when building a release *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')`
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: installed - from source as that's what we do when building a release *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')`
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: not installed - we install pdf.js from source when making a release so it would be nice to do that in tests too. But the `TestPDFJSVersion.test_real_file` unit tests fails because `version._pdfjs_version()` returns `unknown (bundled)`, not sure why. *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')`
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: not installed - we install pdf.js from source when making a release so it would be nice to do that in tests too. But the `TestPDFJSVersion.test_real_file` unit tests fails because `version._pdfjs_version()` returns `unknown (bundled)`, not sure why. *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')`
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: not installed - we install pdf.js from source when making a release so it would be nice to do that in tests too. But the `TestPDFJSVersion.test_real_file` unit tests fails because `version._pdfjs_version()` returns `unknown (bundled)`, not sure why. *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')`
toofar
added a commit
that referenced
this issue
May 18, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in tests, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: installed - we install pdf.js from source when making a release so it would be nice to do that in tests too. *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')` The `TestPDFJSVersion.test_real_file` unit tests currently fails because `version._pdfjs_version()` returns `unknown (bundled)`, not sure why. I think this is pre-existing and it also wasn't being run on CI.
toofar
added a commit
that referenced
this issue
May 20, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in these test jobs, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: installed - we install pdf.js from source when making a release so it would be nice to do that in tests too. *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')` The `TestPDFJSVersion.test_real_file` unit tests currently fails because `version._pdfjs_version()` returns `unknown (bundled)`, not sure why. I think this is pre-existing and it also wasn't being run on CI.
toofar
added a commit
that referenced
this issue
May 24, 2024
This installs pdf.js in a selection of CI jobs. Previously the PDF.js tests (in qutescheme.feature) were skipped in CI because it wasn't installed anywhere. There has been a couple of recent cases where pdf.js started depending on javascript features that are too new for even the most recent QtWebEngine to support. The aim of this commit is to catch that case. This doesn't add coverage for older webengine releases. This also incidentally updates the ace editor in these test jobs, since that is also updated by default by the update_3rdparty script. Hopefully that doesn't cause issues. The reasoning for installing on each type of job: *ubuntu jobs*: not installed - while our main test runs are on ubuntu there is an upstream issue where many assets used by pdf.js (like icons used in the toolbar) aren't packaged, see #7904. This causes warning messages because assets requested via qutescheme can't be found, which causes the tests to fail. We could a) install pdf.js from source instead of using the ubuntu one b) ignore the warning logs c) skip this environment and rely on tests elsewhere. I've chosen to do (c). I don't see a huge benefit in testing pdf.js across multiple environments if we aren't using it installed from the OS anyway. We could install from source but currently all the Qt < 6.5 tests are failing from some other JS error, and I think fixing that is out of scope of this issue. *docker Qt6*: installed - the archlinux pdfjs package works fine and we are only testing the most recent Qt versions because arch users are expected to stay up to date. *docker Qt5*: not installed - doesn't support JS features required by PDF.js. I guess we could install the legacy build from source here. I'm mostly worried about catching new breakages for this commit though *windows*: installed - we install pdf.js from source when making a release so it would be nice to do that in tests too. *macos*: not installed - the tests that were catching the breakages are end2end tests which we don't run on mac. And I think there was an error from the :versions tests here, don't remember. *bleeding edge*: installed - from source pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read properties of null (reading 'mainContainer')` The `TestPDFJSVersion.test_real_file` unit tests currently fails because `version._pdfjs_version()` returns `unknown (bundled)`, not sure why. I think this is pre-existing and it also wasn't being run on CI.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version info: qute://version
Does the bug happen if you start with
--temp-basedir?:pdf.jsis not launched, but the pdf is downloaded.Description: The button images are missing. Following error messages are in
~/.xsession-error:How to reproduce : Try to download a pdf from the internet..
The text was updated successfully, but these errors were encountered: