Ensure TextLayer hiddenCanvasElement is layout-neutral by default

[RolandWArnold]

TextLayer creates a helper canvas with class hiddenCanvasElement and appends it directly to document.body, which can adversely affect the host-page layout/scrolling behavior.

The stock viewer stylesheet web/pdf_viewer.css already makes this element layout-neutral via .hiddenCanvasElement { ... display: none; }, but direct pdfjs-dist / TextLayer consumers are not required to load web/pdf_viewer.css. Consumers that scope the viewer stylesheet to avoid global CSS leakage also lose this protection, since the helper canvas is appended outside the scoped viewer subtree.

This change applies the essential layout-neutralizing rule at the creation site, so the display-layer helper does not depend on viewer CSS to avoid participating in host-page layout.

Related context:

• cleanup hiddenCanvasElement when using renderTextLayer #18086 discussed the same body-appended helper element from a lifecycle/cleanup perspective.
• react-pdf added the .hiddenCanvasElement CSS rule downstream in Hidden canvas element may break layout wojtekmaj/react-pdf#1815 to avoid layout side effects.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.50%. Comparing base (7ade637) to head (16d82e0).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #21218      +/-   ##
==========================================
+ Coverage   79.48%   79.50%   +0.01%     
==========================================
  Files         254      254              
  Lines       64859    64860       +1     
==========================================
+ Hits        51553    51565      +12     
+ Misses      13306    13295      -11     

Flag	Coverage Δ
fonttest	8.64% <ø> (ø)
integrationtest	66.18% <100.00%> (+<0.01%)	⬆️
unittest	55.47% <50.00%> (+0.01%)	⬆️
unittestcli	54.72% <0.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Snuffleupagus]

Given that using the textLayer requires also using the pdf_viewer.css file, since otherwise things are simply not guaranteed to work, it's not clear (at least to me) why this effectively duplicated code should be added here!?

[RolandWArnold]

Thanks for the quick review.

I understand that TextLayer is expected to be used with web/pdf_viewer.css. The case I was trying to cover here is that this particular rule is unusual because the element it targets is not inside the viewer subtree: TextLayer creates the canvas and appends it directly to document.body.

Consumers building custom viewer chrome may include the viewer CSS but scope/rewrite its selectors to avoid leaking PDF.js viewer styles into the surrounding application. In that setup, the rest of the text-layer CSS is present, but .hiddenCanvasElement can be scoped along with everything else and no longer matches the body-appended helper canvas.

That's why I thought applying the essential layout-neutralizing property at the creation site might be appropriate: the body-appended helper would not depend on a viewer-subtree stylesheet rule to avoid participating in host-page layout. react-pdf also had to add the .hiddenCanvasElement rule downstream in wojtekmaj/react-pdf#1815.

If the project’s position is that TextLayer consumers must load web/pdf_viewer.css without selector scoping, and scoped or rewritten viewer CSS is unsupported, I’m happy to close this.

[Snuffleupagus]

Please also remember to write a good commit message, since a single line is rarely sufficient.

[RolandWArnold]

Updated again:

• removed the now-unused hiddenCanvasElement class
• kept hiddenCopyElement’s id because test/integration/copy_paste_spec.mjs uses #hiddenCopyElement to wait for/query the copy helper element
• expanded the commit message

[Snuffleupagus]

/botio browsertest

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

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

Live output at: http://54.193.163.58:8877/5780beff9529d55/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

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

Live output at: http://54.241.84.105:8877/05f99bdd87ab526/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.241.84.105:8877/05f99bdd87ab526/output.txt

Total script time: 18.64 mins

• Regression tests: FAILED

  different ref/snapshot: 1

Image differences available at: http://54.241.84.105:8877/05f99bdd87ab526/reftest-analyzer.html#web=eq.log

[moz-tools-bot]

From: Bot.io (Windows)

---

Failed

Full output at http://54.193.163.58:8877/5780beff9529d55/output.txt

Total script time: 24.59 mins

• Regression tests: FAILED

  different ref/snapshot: 1

Image differences available at: http://54.193.163.58:8877/5780beff9529d55/reftest-analyzer.html#web=eq.log

[RolandWArnold]

Rebased on current master and force-pushed.

I also rechecked the helper-element changes and don't see anything that would obviously explain the issue17779-partial diff. Could you rerun botio when convenient? If it still reproduces on this rebased branch, I'll investigate further.

[timvandermeij]

The firefox-issue17779-partial-page1 failure is not related to this patch, and instead a pre-existing failure that we need to fix. I have created issue #21276 to track that, but for the scope of this PR you can ignore it.

[RolandWArnold]

Thanks for letting me know.

[calixteman]

LGTM. Thank you.