Repository navigation
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #21535 +/- ##
==========================================
- Coverage 90.31% 90.26% -0.06%
==========================================
Files 269 269
Lines 67534 67580 +46
==========================================
+ Hits 60994 61000 +6
- Misses 6540 6580 +40
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Author
|
@calixteman I applied the changes discussed |
calixteman
reviewed
Jul 20, 2026
calixteman
requested changes
Jul 20, 2026
LoukasPap
marked this pull request as draft
July 22, 2026 13:48
LoukasPap
force-pushed
the
fix/false-enable-of-highlights
branch
2 times, most recently
from
July 25, 2026 22:01
9ab860e to
4d5fca8
Compare
LoukasPap
marked this pull request as ready for review
July 25, 2026 22:02
LoukasPap
commented
Jul 25, 2026
LoukasPap
had a problem deploying
to
code-coverage
July 26, 2026 10:00 — with
GitHub Actions
Failure
Contributor
|
It doesn't work unfortunately, here's a STR:
The modified freetext is no more visible. An other problem, here's a STR:
A highlight is visible. |
Author
|
Many cases are covered now. Changes are a little big but I believe the bug is now completely fixed. |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #21498
When the "Show all" toggle is off, the highlights must stay hidden: while scrolling, after leaving editing mode, and when entering again.
Why hiding the editors isn't enough
A highlight can be shown by three different surfaces:
svg.highlightwhile editingHiding an editor only takes care of the first one. As soon as the editing mode is left, or a page is rendered for the first time while scrolling, the annotation is painted into the canvas again and the highlight reappears.
Keeping them out of the canvas
Whether an annotation is painted is decided by
mustBeViewedWhenEditing, which skips the ids it's given. So the highlights to hide must be listed by their annotation id, and that list can't be built from the existing editors: a page rendered after exiting editing mode, has no editor at all. It has to come from the document itself, throughgetAnnotationsByType.That call takes annotation types, which is where the two kinds of highlight diverge. A highlight on a text is saved as a
/Highlight, but a free (hand-drawn) one is saved as an/Inkwith/IT /InkHighlight(seeAnnotationFactory). Asking for highlights alone silently misses every free highlight, so both types are fetched and the ink ones are kept only when their intent says they're highlights.Getting the ids to the renderer
AnnotationStoragealready exposesmodifiedIds, the annotations whose edited version is drawn instead of the original. The highlights to hide need the same treatment but for the opposite reason — they're unmodified — so rather than widening the meaning ofmodifiedIds, they're kept apart:setHiddenIds(ids)/get hiddenIdshold them, with their own hash, computed lazily and cached exactly likemodifiedIds;{ids, hash}pair through a shared#makeIdsWithHash, which is the only change made tomodifiedIdsitself;getRenderingIntentunions the two sets and feeds both hashes into the rendering cache key so either concern invalidates on its own.PrintAnnotationStorageoverrideshiddenIdsto an empty set, as it already does formodifiedIds: hiding a highlight in the viewer must not remove it from the printed output.Why the
hiddenIdsaren't merged intomodifiedIdsI first pushed them straight into
modifiedIds, which is shorter and works. Two things made me keep them apart instead.setHiddenIdshad to invalidate its cache, so switching "Show all" threw away the modified ids and the next render rebuilt them by callingserialize()on each editor.Separating them means a toggle recomputes only what it actually changed, and
modifiedIdskeeps its original meaning.The union is still handed to the worker under the name
modifiedIds, since that's what the whole render path calls it. Renaming it there would make the intent clearer, but it reaches intosrc/core/for what is otherwise a display-layer fix. I can change that in a follow-up, or here, if you'd prefer.Consequences of the fetch being asynchronous
Collecting the annotations walks the whole document, which brings two things to handle:
Tests
test/integration/highlight_editor_spec.mjstest/integration/freetext_editor_spec.mjsThe fourth and fifth ones read the canvas because that's the surface which had the bug: an earlier version of this patch passed a DOM-based assertion while the highlights were still fully painted. Counting the saturated pixels of a page is shared as
countHighlightPixelsintest_utils.mjs, next toisCanvasMonochrome.test/pdfs/comments.pdfgains a free highlight on page 4, a page which isn't rendered when the document is opened.