spun off from bug 19323. pierre, i'm taking a guess here as to whether this is style system related. if you disagree, feel free to reassign (i don't know where else this would go, cc'ing rginda and bill to see if they would.) tested using opt commercial bits 2000.05.12.08 on Mac OS 9.0. to repro: 1. load the above url. 2. select View > Enlarge Text Size. result: web content shifts a bit to the left, but the text size doesn't change. 3. repeat step 2 (several times). result: nothing changes at all. 4. exit and restart the browser. 5. load the above url. 6. select View > Reduce Text Size. result: content moves a smidgen upwards, but no change to text size. 7. repeat step 6 (several times). result: nothing changes at all.

CCd erik who did the implementation on Win and Unix. This should have been extremely easy to implement, like on the other platforms, but it ended up in something a bit puzzling. Basically, we need to do something like this: float textZoom; mDeviceContext->GetTextZoom(textZoom); pixelSize = NSToIntRound(mFont->Size * textZoom * app2dev); In nsFontMetricsMac::Init(), if we simply multiply 'theStyle.tsSize' with the textZoom factor, it doesn't work. However if (in addition?) we multiply mFont.size with textZoom, it works but then we leak thousands of FontMetrics. Pushed to M17.

Please do not modify mFont itself, since the device context uses it in the font cache. On Windows and Unix, I didn't touch mFont for that reason. And that is also why we are doing the text zoom down in the platform-specific code. We could have done the zoom in the XP code, but I think that would have necessitated a copy of the nsFont before looking it up in the cache, and since the font cache is accessed many times, I feared that this would affect performance. Currently, the fonts are cached according to their un-zoomed nsFont.size, and the zooming is done when we turn the logical nsFont into a physical font.

Adding relnote2 keyword.

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

Major loss of functionality. Nominating nsbeta3.

I filed bug 52969 to remove this menu item form the Mac builds, assuming that this bug is not going to be fixed for nsbeta3/rtm (and since this bug hasn't really moved in four months, I expect that this will not be fixed before ship).

Why doesn't this bug have a triage status? Not fixing this would leave Mozilla without a very useful feature that IE has.

To be clear, I'm not advocating removing the menu items as preferable to actually fixing this bug. However, if this bug is not fixed (and it may not be fixed before nsbeta3 and rtm) then we should remove the menu items for this feature.

Could we get a thumbs-up/thumbs-down for this bug being fixed in the nsbeta3 and rtm time frames. If it cannot be done, then we should move forward on the (regrettable) alternative, which is to remove the associated Menu for 'Text Size' from the Mac UI (bug 52969).

Adding rtm+.

Marking rtm- for Netscape folks. If the extenernal contributor can get this to work, then we'll reconsider taking this, but we won't hold the release for it.

So, how do we fix this, and who wants to take a stab? Not having a Mac seriously reduces the chance of me fixing it ;-)

This menu is no longer on the branch (see bug 54965). Marking Future.

Nominating for Mozilla 0.9.

Just to note, this menu is now explicitly disabled on the Mac since the backend did not work. When this bug gets fixed, you will need to undo the fix for bug 52969, and the menu should then Just Work (tm).

the relnotes for netscape 6.0 (or, even better, its online help) should mention that this feature is now gone (see bug 52969). cc'ing vera.

Adding kristif to cc list Possibly include this info in "Migrating to N6 from Other Browsers" guide

Nom. nsbeta1. View Enlarge/Reduce Text Size is basic Nav1.x functionality we'd like to have working on the Mac again, plus it's important for accessibility to the visually impaired. Marking access.

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)

this was futured back in oct 2000 --clearing milestone to renominate.

Removing rel-note designation (which applied to N6) from Status Whiteboard, as this bug is being considered for a fix in a 6.x release.

This bug has been without a target milestone for over two months. Has this fallen off the appropriate radars?

pierre isn't around...->attinasi?

The menu items are gone (still). We need to put them back and then get the functionality in. I think it is best left for Pierre, assuming he returns. Sadly, sending it back to Pierre since I will not have time for this over the summer due to more pressing layout issues.

Moving to m0.9.3.

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

pierre: ping? :-) Are there any plans to fix this soon? It's rather embarrassing, and confusing for Mac people, who can't work out why everyone else has it and they don't. Gerv

I'll look into it again.

I guess I won't have any problem to get r/sr on that one... Simon? Back to 0.9.4

r/sr=sfraser

r/sr means "either r or sr, take your pick". You still need another reviewer or super-reviewer.

Wouldn't you be better off making this adjustment before the following (both for rounding and because of the 9px cutoff)?: short textSize = float(aFont->size) / dev2app; if (textSize < 9 && !nsDeviceContextMac::DisplayVerySmallFonts()) textSize = 9;

David, the textzoom should be done at the end because: - The cutoff is a hidden Mac-only feature that was used a long time ago when font size issues were not resolved yet (bug 18136). - In the current proposal for revisiting font issues (bug 74186), we agreed that the text zoom should have no size limit and be calculated after the minimum font- size calculation and the font-size-adjust, just before the actual value. r/sr someone?

r=rbs - pretty much what the other platforms are doing, but you can hunt for a Mac guru if you prefer. [I am hoping that the !nsDeviceContextMac::DisplayVerySmallFonts() hack could soon go away once the XP font's min-size with the UI is hooked up from bug 30910 and bug 61883...]

a=dbaron on behalf of drivers

Is this getting in? It would help me with bug 31961 if this change got in first.

Fixed checked in nsFontMetricsMac.cpp and viewZoomOverlay.js

Cool! So what makes it possible to do this now?

Pierre, thank you sooo much for fixing this! It was one of the most worst Mac shortcomings. This problem alone was keeping several people I know from using Mozilla/NS6.

Just tried this out in today's Mac OS X trunk build (2001082905) and the zooming/shrinking works great. There is a cosmetic issue, though -- the menu item in the View menu doesn't change to reflect the current size. The submenu correctly displays the zoom, but the top level item always says "Text Size %100" regardless of the current zoom level. Should this be filed as a seperate bug?

Correct. The label stays at the value it has the first time you click on the menu. For instance if you do twice Cmd-'-' after launching the app and click on the menu, the label stays stuck at 75% (even though the zoom itself works fine and the checkbox in the submenu shows the correct value). This is Mac-only; Win98 doesn't show the problem. I guess the bug is in updateViewMenu() in viewZoomOverlay.js. Please open a new bug and assign to me, but if you or someone else wants to take a look, feel free to take it. Thanks!

pinkerton mentioned that the Mac OS X menu not changing is a known Mac OS X problem. There's a bug on that somewhere (bug pink for it or query bugzilla).

I'm seeing the problem in OS 9.1

Hmmm. Well, I assert it's a problem in Mac specific code. The js front-end code works fine on both Linux and Windows (with no special casing) and should just work fine on Mac too. If you're seeing this in Mac OS 9.1, let's file a bug on it and get it fixed :-)

i've filed bug 97549 for Text Size (100%) not updating. vrfy fixed on both Mac OS X [2001.08.29.05-comm] and Mac OS 9.1 [2001.08.29.08-comm, emul over X]. tested both the shortcuts [cmd+plus/minus] and selecting the menu choices. yay!