GNOME Bugzilla – Bug 112291
Right scrollbar of tabbed windows do not comply with Fitt's law
Last modified: 2012-01-23 11:24:54 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.
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.
Marking low because it depend on a gtk change.
*** Bug 125245 has been marked as a duplicate of this bug. ***
*** Bug 126535 has been marked as a duplicate of this bug. ***
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Target Milestone: 1.6 -> 1.8
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.
If this will be fixed magically when gtk fixes, I suggest just marking it a dup.
*** Bug 355375 has been marked as a duplicate of this bug. ***
There is also the same problem with gedit. So should be fixed in gtk.
Has there been a gtk bug created yet?
bug 112007 maybe?
Oh of course the bug this one depends on... bug 123408
Why do bugs set themselves to NEEDINFO?
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.
Created attachment 88336 [details] a faked image of how gedit would look
*** Bug 471617 has been marked as a duplicate of this bug. ***
There is a similar Ubuntu bug on https://bugs.launchpad.net/epiphany-browser/+bug/144402
*** Bug 492392 has been marked as a duplicate of this bug. ***
*** Bug 596587 has been marked as a duplicate of this bug. ***
*** Bug 640070 has been marked as a duplicate of this bug. ***
Let's fix this for 3.0.
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+.
The even better news: this seems to be a bug in GTK+, independent of setting padding to 0.
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
(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).
(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.
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.
(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.
This has been already fixed in gnome-themes-standard. Only took 9 years (!).