109993 - Chatzilla scrolls with new input even when in scrollback

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Akkana Peck]

It's hard to read scrollback in chatzilla, because I scroll back a few screens
and  start reading, but as soon as anyone says anything, the page starts
scrolling (not down to the bottom, just a little).  It would be better if it
didn't scroll when I was trying to read scrollback.

I do like having timeouts or scrolling the window to the bottom when I switch
from one tab to another (which prevents me from getting lost in scrollback and
not seeing new messages, like always happens to me in tkirc) but I do need a way
to make it sit still while I'm trying to read.

Comment 1

[Christopher Stone]

one way not to get lost in scrollback mode is to have the text on the tab
highlight green if there is new text at the bottom of the screen (such as when
there is new text on another tab).

Comment 2

[David Krause]

Remove myself from QA of 33 open Chatzilla bugs and change to default QA
contact, since I have no way to verify these easily.  Still no working Mozilla
on my primary platform and it doesn't look like it will happen anytime soon. :(

Comment 3

[Samuel Sieb]

Attachment: fix

Comment 4

[Robert Ginda]

Comment on attachment 112259 [details] [diff] [review]
fix

r=rginda

Comment 5

[Asa Dotzler [:asa]]

Comment on attachment 112259 [details] [diff] [review]
fix

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 6

[Robert Ginda]

checked in, but we still seem to scroll a few pixels for each new message.

try running "/eval for (i = 0; i < 50; ++i) display(String(i))" while you're in
the scrollback, and you'll see.

Leaving open.

Comment 7

[Andreas Kunz]

I tested the current status:


1) If the line that is currently visible at the bottom is within the last 10
lines then the view still jumps down to any newly received line.
(That means if you are looking at the last received line and press the
scrollbar-up arrow nine times or more, then the view will stay when a new line
is received. When you only press it eight times or less, then every new line
will make the view jump down all the way to that new line)


2) If the currently viewed lines are 'older' (further upward) then:

  a) If very old messages are already being pushed out/forgotten at the very
top, then the view does scroll down exactly two pixels with every new message
(no matter how many lines it has). At least at my computer with my font settings
etc. This is probably what comment #6 meant. And the "if (source.messageCount >
source.MAX_MESSAGES)" above the patched code fragment tells me that this is also
the case that was addressed by the patch.

  b) If there are only few lines received since joining the channel (less than
set under "Chatzilla - Interface - Scrollback options") then there will be no
scrolling at all.


I wonder if 1) wasn't addressed with this bug or if it even is designed to be as
it is... in fact this annoys me most. I'd try to find the problem if I could be
sure that it *is* considered a problem...

Comment 8

[Samuel Sieb]

1) This is intended, although I imagine the range could be made much smaller. 
(It is already a lot smaller than it was originally.)
2) a) Correct.  If anyone can tell me how to get the *exact* height, it would be
very appreciated.
   b) Right, because lines aren't being removed, so the scrolling doesn't need
adjusting anyways.

Comment 9

[James Ross]

I think the difference in calculation and actual is that the rows have
cellspacing between them, which is not being taken into account.

Comment 10

[James Ross]

Attachment: Use top difference from first two rows

Note that this works for collapsed lines because only the nickname (2nd) column is rowspan'ed, the first cell (timestamp) is not. This also doesn't change the distance with which ChatZilla jumps to the bottom (160px currently), only fixes the small offset that occurs when reading scrollback and lines are removed.

Comment 11

[James Ross]

Checked in --> FIXED.

I'm going to mark this fixed even with the 160px 'jump' value as I think this is a suitable compromise between never jumping, and not knowing there is more text. If anyone has a better idea for this, please file a new bug with as much detail on the idea as possible.