ooops...ok so there are some issues.

1. Menus:
You should be able to hit the "File" menu by jamming the mouse up against the left screen edge.

2. toolbars
for horizontal toolbars you should be able to hit the left and right most buttons by jamming the mouse against the respective screen edges.
for vertical toolbar you should be able to hit any iterm by jamming the mouse against the screen edge.

3. Scrolled windows
any scrolled window that has a shadow type of shadow_in makes it impossible to  click items in the  scrolled window by slamming the edges of the screen, good example would be a tree view packed inside a scrolled window. (perhaps this one is notabug and gtk should just strongly suggest using shadow_none for any scrolled window that hits a screen edge in the maximized  state.) 

Problem is the bevel isn't sensitive to mouse clicks, basically.

The last one seems entirely irrelevant to me. Fitts law
doesn't say "every element that could be possibly be
flush against the side of the screen should be flush
against the side of the screen", it just points out
that buttons that are against the side of the screen
are easier to hit, and buttons in the corners even
easier.

But I really doubt that people approach clicking
on a treeview that happens to be against the side
of the screen by slamming their mouse against the
edge of the screen. For one thing, if the button/element
isn't small, then people will aim for the center
and hit the center of it.

(Fits law generally matters much more vertically
than horizontall because items are frequently
wider than tall.)

The other two seem low priority to me.

Well the theory is that it is easier to target when you only have to
 aim in one dimension, not two. Fitts law isn't so much a stead
fast rule as much as something you have to deal with, "a force a
 nature." Basically it states the fact that the pixels along the screen
edge are the easiest to hit, so you should take advantage of them.

For the treeview case it is easier to point and select something by
 slamming mouse against the screen edge than it is to aim at a
specified node in the middle. 

Another example might be a text editor or view, where it is 
much easier to place the cursor before the first character, because
 all you have to do to aim is throw the mouse to the screen edge and
 aim vertically.

Actually, a thing I have been thinking about is to add a new interface
like

interface GtkDeadArare {
       GdkRegion *get_dead_area (Widget *widget);
       
       highlight_area (GdkRegion *region);
       
       signal (* enter) (Widget *widget)

(Mozilla keyboard navigation strikes again ...)

A thing I have been thinking about is to add a new interface
like

interface GtkDeadArare {
       GdkRegion *get_dead_area (Widget *widget);
       
       highlight_area (GdkRegion *region);
       
       signal (* enter) (Widget *widget)
       ...;
}

that a widget could implement to tell what areas of it are dead.

This could be useful, not only for scrolled windows, but also
for paned widgets where the immediate children are often shadow-in
frames that make it look like you could grab beside the actual
handle.

I haven't thought about it in any detail so there are probably tons
of reasons it doesn't work.

Menus at the edge of the screen have similar problems. Good example is
 the gnome applications menu, you should be able to select items from the 
menu by clicking the edge of the screen.

Not clear to me what the concrete steps to take here
are, except that they are difficult, in the GTK+ model
where widgets take up definite amounts of space, and
bevels are outside widgets.

Well, a simple solution would be to get rid of the freaking bevels!

What use is there for them, anyway? Firefox does just fine without them.

Notice that on the Firefox team there are people who are good at usability. See the correlation?

For me, the bevels are just a source of small but endless frustration.

(In reply to comment #9)
> Notice that on the Firefox team there are people who are good at usability. See
> the correlation?

I'm not sure what you are insinuating here, but if it is what I think you meant, I find it offensive. Gnome has a strong focus on usability, and making such (false) statements is not helpful at all.

(Anyway, I was only planning to add myself to the CC of this bug.)

*** Bug 660842 has been marked as a duplicate of this bug. ***

*** Bug 661748 has been marked as a duplicate of this bug. ***

*** Bug 664662 has been marked as a duplicate of this bug. ***

*** Bug 665458 has been marked as a duplicate of this bug. ***

gedit has a workaround for this if someone wants to port it to ephy

http://git.gnome.org/browse/gedit/tree/gedit/gedit-notebook.c#n662

When we can make use of the screen edges, we should. gedit is a good example of where the scrollbar isn't on the direct edge and it makes it more difficult to control. You can argue that that's the case because the widget is in a notebook but that's an implementation detail. From a visual perspective there's no need to keep the "shadow_in" either.

uh? comment (In reply to comment #16)
> When we can make use of the screen edges, we should. gedit is a good example of
> where the scrollbar isn't on the direct edge and it makes it more difficult to
> control.

Uh? Did you try? As stated in comment #15 gedit gets this right...

(In reply to comment #17)
> uh? comment (In reply to comment #16)
> > When we can make use of the screen edges, we should. gedit is a good example of
> > where the scrollbar isn't on the direct edge and it makes it more difficult to
> > control.
> 
> Uh? Did you try? As stated in comment #15 gedit gets this right...

Collided with that comment. It also has only recently been fixed.

This is no longer an issue.

There are still some bugs left, e. g. https://bugzilla.gnome.org/show_bug.cgi?id=758244