-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use default colors only in forced-colors mode (bug 1778068) #15135
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see questions inline.
web/app.js
Outdated
: { | ||
background: null, | ||
foreground: null, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is overkill, since all code should already be able to deal with pageColors
being unset/undefined.
: { | |
background: null, | |
foreground: null, | |
}; | |
: null; |
web/app.js
Outdated
background: AppOptions.get("pageColorsBackground"), | ||
foreground: AppOptions.get("pageColorsForeground"), | ||
}; | ||
const pageColors = window.matchMedia("(forced-colors: active)").matches |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally speaking, it seems a little bit unfortunate to essentially make it impossible for users to specify custom values for these PDF.js-specific color preferences.
Looking at the bug, could we perhaps only disable this functionality when the "problematic" (general) Firefox preferences have been set?
For context: Years ago we had code which checked the browser.display.document_color_use
preference; this was removed (since it'd become unused) in a977882 and mozilla/gecko-dev@7015ab6
Would it make (any) sense to re-instate similar checks here, and do something like this instead?
const pageColors = window.matchMedia("(forced-colors: active)").matches | |
const pageColors = | |
window.matchMedia("(forced-colors: active)").matches || this.supportsDocumentColors |
web/app.js
Outdated
background: AppOptions.get("pageColorsBackground"), | ||
foreground: AppOptions.get("pageColorsForeground"), | ||
}; | ||
const pageColors = PDFViewerApplication.useUserDefinedColors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't the following work here?
const pageColors = PDFViewerApplication.useUserDefinedColors | |
const pageColors = this.useUserDefinedColors |
web/firefoxcom.js
Outdated
static get documentColorUse() { | ||
const support = FirefoxCom.requestSync("documentColorUse"); | ||
return shadow(this, "documentColorUse", support); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remember to add a suitable method here as well, such that the GENERIC viewer works as intended:
Line 185 in bde4663
Also, what is an appropriate value to use in the DefaultExternalServices
-class; perhaps 2
in that case?
web/app.js
Outdated
@@ -730,6 +732,21 @@ const PDFViewerApplication = { | |||
return this.externalServices.supportedMouseWheelZoomModifierKeys; | |||
}, | |||
|
|||
get useUserDefinedColors() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe allowDocumentColorUse
instead here, to have slightly more consistent method names between the app.js
, firefoxcom.js
, and PdfStreamConverter.jsm
files?
My idea with the color change was to change the colors only in HCM (color choice in canvas is binary: either on the CanvasText side or on the Canvas one, there is no shade). |
Right, the situation here is a bit messy since we "advertised" the pageColors feature in the release notes of version How about we try to limit the scope of things here to address the Firefox bug, but still support the HCM-case properly, while also allowing users to override things if desired/needed?
|
Yes I thinks it's the right solution here. |
@Snuffleupagus, I wrote what you proposed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me, with missing doc-comment added; thank you!
/botio integrationtest |
1 similar comment
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @calixteman received. Current queue size: 1 Live output at: http://54.241.84.105:8877/33b8d1be01c00ab/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @calixteman received. Current queue size: 1 Live output at: http://54.193.163.58:8877/ebaee8a9721103f/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/33b8d1be01c00ab/output.txt Total script time: 4.71 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/ebaee8a9721103f/output.txt Total script time: 7.33 mins
|
There is a patch in review for Firefox:
https://phabricator.services.mozilla.com/D151158