Gwibber lists jump to top of page when updated

Reported by zzz on 2009-02-09
638
This bug affects 126 people
Affects Status Importance Assigned to Milestone
Gwibber
Medium
Ryan Paul
One Hundred Papercuts
Low
Unassigned
gwibber (Ubuntu)
Medium
Unassigned

Bug Description

Gwibber's search tabs seem to automatically jump to the top of the page when an update/refresh has been completed. The Messages and Replies tabs (correctly) stay where the user is currently scrolled to.

In my opinion, the search tab should match this functionality and not automatically jump to the top on refresh.

zzz (oldman-deactivatedaccount) wrote :

bumping this up in importance as it seems to happen on all tabs recently

whenever gwibber updates / refreshes, the tab scrolls up some amount

Changed in gwibber:
importance: Undecided → Medium
status: New → Confirmed
summary: - Gwibber search tabs jump to top of page on update
+ Gwibber lists jump to top of page when updated
Russell Harrison (rharrison10) wrote :

This also applies to the messages tab as well. It makes reading more than one page worth of messages quite frustrating.

Serge Matveenko (lig) wrote :

I'm going to fix it on this weekend.

Think we need some default javascript here to scroll to stored message index in some cases.

It looks like implementing this feature will cause possibility to easy implement message reading on mouse over like it is now in google reader.

Serge Matveenko (lig) wrote :

I've tuned some uncommented code here: lp:/~s-matveenko/gwibber/bug but it still does not work well.

Now scrolling returns to its previous position even after changing view: from messages to replies for example.

Also, this scrolling restoration method is not pedantic and have no corrections to scroll position when new messages arrives.

I think the best way to resolve this issue is to differ initial page loading and updating of current view and to perform updates via ajax requests. This method should do the trick very smoothly.

Serge Matveenko (lig) wrote :

Hoping for a fix sometime soon. Somewhat annoying when reading through 350 new tweets and it suddenly jumps all the way to the top again.

It wasn't like this before, though.

John Gill (swfiua) wrote :

I hadn't spotted this bug report and potential fix.

As others have noted, the scrolling is annoying.

A fix here just adds connect/disconnect buttons to the status bar -- so you can turn off updates while you read -- not ideal, but couldn't figure out how to get the scrolling right.

http://bazaar.launchpad.net/~swfiua/ubuntu/lucid/gwibber/scrollfix/revision/20?start_revid=20#gwibber/client.py

Changed in gwibber:
assignee: nobody → Ken VanDine (ken-vandine)
Vish (vish) on 2009-12-26
Changed in hundredpapercuts:
importance: Undecided → Low
milestone: none → lucid-round-5
status: New → Triaged

Any news on this? 2.0.0~bzr491-0ubuntu2~daily1~karmic still suffers from this. Anything I can do to help?

I think is a good idea show a flash message when have new twitts instead jump to top. A ugly mockup is attached.

Matthew Paul Thomas (mpt) wrote :

It would be useful for artists to brainstorm possible ways of showing that there are new messages, without using text to do it as used in that mockup. One possibility would be for the display to momentarily nudge downwards (as if being bumped by the newly arrived messages), before sliding back to its previous position. I'm sure there are many other possibilities.

My suggestion is simply to show a small padded area (in background colour) at the very top of the message view when the topmost message is the newest.

(See screenshot-up-to-date.png)

When new messages have arrived, the bottom of the newer message is now visible in the previously padded area as a visual hint (combined with the new position of the scrollbar) that messages are available.

(See screenshot-new-messages-avail.png)

side by side screenshots of up-to-date vs new-messages-available

I hope this can get fixed in time for Ubuntu 10.04, cause this is really annoying.

Tristan (talinnell) wrote :

Happens on all lists for me too,
Tristan

John Vivirito (gnomefreak) wrote :

On the screen shot provided in
https://bugs.launchpad.net/gwibber/+bug/327172/comments/13 I don't see a notification but if i am right it looks like it just doesn't jump to newest.
Personally i think:
https://bugs.launchpad.net/gwibber/+bug/327172/comments/9 is the best way to go. From a users POV

kyleabaker (kyleabaker) wrote :

The banner display is what I've been used to in the past. Twitterrific updates and displays a banner for a couple seconds and then it disappears on the iPod/iPhone. I think that would be plenty of attention and not overly done since the scroll bar will also be shifted down on updates, making it more obvious that there are newer messages above.

Omer Akram (om26er) wrote :

opened downstream task for tracking purpose

Changed in gwibber (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
frizzle21 (frederik-nnaji) wrote :

happy to see "like" enabled.. !!!!!!

yeah, gwibber needs some serious artwork casting..
comment #9 contains an extremely good idea

perhaps a casting or contest or something on gnome-look.org ?

frizzle21 (frederik-nnaji) wrote :

http://live.gnome.org/GnomeArt/ArtRequests

here's the right place for developers to request artwork.. let's try should we?
i think only developers can edit this list..

Robb Kidd (ubuntu-thekidds) wrote :

Is the consensus that a banner notification be added? Or, along the lines mentioned earlier in this bug thread, that the message view will have a current scrolled index stored and used during a post-refresh render[2]?

I suggest whichever method is selected (or both, gods preserve us) should have a option added in preferences to allow the screen render to the latest as it does today for those who like the current behavior.

[1] Basically like Twitter's web interface.
[2] I've seen this behavior in Seesmic on Android and rather like it.

frizzle21 (frederik-nnaji) wrote :

an elegant form of notification is definitely an improvement to the current state.
the optimum is:
i flip a switch and its visual representation actually shows as flipped

what happens instead:
i flip a switch and the whole room turns dark so i can't see the switch i flipped

there is no problem with sending the current behaviour into the menus or preferences as an option.
the way gwibber is currently behaving though is not in line with the principles of usability described in the current hig-book.

the user is being surprised, his input is overinterpreted in a confusing manner, instead of implemented on the spot.

related issues are:
*there is no visual representation of whether or not i like a broadcast
*there is no visible button or [+] or tree symbol that would instantly expand a comment thread beneath a broadcast message
*comments are not threaded to the message at hand and displayed in context when posted
*the text input field does not visually change to indicate that i'm commenting, when i'm commenting and not writing a new broadcast message
*the status messages entered above the availability settings for IM automatically get sent to all active Microblogging accounts instead of IM accounts

where do i discuss a whole set of usability issues?
the gwibber ML is team only.. :S

Ryan Paul (segphault) wrote :

I'm working on this now. I have a very experimental solution in my pre-3.0 branch, but it still needs a lot of work.

Changed in gwibber:
assignee: Ken VanDine (ken-vandine) → Ryan Paul (segphault)
milestone: none → 3.0
Matthias Niess (mniess) wrote :

Wow. This is really annoying. If you need any help fixing it, let me know.

ruffneckc (ruffneckc) wrote :

Yup, this affects me as well. Wish I could code to help out. Let me know if you need help testing - I can do that at least.

Vish (vish) wrote :

@mniess: If you can fix the bug , do submit a merge with the fix. [Gwibber is hosted on launchpad, you can just follow the merge procedure (1)]
No need to ask first. Anyone can fix a bug. Rather, fixing bugs is welcomed. ;-)

(1) https://help.launchpad.net/Code/Review#Proposing%20a%20merge

Philippe (pcreux) wrote :

Please fix! :)

Jim Hodapp (jhodapp) wrote :

I would really love to see this bug fixed. This is the most annoying thing about Gwibber and, though it doesn't make it unusable, it isn't too far from there. Any way I can help? I'm a programmer, but not much Python experience.

Vish (vish) on 2010-06-10
Changed in hundredpapercuts:
milestone: lucid-round-5 → maverick-round-4-social-networking
Vish (vish) on 2010-06-11
Changed in hundredpapercuts:
milestone: maverick-round-4-potpourri → maverick-round-3-social-networking
John (john-e-francis) wrote :

There seems to be 2 distinct "scroll to top events", one at the beginning of the update, and another one when it is complete. I'd like to see no banner/notification of any kind. Just add the new messages to the top of the list, and the user will see them when they scroll up there themselves.

Carsten Ringe (carsten-ringe) wrote :

I think that's what most Twitter clients do: Remember the last position and let the user decide when to scroll up.

When I understand the code right, the actual list of messages is build from a HTML template that renders all available messages from all streams and then just display it in a Webkit view (happening in gwibber/gwui.py. My python is limited, so I'm not 100% sure about it.

Dan Dart (dandart) wrote :

I'm getting this on 2.30.0.1 on Lucid with Home and Replies.

Ken VanDine (ken-vandine) wrote :

This is planned to be fixed in Gwibber 3.0, it isn't all that simple to backport to 2.30.x.

Changed in gwibber:
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gwibber - 2.31.3-0ubuntu1

---------------
gwibber (2.31.3-0ubuntu1) maverick; urgency=low

  * New upstream release
    - Move backend storage from desktopcouch to sqlite
    - Don't scroll to the top on every refresh (LP: #327172)
  * debian/control
    - Added a Depends for python-pysqlite2
    - Dropped python-desktopcouch-records to a Recommends (still needed
      for account migration, but not strickly required)
    - Made python-libproxy and python-indicate Recommends instead
      of depends
    - Bumped standards version to 3.9.1
  * -debian/patches/lp_539017.patch
    - Merged upstream
  * debian/patches/no_tray_icon_pref_ui.patch
    - Hide the tray_icon preferences
 -- Ken VanDine <email address hidden> Wed, 28 Jul 2010 10:19:29 -0400

Changed in gwibber (Ubuntu):
status: Triaged → Fix Released
Kamus (kamus) wrote :

Thanks Ken!

Changed in gwibber:
status: Fix Committed → Fix Released
Vish (vish) wrote :

Fixed in Maverick!

Changed in hundredpapercuts:
status: Triaged → Fix Released
frizzle21 (frederik-nnaji) wrote :

and oh yeah:
thaaaaank you :D

On Sun, Aug 1, 2010 at 21:16, Frederik Nnaji <email address hidden>wrote:

> is there already a .deb available?
>

Kevin Turner (keturn) wrote :

Glad to see this fixed in Maverick, but will the LTS release (Lucid) get it?

Omer Akram (om26er) wrote :

kenvin, for lucid use this ppa. https://launchpad.net/~gwibber-team/+archive/ppa the fix wont be coming to 2.30 series.

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

Other bug subscribers