Closed Bug 39117 Opened 20 years ago Closed 18 years ago

[zoom]View Enlarge/Reduce Text Size doesn't work on mac


(Core :: CSS Parsing and Computation, defect, P3, major)






(Reporter: bugzilla, Assigned: pierre)


(Blocks 1 open bug, )


(Keywords: access, helpwanted, platform-parity)


(1 file)

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.
Keywords: pp
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;
  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.
Target Milestone: --- → 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.
Keywords: relnote2
*** Bug 48329 has been marked as a duplicate of this bug. ***
Major loss of functionality. Nominating nsbeta3.
Severity: normal → major
Keywords: nsbeta3
Blocks: 52969
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).
Keywords: rtm
Adding rtm+.
Whiteboard: [rtm+]
Blocks: 53207
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.
Whiteboard: [rtm+] → [rtm-]
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.
Target Milestone: M17 → Future
Nominating for Mozilla 0.9.
Keywords: mozilla0.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).
Keywords: relnoteRTM
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

Keywords: relnote2
OS: All
Whiteboard: [rtm-] → [rtm-] relnote-user
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.
Keywords: access, nsbeta1
Keywords: nsbeta3, relnoteRTM, rtm
Whiteboard: [rtm-] relnote-user → relnote-user
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...
QA Contact: chrisd → ian
nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 
Keywords: nsdogfood
this was futured back in oct 2000 --clearing milestone to renominate.
Target Milestone: Future → ---
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.
Whiteboard: relnote-user
This bug has been without a target milestone for over two months. Has this fallen off the appropriate radars?
Blocks: 31961
pierre isn't around...->attinasi?
Assignee: pierre → 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.
Assignee: attinasi → pierre
Keywords: helpwanted
Moving to m0.9.3. 
Target Milestone: --- → mozilla0.9.3
*** Bug 80050 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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.

I'll look into it again.
Summary: View Enlarge/Reduce Text Size doesn't work on mac → [zoom]View Enlarge/Reduce Text Size doesn't work on mac
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I guess I won't have any problem to get r/sr on that one...  Simon?
Back to 0.9.4
Target Milestone: mozilla0.9.5 → mozilla0.9.4
Attached patch small patchSplinter Review
r/sr means "either r or sr, take your pick". You still need another reviewer or 
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
Closed: 18 years ago
Resolution: --- → FIXED

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
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.

You need to log in before you can comment on or make changes to this bug.