Note that this is a regression - I'm pretty sure that previous versions of Ubuntu and/or Firefox had this right.
Description of the problem:
In user interface design (unfortunately not among mist Open Source developers ) it's a wide known fact that objects that are located at a screen edge are easier to target with the mouse - this is the main reason that MacOS menus are always at the top of the screen.
That's because you can simply slam the mouse pointer in the general direction of an edge or corner of the screen and it will stop at the edge - then you can interact with the object by clicking dragging and so on.
Locating UI objects at the edges of the screen is therefore a desired practice for most commonly used objects , so interacting with them takes less effort - it's a significant usability gain.
In firefox's vertical scrollbar context it means one can easily target the scrollbar and scroll the page without precisely targeting the scrollbar - one simply moves the mouse far to the right and it's on the scollbar then.
This hase definitely worked before. Now it doesn't - when I reach the screen edge, I have to retract the mouse at least one pixel back to the left to be able to drag the scollbar. It takes much more effort now and gives an uncomfortable feeling when I use Firefox. To be fair, Konqueror did never do this right, but there's a bug in their Bugzilla: https://bugs.kde.org/show_bug.cgi?id=96727
This effect is known as "mile high menu bar" or "infinite size widget". To quote some experts:
http://www.asktog.com/columns/022DesignedToGiveFitts.html
"Remember that Fitts' Law states that access time is a function of distance and target size. If the target size is larger, then the time is reduced. It is reduced for a simple reason: the user need not slow down when approaching the target for fear of overshooting.
Now consider the screen edge. How deep is the target? If it were really only the one pixel it appears, it would be very hard to hit. However, the screen edge is, for all practical purposes, infinitely deep. It doesn't matter how fast that mouse is going when it hits the screen edge, that pointer absolutely will not overshoot. Having to hit a pixel two pixels in from the screen edge takes much longer than hitting the edge itself. Use that edge. It is your friend."
http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html
"When the Macintosh was new, Bruce "Tog" Tognazzini wrote a column in Apple's
developer magazine on UI. In his column, people wrote in with lots of interesting
UI design problems, which he discussed. These columns continue to this day on
his web site. They've also been collected and embellished in a couple of great
books, like Tog on Software Design, which is a lot of fun and a great introduction
to UI design. (Tog on Interface was even better, but it's out of print.)
Tog invented the concept of the mile high menu bar to explain why the menu bar
on the Macintosh, which is always glued to the top of the physical screen, is
so much easier to use than menu bars on Windows, which appear inside each application
window. When you want to point to the File menu on Windows, you have a target
about half an inch wide and a quarter of an inch high to acquire. You must move
and position the mouse fairly precisely in both the vertical and the horizontal
dimensions.
But on a Macintosh, you can slam the mouse up to the top of the screen, without
regard to how high you slam it, and it will stop at the physical edge of the
screen - the correct vertical position for using the menu. So, effectively,
you have a target that is still half an inch wide, but a mile high. Now you
only need to worry about positioning the cursor horizontally, not vertically,
so the task of clicking on a menu item is that much easier.
Based on this principle, Tog has a pop quiz: what are the five spots on the
screen that are easiest to acquire (point to) with the mouse? The answer: all
four corners of the screen (where you can literally slam the mouse over there
in one fell swoop without any pointing at all), plus, the current position of
the mouse, because it's already there."
this is not a firefox problem. Other GTK+ Application show this behaviour as well. Thus, I reassigned this bug to gtk+2.0.