Closed Bug 32646 Opened 20 years ago Closed 19 years ago

[RFE] Full zoom for content (objects as well as text)


(Core :: Layout, enhancement, P3)






(Reporter: netdragon, Assigned: karnaze)



(Keywords: helpwanted, Whiteboard: [parity-opera])

you should be able to zoom in and out of a page. I have known many times this 
would come in handy.
This is an enhancement.
The amount of reworking of the browser internals that this would require would 
be enormous! If we want Mozilla this side of the Millennium, I'm afraid you are 
going to be disappointed :-( There are options to change font size already. Are 
you having trouble reading small text? There's bugs on this, as well.

Closed: 20 years ago
what is this resolved as?  I'm not seeing anything in the Resolution field .is
this jsut a moz bug :)
Actually, it is for pages that have a lot of text or pictures horizontally and 
vertically or big text and I would like to see more of the page. Or for looking 
at a really big picture. I would rather not download it and use paint shop pro 
or adobe photoshop.
Please reopen if you feel this would be good. 
I can't resolve because I have had my ability to resolve removed. 
Verifying unknown resolution to see what it is (I hope)
I have no idea what the resolution is (How weird) :)
Anyway changing summary...

If this was persued, Mozilla would be the first browser with ability to zoom.
Summary: Zooming → [RFE] Zooming within Mozilla Browser
Actually, I don't think it has a resolution at all. Bug within bugzilla?
Going to go on the newsgroup and see what people think about my new ideas. Do 
whatever you like with this bug.
Summary: [RFE] Zooming within Mozilla Browser → [RFE] ZOOMING within Mozilla Browser Mozilla wouldn't be the first browser with a zoom feature -
Opera has it.  Try it yourself, there's a free evaluation available at

I'm reopening since I agree that this would be a great feature - even more so if
Mozilla could resize images more smoothly than eg. Opera.  (Yeah, I know it's
extremely CPU-consuming to resample images on the fly. Maybe for Mozilla 3.0?
Ever confirmed: true (Asa Dotzler) taking ownership of Browser General bugs. 
 New QA Contact is (Joseph Elwell).  Sorry for the spam.
Assignee: cbegle → asadotzler
QA Contact: asadotzler → jelwell
adding helpwanted keyword and reassigning to
Assignee: asadotzler → nobody
Keywords: helpwanted
Ie 5.5 have supported with Zoom. You can see big picture from zoom. It's new 
feature of IE 5.5. It would added this feature in Mozillia.

feature Zoom would be suitable for image Gif, jpg and bmp.
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
In case you are confused, I meant a zoom like in word processors where you can 
scale the size of the document. It is still functional, just zoomed. I didn't 
mean, though, zooming individual images - I meant the whole page. All you have 
to do is multiply mouse clicks against 1/zoom_factor to see where they clicked 
and to display, you just send the full size document through a filter that 
resizs it. This would resize controls, text, and images.
That's exactly what Opera's zoom is doing.  Very cool feature.
(Changing Platform/OS to All/All, by the way.)
OS: other → All
Hardware: Other → All
See also bug 46996: [RFE] XUL Lense 
reporter - do you agree this is a dupe of an bug with the correct developers
assigned to it?
No, I meant zooming like in Adobe Acrobat or Microsoft Word. Zooming within the 
whole window.
ie5.5 added print preview, a feature that netscape has had for years.

Assuming mozilla had print preview (I think it does/will) and can zoom, would 
you be satisfied?
print preview is going to be in it, don't worry ;)
20943 is the print preview hook-up bug, currently nsbeta3-
> Assuming mozilla had print preview (I think it does/will) and can zoom, would 
> you be satisfied?

No.  It'd be like claiming that because Word has print preview, it doesn't need 
zoom in document editing mode.  Print preview and "browsing zoom" are needed for 
two different purposes.

Adding '4xp' keyword since Opera has had this feature for years.
Keywords: 4xp
Removing 4xp. That's an abuse. Please use status whiteboard instead.
Keywords: 4xp
Whiteboard: [parity-opera]
From :
  "A bug is a Product Parity bug if it occurs on Mozilla builds, but does not
  occur using the latest release of Netscape Communicator 4.x or competitor

I guess you refuse to count Opera as a competitor? :-)

That being said, the definition can be interpreted so that _no_ competitor 
product may have the bug (or in this case, a missing feature) in order for the 
bug to qualify as 4xp.  I understood that a bug is 4xp if there's one or more 
competitor product that doesn't have the bug - effectively giving "4xp" the 
meaning "somebody's ahead of us here!".

Please tell me I was wrong, and I'll file a bug on Bugzilla requesting a more 
precise definition for the keyword.
Howdy timeless. Thank you for supporting this bug, Antti. I think taking a 
roundabout approach to zoom (ie - enlarging images/text) would not add as much 
to the functionality of Mozilla. I can tell you, if Microsoft Word, or Corel 
Wordperfect came without zoom - I would cry! Seriously, the enlarging text is a 
bad feature all in itself because it can really mess up some web pages' layout. 
I think Zoom would be a much better feature for someone with disabilities. I 
even think that if Zoom existed, you could remove the annoying enlarge text. 
BTW - Do you think people want someone going to a web page they worked hard on 
and enlarging my text? Even talks about zooming in the CSS 
documentation. It said it wouldn't include zooming in the CSS definition - that 
is for user agents to do. 

I do not have any idea how this would be implemented - but someone must. It 
would probably require making a zoom class and going through the all interface 
code and multiplying dimensions by the zoom percentage. 

Does anyone have the guts/time to undertake this? 

18.5 Magnification 
The CSS working group considers that the magnification of a document or portions 
of a document should not be specified through style sheets. User agents may 
support such magnification in different ways (e.g., larger images, louder 
sounds, etc.) When magnifying a page, UAs should preserve the relationships 
between positioned elements. For example, a comic strip may be composed of 
images with overlaid text elements. When magnifying this page, a user agent 
should keep the text within the comic strip balloon.
Bleh. It should be noted that the useragent should have some flexibility.
If you make a 16x16pixel picture and force the useragent to render text in 
that, then it's your fault for constraining the text.  The useragent should be 
helping the user experience the site. Zooming is actually a future feature, 
text sizing is a now feature (see mpt/jag comments on the sizing bugs).

If someone wants to make a page that isn't obfuscatable by a useragent, they 
should use PDF, PostScript or JPG/PNG.

Also that reference is useless, it says CSS2 will not govern sizing, nor future 
CSS.  cc: hixie, mpt.

fwiw, in a recent version of wordperfect, print preview is not readonly, it is 
just another view. Word might make a distinction.
So much talk, so little implementation ...

To start with, this is a -->Layout issue. The layout engine, given a zoom level, 
needs to render the document such that:
* text is rendered at the desired zoom level
* objects (such as images) are rendered at the desired zoom level, but *only* if
  the zoom level is outside a certain (minimum,maximum) range which would be set
  in preferences (see <> for explanation).

Once that is done, two dependee bugs can be filed: one to add minimum and maximum 
prefs to the prefs dialog, and one to change the `View' > `Text Size' submenu to 
a `View' > `Zoom' submenu.
Assignee: nobody → clayton
Component: Browser-General → Layout
Depends on: 37940
QA Contact: doronr → petersen
Summary: [RFE] ZOOMING within Mozilla Browser → [RFE] Full zoom for content (objects as well as text)
>> So much talk, so little implementation ...

I agree Mathew. I'm glad someone is finally doing something with this. I would 
do it myself if I knew how / had the time.
Dividing up Claytons bugs to triage
Assignee: clayton → rods
Target Milestone: --- → Future
marking future
This is a new message I posted in the Newsgroup:

I think there should be a zoom in Mozilla. This zoom should be similiar to
that which you see on word processors, and adobe acrobat. It should zoom
text and objects by exactly the same scale. There should be a min zoom of
maybe 20% and a max zoom of maybe 500%. Any zoom within this range should be
allowed by entering it in a special dialog box - selectable from the
View->Zoom menu, or several predefined values on the menu can be selected.
You can set an option in preferences to decide whether zoom values are kept
when you go to a new page or not. I don't believe text or objects should be
independently zoomed, because that affects the way the page looks - to the
dismay of the page author. Therefore, I think zoom should be added, and the
scale text be removed.

I do not believe that there has to be a device independent unit of measure
for zoom, as it is expected that someone with a very large, high res monitor
should see more of the page than someone with a low res, small monitor.

There is already a standard way to define text in terms of pixels.

If it is zoomed out too much to read the text, then that is not a problem.

I have heard that Opera and Internet Explorer both have a zoom feature.
This is how I believe zoom could be added to Mozilla. Firstly, you go through 
EVERY object, including buttons, text boxes, etc, and give them an ability to 
internally scale. You can do this without even disrupting any builds. You can 
then test it with the attribute zoompct - ie <textarea zoompct="50%">. This 
attribute would be removed when Mozilla was released. Then, one by one, you 
could test the zooming abilities of each object. Text boxes, etc could be 
zoomed by multiplying the width of the border * zoompct, the scrollbar width by 
zoompct (the scrollbar is another object), the scrollbar height * zoompct, and 
use the equation to convert pixels to points to convert zoompct to points, then 
multiply it times the text points inside the text box. You can then test each 
object's zooming ability alone. 

Then, you could use that same text zooming tecnique on the text in the 

Images are really easy to zoom. Most operating systems even have APIs to do it 
for you - or you could use a filter.

After that, its time to put the tests into practice - you just multiply each 
object's top, bottom, left and right boundaries times zoompct before they are 
placed on the page, text would also be postitioned using the same technique, 
and viola! You have a zoomed document. You can even set lower and upper zoom 
limits based on what works and what doesn't. 

I think the zoom feature is really important. Disabled people should have the 
ability to view a document the same way we do without it becoming distorted by 
overflowing text. Its not always the designers fault someone can't see a 
document - besides being disabled, someone might have a really small monitor, 
or a very high resolution. When all designers move to CSS, overflowing text 
will probably be cut off. The text enlargement feature is no replacement for a 
zoom feature. It doesn't even zoom images. Text isn't always the only thing 
that needs to be enlarged. 
I do not think this bug should depend on 37940, as that bug is about 
resizing text size - while this is zooming full content. Can we remove that as a 

The hope is that when actual zooming is added, text resizing will be obsolete 
and rarely needed. As there will be some page that a joker makes with 2pt font, 
text resizing will still be needed, but it has the ability to mangle people's 
pages - so hopefully people will use zoom more often instead.
reassigning to core layout
Assignee: rods → karnaze
I see a fairly intensive implementation mentioned.  Is it possible there's a
simpler solution, such as at the GFX layer?  (Plus maybe work with things that
may bypass it, like GTK widgets/etc).

If we could get some others involved (especially people who know "how it should
be implemented" and can write it down), we can put some resources into

This would be a big win for accessibility.

Marc Attinasi has some great ideas on how to proceed:

1) Make nsPresShell::GetScaledPixelsToTwips, GetPixelsToTwips, GetTwipsToPixels 
understand a zoom factor
2) Call nsPresShell::ReconstructFrames to reframe the entire document with the 
new zoom factor

Images that don't have a width or height set will have to be dealt with. Look in 
We're not sure if the conversion routines for pixels to/from twips will handle 
all of the fonts or not.
If the viewport width needs to be affected then there are some to deal with. I 
would hope this is not the case.
I have tested the solution proposed by Marc Attinasi and I think it's the right 
way to do handle the problem.  There are still a lot of problems (images, 
fonts, size of scrollbars, size of the page...) but I will post some patches in 
about 2 weeks and ask for help/advise to finish the work
Cc'ing image buddies.

i also think this is a great idea, especially since it directly helps my own
project ;). In the case where we need to create thumbnails of a page (for UI
hacking, as in my case i'm creating a history UI which will use thumbnails) and
don't want the top 16x16 pixels, but the entire page scaled.
*** Bug 72985 has been marked as a duplicate of this bug. ***
See also bug 73322, auto-resizing images to fit within the window.
Would someone please take this bug.  

*** This bug has been marked as a duplicate of 4821 ***
Closed: 20 years ago19 years ago
Resolution: --- → DUPLICATE
vrfy dupe
You need to log in before you can comment on or make changes to this bug.