actually one of the fedifox things that's been haunting me is a weird timeline issue I saw when I first ran the project again, but it just occurred to me that could've been an issue with the old state still in the desktop localStorage, since fixed in the code I'm looking at now (last edited on my laptop i guess)

getting a complete view of the timeline, interspersed with gaps from network loss / tab closing is surprisingly complex, but maybe it does actually Just Work(tm) now

Did actually do quite a bit of FediFox work today.

Even got around to playing with the [Web Locks API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API), which allows the client to sync new data across multiple tabs running the same client, while only keeping a websocket to the instance open on one of them.

Quite interested to see how stable it is, when opening/closing/switching stuff around https://fedifox.cthu.lu/

like right now I have it open in 3 tabs, first one says
`Lock: has timeline lock; Websocket: open`
while the other two are `Lock: nope; Websocket: waiting for lock`. But these new toots appear in all three tabs as soon as they come in over the first tab's websocket :D

still seems to work really well! on different devices, and across suspends/reloads etc

huh, it also seems Mastodon has stopped just... looping around the timeline pagination responses when fetching toots newer/older than the ~400 (iirc) toots that are in your timeline view

yeah seems good, could paginate back quite a few until either an empty response, or a response with less than the limit also signalling there's nothing more

....... My desktop was slugging a bit, realized it was running out of memory. Thought it might be a memory leak in the (development build) of FediFox. Killed the 4GB ram isolated web process, thinking that'd kill one of my FediFox tabs

and only later realized it was actually the mastodon.social tab with the federated timeline open that caused this