MountPlugins registered every plugin window with authoredGeometryRevision
hard-coded to 0 (RetailUiRuntime.cs), so RetailWindowLayoutPersistence's
MigrateAuthoredGeometry -- gated on "saved revision >= authored revision"
-- never migrated a plugin window's saved size: 0 >= 0 forever. MossTank's
panel went 856x236 -> 984x271 and every user with a stored layout stayed
stuck at 856x236 with no way to see the new default.
Two changes:
1. MountPlugins now passes RetailWindowManager.ComputeAuthoredGeometryRevision
(added previous commit) as the plugin window's authoredGeometryRevision,
derived from the panel's own authored width/height/minw/minh/resizable.
2. MigrateAuthoredGeometry now compares revisions for INEQUALITY
(saved.Revision == authored.Revision) instead of ordering
(saved.Revision >= authored.Revision). A hash is not an incrementing
counter -- two different authored sizes can hash in either order -- so
"the authored size changed" has to mean "the value differs", not "the
value went up". Built-in windows' hand-picked incrementing literals
(chat: authoredGeometryRevision = 1) are unaffected: no existing saved
revision is ever equal to a later, different literal either way.
Mutation shown to fail first: the two new PluginMarkupPanel_AuthoredSizeChanged_*
tests in RetailWindowLayoutPersistenceTests.cs reproduce the exact bug with
concrete literals (856x236/400/150/true -> 984x271/... and
200x100/100/80/true -> 220x110/...) chosen so ComputeAuthoredGeometryRevision's
OLD hash is >= the NEW hash for each pair -- confirmed via a throwaway probe
before writing the assertions, so the pre-fix run fails deterministically
rather than by chance of hash ordering. Both failed before this commit
(size stayed at the old authored extent) and pass after
(PluginMarkupPanel_AuthoredSizeUnchanged_KeepsUserResizedSize, unaffected
either way, is a regression-safety companion). Full RetailWindow/Markup/
PluginSidePanel filter: 249 passed (was 246), 0 failed, 0 skipped.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>