Add a new preference, viewerCssTheme, to allow forcing the use of the light/dark viewer CSS themes (issue 12290)

[Snuffleupagus]

While this does work pretty well in my quick testing, it's very much a hack since as far as I can tell there's no support in the CSS specification for using e.g. a CSS variable to override a @media (prefers-color-scheme: dark) {...} block.

The solution implemented here is thus to edit the viewer CSS, by either removing the entire @media ... block in light-mode or by ensuring that its rules become unconditionally applied in dark-mode.
To simplify the overall implementation, since all of this does seem like somewhat of an edge-case, the viewerCssTheme preference will only be read during viewer initialization. (Similar to many other existing preferences, a reload is thus required when changing it.)

[pdfjsbot]

From: Bot.io (Linux m4)

---

Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/946bd442c0cdd65/output.txt

[pdfjsbot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.67.70.0:8877/946bd442c0cdd65/output.txt

Total script time: 4.16 mins

Published

• Viewer: http://54.67.70.0:8877/946bd442c0cdd65/web/viewer.html
• Viewer (ES5): http://54.67.70.0:8877/946bd442c0cdd65/es5/web/viewer.html

[timvandermeij]

I might be doing something wrong here, but when running PDFViewerApplication.preferences.set("viewerCssTheme", 2); in the console and reloading the page, I get the following stack trace and the viewer doesn't load:

Uncaught (in promise) Error: Permission denied to access property 0
    _forceCssTheme app.js:425
    initialize app.js:259
    run app.js:593
    webViewerLoad viewer.js:230
    __webpack_modules__ viewer.js:240
    Webpack 3
app.js:425:8

Edit: Huh, this happens only when I reload the page with the console opened. If I run that line of code in the console, close the console and then reload the page is does work :-s

[Snuffleupagus]

I might be doing something wrong here, but when running PDFViewerApplication.preferences.set("viewerCssTheme", 2); in the console and reloading the page, I get the following stack trace and the viewer doesn't load:

That's really weird, and unfortunately I can't reproduce it with Firefox Nightly 84.0a1 (2020-11-15) (64-bit); however I've submitted a patch which hopefully should prevent that particular error.
Does that improve things at all, i.e. is the error gone and does the theme switch as expected now?

Edit: Also, I've pushed an updated version of the patch which wraps all of the styleSheet fetching/parsing in try...catch to at least ensure that any errors won't prevent the entire viewer from loading.

[pdfjsbot]

From: Bot.io (Linux m4)

---

Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/a2663e4aabe9cdf/output.txt

[pdfjsbot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.67.70.0:8877/a2663e4aabe9cdf/output.txt

Total script time: 4.17 mins

Published

• Viewer: http://54.67.70.0:8877/a2663e4aabe9cdf/web/viewer.html
• Viewer (ES5): http://54.67.70.0:8877/a2663e4aabe9cdf/es5/web/viewer.html

[timvandermeij]

The reason for the error is at least more clear now: _forceCssTheme: "Permission denied to access property 0". Not sure why this happens, because it only happens when the console is open during the reload. If I close it, it's all good (using Firefox 82.0.3 on Arch Linux). This very much looks like the open browser bug https://bugzilla.mozilla.org/show_bug.cgi?id=1423300, and given that this works fine without the console involved we can land this. Thanks!

[Snuffleupagus]

This very much looks like the open browser bug https://bugzilla.mozilla.org/show_bug.cgi?id=1423300,

That one also references https://bugzilla.mozilla.org/show_bug.cgi?id=1673199, a regression in Firefox 82, which was fixed in Firefox 84 (and uplifted to Firefox 83); so there's a chance that it's actually fixed :-)

Thanks for landing this; hopefully it'll help users work-around some of the problems described in #12290.

[Snuffleupagus]

Given issues/bugs such as #12290 and bug 1660650, which show that a fair number of users clearly want to enforce the dark-theme for the PDF Viewer, I'm wondering if this is the sort of patch that we should consider uplifting to previous Firefox versions (once it's landed in Nightly of course)? /cc @brendandahl

As far as I'm concerned, it should be fairly safe to uplift this since all code which could potentially throw is wrapped in try...catch to prevent the viewer from breaking.

[qwer1304]

Why isn't this preference exported to Options?

[Snuffleupagus]

Why isn't this preference exported to Options?

Huh; please actually provide enough context with your question to make it easily understandable, since I've got no idea what "Options" you're referring to here!

Note that this is, in the master-branch (since it's not been part of an official release yet), already available through both the AppOptions and the Preferences, so I'm not sure what other "Options" there are here!?

[qwer1304]

I was referring to the 'Extension options' (I have built the extension from master and can set the cssTheme from preferences with the desired effect, but don't see anything in Extension options'.) This is in Chrome.

That was easy to fix:

• Added a new viewerCssTheme template to extensions/chromium/options/options.html

<template id="viewerCssTheme-template">
<div class="settings-row">
  <label>
    <span></span>
    <select>
      <option value="0">Auto</option>
      <option value="1">Light</option>
      <option value="2">Dark</option>
    </select>
  </label>
</div>
</template>

• Added title and description fields to viewerCssTheme in extensions/chromium/preferences_schema.json

"title": "Set Theme CSS",
"description": "What CSS should be used.\n 0 = Default (uses system CSS).\n 1 = Light.\n 2 = Dark.",