GNOME Bugzilla – Bug 59186
Delays in tab listing refresh during page switch
Last modified: 2003-09-10 20:19:07 UTC
Sometimes, usually after Galeon's been running for a while, I'll notice that tab switching has become very slow. When I click on a tab, the contents of the page (i.e. the gtkmozembed) get shown immediately, but the tab listing takes a while (up to half a second or more, sometimes) before it's redrawn to show which tab is currently selected. I've been unable to track down the cause of this. I can't reproduce it at will, even when I notice the problem, save the session, and then later load the session. From the use of debugging printf statements, it appears that the pause is NOT taking place in window_notebook_switch_page_cb(). I'm using libgtk 1.2.10, and this has been around for at least several months. I'll try to investigate this further. If anyone finds a reliable way to reproduce it, please let me know.
As a followup, I'm pretty sure that this must be a bug in the GtkNotebook widget. The last time I saw the behavior, I opened a new window and created a few tabs in it. The switching in the new window was normal, but the delays still persisted in the original window (which implies to me that this is not caused by Mozilla or Galeon code). After I closed all but two of the tabs in the original window, it went back to normal. I'm not looking forward to trying to find out why this is happening...
I see this behaviour sometimes too. I thought it was some problem with mozilla, but the GtkNotebook explanation sounds better.
I'm even more convinced that this is a GTK-related problem now. Yesterday, I was able to scroll up and down in the mozembed that I was switching to before the tab display update finished, so it would appear to me that this is not a bug in Mozilla or in Galeon's page switch callback. Since I've never seen any sort of switching delay in other programs that use a GtkNotebook, I'm thinking that this might be somehow related to the way that we're packing an hbox containing a label and a button into each tab, instead of just packing a label (like every other application does). I think this might be a no-no, especially because the closebutton has its own GdkWindow. I'll ask about this soon on a GTK mailing list to see if this could be the cause of the problem. Oh, and to clarify, the delay seems to show up after a lot of tabs have been created/destroyed, not after Galeon has been running for a long time.
> Oh, and to clarify, the delay seems to show up after a lot of tabs > have been created/destroyed, not after Galeon has been running for a > long time. this sounds like a candidate for some automated testing attempt
Hmm, this still shows up when I comment out the code that puts the hbox and closebutton into the tab, so only the label is being put there. Now I'm really confused. :(
Created attachment 5883 [details] a tabswitching trace
Oh well, there's nothing we can do about this from our end, I guess.
*** Bug 79626 has been marked as a duplicate of this bug. ***
Can someone using Galeon 2 state whether this is still a problem or not?
I havn't seen this in galeon 1.3, and galeon 1.2 is no longer supported for bug fixes. If this is still reproducable in galeon 1.3 then please reopen the bug.