Skip to content

v1.11.0 - answers the library used to keep to itself

Latest

Choose a tag to compare

@maschine34675 maschine34675 released this 03 Sep 17:47
· 4 commits to main since this release

Two consumer wishes from CombatLog, and two things found underneath them
while answering. Nothing changes for a mod that does not use the new members.

A mod can ask whether its message was taken. TryPost mirrors the three
Post overloads and answers whether the command entered the library's queue:
false for a disposed handle or a refusal, true otherwise - and true means the
queue, not delivery; the outbox, the target document and the browser still
stand between it and the page. One-shot state a page must not miss - a
finished report - can now be retried when the library itself declined it,
instead of being recorded as sent.

A mod can ask how a Show or Hide finished. Show(cb) and Hide(cb)
answer exactly once with a VisibilityOutcome: Applied, AlreadyThere,
RefusedFullscreen, Superseded, Failed, Disposed or QueueRefused.
The answer travels like a script result, so it survives a dispose and goes
quiet only during shutdown. Every consumer's first request waits for the
browser view and is answered before Ready, and there is deliberately no
order promise between the answer and the VisibilityChanged it caused.
VisibilityChanged itself is untouched; the deeper fix that suggests itself

  • un-droppable visibility - is refuted on the record in the wishlist answers.

A flooding mod now costs itself. The 1.10.0 bound was one queue for every
mod in the process, so the first mod to fill it had every other mod's next
Show, Hide, LoadHtml or Post refused - and the comment beside it
claimed otherwise. Each overlay now has a share of 1,024 under the kept
ceiling of 4,096, obligations never count against a share, and the warning
names the overlay and its mod, at most once a minute. What a neighbour cannot
be spared is the wait behind the flooder's backlog: one queue, one thread,
about a tenth of a second at full rate. Latent rather than observed - every
shipping consumer throttles.

The exclusive-fullscreen refusal is no longer dead by construction. The
plugin read Screen.fullScreenMode from the overlay thread, where Unity's
binding is not thread-safe (get_width is marked thread-safe;
get_fullScreenMode is not), and the throw was swallowed as "supported". The
plugin's Update now caches the answer on the main thread. Reasoned from the
binding metadata rather than measured in the game, which apparently never
enters the mode.

Quieter on the way out. Closed no longer fires from a shutdown
teardown, Show/Hide and answers stay silent once shutdown began, and
main-thread dispatch tests shutdown before it tests for a pump. Also: a
Show in the moment between the window and its browser view no longer shows
a bare popup, and a Show on a failed overlay no longer arms the next
Toggle to hide a dead window.

Rows 79-92 in docs/FAULT-TESTS.md prove it (row 78 re-proven, row 21
extended), five of them by putting the fault back and watching the row fail;
the two limits - the fullscreen path and the bare-popup moment - are stated
in the rows rather than papered over. Consumers gate on 1.11.0 for the new
members; examples/WebOverlayGate.cs shows the shape.