Closed Bug 63462 Opened 24 years ago Closed 19 years ago

Mousewheel requires click to scroll

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: mikepinkerton, Assigned: jaas)

References

Details

(Keywords: embed) 

right now, the area you want to scroll with the mousewheel needs focus. We have
code that uses the mouse position, but it is upset by idle events sending fake
mouseMoves.

To play with it, do:

#define USEMOUSEPOSITIONFORSCROLLWHEEL 1

in nsMacEventHandler.cpp. It works fine, except that we drop events (they go to
the wrong widget) when the wheel moves very quickly. An idle event sneaks in and
resets the mouse position until the wheel stops.
Status: NEW → ASSIGNED
Keywords: embed, nsmac1
Target Milestone: --- → mozilla0.9
I think requiring focus is desired behavior, actually -- so, for example, you 
can scroll e-mail while hovering the mouse over the Delete button. It's only a 
noticable problem because of the wrong things having focus by default -- bug 
9086, bug 37638, and so on.

If the behavior requested by this bug was implemented, mousewheel scrolling 
would leave you marooned in a multiline text field if the field happened to 
pass under the cursor as you scrolled the page.
Being that it seems like all but the Kensington scrolling mouse issues have been 
solved, is this one of them, pink?  Can we close it out?

On the other hand, here's a thought: is there a time when you'd rather scroll a 
text box instead of the main page with the scrolling wheel?  i don't think 
so...In my opinion, it would be better to assign the scrolling to apply to the 
main page only...and the rest can be done manually.  Or, better yet, make it yet 
another Pref Panel:).  -d.

As i've commented elsewhere scrolling of inner objects including textboxes is 
important. [You can write a 10 paragraph bug comment and want to use 
scrolling].  However, i think we'll leave those problems to be addressed by 
other bugs.
I guess the real question comes down to: Do we want to a) offer scrolling for the 

page without having to click inside the frame [i.e. scrolling will not be 

disabled by typing into the URL box, for example], or b) offer scrolling wherever 

the focus is, at the sacrifice of easy scrolling?  Am I understanding this 

incorrectly?  If so, my apologies...but I'm for the "lazy" solution-I'd rather be 

able to scroll the web page at all times, since I can't find a time where 

scrolling a small text box is that important to me.



Perhaps a check to see if the item that has focus is scrollable?  If not, then it 

should default to the main page...i.e. if the URL box has focus, you can still 

scroll....



Just some thoughts.


*** Bug 62492 has been marked as a duplicate of this bug. ***
requiring a click to focus goes against how the mousewheel works with all other
mac apps. do i hear mpt actually arguing for something that doesn't work they
way it does in the rest of the OS?
Yes, because I think requiring a click to focus would be more than twice as 
usable as the platform convention (a convention which is probably dictated by 
the way in which current mousewheel software piggybacks native scrollbars, 
rather than by any UI considerations). Scrolling the wrong thing (or nothing) 
whenever you were hovering over a textfield, HTML SELECT popup menu, or toolbar 
would be considerably more annoying than having to click first in some cases 
(and fixing current focus bugs such as bug 9086 and bug 61299 will reduce the 
number of those cases) in order to scroll.
...which is precisely why I suggest that the scrolling default to the main frame 
unless the focus is somewhere else *that is scrollable*.  Its a waste of 
"scrolling focus" (my terminology sucks here, I admit) to pay attention (in this 
respect) to something else that has focus if it can't scroll....no?

On another note, I agree that sometimes having to guess what will scroll next is 
somewhat annoying, but that's easily fixed by moving the mouse a bit.  Having to 
focus somewhere requires (arguably) more effort on my part.

How's that for lazy?

On an unrelated note, I'm taking this bug from jrgm.  I know he'll love me for 
it.
QA Contact: jrgm → lorca
problem in, from the toolkit, we don't know what the "main frame" is, since that
is a very navigator-specific concept -- this is a general purpose toolkit. or
what about a page with multiple frames? Which is the main frame there?
Hmmm.  Good point.  I'd suggest a larger area would be a more important frame, 
but not only would that be a nightmare, Id be incorrect 1/3 of the time.  Grunt.

So, um, how about the nearest scrollbar?:)

On the other hand, I guess the distinction would come in handy when thinking of a 
"main frame" versus an "iframe."  Thoughts?

What Dan Lorca said -- we shouldn't ignore the mousewheel just because focus is
in a non-scrollable object like a text field.  In that case, we should scroll
the next scrollable parent (usually the main content area).
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
i think we can live with this for the time being.
Target Milestone: mozilla0.9 → Future
*** Bug 69112 has been marked as a duplicate of this bug. ***
*** Bug 138829 has been marked as a duplicate of this bug. ***
*** Bug 135500 has been marked as a duplicate of this bug. ***
This is not just a Mac problem.  I have the same/worse problem on Linux.

The problem is that I have a system-wide X-windows preference
"focus-follows-mouse" and ALL other apps (including Netscape 3.79 BTW) react
nicely to wheelmouse scrolling without a click when they get the cursor/focus.

Mozilla 1.x and 0.99 don't behave this way.  Worse. The don't really require
click to focus, they seem to require holding the wheel down while scrolling it,
which is a VERY strenous operation at least in my logitech wheel mouse.

Please fix this bug. Preferably by leaving the window-manager preference alone
rather than overriding it.  Also, please verify that scrolling actually works
when the mouse wheel is not pressed down _while_ scrolling it.  Thanks!

Please leave this bug for the Mac problem, and get a separate bug filed for the
Linux problem.
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
OS: Mac System 9.x → MacOS X
I'm using Mozillz 1.5 on Mac 10.2.6 with a logitech wireless optical mouse and a
USB Overdrive driver for the mouse.  I personally find the click to establish
focus quite annoying (could live with it given Mozilla is the best browser out
there for the Mac).

I am used to scrolling being controlled by having the focus determine by the
cursor location.  There are a number of sites I use where there are large "inner
windows" that are scrollable.

Just my two cents.
*** Bug 228352 has been marked as a duplicate of this bug. ***
*** Bug 230403 has been marked as a duplicate of this bug. ***
Also seeing this with firebird on WinXP
Assignee: pinkerton → joshmoz
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → Widget: Mac
QA Contact: gerardok → mac
This is not a problem any more as far as I can tell. We do not require focus,
and we behave the same way Safari does.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.