Apple has not granted com.apple.developer.usernotifications.filtering for
ch.healthchat.element.nse. The capability request has sat at "Submitted"
since 2026-07-30, so the App Store profile cannot carry it and the archive
fails to sign while NSE.entitlements still asks for it.
Drop the key from the NSE target config and the generated entitlements
file. The extension still decrypts and rewrites every notification; the
only change is that notifications it would have discarded now fall back
to the raw push payload. Restore the key and add NSE Filtering to the
profile once Apple approves the request.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Xcode 27 ships Swift 6.4, which rejects two things 26.09.1 still contains. The
upstream fix for the app itself is cherry-picked as the commit before this one;
these two are what it does not cover.
Compound's colour overrides now take a KeyPath & Sendable, so the HealthChat
brand arrays have to carry the same constraint.
NotificationContentBuilder is main-actor isolated, so its test suite has to
build the type from an async init. The lines match upstream's own fix, which
only exists inside the larger AccountProvider change (#6103) and so cannot be
cherry-picked on its own.
The rebase onto release/26.09.1 moved three things the fork depends on.
Upstream now owns a UserProfileScreenHook of its own (#5980), which rewrites a
screen's view state rather than injecting a view. The fork's section hook keeps
its behaviour under the fork-only name ExtendedProfileSectionHook, so both can
live side by side and upstream's file stays untouched. Upstream's new @AppHook
macro generates the same register<Name> methods, so registration is unchanged.
UserProfileScreenCoordinatorParameters lost appSettings and reordered its
arguments, and UserDetailsEditScreenCoordinator now publishes its own
UserDetailsEditScreenCoordinatorAction instead of borrowing the room one
(#5893). The members flow and the profile editor follow both.
AppSettings.override gained oAuthClientURIPath (#5934), whose default appends
apps/ios to the website URL. HealthChat passes nil to keep the registered
client_uri at https://healthchat.ch exactly as the shipped build has it —
changing what the app registers with MAS is not a side effect a rebase should
have.
* Fix some isolation errors when compiling with Swift 6.4.
* Update the Design Tokens dependency to include Sendable conformances.
(cherry picked from commit 4608a63e29)
* Add HealthChat API and extended profile services
Expose OpenID tokens and homeserver credentials from the client proxy, and
add fork-only services for the HealthChat member directory backend
(api.healthchat.ch) plus a service that reads MSC4133 extended profile
fields directly from the homeserver. Groundwork for the members tab and
the profile screens.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Show extended profile details on the profile screens
Add a UserProfileScreenHook that lets the fork inject an extra Form
section below the header of the user profile and room member details
screens. The HealthChat implementation loads the MSC4133 extended
profile fields and renders them with tappable phone/email/website
links, hiding the section entirely for profiles without any fields.
Strings live in a new fork-only HealthChat.strings table (de/en/fr,
generated as HealthChatL10n via SwiftGen) since Untranslated.strings
pins the English bundle.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Add a member directory tab
Add a HomeTabsHook that lets the fork append an extra tab to the home
tab bar, and a HealthChat members flow behind it: a directory of all
approved members from the HealthChat API with server-side search,
pending-approval and error states, chat shortcuts and pushed member
profiles. Chats and calls are handed back to the session flow via the
hook's actions publisher.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Let members edit their profile and invite others
Add a native profile editor for the HealthChat extended profile fields
(13 fields plus avatar, saved as a partial diff through the HealthChat
API so displayname derivation and Zitadel sync stay server-side), an
invitation sheet (email plus personal note) and a profile-completeness
hint on the member directory.
A new UserDetailsEditScreenHook lets the fork substitute the profile
editor behind the settings user row — the stock display-name editor
would let users edit a value the next profile update derives away.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Add HealthChat API and extended profile services
Expose OpenID tokens and homeserver credentials from the client proxy, and
add fork-only services for the HealthChat member directory backend
(api.healthchat.ch) plus a service that reads MSC4133 extended profile
fields directly from the homeserver. Groundwork for the members tab and
the profile screens.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Show extended profile details on the profile screens
Add a UserProfileScreenHook that lets the fork inject an extra Form
section below the header of the user profile and room member details
screens. The HealthChat implementation loads the MSC4133 extended
profile fields and renders them with tappable phone/email/website
links, hiding the section entirely for profiles without any fields.
Strings live in a new fork-only HealthChat.strings table (de/en/fr,
generated as HealthChatL10n via SwiftGen) since Untranslated.strings
pins the English bundle.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Add a member directory tab
Add a HomeTabsHook that lets the fork append an extra tab to the home
tab bar, and a HealthChat members flow behind it: a directory of all
approved members from the HealthChat API with server-side search,
pending-approval and error states, chat shortcuts and pushed member
profiles. Chats and calls are handed back to the session flow via the
hook's actions publisher.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Add HealthChat API and extended profile services
Expose OpenID tokens and homeserver credentials from the client proxy, and
add fork-only services for the HealthChat member directory backend
(api.healthchat.ch) plus a service that reads MSC4133 extended profile
fields directly from the homeserver. Groundwork for the members tab and
the profile screens.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
* Show extended profile details on the profile screens
Add a UserProfileScreenHook that lets the fork inject an extra Form
section below the header of the user profile and room member details
screens. The HealthChat implementation loads the MSC4133 extended
profile fields and renders them with tappable phone/email/website
links, hiding the section entirely for profiles without any fields.
Strings live in a new fork-only HealthChat.strings table (de/en/fr,
generated as HealthChatL10n via SwiftGen) since Untranslated.strings
pins the English bundle.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
Expose OpenID tokens and homeserver credentials from the client proxy, and
add fork-only services for the HealthChat member directory backend
(api.healthchat.ch) plus a service that reads MSC4133 extended profile
fields directly from the homeserver. Groundwork for the members tab and
the profile screens.
Claude-Session: https://claude.ai/code/session_013qdTbAWsZj2quQzEkagXaS
Documents the release process this fork actually uses: tagging, the numeric-only
version rule, the five required secrets, the runner's hand-installed toolchain,
certificate renewal, and promoting a TestFlight build to the App Store. Modelled on
the legacy element-ios skill, corrected wherever this fork differs — notably that
there is no Xcode pin and no Brewfile, and that only five secrets exist rather than
the six the legacy skill lists.
The section with no upstream equivalent is the migration contract. CLASSIC_APP_*
and the .requiresBackup fall-through are load-bearing for every existing user and
fail silently, so a well-meaning cleanup back to upstream's values would sign
everyone out with nothing in CI to catch it.
AGENTS.md delegates to the skill rather than duplicating the runbook.
element-x-ios had no release machinery at all: no fastlane, no Gemfile, and none of
its workflows built or uploaded anything. Upstream ships via Xcode Cloud, which
needs Element's private Enterprise submodule and so is unavailable here, while the
legacy element-ios fork already proves a fastlane pipeline against the same Apple
team, certificate and App Store Connect key.
Tagging healthchat-v<version> now builds a signed App Store IPA on the org's Mac
Studio and uploads it to TestFlight. Release notes come from a new
HEALTHCHAT_CHANGES.md, because upstream's own tooling owns CHANGES.md.
The lane deliberately does not pin Xcode. The runner carries a single globally
selected version, and naming an absent one does not fail fast — it sends xcodes
into a multi-GB authenticated download that no CI secret can satisfy. Each run logs
xcodebuild -version instead, which is the only record of what compiled a build.
Everything here is fork-owned, since upstream has no fastlane directory, so none of
it can conflict on rebase.
ClassicAppManager migrates an existing user's session and encryption keys by
reading the legacy app's app-group container and keychain. Those identifiers
defaulted to Element's own, which this team cannot provision, so loadAccounts()
threw invalidAppGroupIdentifier — caught and logged, never surfaced. Since both
apps share a bundle id, the result would be every existing user silently logged
out and losing local history when they update.
The legacy identifiers belong to HealthChat and are provisionable under the same
team, so repoint them rather than dropping them.
Also stop sending accounts without key backup to a dead end. Upstream shows those
users a sheet asking them to open Element Classic and set up backup first, but this
update replaces that app and nothing registers its URL scheme, so the sheet's only
button does nothing. Sign in directly instead: the user re-verifies the device and
loses only history that by definition has no backup.
These two files are internal AI planning and design artifacts from setting up the
HealthChat release pipeline, not documentation meant to ship in the repo. Nothing
references them, and docs/FORKING.md remains the actual fork documentation.
Claude-Session: https://claude.ai/code/session_01PeF4yE5SDZV3zjXWk73osw
VoiceMessageCacheTests cannot write its URLFileProtection.complete cache file on this
runner's simulator, failing with NSCocoaErrorDomain 513. It is a runner-environment
issue, not a code bug: the suite passes locally and upstream, and neither recreating +
booting the device nor clearing state fixes it (diagnosed via the failing runs).
Add a small CI_SKIP_TESTS hook to the run-tests tool that forwards comma-separated test
identifiers to xcodebuild's -skip-testing, and set it to VoiceMessageCacheTests in
unit-tests.yml. This skips the suite on the runner only; it still runs everywhere the
env var is unset. Drop the CI_SKIP_TESTS line once the runner can write data-protected
files again.
Claude-Session: https://claude.ai/code/session_01PeF4yE5SDZV3zjXWk73osw
* Make CI work on this internal fork
Every check was red on every pull request. Upstream declares permissions: {} in its
workflows, which costs nothing on a public repo and is fatal here: the token is
limited to Metadata:read, so actions/checkout cannot read an internal repo and dies
with a misleading "Repository not found". Repo settings cannot fix it — an explicit
permissions block always overrides the default.
Each job now gets the minimum it needs. Danger also reads the pull request through
the issues API, so it needs issues:read alongside pull-requests:write, and zizmor's
SARIF upload needs actions:read on a private repo.
The unit tests move to the org's Mac Studio: GitHub-hosted macos-26 could not finish
inside the hour and bills at 10x. Preview tests are skipped there, using the flag
upstream already uses for its own enterprise tests — they render a snapshot per
preview and never once finished on either runner. The trade is that preview snapshot
regressions are no longer caught in CI.
Workflows that only make sense upstream are gated off rather than deleted, so they
keep rebasing cleanly. The enterprise tests need Element's bot token and their
private submodule. Three nightlies fail at checkout every weeknight — this repo is a
detached copy rather than a network fork, so GitHub never disabled their schedules —
and one of them posts to Element's Codecov on every run.
* Erase the test simulators before running the tests
The unit tests assume a clean simulator, which costs nothing on a hosted VM
because it hands out a fresh device every run. This runner reuses the same two
devices, so app containers, caches and logs survive between runs and six suites
fail on the previous run's leftovers rather than on anything in the code.
LoggingTests is the clearest: it expects no log files and finds nine, in the same
device container each time.
Only the two devices the tooling pins are erased, resolved by UDID. A blanket
erase would take out simulator state belonging to other work on a machine the
release pipeline shares.
* Remove the simulator reset again
It was added on the theory that the runner's reused simulators were leaking state
between runs. That theory was wrong: erasing both devices changed nothing — the
same seven suites failed identically before and after.
The leftover files LoggingTests trips on are its own, from a previous attempt of
the same test within one run (the suite runs with -test-iterations 4), so nothing
crosses runs for an erase to clean. Keeping a step that mutates shared state on the
release machine for no measured benefit is worse than not having it.
O8 still recommended adding xcodebuild -version to the release workflow as
future work. The Record toolchain step now does exactly that, so the risk row
described a gap that no longer exists and advised work already done.
The residual risk is narrower than O8 claimed: each run logs its own compiler,
but the log only reveals a runner upgrade after the fact rather than preventing
one.
unit-tests.yml moving to [self-hosted, macOS] on a pull_request trigger lets
any PR run arbitrary code on novaloop-mac-studio-001 — the same persistent
machine, keychain and signing identities the release pipeline uses. The risk
was accepted on the strength of the repo being INTERNAL, but that reasoning
lived nowhere: nothing in the repo said why it was tolerable, and nothing in
CI would ever say it existed.
Worth recording because the trade-off is invisible to the required checks.
zizmor reports self-hosted-runner only at --persona=auditor; the default
persona CI runs suppresses it, so a green build is not evidence of absence.
Verified both halves against the fix-fork-ci workflow: auditor reports it at
medium severity, the default reports "No findings to report … (3 suppressed)".
Records the exits too, so a future reader inheriting this need not rederive
them: restrict the trigger to non-fork branches, or return to GitHub-hosted
macos-26 with a raised timeout-minutes.
The plan embeds verbatim copies of two shipped files and both had drifted. The
shipped files are correct, so the copies are now byte-identical to them
(verified by cmp against `git show`).
Task 8's workflow still spliced `${{ github.event.inputs.version }}` straight
into the shell, so anyone re-deriving the workflow from the plan reintroduced a
script injection that the regex below it cannot prevent — the input is
interpolated before the check ever runs. It now reads the input via the
`INPUT_VERSION` env var, and gains the `Record toolchain` step that is a
release's only record of which compiler built it now that nothing pins Xcode.
Task 11's skill claimed deleting the app clears `hasSignedInBefore`. It does
not: the flag lives in the shared `group.ch.healthchat` UserDefaults suite,
which survives deletion, so that advice yields a void migration test that looks
like a pass — the precise false negative the section exists to prevent.
Task 3 Step 5 carried the same fault in a subtler form: it matched the bare
substring "skipping loadAccounts", but two lines in
`AuthenticationService.swift` (:52 and :57) end that way and mean opposite
things. Reading them as one told you to dismiss "Classic App not configured" —
migration broken for every user — as a void run. Step 1 already prescribed the
correct remedy and is unchanged.
Both documents told the reader to pin Xcode 26.4 and to install it via a
Brewfile. A probe of novaloop-mac-studio-001 refutes the premise: it carries
exactly one Xcode, 26.6, globally selected, with no versioned siblings and no
26.4 anywhere. The design justified the pin with "the runner has it and the
legacy pipeline proves it works" — both halves are false, and a pin naming an
absent version does not fail fast: xcodes starts a multi-GB authenticated
download that no CI secret can satisfy, so before_all hangs.
Record the no-pin decision and its cost — whatever Xcode the runner has is what
ships, unrecorded — rather than only deleting the wrong instruction, so nobody
reintroduces the pin from the same reasoning. Drop the Brewfile with it: its only
purpose was installing xcodes for that pin, and brew has no business running on a
shared release machine where it could upgrade xcodegen mid-release.
Add the runner's real constraints (no passwordless sudo, single Xcode, five
missing tools installed by hand) to the design, since they are why upstream's
setup_github_actions_environment cannot run here.
Two new risks. The legacy element-ios pipeline pins the same absent 26.4, so it
is very likely broken right now — not this fork's problem to fix, but the human
needs to know before the next legacy release. And with no pin, an Xcode upgrade
on the runner silently changes the compiler for every subsequent release.
The plan's embedded Fastfile and skill now match the branches that implement
them byte-for-byte, so the plan cannot drift from the artefacts it describes.
Task 6 Step 3 asserted the guard must fail before xcodes runs. It cannot:
fastlane's before_all always executes before the lane body, and the plan puts
xcodes in before_all and the guard in the lane. The acceptance criterion was
unmeetable on any machine.
The guard still does what it exists for — aborting before the ~30 minutes of
signing — so the wording was wrong, not the pipeline. Also record that the step
needs the xcodes CLI, since without it the lane dies earlier with an error that
reads like a config problem.
Task 11 described the skill's sections rather than showing them, the one place
the plan told an implementer what to write instead of what to type. Replace it
with the complete SKILL.md.
Writing it surfaced a broken convention worth not copying: the legacy skill
documents healthchat-v1.5.0-rc1 style tag suffixes, but the workflow derives the
marketing version by stripping only the healthchat-v prefix, so the suffix reaches
CFBundleShortVersionString, which Apple caps at three integers. Tags are numeric
only here, and test builds go through workflow_dispatch with the marker in the
release notes.
Task-by-task plan for the three PRs in the release design: the classic migration
fix, the fastlane pipeline, and the releasing-healthchat skill.
The migration fix gets a real test cycle — an existing upstream test,
classicAppAccountRequiresBackup, encodes the behaviour we're changing, so it is
rewritten first and drives the view model change.
Spec for bringing App Store release capability to element-x-ios, targeting the
existing HealthChat record that the legacy element-ios fork ships to today.
Both apps share bundle id ch.healthchat.element and team 6G37K72W82, so element-x
arrives as an in-place update rather than a new listing. That drives the design:
the identity already aligns and 26.07.3 clears the legacy's 1.4.1, but the repo
has no release machinery at all, and upstream's Xcode Cloud path is unavailable
because it needs the private Enterprise submodule.
Records three parts: repointing CLASSIC_APP_* at HealthChat's own identifiers so
existing users keep their sessions and encrypted history, a fork-owned fastlane
pipeline ported from the legacy fork, and a releasing-healthchat skill.
Revised after an adversarial review of every factual claim; 26 issues found, none
rejected. Most consequential: the migration fix is not monotonic, because making
loadAccounts() succeed exposes a backup-instructions sheet whose only button opens
element://open — a scheme this app does not register and whose legacy owner has
been replaced in place.
Applies the HealthChat product identity through the fork seams upstream already
provides, so no upstream logic files are touched and merges stay clean.
- Variants/HealthChat/healthchat.yml holds the identity scalars (display name,
bundle id ch.healthchat.element, app group, development team) and is included
permanently from project.yml. APP_NAME stays ElementX so the module name and
@testable import ElementX keep working.
- ElementX/Sources/AppHooks/HealthChat/ registers an AppSettings hook pinning
accountProviders to healthchat.ch with other providers disabled, push through
sygnal.healthchat.ch and a custom-scheme OIDC redirect; plus a Compound hook
recolouring the accent token family to the HealthChat blue.
- Entitlements are edited directly in ElementX/SupportingFiles/target.yml rather
than in the variant, because XcodeGen concatenates arrays on include-merge and
a variant can override scalars but cannot remove array entries. Drops the
Element Classic app group and keychain group, and narrows associated domains
to app.healthchat.ch, keeping matrix.to for permalinks.
- Info.plist CFBundleName now follows APP_DISPLAY_NAME — it, not
CFBundleDisplayName, is what the web authentication sign-in alert shows.
- App logo and app icon assets swapped in place; the onboarding welcome title
moves to a new screen_onboarding_welcome_title_ios untranslated string.
* Scope dark mode change only to the presenting sheet, instead of the whole window
* Apply review suggestions to the presentation colour scheme modifier
API:
- Take a `ColorScheme?` at the SwiftUI level instead of a `UIUserInterfaceStyle`
and map it once inside the representable (`nil` means no override).
- Rename to `presentationColorScheme` and the file to match.
- Restore the `preferredColorScheme` property on the media preview details and
redact confirmation views, and the `nil` at the media timeline call site, so
no UIKit types leak into the views.
Cleanup:
- Walk the responder chain with `sequence(first:next:)` instead of a while loop.
* Re-record the media upload preview iPad snapshots
The Cancel button no longer has an explicit tint, so its label colour changed
very slightly from `textActionPrimary` to the default. Only the iPad references
include the toolbar, which is why the iPhone ones were unaffected.
* Add a developer option and selection mode for timeline messages
First step of the multi-select messages feature (element-meta#3255, iOS
counterpart of element-x-android#6918). Everything is gated behind the new
`messageMultiSelectEnabled` developer option and nothing changes while it
is off.
- Adds a "Select" action to the timeline item menu for remote messages in
the room, focused and thread timelines. Choosing it enters selection
mode with that message selected.
- While selecting, every bubbled row shows a checkbox on its leading edge
and tapping or long pressing a row toggles it. State events, redacted
messages, live locations, unsupported events and local echoes cannot be
selected and stay inert. Selected rows get the accent background.
- The navigation bar swaps to a Cancel button and an "N selected" title,
the back button is hidden and the composer is removed until the
selection ends (Cancel or deselecting the last item). This is the hook
where the bulk action bar will land in the next PR.
- The selection is capped at 30 messages, showing a toast when the cap
is hit, and is cleared if the developer option is switched off.
- The selection state lives in `TimelineViewModel` so room and thread
timelines share the behaviour without extra plumbing.
Includes unit tests for the menu action gating and the selection state
transitions, plus RoomScreen and bubble styler previews for the new state.
* Harden the timeline selection mode after review
- Reconcile the selection with timeline updates: selected messages that
become unselectable (e.g. redacted) are dropped, and the selection is
cleared when the timeline is swapped for a focused or live one, so the
count can never refer to items that aren't on screen.
- Keep the composer mounted but collapsed while selecting, instead of
removing it from the hierarchy. This preserves the draft and composer
mode and avoids the disappear side effects. The footer with the identity
warnings stays visible.
- Give the long press modifier an `isEnabled` flag so the recogniser is
disabled while selecting, rather than only skipping the action while
still animating and buzzing.
- Gate the Mac context menu on the selection like the other gestures.
- VoiceOver: a selectable bubble becomes a button carrying the selected
trait whose default action toggles it, non-selectable rows lose their
message actions while selecting, and reactions, thread summaries and the
checkbox are hidden from the accessibility tree in selection mode.
* Stop voice message recordings when entering selection mode
The composer is collapsed rather than removed while selecting, so an
in-progress recording would otherwise keep the microphone open out of
sight. Entering the selection now stops the recording, which moves the
composer to the preview state so the message is still there to play or
send once the selection ends. Playback of voice messages is unaffected.
* Use the translated strings for the message selection mode
The selection strings have been imported to Localazy, so the untranslated
placeholders are dropped in favour of `action_select`,
`screen_room_maximum_messages_selected` and the `screen_room_selection_count`
plural. Only these keys are taken from the download to keep the change
focused.
* Apply review suggestions to the message selection mode
Addresses the first review round on the selection mode:
- Undecryptable messages are no longer selectable, as none of the bulk
actions can be taken on them from the single item menu either.
- Renames for clarity: the menu action is `selectMessages` (leaving room
for a future `selectText`), the view action is `startSelection`, the
state exposes `contains(_:)`, `limit` and `isAtLimit`, and the composer
collapsing modifier is `collapsedInPlace(_:)`.
- `canSelectMessages` uses a switch expression, the selection state doc
comment refers to a feature flag rather than Labs, the recording helper
doc describes only what it does, and `toggleSelection()` moves below
the subviews.
* Keep the accessibility labels of timeline items while selecting
The selection mode used to replace each item's accessibility body with a
plain combined element, dropping the sender name representation and the
gallery label. The per item labelling now always applies, and the selection
only changes the interaction on top of it: the message actions are offered
as before, or the item becomes a button carrying the selected trait whose
default action toggles it. Polls and galleries collapse into a single
element only while selecting, as their children are inert then.
* Keep the timeline types within the lint limits after rebasing
The redaction reason work on develop grew the menu action handler and the
timeline view model right up to SwiftLint's size limits, so the selection
additions tipped them over. The `selectMessages` case now shares the
`downloadMedia` break and the selection flag subscription lives in the
selection extension.
* Fix the snapshot regressions from the selection mode
- Drop `geometryGroup()` from the bubble row: it stopped the avatar
placeholder initial from rendering, which showed up as a mismatch in
every timeline item snapshot.
- Collapse the composer with opacity instead of clipping, as the clip also
removed the composer background from the home indicator area while the
composer was fully visible.
- Keep the timeline item menu preview on the default flag-off state so the
existing menu snapshots stay valid.
- Record the new "Selecting" room screen and "Selection" bubble snapshots
on the same iPhone SE simulator CI uses.
* Only show a spinner when opening the media viewer is slow
* Keep a sent local echo's page in the media viewer
* Fix the caption visibility.
---------
Co-authored-by: Stefan Ceriu <stefan.ceriu@gmail.com>
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
* Fix the tab rail flickering on narrow iPad windows
The rail is laid out beside the split view, so hiding it when the split
collapsed handed that width back to the split, which then had room for its
sidebar again, which showed the rail, which collapsed the split. Any window
whose width sat within a rail of the split's collapse threshold flickered
forever, an iPad mini in fullscreen among them.
The split reports the same column visibility whether it collapsed on its own or
because the sidebar was toggled, and at the same width, so the two can only be
told apart by when they arrive: the rebound lands in the next layout pass. A
collapse that soon after showing the rail is therefore taken as proof that the
rail and the sidebar don't fit at this width, and the rail is left hidden until
the window is resized. Later collapses are treated as deliberate and still hide
the rail as before.
The container width, the width the rail and the sidebar were shown not to fit
at, and the moment the rail was last shown are one piece of state with
invariants between them rather than three independent values, so keep them and
the decision they feed together in TabRailVisibility.
Sedat Qaja
joel.poyet
Doug
Mauro
Doug
Stefan Ceriu
Element CI
ElementRobot
Mauro Romito
renovate[bot]