Fix raw HTML in Google Calendar event descriptions - #2193
Merged
callumalpass merged 2 commits intoAug 23, 2026
Merged
Conversation
martin-forge
force-pushed
the
martin-forge/plain-text-google-calendar-descriptions
branch
from
August 10, 2026 13:29
accd5a1 to
db11da4
Compare
The Google Calendar API documents the event description field as one that can
contain HTML, and Calendar's own editor stores markup there. TaskNotes consumes
that string as plain text everywhere: event tooltips, the ICS event info modal,
copy as markdown, the {{icsEventDescription}} template variable, generated note
bodies, and folder templates. Several of those write the value into the vault,
so raw markup was persisted into notes and folder names.
Normalize the description once at the Google provider boundary, preserving
paragraph breaks, list structure, and link targets. Plain text is returned
unchanged, so angle-bracketed addresses and placeholders are untouched.
Descriptions sent back to Google are always rebuilt from the task, so this does
not round-trip flattened text into Calendar.
martin-forge
force-pushed
the
martin-forge/plain-text-google-calendar-descriptions
branch
from
August 21, 2026 21:57
db11da4 to
ef167b8
Compare
# Conflicts: # docs/releases/unreleased.md
Owner
|
Thanks for the contribution, @martin-forge! |
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.
Problem
The Google Calendar API documents the event
descriptionfield as one that can contain HTML, and Calendar's own editor stores markup there. TaskNotes consumes that string as plain text everywhere: event tooltips, the ICS event info modal, "copy as markdown", the{{icsEventDescription}}template variable, generated note bodies, and folder templates.Several of those write the value into the vault, so raw markup was not only displayed — it was persisted into note bodies and folder names.
Fix
Normalize the description once at the Google provider boundary, parsing it with Obsidian's HTML sanitizer. Paragraph breaks, list structure, and link addresses survive the flattening.
Plain text is returned unchanged, so descriptions that merely contain angle brackets —
Contact <user@example.com>, placeholders such as<TBC>— are untouched. Normalizing at the boundary keeps every consumer plain-text rather than making each one handle HTML separately. ICS subscriptions read descriptions through their own path and are unaffected.Why not a plain
textContentreadtextContentdrops paragraph and list breaks and discardshrefvalues, so a description holding a bulleted agenda and a meeting link collapses into one run-on line with the link gone. The flattening pass exists to keep those three things and nothing more.Descriptions sent back to Google
Writes are unaffected.
TaskCalendarSyncServicerebuilds the description from the task before every update, and the drag/resize path sends only start and end. The normalized value is never round-tripped into Calendar, so formatting a user has set there is not flattened by this change.Relationship to earlier work
This complements #1882, which fixed the TaskNotes-to-Google export; this covers the Google-to-TaskNotes input side. It is also the actual cause behind #2102, which I closed after testing: the entity handling I proposed there was a symptom of descriptions being read as plain text, not the underlying problem.
Validation
50 focused tests pass. The full suite shows no new failures against current
main. Rebased on currentmain.