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 112291 - Right scrollbar of tabbed windows do not comply with Fitt's law
Right scrollbar of tabbed windows do not comply with Fitt's law
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Tabs
2.20.x
Other All
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 125245 126535 355375 471617 492392 596587 640070 (view as bug list)
Depends on: 123408
Blocks:
 
 
Reported: 2003-05-05 13:18 UTC by Tim Riley
Modified: 2012-01-23 11:24 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
a faked image of how gedit would look (59.68 KB, image/png)
2007-05-17 15:29 UTC, Jan Niklas Hasse (Account disabled)
  Details
ephy-notebook: force padding to 0 (1.38 KB, patch)
2011-01-21 02:16 UTC, Diego Escalante Urrelo (not reading bugmail)
none Details | Review

Description Tim Riley 2003-05-05 13:18:16 UTC
Window managers like openbox3 and metacity remove the window borders when
windows are maximised.  This is so a user may slam his cursor to the right
edge of screen, where he can drag up and down to control the scrollbar of
the maximised app.

When using ephy without a tabbed window, this is possible - clicking and
dragging at the extreme right edge of a maximised ephy window allows the
cursor to control the scroll bar.

However, when using a tabbed window, there is padding space associated with
the notebook tab interface and this therefore requires the user to more
precisely position his cursor, creating a more difficult to use interface.

This problem does not exist in other tabbed browsers like Mozilla and Phoenix.
Comment 1 Dave Bordoley [Not Reading Bug Mail] 2003-05-11 04:04:45 UTC
a similar bug to this in IE4 is really getting to me right while 
using my mom's Pentium pro and crap mouse. It's hard to target and 
the fact that slamming against the edge of the screen doesn't work is 
way annoying. Basically I sypathize.
Comment 2 Marco Pesenti Gritti 2003-09-28 10:08:13 UTC
Marking low because it depend on a gtk change.
Comment 3 Christian Persch 2003-10-22 22:02:55 UTC
*** Bug 125245 has been marked as a duplicate of this bug. ***
Comment 4 Christian Persch 2003-11-09 12:17:47 UTC
*** Bug 126535 has been marked as a duplicate of this bug. ***
Comment 5 Christian Persch 2004-10-13 10:51:14 UTC
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Comment 6 Christian Persch 2005-02-27 13:43:48 UTC
Target Milestone: 1.6 -> 1.8
Comment 7 Josh Lee 2005-06-19 19:22:43 UTC
If nothing else this bug is annoying because it is inconsistent: Sometimes I can
use the scrollbar and mousewheel with the pointer all the way to the edge of the
screen, and sometimes I can't.
Comment 8 Luis Villa 2005-07-14 20:08:33 UTC
If this will be fixed magically when gtk fixes, I suggest just marking it a dup.
Comment 9 Christian Persch 2006-09-11 11:28:06 UTC
*** Bug 355375 has been marked as a duplicate of this bug. ***
Comment 10 Jan Niklas Hasse (Account disabled) 2006-12-27 17:05:13 UTC
There is also the same problem with gedit. So should be fixed in gtk.
Comment 11 Jan Niklas Hasse (Account disabled) 2007-03-29 14:14:37 UTC
Has there been a gtk bug created yet?
Comment 12 Reinout van Schouwen 2007-03-29 15:04:39 UTC
bug 112007 maybe?
Comment 13 Reinout van Schouwen 2007-03-29 15:05:43 UTC
Oh of course the bug this one depends on... bug 123408
Comment 14 Reinout van Schouwen 2007-03-29 16:16:53 UTC
Why do bugs set themselves to NEEDINFO?
Comment 15 Jan Niklas Hasse (Account disabled) 2007-05-17 15:28:24 UTC
What do you think of a new GtkWidget named something like GtkTabBar or something like this, which only has a top line of "selectors" (don't know how to name them) and does not have any border. (in short: Like the one in Firefox)
This could be use in epiphany, gedit, etc. only for the different documents and all other GtkNotebook would still look good.
Comment 16 Jan Niklas Hasse (Account disabled) 2007-05-17 15:29:22 UTC
Created attachment 88336 [details]
a faked image of how gedit would look
Comment 17 Reinout van Schouwen 2007-08-30 21:51:35 UTC
*** Bug 471617 has been marked as a duplicate of this bug. ***
Comment 18 Sebastien Bacher 2007-09-27 21:32:04 UTC
There is a similar Ubuntu bug on https://bugs.launchpad.net/epiphany-browser/+bug/144402 
Comment 19 Reinout van Schouwen 2007-11-01 17:15:12 UTC
*** Bug 492392 has been marked as a duplicate of this bug. ***
Comment 20 Reinout van Schouwen 2009-09-28 11:39:20 UTC
*** Bug 596587 has been marked as a duplicate of this bug. ***
Comment 21 Dan Winship 2011-01-20 14:41:13 UTC
*** Bug 640070 has been marked as a duplicate of this bug. ***
Comment 22 Xan Lopez 2011-01-20 14:50:33 UTC
Let's fix this for 3.0.
Comment 23 Diego Escalante Urrelo (not reading bugmail) 2011-01-21 02:08:53 UTC
The good news:
it works if you just remove padding from the notebook, try this in .config/gtk-3.0/gtk.css:

GtkNotebook {
  padding: 0;
}

obviously we can do this with a few lines of code in EphyNotebook.


The bad news:
the scrollbar goes nuts, sometimes it detects clicks on the handle (drags), sometimes it detects the clicks on the empty spaces (jumps). I'll blame GTK+.
Comment 24 Diego Escalante Urrelo (not reading bugmail) 2011-01-21 02:10:52 UTC
The even better news:
this seems to be a bug in GTK+, independent of setting padding to 0.
Comment 25 Diego Escalante Urrelo (not reading bugmail) 2011-01-21 02:16:40 UTC
Created attachment 178905 [details] [review]
ephy-notebook: force padding to 0

Don't break Fitt's law on scrollbars when more than one tab is opened.

Bug #112291
Comment 26 Xan Lopez 2011-01-21 11:02:27 UTC
(In reply to comment #24)
> The even better news:
> this seems to be a bug in GTK+, independent of setting padding to 0.

Hum, so how do you reproduce it without setting the padding to 0? I've tried the patch and the effect is somewhat annoying, we should probably try to fix things before landing it (and FWIW, I'd just try to convince the GTK+ guys to do the whole thing upstream, it makes perfect sense).
Comment 27 Xan Lopez 2011-01-21 11:06:53 UTC
(In reply to comment #26)
> (In reply to comment #24)
> > The even better news:
> > this seems to be a bug in GTK+, independent of setting padding to 0.
> 
> Hum, so how do you reproduce it without setting the padding to 0? I've tried
> the patch and the effect is somewhat annoying, we should probably try to fix
> things before landing it (and FWIW, I'd just try to convince the GTK+ guys to
> do the whole thing upstream, it makes perfect sense).

OK, obviously you meant that the same things happen, without the patch, when there are no tabs opened (I guess I never noticed because I rarely have no tabs). Still I'd say we should not commit until this is fixed, making it happen *all the time* is kind of bad.
Comment 28 Diego Escalante Urrelo (not reading bugmail) 2011-01-21 16:34:47 UTC
Of course, we need to fix GTK+ first. These are two bugs I think: allowing to not show notebook borders and click detection when the notebook has no padding.
Comment 29 André Klapper 2011-02-11 11:03:33 UTC
(In reply to comment #22)
> Let's fix this for 3.0.

I don't see why this is suddenly a blocker if it has not been for years.
Removing gnome target; feel free to use a target milestone.
Comment 30 Xan Lopez 2012-01-23 11:24:54 UTC
This has been already fixed in gnome-themes-standard. Only took 9 years (!).