Message pane repaints frequently and resets the scroll status, losing reading position

Bug #487064 reported by Paul Jakma
106
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Gwibber
Fix Released
Medium
Ken VanDine
gwibber (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

I'm running gwibber-2.0.0-1.478bzr.fc11.noarch. I have gwibber set to update only every 15 minutes, and I have it configured with Identi.ca, Twitter and Facebook accounts. Despite the 15min update time, the gwibber message pane window seems to repaint/update itself very frequently, e.g. as often as 10s. When it does so the scroll status is reset back to the top, thus losing the place where you were reading.

This makes trying to read through a list of messages very frustrating, if that list requires more than a scroll or two.

I think:

a) There is some problem with gwibber repainting/updating the message pane *far* more frequently than the configured update time

b) There is a secondary problem where Gwibber, on an update of the message pane, resets the scroll state. I think it should not do so - even if a) were fixed, I would be annoyed if I lost my place if I was reading as an update occured. (However, I note there is a pre-existing "Wont fix" bug about this same issue).

Great app though, thanks!

Revision history for this message
Paul Jakma (paul+launchpad-jakma) wrote :

Apparently there's some suggestion this problem is specific to cases where the update pane is still in the first third or so of how it can scroll / the list of messages. I.e. that once you're scrolled past 1/3 that this problem no longer occurs.

I have just tested and it still occurs even with the pane scrolled to about 1/2-way down, also scrolled to almost near the bottom, also with the pane fully scrolled to the bottom.

Revision history for this message
Paul Jakma (paul+launchpad-jakma) wrote :

Further requested info (from IRC):

- the theme is 'default'
- webkit versions are:

# rpm -qa | grep webkit
webkitgtk-1.1.10-1.fc11.i586
pywebkitgtk-1.0.1-6.fc11.i586

- it's not image loading. Image loading can cause the pane to scroll a little as it fills out, but it does not reset the scroll state.

- this bug does not always manifest itself immediately it seems. I'm unsure of the exact conditions needed to recreate, however it is reproducible to some degree as it has occured across several restarts of gwibber for me.

Revision history for this message
Paul Jakma (paul+launchpad-jakma) wrote :

It seems to be caused by searches. I have about 4 defined, and eventually I get things like:

DEBUG:gwibber:Queueing Op: <search:twitter>
DEBUG:gwibber:Queueing Op: <search:identica>
DEBUG:gwibber:Performing Op: <search:twitter>
DEBUG:gwibber:Performing Op: <search:identica>
DEBUG:gwibber:Starting scheduled operations
DEBUG:gwibber:Finished Op: <search:twitter>
DEBUG:gwibber:Starting scheduled operations
DEBUG:gwibber:Finished Op: <search:identica>
DEBUG:gwibber:Loading Complete
DEBUG:gwibber:Queueing Op: <search:twitter>
DEBUG:gwibber:Queueing Op: <search:identica>
DEBUG:gwibber:Performing Op: <search:twitter>
DEBUG:gwibber:Performing Op: <search:identica>
DEBUG:gwibber:Starting scheduled operations
DEBUG:gwibber:Finished Op: <search:twitter>
DEBUG:gwibber:Starting scheduled operations
DEBUG:gwibber:Finished Op: <search:identica>
DEBUG:gwibber:Loading Complete

There was about 7s between those 2 searches. That was part of a series of 3 search-related "Loading Complete"'s which were about 40s, 7s and finally 13s apart.

Changed in gwibber:
assignee: nobody → Ken VanDine (ken-vandine)
importance: Undecided → Medium
Revision history for this message
Richard de Vries (richarddevries) wrote :

I'm running 2.0.0~bzr476-0ubuntu3 and I'm affected. I don't have any searches defined.

Omer Akram (om26er)
Changed in gwibber (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Omer Akram (om26er)
Changed in gwibber:
status: New → Confirmed
Revision history for this message
Ryan Paul (segphault) wrote :

I think that Paul's explanation is plausible. But I suspect it's caused by any kind of transient stream, not just searches. I think that this is no longer an issue in version 2.29. I'd appreciate it if somebody could help me confirm that.

Revision history for this message
Kai Jauch (kaijauch) wrote :

In 2.29 it no longer jumps up to the top of the list, but the reading position is still lost if new messages come in. The position on the scrollbar stays the same, but that position no longer corresponds to the reading position (you're hopping up several messages).

This was happening with a twitter account in the "normal twitter pane" (the one with the twitter symbol).

gwibber 2.29.1-0ubuntu1

Revision history for this message
Kai Jauch (kaijauch) wrote :

Hm, apparently it still jumps to the top of the list on refreshes. I don't know why it only jumped up a bit two days ago.

Revision history for this message
Omer Akram (om26er) wrote :

This bug is fixed in gwibber 2.29.x Kai Jauch the problem you are facing is bug#327172

Changed in gwibber (Ubuntu):
status: Triaged → Fix Released
Changed in gwibber:
status: Confirmed → Fix Released
Revision history for this message
Tristan (talinnell) wrote :

I am running 2.29.92.1 on the latest Ubuntu Lucid Beta 1 with all updates, and this still happens for me.

Revision history for this message
Ken VanDine (ken-vandine) wrote :

Tristan: Can you confirm what you are seeing is the same as this bug, of if it is bug #327172?

Revision history for this message
Tristan (talinnell) wrote :

Yes, sorry, it is bug #327172. Sorry for the confusion.
Tristan

Revision history for this message
Vitaly (vbabiy86) wrote :

I am on 2.29.95 and I have the issue in the main stream

Revision history for this message
Joss Winn (josswinn) wrote :

This is still happening for me with 2.30.0.1 (Lucid)

Revision history for this message
Rob Candee (rob-candee) wrote :

This also happens for me with 2.30.0.1 in Ubuntu 10.04 (Lucid). Very annoying!

Revision history for this message
Dan Dart (dandart) wrote :

Bug still present in 2.30.0.1 for me. No point in saying it anymore, is there? Can we get this "fix" pushed, please?

Revision history for this message
Rob Candee (rob-candee) wrote :

And in 2.30.1...

Revision history for this message
Ken VanDine (ken-vandine) wrote :

This bug was due to transient streams people had triggering the message pane to render every few seconds, not everytime gwibber refreshes. I suspect all of the recent comments on this bug are really referring to bug #327172 which is targetted to be fixed in Gwibber 3.0.

Revision history for this message
Juan Simón (simonbcn) wrote :

I use Gwibber 2.30.3 in Ubuntu Lucid and this still happens!! :-(

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.