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>
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.
Every connected client sent a Core/echo every 30 seconds for as long as
the page was open, background tabs included: 120 requests an hour per
login, which on an otherwise idle night made up nearly all the traffic
a server saw. A client with an SSE stream already hears from the server
every 30 seconds, since the stream is opened with ping=30.
The keep-alive tick now skips the echo when the stream delivered an
event or a ping within the last 45 seconds and the previous echo did not
fail. A stream that goes quiet or drops lets the echo through again on
the next tick, so a lost connection is still reported and reconnected
as before, at most one tick later. Clients without a stream (no
eventSourceUrl, or over the per-tab stream budget) keep pinging every
30 seconds.
Linus Rath
Conrad
Jacob Zeitz
Linus Rath
Julien Béti
lucamzanon