After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 415677 - Epiphany progress bar jumps around while loading pages
Epiphany progress bar jumps around while loading pages
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.10.x
Other Linux
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
: 421063 483139 (view as bug list)
Depends on: 368759
Blocks:
 
 
Reported: 2007-03-07 12:17 UTC by Sebastien Bacher
Modified: 2008-03-05 17:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase (1.59 KB, text/plain)
2007-10-19 21:27 UTC, Xan Lopez
  Details
Testcase, second version (2.20 KB, text/plain)
2007-10-19 21:41 UTC, Xan Lopez
  Details
[1/2] We always chain to the parent size_allocate, no need to do this. (441 bytes, patch)
2007-12-25 20:09 UTC, Xan Lopez
committed Details | Review
[2/2] Take into account modifications of the inner frame for has_extra_children. (543 bytes, patch)
2007-12-25 20:09 UTC, Xan Lopez
committed Details | Review
The full testcase (2.25 KB, text/plain)
2007-12-25 20:16 UTC, Xan Lopez
  Details
[1/1] Another small cleanup: do not reimplement g_list_find. (702 bytes, patch)
2007-12-26 02:33 UTC, Xan Lopez
rejected Details | Review
screencast of the bug in 2.21.92 (316.16 KB, application/ogg)
2008-03-05 15:39 UTC, Jean-François Fortin Tam
  Details

Description Sebastien Bacher 2007-03-07 12:17:56 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"
Comment 1 Christian Persch 2007-03-07 18:35:05 UTC
I'm guessing this comes either from a gtkstatusbar bug, or, more likely, from the unusual way that gtkprogressbar does its drawing...
Comment 2 Diego Escalante Urrelo (not reading bugmail) 2007-03-09 23:32:47 UTC
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.
Comment 3 Reinout van Schouwen 2007-03-11 13:06:01 UTC
Moving.
Comment 4 Christian Persch 2007-03-21 15:27:37 UTC
*** Bug 421063 has been marked as a duplicate of this bug. ***
Comment 5 Alexander “weej” Jones 2007-03-23 02:38:52 UTC
I'm seeing this too. Subscribing.
Comment 6 Christian Persch 2007-10-03 23:30:58 UTC
*** Bug 483139 has been marked as a duplicate of this bug. ***
Comment 7 Andrea Cimitan 2007-10-18 10:06:09 UTC
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?)
Comment 8 Christian Persch 2007-10-18 11:58:40 UTC
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.
Comment 9 Xan Lopez 2007-10-19 21:27:34 UTC
Created attachment 97494 [details]
Testcase

Shouldn't it happen here too then?
Comment 10 Xan Lopez 2007-10-19 21:31:29 UTC
No, it shouldn't, I didn't read it carefully enough :)
Comment 11 Xan Lopez 2007-10-19 21:41:58 UTC
Created attachment 97497 [details]
Testcase, second version

But this copies the ephy layout AFAICT. Still nothing.
Comment 12 Xan Lopez 2007-10-19 21:52:16 UTC
Hiding and showing the statusbar on each set_fraction triggers the bug.
Comment 13 Xan Lopez 2007-12-25 20:09:12 UTC
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(-)
Comment 14 Xan Lopez 2007-12-25 20:09:21 UTC
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(-)
Comment 15 Xan Lopez 2007-12-25 20:10:34 UTC
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.
Comment 16 Xan Lopez 2007-12-25 20:16:53 UTC
Created attachment 101594 [details]
The full testcase
Comment 17 Xan Lopez 2007-12-26 02:33:57 UTC
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(-)
Comment 18 Matthias Clasen 2007-12-26 05:00:18 UTC
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...
Comment 19 Xan Lopez 2007-12-26 11:29:23 UTC
(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.

Comment 20 Xan Lopez 2007-12-26 11:38:32 UTC
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)
Comment 21 Jean-François Fortin Tam 2008-03-05 15:39:50 UTC
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
Comment 22 Christian Persch 2008-03-05 15:57:34 UTC
Using gtk+ svn trunk (or 2.13.0) ?
Comment 23 Jean-François Fortin Tam 2008-03-05 17:13:23 UTC
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...