User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4 With long list of email (e.g., fedora mailing list) the scroll bar grabber (or maybe its called thumb) is difficult to correctly grab with the mouse and sometimes does not scroll as expected or at all. I have to keep trying to get the scrolling going. The position also moves around randomly or top to bottom when you alt-tab over to thunderbird. (Sorry this a bit hard to describe.) Reproducible: Always Steps to Reproduce: 1.Look at email list 2.Try to grap the scroll thumb to move up or down 3.Scroll thumb sometimes appears to be partially covered by something. 4.Keep trying. Eventually you grab it right and can scroll 5.Sometimes it starts scrolling on its own Actual Results: Well, it eventually scrolls but it is hard to position the mouse correctly. Sometimes (often) it starts scrolling up or down fast like you have not actually grabbed the thumb. Expected Results: Grab the scroll thumb and move up or down cleanly with the mouse with no problems. Again, this is a bit hard to describe. I suspect it is a known bug but I can't find it.
FWIW, for my installation, scroll bars in thunderbird are fine in gnome. They are only bad in, as described in previous comment, in KDE.
Could you give me some exact URL to reproduce?
There is no URL. The problem is with the scrollbar on Thunderbird email. This is seen using my personal email folders.
Created attachment 345343 [details] screenshot of non-reproduction (In reply to comment #1) > FWIW, for my installation, scroll bars in thunderbird are fine in gnome. They > are only bad in, as described in previous comment, in KDE. Oh, I see. I cannot reproduce it here in Gnome, which means IMHO that the problem is somewhere in the interaction between Gtk+ and KDE. Reassigning
In KDE appearance setting there is a category called "GTK Styles and Fonts". There is something about a "scroll bar fix" for tbird and firefox. However, I have tried that and it makes no difference. I have also disabled the "Use my KDE style/fonts in GTK apps" options and it makes no difference. FWIW, this same configuration category was in early ubuntu 9.04 alpha/beta but was removed. Scroll bars in u9.04 KDE tbird are fine (but fonts aren't so great).
OK, I found what is causing the scroll bar problem plus crashes and/or lockup on shutdown of thunderbird, firefox and gvim (all GTK based apps I assume). If I change the selection for GTK Styles to anything other than "Use another Style: qt4" to any of the others (e.g., Nodoka) the scroll bars are fine. Also it fixes the startup and shutdown crash of thunderbird, firefox and gvim that I reported as bug 501423 and bug 501621 (which are essentially duplicates of this). Also, the "Nodoka" style seems to match what I see in Kubuntu 9.04 for GTK based apps in KDE.
*** Bug 501423 has been marked as a duplicate of this bug. ***
*** Bug 501453 has been marked as a duplicate of this bug. ***
Hmm, more specifically it looks like some issue with gtk-qt-engine.
You can mark bug 501621 as duplicate of this too. This brings up another observation regarding firefox, thunderbird and gvim (and possibly other GTK based apps running under KDE). The fonts that appear in the menus and in thunderbird, the folder list and the email list font seems to always be kind of large and cannot be adjusted regardless of how I set the GTK Fonts under "GTK Fonts and Style" in KDE settings. These applications look OK when run under Gnome. I don't know if this should be entered as a new bug but it also seem to be related to "gtk-qt-engine" and/or the KDE method of setting the parameters to it. Basically, the parameters under GTK Fonts and Styles for GTK Fonts have no effect. (But setting GTK Styles to Nodoka fixes several problems.)
*** Bug 501621 has been marked as a duplicate of this bug. ***
*** Bug 455413 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > This brings up another observation regarding firefox, thunderbird and gvim (and > possibly other GTK based apps running under KDE). The fonts that appear in the > menus and in thunderbird, the folder list and the email list font seems to > always be kind of large and cannot be adjusted regardless of how I set the GTK > Fonts under "GTK Fonts and Style" in KDE settings. I suspect this has something to do with DPI settings -- does Gnome still force everything to 96DPI or not? Probably this is another bug in any case ... Should the summary of this bug be changed to make it easier to find?
Upstream please, there's not much chance of us making a fedora-only change (unless someone wants to throw a patch my way), http://code.google.com/p/gtk-qt-engine/issues/list Unfortunately, there's several issues raised here... the first/primary one being tb scrollbars, then hanging, then fonts. Scrollbars -> upstream hanging -> unknown (I suspect app bugs myself, but there's no evidence either way). Not reproducible with tb myself. fonts -> probably disfunctional, kde font settings are already shared with gtk apps via xsettings-kde (if xsettings-kde is installed anyway).
The problems with starting vim are already filed upstream: http://code.google.com/p/gtk-qt-engine/issues/detail?id=51 I've never personally had firefox crash on me (and I don't use Thunderbird), but Firefox does look seriously ugly if I use the default style -- this is bug 455404 and http://code.google.com/p/gtk-qt-engine/issues/detail?id=66
(In reply to comment #15) > The problems with starting vim are already filed upstream: > http://code.google.com/p/gtk-qt-engine/issues/detail?id=51 > > I've never personally had firefox crash on me (and I don't use Thunderbird), What I see when I set "Use my KDE styles in GTK application" or if I set "Use another style" to Qt4, on shutdown of firefox or thunderbird they usually hang without actually crashing so you have to "killall -9 thunderbird-bin firefox" to restart them. About 1 in 4 times, on shutdown, they might crash which allow them to be restarted with no kill. With other setting of this option (such as Nodaka) firefox and thunderbird always shut down cleanly with no hang or crash. > but Firefox does look seriously ugly if I use the default style -- this is bug > 455404 and http://code.google.com/p/gtk-qt-engine/issues/detail?id=66 Choosing Nodaka as described above fixes this problem of strange artefacts in tabs. You also get a nice shaded blue tinge on the selected tab with Nodaka. However, the font size in thunderbird, firefox and gvim on non-rendered items such as menus folder and email lists are a font size that are a step or two too large compared to other KDE app such as kfm and can't be adjusted (Setting GTK Fonts in "Use my KDE styles and fonts" has no effect).
(In reply to comment #16) > (In reply to comment #15) > > The problems with starting vim are already filed upstream: > > http://code.google.com/p/gtk-qt-engine/issues/detail?id=51 Forget to mention that selecting Nodoka for GTK Style also fixes this GVIM problem for me.
The font size differences are likely due to gtk defaulting to 96dpi whereas qt/kde uses what the X server reports for dpi. You could try setting 96dpi for font sizes in systemsettings for fonts and see.
(In reply to comment #18) > The font size differences are likely due to gtk defaulting to 96dpi whereas > qt/kde uses what the X server reports for dpi. You could try setting 96dpi for > font sizes in systemsettings for fonts and see. No diff between disabled, 96 and 120. Always big font in tbird, firefox and gvim menu.
*shrug* it worked for me. oh well.
To be clear, changing the kde dpi setting, changes relative font size in qt/kde apps, (presumably) to match the gtk ones.
(In reply to comment #19) > (In reply to comment #18) > > The font size differences are likely due to gtk defaulting to 96dpi whereas > > qt/kde uses what the X server reports for dpi. You could try setting 96dpi for > > font sizes in systemsettings for fonts and see. > > No diff between disabled, 96 and 120. Always big font in tbird, firefox and > gvim menu. You might need to log out and log back in to see the effect of this ... still, font size is a separate bug to crashing/hanging and should probably be filed separately, no?
(In reply to comment #22) > > You might need to log out and log back in to see the effect of this ... still, > font size is a separate bug to crashing/hanging and should probably be filed > separately, no? KDE says you just have to restart the app. However, logging out/in and restart OS had no effect. I went ahead and entered a new bug 502925
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 512487 has been marked as a duplicate of this bug. ***
The bug I reported is deemed the same as this. The symptom I observed was that firefox kept on running after closing the last window and consuming 50% of my cpu power on a desktop x86_64 and up to 80% on a laptop PAE/i686 system. I see that the initial complaint here is that the scroll jumps around. I never realized that this was a further manifestation of the bug, but I have observed it, too (never, however reported). In openoffice (using qt4 style, haven't experimented with clearlooks), I have long noticed that, when scrolling through long documents, the mouse refuses to grab the scroll tab and the tab jumps all over the place, making it difficult, even impossible, to scroll through a document.
Petrus: Would it be right to guess that yoru x86_64 desktop is dual-core (or dual-CPU), and your i686 laptop isn't? That's probably the difference in the percentages you see; Firefox is using up one core entirely, while the other takes care of the rest of your system. On the laptop, it has to share that core. And yes, I'm another one that's also had those scrollbar problems in Thunderbird, but never bothered to track it down, since it was just a bit worse than cosmetic.
*** Bug 501139 has been marked as a duplicate of this bug. ***
(In reply to comment #27) > Petrus: Would it be right to guess that yoru x86_64 desktop is dual-core (or > dual-CPU), and your i686 laptop isn't? > That is correct. And I also surmised that this explains the different percentages.
There's some discussion of this from the xcb point of view in the thread at http://lists.freedesktop.org/archives/xcb/2009-July/004870.html .
I've found mozilla bug #417163 which discusses this issue. They paper over the gtk/qt bug by not closing the display if the theme is qt, http://hg.mozilla.org/releases/mozilla-1.9.1/diff/161994346487/toolkit/xre/nsAppRunner.cpp However, this doesn't work any-more as they check "theme_is_qt = strcmp(theme_name, "Qt") == 0" and the theme is named "Qt4", at least in fedora. I wonder if it's possible to check some property of the theme engine rather than the theme name, it would be less fragile.
Comment 22 and 31 of https://bugzilla.mozilla.org/show_bug.cgi?id=417163 discuss the interaction between gtk and the gtk-qt-engine and why gtk-qt-engine's theme_exit() is (apparently) never called. In particular, "...GTK makes no promises to notify theme engines when opening and closing displays. It is up to the theme engine to register for close display signals." Is this talking about http://library.gnome.org/devel/gdk/stable/GdkDisplay.html#GdkDisplay-closed ? I'm not sure how qt-glib mainloop integration works, but would it be possible for gtk-qt-engine to register for that signal? Even if it is, there's another problem ahead: according to http://code.google.com/p/gtk-qt-engine/source/browse/trunk/gtk-qt-engine/src/engine.cpp#140 the engine uses a dummy event dispatcher to "stop Qt from integrating with the Glib event loop and stealing events from GTK." As the code there was imported from an unknown repository (and bugtracker) fairly recently, it's hard to know more about when this was added and why. But examination of all the archived tarballs reveals that this was added during the port to Qt4 (after gtk-qt-engine-0.8.tar.bz2) But I don't know what the problem with the glib event loop was, or whether it is still valid.
Finally, note that gtk-qt-engine will be removed from ubuntu, due to a semi-abandoned upstream - see https://bugs.launchpad.net/ubuntu/+source/gtk-qt-engine/+bug/404930 and https://bugs.launchpad.net/ubuntu/+source/gtk-qt-engine/+bug/366670
I did have this with F11 until a few days ago (i686) - but I suddenly noticed that after updating two systems today Thunderbird no longer leaves processes running on quitting the application! I don't know what changed but both my systems now have clean Thunderbird shutdowns.
I have switched to kcm-gtk. Happily so!
Similar to comment #33 on ubuntu, we've retired gtk-qt-engine from F-12 onwards, in favor of kcm-gtk
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
i do have the same problem as is mentioned in Bug 501139, this Bug is closed as a duplicate of this message. The problem is: "Thunderbird hangs when i try to close Thunderbird" Version: Thunderbird 3.0.4 OS: WindowsXP SP3 Account: IMAP IMAP-Server: Dovecot 1.2.5
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.