User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 Past versions of Firefox allowed me to zoom the text of a page with holding down CTRL and turning the wheel down. With the new page zoom feature this is reversed. CTRL and wheel down zoom out of the page (makes everything smaller) when I expect it to zoom into the page (make everything bigger). Reproducible: Always

This is intentional, all other applications (except IE versions before IE 7) use the same logic, see bug 141476. So I'd say this is WONTFIX.

I understand, to some degree. I would be happy with a hidden configuration already so I get at least the same behaviour like it was in pre-FF3 ... Any chances? I see that the current functionality for page zoom already uses the special mouse wheel action '5', so a '6' could be introduced which does the same, just reverses the directions?

on attachment 282737 [details] [diff] [review] of bug 141476 need to change from ChangeTextSize((adjustment > 0) ? -1 : 1); to something like ChangeTextSize((adjustment > 0 ? -1 : 1) * (getBoolPref("page.zoom.on.mouse.wheel.up")? 1 : -1));

Thanks for the hint, Biju. Here's my attempt with this patch. I'm now running my custom build with the hidden pref "zoom.reverse" set to true and it's a pleasure.

Thanks Markus for the patch Now we have to go through the process, to get it landed. ie, review, super-review, approval etc. see http://www.mozilla.org/hacking/reviewers.html For that once you upload patch you have to set flags, ie select "?" for review and put a requestee at https://bugzilla.mozilla.org/attachment.cgi?id=290112&action=edit I will do it for you now. But I am quite not sure who is supposed to review and all so I am putting jonas@sicking.cc, as jonas did review for bug 141476 I am also adding others to CC, so that they can correct if I am wrong.

I don't think we should do this. Yes, I realize that it means that a few users (which unfortunately includes Markus) won't get the behavior they are used to. But we're doing both the logical thing (up means bigger), and following platform behavior (with exception of old versions of one app, IE 6 and lower). Having prefs like the one suggested here is always a pain to maintain in the long run. Markus, why do you want firefox to behave this way?

Jonas, I was one among those who requested to get bug 141476 fixed. But after I got used to the old firefox way, now I find little difficult to do it in the new way. I believe, I will get adjusted to new way in a month or two. So I feel many those who got adjusted to old way may find the new changes making life difficult. ie, something becomes a habit and get wired to the brain. You may notice, some people who may not have worked on VI editor for years and forgotten all commands, may still be able to use VI editor without any problem. Very difficult to believe till I saw a friend of mine did it after 25 years away from coding and using UNIX.

I think it'll be relatively easy to relearn that up means bigger, especially given that that is how it works in all other apps.

Hello Jonas, I've been using Firefox since it's first day (9th Nov. 2004 if I'm right) and I've since then used the font resizing feature with the mouse and .. well, this are about three years and that's why I'm very used to it. I don't use zoom that way in other applications; at least not that often. I'm using the zoom feature literally every day. My sight vision simply demands it. I was so pleased to finally see full page zoom because with just text resizing 50% of the pages had glitches when just the text was zoomed but not the layout. I've been using font zooming in IE6 and it used to be the same as in Firefox. I don't use this zoom feature in e.g. Word, simply because usually when I open word the zoom factor is already satisfying enough to simply work ahead. I realize that this behavior has changed in IE7 too, but I'm not using this browser eight to then hours a day. This is why I want Firefox to behave this way.

Try raising the issue in the newsgroup. I just don't think that the minor inconvenience of relearning this is worth including and maintaining this code (especially since nothing bad happens if you get it wrong). But this decision shouldn't be solely mine.

(In reply to comment #10) > Try raising the issue in the newsgroup. which one? > ... minor inconvenience of relearning it depends on people

I'd say mozilla.dev.platform. Or try to get the people that wrote the original patch involved.

Hi Andrew, Fix for bug 141476 do not have a config option. This make it difficult for people whos brain got already wired to the way firefox did earlier. So can please help to get it configurable (at least by about:config) Markus has already put the logic in attachment 290112 [details] [diff] [review] "One can keep a dog's tail in a straight tube and hold it there for as long as the dog lives. But it will curl as soon as you take it out of the tube!" (In reply to comment #12) > I'd say mozilla.dev.platform. Or try to get the people that wrote the original > patch involved. I am adding others involved in bug 141476 who seems to like it configurable

Don't we already have a config item for this: mousewheel.withcontrolkey.numlines can be either positive or negative.

(In reply to comment #14) > Don't we already have a config item for this: > mousewheel.withcontrolkey.numlines can be either positive or negative. Yes, setting it to "-1" seems to produce the desired effect.

Jonas, are you sure that no Gecko-based app will want the old behavior? I agree that Firefox probably does not, but I'm not sure I like changing behavior on all embedding apps like this... For embedding purposes, it would be really nice if the embeddor could control this without making C++ changes. That said, if the numlines pref can be used to achieve that effect, that might be good enough.

Since no embedding app has requested a pref like this in the past I don't think we should assume that they'll want it now. If some embeddor speaks up and has a good reason to want this then I guess we can reconsider. Anyhow, seems like there is another pref that accomplishes the same thing. So I'm closing this bug as WONTFIX

thanks all for looking into this issue

A big thanks from me, too. I will a bit like firing a rocket against birds ;)

I appreciate the "mousewheel.withcontrolkey.numlines = -1" setting. Although the mozilla developers apparently agree on their own personal preference for changing Firefox 3's zoom to behave more like IE7 and Opera, for the many Firefox 2 users who prefer Firefox 2's behavior, this gives them a simple way to revert it. Even better would be a checkbox within the preferences dialog, so users wouldn't need to discover and manually modify the about:config setting. (If it were up to me, I'd keep Firefox 2's behavior as the default, and allow users to reverse the direction only if they choose to).

See bug 437596 for reverting the default.

Info for likely future visitors from Google after release of Firefox 17: The Firefox's <=16 equivalent of mousewheel.withcontrolkey.numlines = -1 in Firefox 17+ seems to be: mousewheel.with_control.delta_multiplier_y = -100 https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling