GNOME Bugzilla – Bug 415677
Epiphany progress bar jumps around while loading pages
Last modified: 2008-03-05 17:13:23 UTC
That bug has been opened on https://launchpad.net/ubuntu/+source/epiphany-browser/+bug/86845 "Binary package hint: epiphany-browser I'm using Epiphany 2.17.91 on Ubuntu Feisty. They recently replaced the progress bar to look more like Totem's buffer bar. The bar seems to jump to the right and then jumps back and forth when a page is loading. This is on a unmaximized window. I'm not sure if this is an upstream bug. ... http://librarian.launchpad.net/6649504/bar-error.png The over extended progress bar This is happening on the latest version. It happens on every website while loading on a non-maximized window. Maximized windows extend the bar farther to the right than a non-maximized window. What's happening is the bar stalls at a certain percentage. When the bar resumes it jumps to the right at the position it'd be at if it were maximized, but then quickly jumps back to the correct position. I've attached screenshots. http://librarian.launchpad.net/6649505/bar-normal.png Normal position for the bar. http://librarian.launchpad.net/6649507/fullscreen.png Shot of a maximized window while loading"
I'm guessing this comes either from a gtkstatusbar bug, or, more likely, from the unusual way that gtkprogressbar does its drawing...
Well it doesn't sound feasible that this is a bug in Epiphany, after all what could you do to make a widget do that?. I agree that this looks like a gtk+ bug.
Moving.
*** Bug 421063 has been marked as a duplicate of this bug. ***
I'm seeing this too. Subscribing.
*** Bug 483139 has been marked as a duplicate of this bug. ***
subscribing. All gtk-engines are affected so it is a gtk bug or a bug of epiphany (why we have this bug only in ephy?)
The problem is with the interaction of how epiphany puts the progressbar in the statusbar, and how the statusbar does its size allocation. The situation is like this: GtkStatusbar GtkFrame (the statusbar's internal frame) GtkHBox GtkLabel (the statusbar's internal label) GtkProgressBar [pack-end] (The reason for this arrangement is to make the frame extend around the whole statusbar.) Now, if the grip isn't rendered (like in fullscreen mode), everything is fine. However, with the grip present, what happens is that we always get size-allocate twice on the progress bar: first: >[Label................] [Progress]< second: >[Label...........][Progress][Grip]< because gtkstatusbar's size-allocate first chains up to the parent (gtkhbox)'s size-allocate, and then subtracts the grip's with from the frame's child width, and size-allocates the child (the frame) anew.
Created attachment 97494 [details] Testcase Shouldn't it happen here too then?
No, it shouldn't, I didn't read it carefully enough :)
Created attachment 97497 [details] Testcase, second version But this copies the ephy layout AFAICT. Still nothing.
Hiding and showing the statusbar on each set_fraction triggers the bug.
Created attachment 101592 [details] [review] [1/2] We always chain to the parent size_allocate, no need to do this. gtk/gtkstatusbar.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
Created attachment 101593 [details] [review] [2/2] Take into account modifications of the inner frame for has_extra_children. gtk/gtkstatusbar.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
The first patch is as very small cleanup. The second is the best solution I can think of without copying size_allocate (and modifying it a bit) from hbox.
Created attachment 101594 [details] The full testcase
Created attachment 101606 [details] [review] [1/1] Another small cleanup: do not reimplement g_list_find. gtk/gtkstatusbar.c | 11 +++-------- 1 files changed, 3 insertions(+), 8 deletions(-)
The testcase doesn't reproduce the epiphany problem for me; but the first 2 patches look reasonable to me. The last one seems wrong. g_list_find (GTK_BOX (statusbar)->children, statusbar->frame); compares l->data to statusbar->frame for each list element; the code that you remove compares l->data->widget to statusbar->frame...
(In reply to comment #18) > The testcase doesn't reproduce the epiphany problem for me; but the first 2 > patches look reasonable to me. The last one seems wrong. It doesn't? For me it shows the progressbar extending over the resize grip with GTK+ 2.12.0. What version are you using? > > g_list_find (GTK_BOX (statusbar)->children, statusbar->frame); > > compares l->data to statusbar->frame for each list element; the code that you > remove compares l->data->widget to statusbar->frame... > Right. Of course using the testcase that exits early to test that patch was not too smart. I guess we could use g_list_find_custom, but does not seem like a big win then. Thanks for the review.
Committed. 2007-12-26 Xan Lopez <xan@gnome.org> * gtk/gtkstatusbar.c (has_extra_children): take into account the modification of the internal frame contents to decide if we have extra children. (#415677)
Created attachment 106622 [details] screencast of the bug in 2.21.92 could you reopen this bug? I still see this in epiphany-gecko 2.21.92
Using gtk+ svn trunk (or 2.13.0) ?
Ah, no, it seems ubuntu hardy has ligtk2.0-0 version "2.12.8-1", so I guess this is the problem. I thought that this was fixed inside epiphany, but it was a gtk bug as I see. False alert, I guess...