Live page

[Altai-man]

Todo:

• [ ] Fix message duplication
• [ ] Make scroll-up return a whole day or something more sensible than just 10 messages?
• [ ] Streaming of latest messages

[lizmat]

So, I've been playing a bit with it, and have come to the following conclusions:

1. We probably do not want to do the special commit messages / Camelia output parsing, as these can span multiple scroll requests, and that can get very confusing very quickly.
2. There is no offset issue. My intent was that the target of the last <tr> would be looked up in the existing table, and anything including up to that <tr> would be removed before inserting the <tr> obtained from the HTTP request. This is the only way to properly handle removing the date header and be sure it properly handles switching days (when the date header should be kept). So I guess some selector / dom removal logic is needed.
3. The scrolling feels very sensitive and you must first scroll down the window a little bit before the scroll up kicks in. I guess we also need a scroll up logic on the whole viewport?
4. As to the number of lines to get: it feels to me this shouldn't be too much: I think you should be able to see the former top message on the same screen still when scrolling up. OTOH, some people will just want to go back a whole lot to read from there. Maybe the number of lines should be dependent on how "fast" you scrolled up?

[Altai-man]

We probably do not want to do the special commit messages / Camelia output parsing, as these can span multiple scroll requests, and that can get very confusing very quickly.

You mean squashing reports by Geth and the like?

So I guess some selector / dom removal logic is needed.

A-ha, makes sense to me.

The scrolling feels very sensitive and you must first scroll down the window a little bit before the scroll up kicks in. I guess we also need a scroll up logic on the whole viewport?

I am not sure if I understand.

1)Sensitive as in you want the older messages to be loaded after some delay? 2)Don't we already have logic for scrolling to the bottom of the page when its loaded? So there is no need to scroll down, it's already done when the page is ready, no?

I think you should be able to see the former top message on the same screen still when scrolling up

Well, we append the past messages and do not move the viewport up, so the user is able to see the former top message on the same screen regardless of how many new messages you loaded, no?

Maybe the number of lines should be dependent on how "fast" you scrolled up?

This sounds complicated to implement IMO. I would just bumped the limit to something "reasonable" like at least 50-80 messages per batch at left it this way. But 10 (IIUC this is the current limit) is just not enough.

[lizmat]

You mean squashing reports by Geth and the like?

Yes, I've now removed that for the live view.

Sensitive as in you want the older messages to be loaded after some delay?

No, it's not about delay. The scrollup fetching logic is not called when you try to scroll up the document window. It only kicks in if you scroll up in the message window. And that you can only do when you first scrolled down, because otherwise you're scrolling up the document window. Does that make it clear?

Well, we append the past messages and do not move the viewport up

The viewport is moved up for me on Safari.

This sounds complicated to implement IMO

We're looking at some Y values and a time I guess. In any case, the backend now allows you to specify an entries value that I've now set to 15. It should probably also be dependent on how many lines are actually visible?

[Altai-man]

Yes, I've now removed that for the live view.

If it's just a live view then alright, though it is an invaluable feature for normal pages IMO.

The scrollup fetching logic is not called when you try to scroll up the document window. It only kicks in if you scroll up in the message window. And that you can only do when you first scrolled down, because otherwise you're scrolling up the document window. Does that make it clear?

Sorry, it seems I still don't get it.

The viewport is moved up for me on Safari.

Hmm, then we need to patch that up to work more reliably across more browsers, it shouldn't work this way, agreed.

We're looking at some Y values and a time I guess

I still feel this is a nest of bugs and edge cases, while not being very predictable. I understand why you disagree with just a larger constant number, because the viewport is moved up for you on Safari, so this is probably something to fix first.

[lizmat]

I have upscroll and downscroll implemented now. I just need to finetune the downscroll trigger: it's not very nice on the server atm :-)