A plugin's results to a search came all at once after its handler answered,
with nothing before: the block then appeared above the message list and
pushed it down, under a pointer about to click a row. onProvideSearchResults
handlers that search elsewhere (a CRM's search by meaning) take seconds.
Each plugin's answer now shows as it comes, and the store keeps the plugins
still asked. One that has not answered after 300 ms gets the block at a fixed
height with placeholder rows under "Searching for more results…"; its
entries then fill that height, so the list moves once, with its own results.
A plugin that answers at once (one not searching for this query) shows
nothing.
An entry from onProvideSearchResults may wrap what matched in <mark>, as
SearchSnippet/get does, and the block above the message list highlights
it with the list's own SearchSnippetText. The host keeps the marks,
escapes everything else and cuts the snippet by its text, closing a mark
it cuts, so the snippet is still never rendered as HTML.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A draft does not have to come from the composer: the JMAP API, another
client, an automation or a template can leave one in Drafts, and its
paragraphs carry no style, so every mail client lays them out with the
user agent's 1em margins. Since #1340 the composer stamps its own 4px
margin on every paragraph it serializes, so opening such a draft to read
it over and pressing Send re-flowed the message, and the composer showed
it at a spacing the recipient would never see.
What is loaded now keeps the spacing it came with: a paragraph with text
and no margin of its own is stamped with the mail default on the way in,
so the editor shows the message's own layout and what goes out is what
came in. The empty paragraph a new message is scaffolded with is left
alone, as are table cells, the quoted original and an embedded
signature. addParagraphSpacing skips a paragraph that already states a
margin, so nothing is declared twice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The export declared VERSION:3.0 but wrote vCard 4.0 syntax, and wrote the JSContact phone feature \"mobile\" as TYPE=MOBILE, which is no vCard type, so importers dropped such numbers.
- Declare VERSION:4.0 and write 4.0 throughout: basic-format dates and timestamps, data: URIs for inline media, VALUE=text for a UID or RELATED that is no URI, geo: URIs, lines folded at 75 octets, CRLF after every line, and the webmail's own PRODID.
- Map "mobile" to CELL and back; MAIN-NUMBER and x- types are kept.
- Write N before FN: some importers ignore the name otherwise.
- The contact form stores mobile phones as "mobile" (RFC 9553) and still reads the "cell" it used to write.