mouse wheel zoom consistency

Almost forgot: build 20020426 Linux.

Mousewheel stuff is bryner...

The current behavior comes from IE. IMO, we should keep this in line with what
IE does.

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

why not make it a configurable option?
Duplicating unintuitive behavior from IE it's ok for de facto "standards"
compliance, but an option for a more appropiate implementation should be
included.

I am just saying that it is pretty unintuitive to make text bigger when you
move the wheel down.

IE's behavior could be a bug. In Office (Outlook for example), when you scroll
down while pressing CTRL, text gets smaller, and when scrolling up, it gets
bigger.

No, making an option for this is plain overkill. There is the valid point,
however, that IE behaves one way and Office behaves the other. But we're the
same as IE right now, so I think that's fine for now. Verifying.

Would you please clarify why do you think it would be overkill?
I mean I would be most happy if the proposed behavior replaced the current one,
but that'd be selfish, because there probably are people who are already used
to the old one. I'd be rather unhappy if out of the blue the UI behavior I am
used to changed to something else without giving me choice to retain my old way.
That's why I think it should be a user option.

I would love to hear reasons other than "IE does it like that" for not offering
this option/UI behavior.
Is the system hardcoded in the current behavior?

I can pretty confidently predict that I will get this backwards every single
time, which means it will take me three clicks (my mouse "wheel" is actually two
buttons), plus the redraw delays, to change text size.

<rant>I feel that mozilla is much too extreme in limiting configurability. Yes,
we all want a browser that "just works" well. But we all inevitably find one or
two things that annoy the heck out of us, and it's user-hostile to say "live
with it". Computers are infinitely flexible, so the end goal--an awesome user
experience--should be achieved by a combination of thoughtful defaults, and
adjustment to the user's needs and tastes. Mozilla seems to be stuck on the
former.</rant>

I don't mind if this preference is "hidden", as long as it's documented.

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

I recommend to reopen this bug, since Microsoft has reversed the mouse wheel zoom direction in IE 7. Now Mozilla remains the only application zooming in the wrong direction.

I agree with Stefan, correcting zoom direction is the obvious thing to do now that IE 7 is out.

(In reply to comment #3)
> The current behavior comes from IE.
> IMO, we should keep this in line with what IE does.

Reopening as IE7 has now changed the direction of zoom.
If somebody still wish the other way it can be an about:config item

Good if we can have a zoom button,
see IE7 attachment 245423 on
bug 155562 Ability to add a Zoom button to the Toolbar

Also there should an about:config item to change
ctrl+scroll to shift+scroll or alt+scroll
to avoid situation like bug 215950
"Ctrl + scroll wheel does not zoom text if system scrolls one screen at a time"

similar bugs
bug 299879 <control + mouse scroll> zooms in wrong direction for gnome
bug 358431 Ctrl + mouse wheel zooms in wrong direction

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

i don't know of a single other application that zooms out with the wheel up. if you like i can make a list of apps that work the other way around. (but seriously, just pick a random one)

the longer you wait to fix this, the more people will get used to firefox being backwords and complain later.

Please change the zoom direction asap.

I always zoom in the wrong direction first because I'm so used to Adobe Acrobat and my Office applications working the other way.

An argument for keeping things as they are, I find it intuitive to role 'forward' to zoom in, as it feels like getting 'closer' to the document

An argument for changing things: scrolling downward (towards me) is like grabbing the document and bringing it closer to the eyes.

Also, I filed a bug on Ubuntu for this ( https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/54633 ) and included a small list of applications on Linux that does it differently:
* Evolution
* Google maps (without ctrl)
* Evince
* The Gimp (with shift instead of ctrl)
* Abiword

Oops, please forget first paragraph of previous comment, my mistake! I meant:
scrolling upwards is like 'diving into' the document, taking a closer look.

Can someone whip up a patch? Also, this seems to affect all systems, and OSX's ctrl+mousewheel also says "up = bigger" (though in that case and GMaps, the idea is "up = in", but same difference) so let's get 'er done.

Created attachment 282721
fix via nsEventStateManager::DoScrollTextsize()

Fix attached. I'm not sure who to ask for a review.

Comment on attachment 282721
fix via nsEventStateManager::DoScrollTextsize()

Jonas, will you take a look?

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

Comment on attachment 282721
fix via nsEventStateManager::DoScrollTextsize()

> // positive adjustment to increase text size, non-positive to decrease
>- ChangeTextSize((adjustment > 0) ? 1 : -1);
>+ ChangeTextSize((adjustment > 0) ? -1 : 1);

Please also change the comment to reflect the new behaviour. Looks fine to me otherwise, but I'm not a reviewer... ;-)

Created attachment 282737
same fix with updated comment

Comment on attachment 282737
same fix with updated comment

Would like to get beltzner to UI-review this, but there doesn't seem to be such a flag for Core bugs.

Comment on attachment 282737
same fix with updated comment

jonas: yeah, second-review works for components without ui-review :)

Parity with IE was the only reason we were keeping this, AIUI, and I'm fine to match the behaviour of pretty much every other app and OS under the sun.

Apologies for the slight break in muscle memory for some, I know you'll adapt quickly, and it makes more sense.

Checking in content/events/src/nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v <-- nsEventStateManager.cpp
new revision: 1.710; previous revision: 1.709
done

Stuart Axon said "An argument for keeping things as they are, I find it intuitive to role 'forward' to zoom in, as it feels like getting 'closer' to the document"

I totally agree. It might not be the way every other app does it, but I reckon it's the right way. This new way is akin to scrolling the document "down" when I mousewheel up because I'm going "forward" in the document. It's not intuitive to whats happening on screen.

Verified fixed in Gecko/2007100204 Minefield/3.0a9pre nightly build.

current fix is not configurable,
Bug 404775 has the fix,
Need you guy's attention there

I know this bug is "fixed", but I at least wanted to provide a reason to keep the mousewheel-DOWN = increase text size:

- Pulling the mousewheel DOWN is like PULLING the page toward you.

- Pushing the mousewheel UP is like PUSHING the page away from you.

Think of how a fishing reel or a pulley works.

Also, when I "pull" on the mousewhell, it (subtly) brings my body (eyes) closer to the screen. It's the third Law of Physics: Every Action has an Equal and Opposite Reaction.

Please either:
1. reverse this bug
2. make this a UI option
3. make this a hidden option (edit:config)

There is already a hidden pref to revert to the previous behaviour, see bug 404775 comment #15.

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

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

This should be under Accessibility options - I constantly use the mouse wheel to try to get a readable font size, and am accustomed to the down=enlarge behaviour.

No doubt had I become accustomed to the reverse, it would be natural to me, but it's hard to break a habit.