Workaround WebKit canvas rendering bug when zooming PDFs

[nicolo-ribaudo]

WebKit has a bug when rendering canvases that have their width defined as relative to their container, and their parent is resized. This causes a This causes a "tearing" effect when zooming in PDFs past a certain threshold, which is device-dependent but tends to be between 120% and 200%.

The DOM structure around the canvas is as follows:

div.pdfViewer [ --scale-factor: ...; ]
  > div.page [ width: round(var(--scale-factor) * ..., 1px); ]
    > div.canvasWrapper
      > canvas

Setting width: inherit on the div.canvasWrapper and on the canvas is equivalent to explicitly specifying the same width property in pixels as in div.page, thus making Safari properly redraw the canvas on resize.

See https://bugs.webkit.org/show_bug.cgi?id=267986 for more details on the WebKit bug.

Fixes #16155, fixes #16329, fixes #17459, fixes #17713

#17459 shows a good video of what the rendering bug fixed by this PR is.

---

Note that it's very easy to fix this for downstream consumers of pdf.js. I think adding this CSS to their page is enough:

.pdfViewer .canvasWrapper,
.pdfViewer .page canvas[zooming] {
  width: inherit !important;
}

however, I'm opening this PR because

1. I noticed that multiple people submitted issues about it
2. the fix is very minimal and does not impact other browser, given than in this case width: 100% and width: inherit should have the same behavior.

Marking as a draft because I tested it on an iPad but I'm waiting for something with an iPhone to confirm that this indeed works for them too :)

[Snuffleupagus]

Sorry, but why is this not a WebKit bug that ought to be addressed in those browsers rather than worked-around here?

2. the fix is very minimal and does not impact other browser, given than in this case width: 100% and width: inherit should have the same behavior.

Please note that we really want to avoid introducing any browser-specific compatibility hacks in the main code-base.
The reasons for this is to not negatively impact readability/maintainability of the code, and to avoid having to deal with any potential regressions later (given the "should"-part this just seems like unnecessary risk).

Please keep in mind that the built-in Firefox PDF Viewer is the primary development target for the PDF.js library.

[box10]

thanks so much. this seems to work fine on iPad and from my quick test, also on iPhone

[extremegf]

I can confirm, that adding css

.pdfViewer .canvasWrapper,
.pdfViewer .page canvas[zooming] {
  width: inherit !important;
}

to viewer.css completely resolves the issue on iPhone iOS 16.7.4.

[Snuffleupagus]

As mentioned in #17571 (review) we generally don't want to add browser-specific compatibility hacks in the main code base, even more so when the browser in question is only listed as "Mostly" supported; please note https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#legacy-build

[calixteman]

I had a look and removing the display property:

pdf.js/web/pdf_viewer.css

Line 158 in f3b03e5

display: block;

(or setting it to inline) fixes the issue for me with Safari on mac.
I don't see any reason why it's block, as far as I can tell it comes from:
#136
Since we add some svg elements in the canvas wrapper when highlighting, I checked if everything is ok and it seems to be.
So I guess we can remove it.
And tbh, I wasn't super excited by the original patch, especially because it's hard to test and because I had the feeling that even if it was small it could have led to easily introduce some regressions in the future.
@nicolo-ribaudo, could you check that it fixes the issue on ipad/ios (I don't have such devices) ? and if it's ok for you, please make an other PR.

[Snuffleupagus]

Re #17571 (comment), please let's make a new release first (as mentioned elsewhere) before we consider hacking around a Safari-only bug.

[calixteman]

Re #17571 (comment), please let's make a new release first (as mentioned elsewhere) before we consider hacking around a Safari-only bug.

Yes of course, there is no rush here.