Bug 815728

I can confirm this behavior. In addition to the scrollwheel not working, clicks in empty space on the scrollbar do not cause the view to move up or down. I have to click and hold the bar to move the timeline up and down.

Another confirmation on F17 x86_64 with gwibber 3.4.2. When I start gwibber for the first time and the Home Timeline screen is shown then:

Scrolling with the scrollwheel does not work at all.

Clicking with the mouse in the grey part of the scrollbar area does not result in any scrolling.

Scrolling with navigation keys does not work. Initially, using the key with the arrow pointing down causes gwibber to scroll down through the older tweets but this only works for a few tweets and then scrolling stops. After I let go of the key on the keyboard scrolling will continue intermittently for a few secs. 

Any type of scolling (with mouse or keys) is not fluid. It's very jumpy and never in a consistent speed.

While still in the Home Timeline screen the text of the tweets greys out when selecting another window and will only intermittently return to the original black color when the gwibber window is selected again.

But... after I click on a twitter id in the Home Timeline screen and gwibber shows the profile page of that person, then scrolling starts to work properly using both the mouse and keys and the greying out of text also no longer happens.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I have the same issue in Fedora 20, with gwibber-3.4.2-9.fc20.x86_64
Scrolling with the mouse-scrollwheel works...somewhat, and only for a short time, then it's unusable.

1) Scrollwheel-down scrolls down ~10 tweets in the timeline, then stops.
2) At this point, scrollwheel-up does not work either.
3) Moving the mouse around a bit helps a bit: then scrollwheel-up/down
   scrolls through another 3 tweets or so, until it stops.
4) Using the scrollbar with the mouse is very erratic: the whole timeline
   flickers and goes up and down while pulling down the scrollbar. And vice-versa
   if the scrollbar is pulled upwards.

Scrolling the timeline via the down/up arrows on the keyboard works. Sometimes scrolling stops too, but resumes half a second by itself.

Maybe switching to the latest gwibber version would help? Unfortunately, Gwibber's launchpad site lists its latest version (3.6.0) as "released 2012-10-04", its blog is pretty much dead too, only its source repository is a tiny bit more active (last commit on 03/2013).

(I can't re-open this bug, should I file a new one?)

The problem with the 3.6 trunk code is that it depends on Ubuntu Unity, which is why this package can't really use it.

I'd suggest trying corebird instead (twitter only, though).

Alternately, I'd be willing to apply patches to gwibber, if you have the time to figure out the scrolling issues. This is technically on my "when I have spare time" list, but I haven't had spare time in a while.

Thanks, corebird seems to work just fine.

Unfortunately I won't be able to provide patches to fix the issue in Gwibber. If Gwibber depnds on Unity (and Ubuntu?), why is this package in the Fedora repositories? If it has stay in the repository, could a note be added to the "yum info gwibber" output? Like "Needs Ubuntu Unity to work" or something?

Also, why the WONTFIX/NEEDINFO?

This branch of gwibber (mostly) works, and doesn't need Unity. I'm not sure the package metadata is the best place for comments about other branches of the gwibber code. :)

OK, the package metadata may not be the right place to convey "known issues" for a package. But the issue is still not fixed and I still don't understand the WONTFIX here.

Of course "gwibber (mostly) works" but this bug is about "scrolling with scrollwheel doesn't work (in gwibber)" - so why does this bug has to be closed with WONTFIX? Because it is hard to fix? Or unlikely to be fixed? Or not an issue for most people? I don't understand...

I'm guessing "unlikely to be fixed", though I'm speaking as a user, not developer or maintainer. The sad truth is that gwibber devs threw in their lot with Ubuntu and Unity, and we're pretty well stuck with this version. Without someone with the time and interest to do anything about it, it's probably best recognized as an "as-is" product.

Michael is right, WONTFIX == I won't be fixing it, nor should we expect upstream to do it.

That said, -10 which just went out to updates has some user provided improvements for scrolling.