Find collection view section headers deliberately, not by luck

[RoyalPineapple]

Collection view section headers are only found by luck today, and often that luck runs out. This makes the search ask for them.

Problem

The scroll search in -[UIView(KIFAdditions) accessibilityElementMatchingBlock:notHidden:disableScroll:] enumerates numberOfItemsInSection only:

for (NSUInteger section = 0; section < numberOfSections; section++) {
    for (NSUInteger item = 0; item < numberOfItems; item++) {

Supplementary views are not items, so nothing ever looks for one. A section header or footer that has not been scrolled near is never realised, and searching for it fails with a 10 second timeout even though it exists. A cell at the same scroll offset is found without trouble.

Whether a header is found at all comes down to whether scrolling toward some item happened to drag it into the viewport. That depends entirely on where the layout put the header, which the search never asks about and cannot infer.

This affects any collection view whose section headers carry accessibility labels. Lists built on frameworks that vend headers as supplementary views hit it for every offscreen section header.

The existing fixture registers no supplementary views, so no test covered this path.

Fix

Ask the layout which supplementary views exist and where they are, scroll straight to each one, and match it.

Scrolling directly is the part that matters. A header is only conceptually between sections; the layout decides where it actually goes. A horizontally scrolling layout puts it to the leading side rather than on top, and a custom layout can put it anywhere: pinned, inset, or somewhere with no relation to the items at all. Nothing about a supplementary view's position can be inferred from the items around it.

So both the position and the set of kinds come from the one object that knows them:

NSArray *allAttributes = [collectionView.collectionViewLayout layoutAttributesForElementsInRect:contentRect];
// ... filtered to UICollectionElementCategorySupplementaryView
[collectionView scrollRectToVisible:attributes.frame animated:NO];

Reading the kinds from the layout rather than naming them is deliberate, and the reason is in the review history below.

A view that is already realised was reachable by the ordinary subview search, so it is skipped. That mirrors how the item loop skips -indexPathsForVisibleItems, and it keeps supplementary views from jumping ahead of everything else in the search order.

Attributes with an empty frame are dropped, so a layout that vends nothing costs nothing. On a match the search returns a full re-search from the top with disableScroll:NO, the convention the item branch already uses. The helpers sit outside the @available(iOS 18, *) split, so there is a single code path on all supported versions.

Two bugs this went through, both caught downstream

The first version of this fix named the two UIKit kinds directly and called -layoutAttributesForSupplementaryViewOfKind:atIndexPath: for each section. Both bugs below came out of squareup/ios-register#157382, which pins this branch and runs a large KIF suite against it. Neither was visible in this repo's own tests.

Asking for a kind a layout does not vend is not a supported query. It is not a nil-returning lookup; layouts commonly assert. RGUIFormLayout in ios-register defines two custom kinds and raises Invalid supplementary view kind for anything else, which crashed the app under test in 95 of 100 failing tests across 30 unrelated suites, most with SIGSEGV. Fixed by reading the kinds from -layoutAttributesForElementsInRect: instead, which is how UIKit itself discovers them and works for any kind a layout defines.

Matching an already-realised view changes the search order. A realised supplementary view was already covered by the ordinary subview search; matching it here as well put every visible supplementary view ahead of the rest of the hierarchy. A search running while a screen was still settling could return one of them instead of the element the caller was waiting for. This showed up as a single flaky test:

KIF version	Runs	Failures
With the bad ordering	20	3
4.0.2 baseline	30	0

Fixed by returning early when the view is already realised, which is what the pass did originally.

Test

CollectionViewController now vends a header and a footer. testWaitingForOffscreenSupplementaryView asserts both the onscreen header and the footer below 200 items can be found.

Verified on iOS 18.1:

Run	Result
New test, without the fix	fails: Failed to find accessibility element with the label "Section Footer" after 10s
New test, with the fix	passes in 1.5s
CollectionViewTests, CollectionViewTests_ViewTestActor, TableViewTests, TableViewTests_ViewTestActor, OffscreenTests_ViewTestActor	59 tests, 0 failures

The fixture change is deliberately additive (one section, one header, one footer) so the existing tests' index arithmetic is untouched. An earlier two-section version broke three existing tests; I confirmed that was the fixture and not the fix by reverting the fix and observing the same failures.

Pinning the table view's luck

The UITableView branch has the same shape, enumerating numberOfRowsInSection only, so I expected it to fail the same way. It does not, and the reason is the luck described above.

Its row loop calls -scrollRectToVisible: on every row in turn, whether or not that row is a candidate. Section headers and footers are interleaved with the rows, so walking a section scrolls the table through it and drags those views into the viewport. They are realised as collateral from scrolling toward the rows around them, without ever being searched for.

I expected the last section's footer to be the exception, since no rows follow it to scroll past. It is found too, in 4.8s.

So there is nothing to fix on the table view side. One commit adds a test anyway, because header and footer lookup there rests entirely on a side effect that nothing else pins. Making that row loop more selective, so it stops scrolling to rows it does not need, is an obvious future optimisation, and the last section's footer is the first thing it would break. The fixture had no footers, so the last section gains one.