Description
This seems to be happening again on iOS: the initial scroll position (or maybe the scroll position a fraction of a second after opening a narrow) is far higher than it should be. It's not yet clear how this relates to #3457 or #4863, and I don't yet have a clear reproduction recipe.
For anyone wishing to help, a great first step would be to find a good reproduction recipe: a list of steps that I or anyone else can take to see the bug happening. So far it only seems to happen sometimes, and I haven't found a pattern.
@gnprice said, in #3457 (comment):
There's still a potential opportunity here to simplify our interactions with the browser's layout and scrolling: #3457 (comment) That could potentially make us more robust to having an issue like this appear in the future. If we see another issue like this one in the future, that's one direction we'll want to investigate.
So let's look into that too. I think I'd actually like to take a slightly different approach. The proposal I made there wasn't ideal: it would change getFirstUnreadIdInNarrow
so that the ID it returns isn't always…the first unread ID in the narrow. That function is right to return null
when "the first unread ID in the narrow" can't be given because it doesn't exist. But after calling that function, we can conditionalize on a null
value so that we still use the last message ID for initialScrollMessageId
.