iOS simulator: a one-frame horizontal seam in the page background over the lower screen, on dev as well as on #1014 #1017

New issue

Open

opened 2026-11-08 12:27:38 +00:00 by kayg · 1 comment

kayg commented

2026-11-08 12:27:38 +00:00

Owner

It is there on dev too. I recorded dev (cd7f84432, built the same way and served the same way, same simulator, same six runs: 30 pushes + 30 pops by the pill, 10 edge swipes, 10 cancelled swipes, light and dark, same action scripts, same lengths of recording) and ran the same detector on dev and on #1014's head 3a6146223. The detector looks for a run of one or two frames that differ from the still screen before them and are exactly that screen again after them.

run	dev `cd7f84432`	#1014 `3a6146223`
push/pop light	1 (frame 1033)	0
edge swipe light	0	0
cancelled swipe light	1 (frame 1052)	1 (frame 1194)
push/pop dark	0	1 (frames 1135–1136)
edge swipe dark	0	0
cancelled swipe dark	1 (frames 1051–1052)	1 (frame 1177, weak)
edge swipe dark (second hit)	1 (frame 1415, weak)	0
total in six recordings	4	3

(The first recordings of #1014 at an earlier head had 1 in six; the one before that 0.) So the rate is the same with and without the pane changes, and the frames are the same picture: not caused by #1014.

Dev, dark, frames 1048 to 1055 (band at 1051–1052):

Dev, light, frames 1030 to 1037 (band at 1033):

#1014, dark, frames 1131 to 1140 (band at 1135–1136):

#1014, light, frames 1190 to 1197 (band at 1194):

All seven hits are at 53.0 to 53.8 seconds into their recording, in dev and in #1014 alike, whatever the run was doing (dev 53.29, 53.11, 53.44, 52.98 s; #1014 53.76, 53.58, 53.26 s), and the other five recordings do not have one. A fixed time after the recording starts points at the simulator's recorder or compositor (a segment or keyframe boundary of the capture), not at the page. It is not shown to be absent on a real device: that is what the #1014 device checklist is for.

Not a blocker for #1014.

Found while recording #1014's strips (iOS 27.0 simulator, iPhone 18 Pro, Home Screen app). In a recording of a screen at rest, one or two frames show a horizontal seam in the page background over the lower part of the screen, with the text and pills unchanged, and the next frame is the old picture again (frames 1135–1136 of #1014's dark push/pop run). It looks like a tile of the background being drawn again, not a card or a screen. The seam is at the same height (about 44% of the screen height) every time. **It is there on dev too.** I recorded dev (`cd7f84432`, built the same way and served the same way, same simulator, same six runs: 30 pushes + 30 pops by the pill, 10 edge swipes, 10 cancelled swipes, light and dark, same action scripts, same lengths of recording) and ran the same detector on dev and on #1014's head `3a6146223`. The detector looks for a run of one or two frames that differ from the still screen before them and are exactly that screen again after them. | run | dev `cd7f84432` | #1014 `3a6146223` | |---|---|---| | push/pop light | 1 (frame 1033) | 0 | | edge swipe light | 0 | 0 | | cancelled swipe light | 1 (frame 1052) | 1 (frame 1194) | | push/pop dark | 0 | 1 (frames 1135–1136) | | edge swipe dark | 0 | 0 | | cancelled swipe dark | 1 (frames 1051–1052) | 1 (frame 1177, weak) | | edge swipe dark (second hit) | 1 (frame 1415, weak) | 0 | | **total in six recordings** | **4** | **3** | (The first recordings of #1014 at an earlier head had 1 in six; the one before that 0.) So the rate is the same with and without the pane changes, and the frames are the same picture: not caused by #1014. Dev, dark, frames 1048 to 1055 (band at 1051–1052): ![dev dark](https://git.kayg.org/attachments/454eb7e0-ac80-4297-bd38-6ed7d753759f) Dev, light, frames 1030 to 1037 (band at 1033): ![dev light](https://git.kayg.org/attachments/f082943b-cc42-4a80-810d-75c7d9904ec2) #1014, dark, frames 1131 to 1140 (band at 1135–1136): ![pr dark](https://git.kayg.org/attachments/9eb37035-b92f-4bf8-bb83-96a51c75dfd9) #1014, light, frames 1190 to 1197 (band at 1194): ![pr light](https://git.kayg.org/attachments/934aef63-80ae-4ce3-9299-5acb259fe5d1) **All seven hits are at 53.0 to 53.8 seconds into their recording**, in dev and in #1014 alike, whatever the run was doing (dev 53.29, 53.11, 53.44, 52.98 s; #1014 53.76, 53.58, 53.26 s), and the other five recordings do not have one. A fixed time after the recording starts points at the simulator's recorder or compositor (a segment or keyframe boundary of the capture), not at the page. It is not shown to be absent on a real device: that is what the #1014 device checklist is for. Not a blocker for #1014.

K-dev-light.png

557 KiB

K-dev-dark.png

666 KiB

K-pr-light.png

668 KiB

K-pr-dark.png

732 KiB

~~kayg referenced this issue 2026-11-08 16:49:59 +00:00~~

fix(phone): one push/pop slide for every phone stack, built once and only moved; no flash of the previous pane (#1005, rebuild of #1006) #1014

kayg referenced this issue

2026-11-08 16:50:33 +00:00

fix(phone): one push/pop slide for every phone stack, built once and only moved; no flash of the previous pane (#1005, rebuild of #1006) #1014

kayg commented

2026-11-08 16:51:05 +00:00

Author

Owner

In the final recordings of #1014 (head 3c5c99618, six recordings) the detector finds no band; dev has 4 in its six (above). Same fixed time into the recording where there is one (53.0 to 53.8 s).

In the final recordings of #1014 (head `3c5c99618`, six recordings) the detector finds no band; dev has 4 in its six (above). Same fixed time into the recording where there is one (53.0 to 53.8 s).

kayg referenced this issue

2026-11-08 19:01:27 +00:00

Housekeeping 2026-11-07 #1009

kayg referenced this issue

2026-11-08 22:37:27 +00:00

fix(phone): one push/pop slide for every phone stack, built once and only moved; no flash of the previous pane (#1005, rebuild of #1006) #1014