Closed Bug 4821 (pagezoom) Opened 25 years ago Closed 17 years ago

Full zooming not functional (images, objects as well as text) (page zoom like opera)

Categories

(Core Graveyard :: GFX, enhancement, P1)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9alpha8

People

(Reporter: michaelp, Assigned: sharparrow1)

References

Details

(Keywords: access, Whiteboard: parity-opera parity-IE7)

Attachments

(19 files, 3 obsolete files)

55.82 KB, image/jpeg
Details
65.17 KB, image/jpeg
Details
822 bytes, text/html
Details
73.09 KB, image/jpeg
Details
3.77 KB, patch
Details | Diff | Splinter Review
111.59 KB, image/jpeg
Details
37.17 KB, image/gif
Details
35.45 KB, image/gif
Details
30.15 KB, image/gif
Details
2.28 KB, text/html
Details
1.83 KB, text/html
Details
72.63 KB, image/gif
Details
126.74 KB, image/jpeg
Details
97.27 KB, image/jpeg
Details
2.80 KB, patch
Details | Diff | Splinter Review
20.32 KB, patch
sharparrow1
: review-
Details | Diff | Splinter Review
15.28 KB, patch
roc
: review+
Details | Diff | Splinter Review
14.37 KB, patch
Details | Diff | Splinter Review
99.09 KB, image/jpeg
Details
zooming needs to be finished. you have the code as i left it.
Status: NEW → ASSIGNED
Target Milestone: M6
-> M6
Target Milestone: M6 → M8
Target Milestone: M8 → M9
Target Milestone: M9 → M12
Target Milestone: M12 → M13
Target Milestone: M13 → M20
Reassigning all view bugs to kevin.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
Component: Compositor → Views
Status: NEW → ASSIGNED
This bug is marked "future" because it is not critical for RTM (Release To 
Manufacturing). If anyone believes it is critical, please explain why in
this bug. 
Target Milestone: M20 → Future
*** Bug 32646 has been marked as a duplicate of this bug. ***
URL: all
Keywords: helpwanted
OS: other → All
Note that there are many different types of zooming.  Which one does this cover?
There are:

 * increasing the default font size (which we can currently do in prefs)
 * increasing the logical resolution (we also have this in prefs)
 * increasing the size of all text, no matter how its size was specified, along
with everything else that depends on text size (I think this is what View | Text
Size does, except it doesn't change things that are sized relative to the text)
 * increasing the size of everything (text and images) -- perhaps that's what
this bug covers?
 * increasing all sizes specified by the page author (including or excluding the
default sizes of images)

Hawing all of these would be very confusing -- it's not clear which we want.
I'm guessing this covers the "increasing the size of everything" option, which is
what Opera's zoom does, I think.  I don't remember what it does on WinIE/MacIE.
Since my bug was made a duplicate of this, so I believe this bug talks about 
the zooming of *EVERYTHING* - images, text, forms, etc. Having this would make 
the enlarging text not as important. Look at how adobe acrobat, opera, and 
microsoft word for windows do it.

I think one way to do this might be to send everything through a new layer that 
handles clicks and output and translates everything to the correct coordinates 
relative to zoom, but this might slow things down.
IE55 and up has this feature as well and is used as a MS proprietary css 
property called zoom. It is heavily used in the print preview window but can be 
used on any element.

document.body.style.zoom = "120%";
[Resummarizing to avoid confusion with bug 39117.]
Summary: zooming not functional → Full zooming not functional (objects as well as text)
Will this feature be implemmented in mozilla 1.0 ?
I found a very _simple_ solution to get DeviceContextImpl::SetZoom() _working_ -
and it seems that this doesn't break _anything_.... :-)))

Anyone interested ?
Roland could you post your solution?
Basically zooming could be implemented like this:

-- snip --
--- nsDeviceContext.cpp.original        Wed May 23 14:17:41 2001
+++ nsDeviceContext.cpp Wed May 23 14:18:30 2001
@@ -176,7 +176,7 @@
 
 NS_IMETHODIMP DeviceContextImpl :: GetCanonicalPixelScale(float &aScale) const
 {
-  aScale = mCPixelScale;
+  aScale = mCPixelScale * mZoom;
   return NS_OK;
 }
-- snip --

This should work without problems for all existing code.
For correctness I suggest to implement a new method which returns the plain
mCPixelScale.

That's _all_ - except the GUI interface.
The problem with the proposed solution is that everything is zoomed (status bar,
scroll bars...)  I don't think that's what the user expects and wants.
Is there a way to easily separate zoomable from non zoomable widgets?  Guidance
welcome.
A related discussion happened in bug 95267 starting at [dbaron 2001-09-19 09:32].

We may have to rewrite some GFX or ImgLib functions if we implement a low-level 
pixel zoom.  I'll attach a couple of pictures and a testcase to illustrate this.
Attached image Picture at 100%
There are some nice books that talk about image scaling. The images should be
antialiased, etc. I think photoshop does a pretty nice job on my computer. I'll
provide an attachment. 


 

Adding dependency on bug 98971 - Bilinear scaling need for line art and scalable
web pages
Depends on: 98971
Severity: normal → enhancement
Naah, we don't need Photoshop-quality scaling (though that would be nice). Most 
of the time when you zoom text for easier reading, you don't also want to zoom 
the graphics; that is only necessary in extreme cases. And having two different 
zooming functions would be hopelessly confusing ... So (this was Todd Fahrner's 
idea) you have a threshold beyond which `View' > `Zoom' will affect non-text 
objects as well as text. E.g. (this might be the default) zooming anywhere 
between 75 % and 150 % would only scale the text, but outside that range,
non-text items would scale as well. That way you don't get jaggies as noticable 
as the ones shown in Pierre's screenshot. Unfortunately, it also means that a 
fix as simple as Roland's is definitely too simple. :-]
No longer depends on: 98971
Well... my solution works except that it scales chrome, too - which is not
usefully/wanted except for XUL in the content area.

Maybe the "correct" solution is to use two device contexts - one for the chrome
and one for the content area (which would be nice because it would allow the use
of different visuals for the X11 Zillas)...
Scaling everything including chrome is perhaps a very nice feature from an
accessibility's perspective. I am *not* kidding ; please keep your code safe
somewhere...
Daniel: IMHO enter 'scaling everything including chrome' as new bug, because
it's really useful accessibility enhancement.

Whiteboard: [Aufbau-P2]
Whiteboard: [Aufbau-P2]
Most of the time when you zoom text for easier reading, you don't also want to zoom 
the graphics

That's not necessarily true.  I used IE's zoom feature
document.body.style.zoom
and I need it to scale EVERYTHING, especially images  (scroll bars don't matter
though as someone else mentioned)

As a corect implementation, I do believe zooming everything on the page like
like an image editor would zoom a bitmap image would be the best way.  
Of course it does not HAVE to be photoshop quality with antialiasing and all.

Here's a site of mine that uses the zoom function
See the zoom in buttons on the left side of the page (USE IE to test it for now)
http://op.virtualave.net/MapEditor/mapeditor.html
BTW, the purpose of the zoom function is NOT to enlarge text but to enlarge
everything.  Thus, it should NOT be limited to just text or have some limit on
images.
BTW, Internet Explorer regular numbers to determine the zoom level.
1= normal size
2= twice the size
etc....
this makes some things easier to program than using percentages
for example I use the following code I got from dynamicdrive.com to allow you to
zoom in by increments of .6:
if(document.body.style.zoom!=0)
  document.body.style.zoom*=1.6;
else
  document.body.style.zoom=1.6;
What attachment 50306 [details] shows is not what would happen if Zoom were implemented in
the way described in comment #12.  Instead, fonts would be scaled correctly. 
The only obstacle I see to making that type of zoom work correctly is that some
XUL code involved in the drawing of scrollbars does not recognize the canonical
pixel scale correctly -- since these are never printed nobody ever noticed.
This patch implements full zoom in the device context (though perhaps we'd want
a separate member variable rather than just using the canonical pixel scale --
although I don't really see why).  Rather than take the time to hook up the UI
correctly into a separate menu for testing, I just made the text zoom menu do
the real zoom.
Comment on attachment 60121 [details] [diff] [review]
patch that allows testing of real-zoom using the text zoom menu

Oh -- I forgot to mention the second obstacle, which is that this has some
dynamic refreshing problems -- we probably need to blow away more cached data
than we are doing.
Just for people new to this bug...

As you can see... This is not how the Slashdot site creator wanted his page to
look. This is why Real zooming might be a better accessability feature.
I had a chance to try dbaron's patch and it looked rather promising. It zooms 
the content window as expected. The chrome (and the sidebar) stayed untouched.
The hickup is with the scrollbars as he mentioned.

(Those would like this zoom feature should consider pushing for bug 98971 since
images quickly become jagged.)
Errata. just noted that dbaron's attachment 50306 [details] zooms everything except text. 
In order to get full zoom, I had to keep _both_ of these settings in
|set textZoom(aZoom)|:

@@ -87,7 +87,7 @@
     if (aZoom < this.MIN || aZoom > this.MAX)
       throw Components.results.NS_ERROR_INVALID_ARG;
 
-    getMarkupDocumentViewer().textZoom = aZoom / 100;
+    getMarkupDocumentViewer().zoom = aZoom / 100;
I'm pretty sure it zoomed text for me on Linux -- did you try reloading.  There
were some problems with dynamic refresh.  It could also be that different widget
ports' font code responds differently to the canonical pixel scale.
My tree is re-spinning at the moment. Will let you know how it goes later on.
I am seeing some inconsistencies - e.g., Ctrl++ doesn't zoom the textual content
of mozilla.org but it zooms everything at CNN.com (although the "Search" field 
at the top right stays the same, while the "Wheater" field looks alright -- 
okay, it is confusing to explain with words, will attach screenshots :-)
I couldn't confirm if it was a refresh problem since the zoom is not persistent 
on reload.
Attached image full zoom @ mozilla.org
I'm a little unsure, what methods are we implementing here?

Percentages?
document.body.style.zoom = "120%";

Floating point numbers like in IE?
document.body.style.zoom = .00001;
document.body.style.zoom = 0;
document.body.style.zoom = 1.6;

Parden me, If I'm misunderstanding things here and if this, well, sounds like a
stupid newbie question.  I'm not sure of W3C's specs on this....  All I know is
what I've implement on my website (which currenlty only works in IE).
I'd like to discuss the threshold idea. I personally don't want the text to zoom
independantly of the images ever. I would be severely annoyed by a threshold. I
want the page to look EXACTLY as it is intended to look (save having the whole
thing zoomed).

I would like to recap Dbaron's statement in comment 5. He said that this bug
could cover:

 * increasing the default font size (which we can currently do in prefs)
 * increasing the logical resolution (we also have this in prefs)
 * increasing the size of all text, no matter how its size was specified, along
with everything else that depends on text size (I think this is what View | Text
Size does, except it doesn't change things that are sized relative to the text)
 * increasing the size of everything (text and images) -- perhaps that's what
this bug covers?
 * increasing all sizes specified by the page author (including or excluding the
default sizes of images).

I feel that actually this bug should cover the last two. 

Basically, each element of the page can be zoomed independantly (by the html
designer), also the entire page can be zoomed in the menu. Along with that the
text size can be changed in the menu. 

The menus would be like this:

Zoom>
      Text Size > Smaller
                  Larger
                   ...
                  Other

      Page Size > 25%
                  50%
                  75%
                  100%
                  150%
                  200%
                  Other

The size of text and textareas, etc would be affected by:
Text size in menu
Size of text in html and css
Accumulated zoom of containing elements up to and including body
Zoom of page set in menu

The size of images would be affected by:
Size of image (either image's size or the set width and height)
Zoom of image
Accumulated zoom of containing elements up to and including body
Zoom of page set in menu

Therefore both text size and zoom have an affect along with any zooms set by the
html designer.

I think the menu should also have a Zoom> Default to reset everything back to 100%.

Since Zoom isn't in CSS standard and IE did it first we should probably allow
both percentages and scale just like ie. Also, CSS usually uses either
percentages, scales, or actual pixel sizes. I imagine we could allow all three.
For instance, Zoom: 1% and Zoom: .01 would make the page 1/100th its current
size. Also, you should be able to do Zoom-Vertical and Zoom-Horizontal, along
with allowing
Zoom: 20% 10%.
Ignore this attachment, it's part of the next attachment.
Attached file IE Zoom
This is an attachment to view and test zoom as used in IE.
It uses floating point numbers.

With the pop-up menu you can test the page in IE and (hopefully later) in
Mozilla to see how it works.
Zoom increment affects how much the zoom in and zoom out buttons zoom.
Go to this zoom level takes you to whatever zoom you may want to test.	Take a
look at .001 :)
In response to Brian's comment
(http://bugzilla.mozilla.org/show_bug.cgi?id=4821#c41), I think that this bug
covers (in particular) #5, "increasing the size of everything (text and
images)".
Agreed. All I am saying is that the correct way to do this (imho) is to put in
the support for scaling of all elements. Scaling should filter down to
subcontainers. Even the body element should have ability to scale. Then, with
that all in place, this bug would be trivial. All that would be necessary would
be to multiply the scale of the body element by whatever the user's zoom is
chosen as.

BTW - look at bug 112018
Having correct zooming would be very useful for ultra-high resolution screens!  
Mine is 170 pixels per inch, and if I zoom text so it's readable then pages 
with fixed-width tables start to look pretty ridiculous - 700 pixels wide isn't 
really that much on a 170 DPI display.  (I filed Bug 114278 not knowing it was 
a near-duplicate.)

Hm, should you be automatically setting the scaling factor based on system 
DPI?  For instance at my 170 DPI I'd set a scaling factor of 170/96 = 177%.  I 
think this would be desirable in Windows, but it would have to be off by 
default in Unix since there is more than one default system DPI in wide use.
We certainly can ask X for the DPI of the display - though there's nothing to
verify that it's correct, and I think in most cases it defaults to 75DPI - but
not all.  Users rarely (from what I've seen) take any note of the DPI setting,
let along match it to the display size's actual DPI.  It's too bad XF86Config
doesn't take the monitor size and calculate DPI for all screens automatically
(perhaps it does and I somehow never heard of it?)

While auto-calculating a scale from DPI is admirable, on Unix it's not likely to
be effective (please correct me if I'm wrong).
> While auto-calculating a scale from DPI is admirable, on Unix it's not likely 
> to be effective (please correct me if I'm wrong).

Not all X11 implementations are that "broken" like Xfree86. Some of them do
automatic calculations of the DPI value - and some users/admins are smart
enougth and adjust the value to match their monitors resolution. We should
always honor this value and not try to hack around it - otherwise we will hurt
those users at lot just because they are conform to the standard... ;-(
I think that applying a scaling factor based on DPI on Unix *by default* would 
be a Bad Idea.  You would get many users confused and complaining because there 
are many different default DPI settings on Unix.  75 and 100 are the main 
ones.  So scaling would be enabled for some group of people by default and 
that's not expected behavior.  It should be a user-selectable option though.

On Windows the situation is different.  Nearly everyone has their DPI set to 
96.  The only way it gets changed is if the user explicitly tells the OS to 
scale all GUI elements and fonts.  So enable DPI-based scaling by default on 
Windows and calculate the factor based on a 96 dpi reference (120 dpi = 120/96 
= 125% scaling factor).
What about using |scale_dpi=max(90,dpi_from_xserver)| to avoid this problems on
X11 ?
Why would you want to assume a certain default for scaling based on DPI?  What
if my DPI is 120dpi, but I still want a pixel to be a pixel since scaled images
are ugly, and I want author-specified sizes intended to work with images to work
correctly?  After all, we already have the 'pt' unit for web pages to depend on
the DPI, but it's proven to be far worse than pixels because of systems' bad
ideas of their own DPI.
James Crowson:
Maybe we should just implement it the correct way and let Xfree86 fix their
xx@@!!-broken implementation. Other X implementations are working - maybe the
Xfree86 people should start to do the same...

Using |scale_dpi=max(90,dpi_from_xserver)| may be a reasonable workaround as
this bumps-up the DPI value used for scaling to a more common value than 75DPI
...

----

dbaron:
What about adding a menu check item which says: "Use display DPI for scaling" ?
Yeah, a menu check item was what I was kind of getting at.  Off by default on 
Unix, on by default on Windows (but see Bug 114270)...  Best case is everyone's 
DPI is set correctly and you use a decent image scaling algorithm so that 
scaled images don't look ugly.  I thought XFree86 set the DPI to a correct 
value automatically if you have a plug and play monitor.

Hm, what this gets you is webpages that display at the *same physical size* on 
everyone's screen, regardless of their resolution.  I'm not sure this is a good 
thing to be doing by default!  It certainly majorly goes against people's 
*expectations* of what changing resolution does.  I'm not sure that's a good 
change to make.  (In Unix, I think it still works out in Windows OK if it's on 
by default.)

There are some good comments on what to do in the discussion for Bug 95267 as 
well.

Although the point of view I'm coming from is "high-dpi screen owner".  170 
DPI.  The 177% text zoom I have to use to make fonts a good size breaks layouts 
so badly...  I can't even use Mozilla on a day-to-day basis till Bug 4821 (this 
one)'s fixed.
> Yeah, a menu check item was what I was kind of getting at.  Off by default on 
> Unix, on by default on Windows (but see Bug 114270)...

I disagree here. "ON" by default on Unix, too - except that any DPI value lower
than 90DPI should be bumped up to 90DPI (or 96DPI if you like... :-)
This will give good results in all cases and will avoid any problems if someone
sets his/her Xserver resolution to a higher value ...
Honestly, I can't see any possibility of having DPI-based scaling on by default
under ANY circumstances.  If we fix this bug, we'll have full scaling available,
and we can have a checkbox and/or menu item that sets the scale based on the DPI
(in addition to entering in a scale or choosing one from a list (75%, 100, 125,
150, 200, 300, other, automatic based on DPI).

There are just too many problems on too many systems (especially X11) to turn
that on by default - not to mention the standards-compliance issues.

Let's get this bug fixed and then worry about the UI/prefs.
Doing zooming based on DPI goes against years of experience in the CSS
community.  Ask on www-style and you'll be told not to use fixed font sizes, but
that if you do, use px rather than pt.  Why are our font preferences in pixels
rather than points?  Because pixels are more consistent.  We've been moving away
from using the DPI for anything for a number of years because it just doesn't
work.  Before we do anything so drastic as move towards scaling based on DPI, we
should first reconsider our non-use of the DPI for these other things.  However,
I suspect you'll find a lot of disagreement if you want to do that.
I think we are going way off track here. Mozilla is not an operating system or
an extremely low level application. Its a web browser. The web isn't designed to
cater to different hardware individually (I think). If someone's system's
resolution is so high that it doesn't look good on their system, then they
either need to:
A) Change their resolution
B) Select an arbitrary zooming factor based on a percentage. Once they choose
that zoom percentage, it would stay that way. Therefore, they wouldn't have to
choose it every time they start Mozilla. They can play around with it until it
looks good. Mozilla shouldn't have to do any low-level calculation of zoom factor.

What is so hard about choosing Custom > 177%? It would be pretty standard on all
applications.

I have a 1600x1200 19" monitor that makes things look extremely small. This will
become a problem as 1600x1200 is considered average. Geforce cards can support
way over this in 3d. Either monitors will have to become bigger in surface area,
or software will have to increase the size of their UI and allow it to scale
down. Personally, I think that is the best solution for Mozilla's chrome. Either
make multiple versions, or allow it to be scaled down. Scaling up the chrome
will look ugly, of course. In my opinion, eventually programs will have to do
this, because there is a limit to how small an application can be, and you can't
use Mozilla if its 1 inch wide on your monitor.

Having Mozilla auto-detect this is a bad idea until it becomes the standard
thing to do.

IMHO - put in the support for the scaling of chrome and web pages, and allowing
people to pick their own scaling amount by trial and error. There is just too
much of a variance in how monitors work, etc for Mozilla to auto-detect the scaling.

Besides, this bug isn't about auto-detecting monitor resolution. Let's please
not complicate things so this bug takes longer.
In case dpi stuff hasn't been beaten to death enough, i'll make a few useless
comments about it:
1. we already have a preference panel option to control dpi
2. any complicated controls for dpi do not belong in menus, they should join the
already present preference in the panel
3. any problems relating to any of the above should be beaten to death in other
bugs or newsgroups.
So, I agree, let's get back to creating the functionality we need.  As best I
can tell we're pretty close on this (which will give us functionality similar to
Opera (and recent IE)).  Are there any other issues than scrollbars?
*** Bug 123963 has been marked as a duplicate of this bug. ***
Build moving all existing future-P3 bugs to future-P4.
Priority: P3 → P4
Keywords: access
*** Bug 141683 has been marked as a duplicate of this bug. ***
taking
Assignee: kmcclusk → dcone
Status: ASSIGNED → NEW
Will you be able to speficy zoom using javascript?

for example I currently use the following in IE:
document.body.style.zoom = 2;
and
document.body.style.zoom *=2;
afaik, zoom isn't CSS compliant (unless its going to be on CSS3).

CCing Hixie because he might be better able to answer this.
Zoom is purely a UI feature and is not exposed in CSS. It is very compliant with
CSS, it is in fact explicitly mentioned in both CSS1 and CSS2 if I remember
correctly. I don't know if we shoul expose it to the document's DOM, I would
suggest that is a separate bug.
*** Bug 152793 has been marked as a duplicate of this bug. ***
Note that the technical issues in bug 153080 comment 9 probably need to be
ironed out before this can really work.
I think something has changed recently so that attachment 60121 [details] [diff] [review] would no longer
do what it did at the time.  See bug 167162 comment 4.
Let's implement this with a automatically disabled pref before worrying about
bug 98971 for bilinear scaling.

See also bug 73322, about auto-scaling images as in IE. We should make sure that
these two features coincide without conflict.
*** Bug 171340 has been marked as a duplicate of this bug. ***
*** Bug 172396 has been marked as a duplicate of this bug. ***
*** Bug 174591 has been marked as a duplicate of this bug. ***
*** Bug 175632 has been marked as a duplicate of this bug. ***
I discovered that the failure to go full screen appears to be a first use deal.
 On my first attempt to use Full Screen the window, instead of going full
screen, minimized.  When I used the tab on the tool bar to "restore" it, it did
go to a full screen window.  Following that I used the tab in the upper right
corner and hit the square restore button.  Once again it went back to a normal
screen.  After that using Full Screen under the View tab worked properly.  I'm
not sure if this is unique to my machine and the way I have my settings or it is
something inherit with  the browser. 
ken-k@satx.rr.com, what has with full screen viewing to do with zooming?
I'll summarise what I've read as user requirements in this discussion...

1) ability to zoom *everything* inc text. graphics, browser controls &
decorations for accessibility and high resolution screens
2) ability to zoom just text to make up for bad web coding
3) ability to zoom text and graphics

for 2 (and 3?) eed *both* minimum size of font definition *and* the ability to
scale up fonts globally or by URL window/tab, *and* to have this stick between
sessions, it'd also be good to be able to have something like a "zoom manager"
where you could define a single page or a whole site to always be treated a
cretain way (min fint size, text zoom, graphics zoom etc.  The basis for this
would also be useful for other functions, such as "never show annoying popups
for *.badspamheads.com". 

CSS definitions of what is the right/wrong way to specify fonts should not apply
to how I want to customise what I want to see on my screen. If I want to show 6
pixel fonts as 48 pixel, that is *my* business (user-centric view of the mozilla
UI).  Allowing the flexibility to suit the requirements of the user should be,
IMHO, the priority.  I don't think mozilla is at the leading edge of making life
simple for users when it comes to zoom (see galeon for a good example of how to
easily support at least number 3).

Cheers,

Indulis
Well, since my very own zoom bug was changed to duplicate (not of this one
though, your guys really ned a meta bug that covers text-only zooming and full
zoom) I'll add my grain of salt.

1. most of the times zoooming text + images together would be nicer

2. however I feel I (as a user) would probably use text-only zooming more (with
specific zooming on images I really want bigger like ie) because:

  a. I hate horizontal scrolls. Not all sites are difficult to read because they
were designed for smaller screens. Very often they were actually designed for
big screens but with smalish font (usually because they were sold via paper
lookalikes and small text looks better on paper)

  b. Quite often now a large part of the screen real-estate is wasted by big add
placeholders. Which I usually block. But I'd hate to have a zoom that enlarges
all those large white zones in my screen (in fact I'd usually want to shrink them)


And please - I've seen a lot of ranting about XFree dpi settings in this thread.
Modern X is actually quite good at computing the screen's actual dpi value (ati,
matrox and probably other drivers will query the screen via DDC to get its
physical size). It moved past windows quite a long time away. Why should I care
that windows users are used to achieve zoom levels by lying about their real dpi
value ? It's nothing but an hack. 

Real sizing is subjective (because we are all different) zoom over a fixed size
reference (ie 1 cm is 1 cm everywhere, but the preferred font size in cm varies
from person to person). So we need both a control to say: this is one centimeter
and another to say : this is the relative zooming I prefer. This is even more
important in networking environments where the same user will use the same app
preferences on different stations, which may have different screens with
different harware dpi. If the preferred size is remembered as a fixed pixel
value and not a percentage of an universal unit (which can be computed by
querying the os about the real dpi value) you'll be in trouble.
(and btw dpi is both horizontal *and* vertical. For a long time they were the
same thing, but we're now moving in a zone where screens are still sold with a
physical 4/3 ratio but "standard" resolutions are 5/4 instead - 1280*1024, etc.
On high-end screens you'll get even worse dpi distortion with resolutions
approaching 16/9 while the screen itself is still 4/3)
And (last comment I swear) people need two kind of zooms

1. a persistent per-site zoom level used to equalize base font size
2. a non-persistent per-session zoom level that works relative to the zoom in 1.
(for late work, presentations and so on)

This is similar to what's done by modern tv sets - since channels could not
agree on what base levels were people start by adjusting color/sound levels on
each channel so they match a common base (done automatically now) and then
during everyday use they adjust sound/color level based on room overall
brightness, noise level (damn the neighbour decided to mow his lawn) and user
tiredness. And this everyday adjustment works across channels relative to the
initial per-channel settings
[ Btw - the CC list is getting impressive but do not forget to vote for the bug
too if you want this. It's "still" P4 after all ]
Users,

In answer to: Additional Comment #3 From Kevin McCluskey  2000-06-06 11:08.

I want to be able to zoom an entire page as is possible in Opera. The reason is
a web page I use, http://www.lycos.co.uk has been optimised for microsoft ie
(I've already complained to their support team of their myopic attitude) and I
can't see the left hand menu bar in Mozilla. Text zooming does not help, only
the window zooming that opera offers.
http://www.lycos.co.uk looks fine to me in a 900px wide window.
I think this is among the highest priority features to be implemented.  I don't
think further answers to comment 3 are needed.  Assigning bug to myself (and
leaving as Future), although it's probably going to take a bit of work, perhaps
from multiple people, to do this correctly, and it's probably not my top
priority (I'm more concerned with bugs in code we already have and other
architectural problems).  See also comment 69.
Assignee: dcone → dbaron
Component: Layout: View Rendering → GFX
Priority: P4 → P1
QA Contact: petersen → ian
The way to do this is not to mess with DPI or text scaling or whatever. The way
to do this is to make each nsIRenderingContext implementation apply its
transform matrix to all rendering primitives, including images and text
rendering. Then zooming is just a matter of setting the correct initial
transform matrix.
*** Bug 216750 has been marked as a duplicate of this bug. ***
Alias: pagezoom
Summary: Full zooming not functional (objects as well as text) → Full zooming not functional (objects as well as text) (page zoom) (like opera)
*** Bug 215462 has been marked as a duplicate of this bug. ***
*** Bug 224622 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Hi,

I am still getting this email even though I removed my email address.

I am not listed in the table in the html (<input type="checkbox"
name="removecc">Remove selected CCs), or the webpage as far as I can see



Can someone remove me please? or tell me who to contact please?

mozilla AT jguk DOT org

Thanks

JG
Or if he wants to keep the vote, he needs to modify his prefs so that he doesn't
get emails for bugs he votes on.
ah, ok.  I've turned off the vote email stuff now.  Thanks for the help.

JG
Whiteboard: parity-opera
*** Bug 230935 has been marked as a duplicate of this bug. ***
*** Bug 231239 has been marked as a duplicate of this bug. ***
*** Bug 235229 has been marked as a duplicate of this bug. ***
Please include "image" in the bug description -- to avoid duplicates. Thanks.
Summary: Full zooming not functional (objects as well as text) (page zoom) (like opera) → Full zooming not functional (images, objects as well as text) (page zoom like opera)
Users (incl. me) really want this feature.
See http://forums.mozillazine.org/viewtopic.php?t=55876
The bookmarklet nearly does it for some sites.
Is there any hope that this will ever be implemented in Mozilla.  My laptop has 
a very high DPI display and this makes this feature critical for Mozilla to be 
usable on the system.  IE 6.0 has this feature (by way of scaling the page based 
on your DPI setting) and works great, Opera has it (by manually selecting zoom 
level) and works decent (the Opera implementation has a few glitches) on both 
Windows and Linux, but I really miss using my favorite browser.

There is a hope or it would be marked WONTFIX. :-)
*** Bug 242290 has been marked as a duplicate of this bug. ***
Many of the duplicates here simply request the font zoom level be inherited when
opening a new tab. Isn't it possible to implement that first, and deal with the
rest leater? It really is tedious to have to zoom and zoom and zoom again..
Such bugs should be marked wontfix (for the reasons described in bug 65571) but
with reference to feature requests bug 4821 (this bug) and bug 108391.
Should bug 230935 be reopened then?
Yes, its a totally different bug than this one. I don't agree that it should be
marked WONTFIX (if you pay attention only to part b), but if it is marked
WONTFIX, that's better than being duped to this unrelated bug. I think this bug
and bug 108391 have sorta become a bit of a catchall for bugs with poor bug
reports or hard-to-find dupes, and some of the bugs shouldn't be duped to this
one, but be either standalone WONTFIX, dependencies, or bugs duped to each
other, but not to either this bug or bug 108391. Doing so creates confusion for
bug reporters and others following dependency trees, referenced bugs, etc.
*** Bug 243790 has been marked as a duplicate of this bug. ***
First of all, I'm a new commer in bug report and, reading comment #106, I wonder
if this comment is the best way to explain what I'll explain, if not, tell me
what to do (maybe creating an RFE with dependencies on this bug report ?).

So, I'd like to add another perspective and some explaination about the use of
an increasing the size of everything's zoom.

It seems that the "text zoom" has been created for accessibility reason; but, it
is not respectfull of the fixed size like cm, px and pt, and that is a real
problem in some case.

I know lots of webmaster/webdesigner don't use fixed size in a proper way (and
the best thing to do is to educate them to a proper use of (X)HTML/CSS), but,
for those who use it in a proper way, there are some reason for fixed size not
to be resized without the other elements of the page, almost graphical ones (for
exemple, when a text size is defined to fit with an image) and, on those last
type of case, the fact that "text zoom" also resize the fixed size is a
malediction for webmaster/webdesigner.

So, the text zoom should only work with em size to be respectfull of the fixed
size and, on other cases, there should be a zoom increasing the size of
everything, so people with visual deficiency, may use it to be able to read too
small font with fixed size.

Though, as wrote on a previous comment, having few way to zoom may be confusing
for users. About that, I think that the only solution is to be really clear on
the way to call those two differant zoom:
The increasing the size of everything's zoom should be called: "Zoom" or "Zoom
on everything" and should placed before the text zoom to add some weight on the
fact that the text zoom is a more specific type of zoom.
The text zoom should be called: "Change defaulf font size" or "Change font size"
(though, this last one may be confusing as only em's sized text would be changed).
*** Bug 250281 has been marked as a duplicate of this bug. ***
Three years ago, someone commented in this bug that "I don't think the user
would want everything, including scrollbars, to zoom", but actually, I do.  The
reason I'm (now) interested in this is that I have a new monitor that can do
2048x1536.  It's fantastic for image editing, and terrible for browsing the web.  

I can scale my global font size up, and my desktop icons, but there's no way to
tell Mozilla to scale up images, and without that, most of the web is unusable
at this resolution.  Images are too small to see, images-of-text are unreadable,
and everything lays out wrong...

I think that the (proposed) "scale everything" and (existing) "change font size"
commands both have uses (the former is for those of us with high res displays;
the latter is to work around bad choices made by web designers on a page-by-page
basis.)
I agree totally with jwz here. I'm actually using opera on my workstation,
because it can really scale _everything_. Browsing pages at 150% is such a
relief on my poor eyes.
The proper fix for high-density displays is this:

http://ocallahan.org/mozilla/units.html

Doing zoom would be cool too but it's more of a stop-gap fix.
This functionality would be nice in Mozilla (and probably better than anything
generic a display system could provide), but I'm also thinking that the display
system for XWindows and Windows should be providing scaling functionality of
allowing user scaling of the entire application's client area, also. It would be
done in a way that's transparent to the application itself unless it does some
real hackery.
*** Bug 261910 has been marked as a duplicate of this bug. ***
Until a full zoom an be implemented, can "px" sized fonts be exluded from text 
zoom in quirks and almost standard modes? No web author is using px if they 
want the text to be resizable (because it will not be in IE) and many are 
using px because the don't want it resizable. Regardless of your text sizing 
philosphy, resizing px sized fonts breaks many existing sites and the fewer 
broken sites the better for mozilla acceptance.  
Please no. web authors usually use px for petty prettiness reasons, while users
zoom to actually salvage a pretty site from uselessness on displays with a
different resolution.

There is absolutely no reason to use px for fonts or excluding them from zoom.
If you actually believe this please sent me a monitor with auto-adjusting
resolution (or at your convenience a collection of monitors covering the
resolution range web authors using px like to use)

px is a meaningless measure for human-readable content, allways was, allways
will be. It just took several monitor generations with differing base
resolutions for everyone to realise it.
> because it will not be in IE

All the more reason for a user with accessibility needs to use Mozilla instead
of IE.
Here is what says the W3C ( source:
http://www.w3.org/TR/REC-CSS2/syndata.html#length-units ):

There are two types of length units: relative and absolute. Relative length
units specify a length relative to another length property. Style sheets that
use relative units will more easily scale from one medium to another (e.g., from
a computer display to a laser printer).

Relative units are:

    * em: the 'font-size' of the relevant font
    * ex: the 'x-height' of the relevant font
    * px: pixels, relative to the viewing device 

[...]

The 'em' unit is equal to the computed value of the 'font-size' property of the
element on which it is used. The exception is when 'em' occurs in the value of
the 'font-size' property itself, in which case it refers to the font size of the
parent element[...]

The 'ex' unit is defined by the font's 'x-height'. The x-height is so called
because it is often equal to the height of the lowercase "x". However, an 'ex'
is defined even for fonts that don't contain an "x".

[...]

Pixel units are relative to the resolution of the viewing device, i.e., most
often a computer display[...]

[...]

Absolute length units are only useful when the physical properties of the output
medium are known. The absolute units are:

    * in: inches -- 1 inch is equal to 2.54 centimeters.
    * cm: centimeters
    * mm: millimeters
    * pt: points -- the points used by CSS2 are equal to 1/72th of an inch.
    * pc: picas -- 1 pica is equal to 12 points. 

[...]

It is clear that the px are relative to the viewing device. As the viewing
device don't depend on Gecko navigators, so, Gecko navigators should not resize
px values ! That's what IE and Opera do, Opera beeing more accessible with his
zoom option.

Gecko navigators use the words "text zoom" or "increase size" to bypass the fact
that they modify a size they don't have to modify!

Personaly, I'd preffer Gecko navigators to be as limited as IE while there are
no real zoom like in Opera instead of bypassing rules with well choosen words.
Indeed, Gecko navigators is the only browser that act like that and, that may
cause some problems.

Here is a concrete exemple:

There are some discution in the way to put image on a title (h1,h2,...):

First solution is to put the entire image in the title and use alt atribute to
render the text on the image:

<h1><img src="Title_text_in_image_surounded_by_frames.png" width="500"
height="50" alt="Title delimited by an image frame that so can't be resize" /></h1>

The problem is that alt attribute are not as well concidereted by search
engineer as some text, so, here is a better solution with the use of CSS (that
might be more sementic by the way):

html:
<h1>Title delimited by an image frame that so can't be resize</h1>

css:
h1 {
 background:url(Frames_for_the_title.png);
 width:500px;
 height:50px;
 font-size:Npx;
}

N on the font-size beeing the size that fit with the image's frames.

This works on IE and Opera very well, but, in Gecko navigators, if some-one
increase the size, the all design is broken, so, because of Gecko navigators,
we, web-developers/web-designer have to use the first solution. That's what I've
donne there (and I'd realy prefer to use the second solution):
evolutionnaire_DOT_be (replace the _DOT_ by a dot, the web-site is not officialy
open, so, I don't want to tie it directly).

Note: some may use a different way with css: replacing text by an image, but, I
think that it is ethicaly very arguable, almost when it's only because of Gecko
navigators way to deal with px that cause problems.
Please bring that off-topic issue up in another bug.

On your CSS example, can't you make use of the overflow property?

> Gecko navigators should not resize
> px values ! That's what IE and Opera do, Opera beeing more accessible with his
> zoom option.

Yes, it should at the user's request, because not all eyes are created equal. It
is done for accessibility reasons, and we don't have faith in all web developers
to test their pages on those with eyesight issues. Let's discuss medium:

                       --------|
       | \       ------        |
retina |  (<>) --              | screen
       | / eye   ------        |
                       --------|

We have no right to control the user's viewing of a page because of assumption
we make about the eye and retina portion of their viewing medium. We have no
right to control the browser in such a way, making the web inaccessible for some
users. If web developers want to make their pages look ugly for people with
accessibility issues, that's their choice. They can enlarge the font and make
sure their page looks good.

Anyway, please bring that suggestion up in a different bug, as it has no
relevance to full zoom except that I guarantee it wouldn't even be considered
until this bug is fixed. Even then, some users don't want their page zoomed
requiring constant scrolling and would just like to enlarge the text.
As was written in comment #118 px is relative to the viewing device.
Since you, the web designer have absolutely no mean to control the viewing
device, using units tied to it is cheer stupidity (except in rare cases like an
intranet where all screens are the same but this is not a representative example).

USERS DO NOT ZOOM TO **** YOUR DESIGN. Users zoom because stupid design choices
like using absolute units for text FORCE them to zoom to try to compensate for
the design UTTER STUPIDITY.

(sorry for the shouting, but I'm damn tired or seeing postmark-sized 800x600
sites after all these years because the designer didn't want to bother with flow
problems and used absolute measures everywhere. If people wanted printout-style
sites we'd all be using pdf everywhere now.)

I guess when M$ will have finished fixing its display libraries so it needn't
force the same font resolution on about every windows system on earth some
people will realise at last 96dpi isn't a new physics constant.
(In reply to comment #119)
> Yes, it should at the user's request, because not all eyes are created equal.
> It is done for accessibility reasons, and we don't have faith in all web
> developers to test their pages on those with eyesight issues. Let's discuss
> medium:
> 
>                        --------|
>        | \       ------        |
> retina |  (<>) --              | screen
>        | / eye   ------        |
>                        --------|
> 
> We have no right to control the user's viewing of a page because of assumption
> we make about the eye and retina portion of their viewing medium. We have no
> right to control the browser in such a way, making the web inaccessible for
> some users.

That's why web developers have to use mostly em and px only when needed, but,
that's not to the browser to correct bad web developers implementations!

> If web developers want to make their pages look ugly for people
> with accessibility issues, that's their choice. They can enlarge the font and
> make sure their page looks good.

If web developers wants to make their page inaccessible by using px instead of
em, that's their choice.

> Anyway, please bring that suggestion up in a different bug, as it has no
> relevance to full zoom except that I guarantee it wouldn't even be considered
> until this bug is fixed. Even then, some users don't want their page zoomed
> requiring constant scrolling and would just like to enlarge the text.

I was just explaining why only "text-zoom" is not a good solution and why a full
zoom would be the best why to deal with accessibility, and, moreover, that,
before the implemantation of a full zoom, it might be good to respect web
developers will, what ever they are right or wrong (flash works on Gecko
browsers, flash is not an accessibility exemple, that's the same, if web
developers do not make the choice of accessibility, that's not the browsers that
have to render their page accessible by creating problems on the interpretation
of their size units).

I am not suggesting a bug, I was answering the previous comments by giving
another point of view, someone asked about an exemple where it is a problem, so,
I gave an exemple, but, that's only an exemple.
A web browser is a USER AGENT. As a user agent, its primary job is to meet the
needs of the USER, not page designers. As long as designers insist they know
better how big text on a page should be and litter their pages with mousetype,
users need the ability to override this designer obstacle to accessibility.

This advocacy needs serves no purpose to fixing this bug. Please, take further
discussion not directly related to actually fixing this to the discussion forums.
(In reply to comment #120)
> As was written in comment #118 px is relative to the viewing device.
> Since you, the web designer have absolutely no mean to control the viewing
> device, using units tied to it is cheer stupidity (except in rare cases like
> an intranet where all screens are the same but this is not a representative
> example).

You didn't understood my exemple.

1. I'm not a web designer, I'm a webmaster and, I had to do some design.
2. I take care of accessibility, I was explaining that, in some typical case,
their may be reasons to use px: when you want to associate a text size with an
image size (for exemple, a frame surounding a text). By doing so, of cours, for
people with visual defiances, the letter size have to be big, that fit with a
title, so, it don't create accessibility problems. For the rest, of cours,
text-size are in em for people to be able to read it with visual deficiances.
3. I've answers a bit about it on my previous comment (and I'll go further, if
bad web developers makes unaccessible page, it's better to educate them by
keeping their page inaccessible, so that people with visual deficiances will
shout at them). ;-)

> USERS DO NOT ZOOM TO **** YOUR DESIGN. Users zoom because stupid design
> choices like using absolute units for text FORCE them to zoom to try to
> compensate for the design UTTER STUPIDITY.

I totaly agree with you, once again, that's why a full zoom is needed, because a
text zomme might create problems for web developpers creating design by taking
care of accessibility (do you think it is better to have some text in image when
there are no image zoom ?).

> (sorry for the shouting, but I'm damn tired or seeing postmark-sized 800x600
> sites after all these years because the designer didn't want to bother with
> flow problems and used absolute measures everywhere. If people wanted
> printout-style sites we'd all be using pdf everywhere now.)

I understand, but I'm definitely not this kind of personne!
It would also be nice to recenter to the current view after resizing:

If my current window shows

xxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx
xxxxxxxxxAxxxxxxxx
xxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx

and I resize, it would be nice to still see "A".
(In reply to comment #124)
Hi,

Can someone who is familiar with Mozilla's formal procedures please tell me
what one needs to do, to raise the urgency and seriousness of this bug?

The description of its severity as an 'enhancement' and the target milestone
of 'future' seem wholly inappropriate.

Section 18.5 (Magnification http://www.w3.org/TR/REC-CSS2/ui.html#q6) of the
CSS2 recommendation makes is quite clear that User Agents should implement
proportional full screen magnification, and in the following way:

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

Yet a significant proportion of comments on this and related Mozilla bugs seem
opposed to the very idea of full-screen zoom, preferring the clearly
anti-standard practice of letting text zoom screw up layouts and cause
unreadable text overflow.

I can also find little evidence of coding work over the last couple of years.

I believe that the CSS2 recommendation, the W3C accessibility guidelines, and
the struggle to defend open web standards against Longhorn/XAML etc all suggest
that this bug is a great deal more important than has been commonly assumed.

I am willing to invest the time in detailing the arguments why this is the case
(in the appropriate forum), providing I have some confidence that they will be
listened to and taken more seriously than they have been up to now.

Dave
Dave: Most mozilla developers will agree with you that this is a very important
feature, but the importance of the feature is not the issue. There just isn't
anyone available with the time and knowledge to do the work. That is what the
"helpwanted" keyword signifies. Before this bug can move forward we have to find
somebody willing to volunteer to do the work.
However, could the severity be raised anyway, or would that not do anything to
help spur potential developers to take a look at this bug?  I think it's been
successfully argued that this is not an "enhancement", but rather an actual bug
in the page resizing code, perhaps severity raised, to, say, "normal" would be
appropriate?
It has not been successfully argued that the current behavior is a bug. The CSS2
specification excerpt in comment 125 does not mention resizing the comic text
balloon, only ensuring that the text is still within it.
Hopefully this will follow pretty easily once we switch to Cairo, so I don't see
the point of working on it before then.
*** Bug 291646 has been marked as a duplicate of this bug. ***
*** Bug 292135 has been marked as a duplicate of this bug. ***
A zoom function that enlarges everything needs to consider various factors I see
as important:

1. What happens to scrollbars in IFRAMEs and DIVs. Opera does not resize these.
This means that a page layout can never be maintained exactly as it is enlarged.
With a site 100% wide to begin with, zooming in breaks the layout anyway, as
elements resize to fit the same screen width.

2. The example Photoshop zoomed images here are misleading, because they are
treating the text in the same way as the graphics, ie: as bitmaps. In the
browser, this isn't the case - text is in vector format, whereas only images are
in bitmap form. (So a browser can resize text without losing quality, but images
will become jagged.)

3. The way I see a zoom function working is that there are two main routines
needed: one for enlarging bitmap images, and one for resizing text as is
presently possible. A combination of both will result in a successful page zoom.
The problem lies in maintaining a precise balance between the two routines, so
the layout is maintained as best as possible.

4. Further routines may be needed for elements like forms and frames.

5. What about Flash? Opera currently fails to enlarge text in headlines created
in sIFR when zooming in.

6. What happens when the website adds content using the DOM? This will have to
match the existing zoom size.

Now it may be unnecessary for zoom to be implemented at all in the forthcoming
Windows Longhorn. I believe this is capable of zooming ANY window, precisely
retaining the contents. It's because it can use the graphics card to draw
windows. I'm not sure, but this might also be ported to XP as part of Avalon, so
in theory XP and Longhorn users can then easily resize websites to fit larger
screens. Of course zoom would still be necessary for all the other platforms.
Points (3), (4), and (6) in comment 132 are irrelevant, since the point of this
bug is implementing zooming as a transformation, not separately on each type of
rendering object.  (1) is an interesting issue that we have to be careful of,
but it shouldn't be too hard.  (5) may or may not be solvable depending on plugins.
And wrt. (1), relying on scrollbars to be present, absent, or a certain size
already breaks layout for browsers/OSes/OS configs other than the one you use.
(In reply to comment #132)
> 2. The example Photoshop zoomed images here are misleading

Yep, the example should be a software like Adobe Illustrator, which has to
handle zooming a mix of bitmap and vector.
*** Bug 294744 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
*** Bug 309104 has been marked as a duplicate of this bug. ***
*** Bug 309341 has been marked as a duplicate of this bug. ***
According to this page
(http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=170703211),
Internet Explorer 7 will have full zoom:

"Page Zoom, meanwhile, allows users to zoom in on text and graphics of Web pages."
*** Bug 315963 has been marked as a duplicate of this bug. ***
*** Bug 318037 has been marked as a duplicate of this bug. ***
*** Bug 307196 has been marked as a duplicate of this bug. ***
+1 to comment 125. As an example of something that needs to be handled, I would like to offer my site at http://go.kestrel.nu 

I have installed the Image zoom 0.2.1 and Page Zoom 0.2.2 extensions in firefox, and neither does the "right thing" as far as I am concerned (though they both are useful) What I was hoping for in installing these was the Zoom everything that is described in some of the comments. 

The proper form of the solution seems to me to be "as if a magnifying glass was placed between the browser window and the final page rendering". So that everything that would have been 2 pixels wide without 200% zoom becomes 4 pixels wide. This zoom should apply to every thing that is "the page." It should not need to be implemente for any object type, but be a modification of the final product of existing rendering. 

If it isn't done this way, then scaling my site at http://go.kestrel.nu with this type of zoom will not change whether or not the scroll bar appears for my left menu. 

Text only zoom has it's place and is an interesting feature, but it is very difficult to design for. If history has prooven one thing, it is that while some web designers and webmasters are conciensious and skilled, the other 90% don't give a $*!$ and just want to get a page out that someone will pay them for. For them its a job not a crusade. Typing harsh comments about them in this bug in all caps won't change their minds or make them do the right thing. If they know that their client will not look at it in other browsers or think to try out text zoom, they simply are not going to spend any time on it. If they aren't skilled, it won't matter if they want to do it right or not... 

A true post render zoom would not mess with the author's intent at all, accomodating both the author and the user.

I am really keen on this bug because I use 1600x1200 on 2 screens (at once, one laptop, one monitor) at work, and 2048x1536 on my linux box at home. I program for a living and my personal style is that screen size is key for making all the funky windows of my IDE big enough to acctually accomodate the names of methods, ant targets, navigation trees, more than 2 lines of problems and warnings... etc and still have somewher to put the code :) Then I go to look something up on the web and half the time I can't read it...

So I do text zoom and the form controls images and nearly everything mishmashes into a mess. Often form controls or content in floated divs will just overlap and obscure things, particularly on blogs it seems. It's a mess.

Sadly I'm only reasonably familiar with in Java, perl and sh. The last time I programed in C it was in Borland's Turbo C 1.5 :) so I can't really help with coding this, but if I could I would. This has bugged me for years.
I have a few comments/questions on the status of this bug.

Reading the dependent bug reports, it looks like the work on bug 177805 may fix this bug. Is this correct or is additional work required?

Regarding comment 125 and the response in comment 128, I don't see any way to guarantee that you can keep HTML text within a graphic word balloon without the zooming proposed here. So I believe the CSS2 recommendation implies zooming all elements.

I just implemented a site which does full text and image zooming when using Firefox. See http://www.ripplerunresort.com. To make this work, I had to convert all pixel units to em's. The stylesheet that does this is a PHP script and the conversion gets a little hairy when there are nested elements with variant font sizes.

This begs the question: if I can do this today with no change to the Firefox code, could what I did be placed into the code? Is this what bug 177805 is doing? More interesting, could this be done in a plug-in so we could get this feature now instead of later? It isn't clear what the timeline for bug 177805 is.

A variant of this comment will go into bug 177805.

The problem with comment #125 is we are not talking about the same things at all.

Fonts nowadays are mainly vector fonts and can be scaled cleanly.
Images OTOH are mostly bitmap and do not scale at all sizes without data loss (a bad scaling may make a picture totally useless)

What people are asking is a mode that scales only vector elements (fonts, svg) and leave the rest alone.

(Note that most web designers mix absolute and proportional elements, when you specify font size in points you've already lost any warranty it will be a particular size wrt bitmap images. A full px HTML page could possibly be scaled cleanly. A full vector/proportional page too. A mixed page is broken by design and only sort-of works when the designer system and the viewer systems are very close)
(In reply to comment #145)

> Fonts nowadays are mainly vector fonts and can be scaled cleanly.
> Images OTOH are mostly bitmap and do not scale at all sizes without data loss
> (a bad scaling may make a picture totally useless)

Actually, my request for a magnifying zoom is based on using Opera. If I could load all the Firefox extensions into Opera, I would switch over to using it. Because I scale Web pages to make them easier to read, I can certainly live with bad scaling of a bitmap image:

1) I rarely scale down--just up.
2) An unreadable bitmap based navigation button is much more of a problem than
   its poorly scaled but readable larger cousin.

> What people are asking is a mode that scales only vector elements (fonts, svg)
> and leave the rest alone.

Not me, I'd like to scale everything that can be reasonably be scaled. Bitmapped images can be reasonably scaled. I'll happily live with the imperfections. I would personally be happy to live with the odd unscaled Flash or Java object as long as the area it occupies is scaled (to maintain the layout).

Because of potential arguments about the "right" way to scale and about a 95% solution, I'd love to see this implemented as an extension. I don't know a thing about the innards of Firefox, so I don't know whether this could be done with an extension. I'd be willing to work on it if a more experienced person would act as an advisor. Please e-mail me directly.
(In reply to comment #146)

> 2) An unreadable bitmap based navigation button is much more of a problem than
>    its poorly scaled but readable larger cousin.

That depends if its larger cousin is not part of the page main content (as opposed to button eye-candy), and bitmaps that contain text will become unreadable fairly easily at small zoom levels (110%, 95%)

Also, in the case where vector text is mixed with bitmap decoration you can not get it right. There is no pt <-> px conversion scale, unless you assume some particular windows configuration, which 
1. is not shared by everyone (and definitely not by new windows systems since they finaly started doing vector fonts in the UI)
2. will break every single page that didn't take the same broken assumptions as you, ie you'll be evangelizing a wrong model

Had this been proposed a few years ago I'm sure someone would have said "let's just assume the designer system is 96dpi 1024×768". Today no one would dare that (at least I hope) but even the remaining assumptions that would be used to create this auto scaling policy are dead wrong.
(In reply to comment #145)
> What people are asking is a mode that scales only vector elements (fonts, svg)
> and leave the rest alone.

This bug is clearly about scaling everything, not only vector elements; please do not confuse the issue.  If you want some other sort of zooming, please take your comments to another bug or the forums/newsgroups.  FWIW, some of your poor scaling concerns will be addressed by bilinear filtering which may be added once the new graphics rendering engine is complete.
(In reply to comment #147)
> 
> That depends if its larger cousin is not part of the page main content (as
> opposed to button eye-candy), and bitmaps that contain text will become
> unreadable fairly easily at small zoom levels (110%, 95%)

Having used Opera to scale Web pages, I disagree completely with the statement that bitmaps containing text become unreadable at small zoom levels--as long as we are zooming in. In this case, seeing is believing.

Zooming out is used for other purposes. For example, the Viamatic foXpose creates small versions of each tabbed window, all unreadable but visually useful.

> Also, in the case where vector text is mixed with bitmap decoration you can not
> get it right. There is no pt <-> px conversion scale, unless you assume some
> particular windows configuration, which 

Please post the URL of a Web page which you believe cannot be magnified correctly. I would be interested in understanding the problem (I will use Opera to magnify the page--you may want to check the page with Opera before posting).
couldn't this be done with canvas?

The: Tab Sidebar, Tab Catalog, Tab Preview and Tab Expose extensions do an very similar job to this bug: they resize a webpage to an thumbnail...
(In reply to comment #150)
> couldn't this be done with canvas?

No, because you would no longer be able to interact with the document that the canvas displays (e.g. filling out forms, clicking links). Canvas is not the way to go here.
(In reply to comment #149)
> (In reply to comment #147)

> > Also, in the case where vector text is mixed with bitmap decoration you can not
> > get it right. There is no pt <-> px conversion scale, unless you assume some
> > particular windows configuration, which 
> 
> Please post the URL of a Web page which you believe cannot be magnified
> correctly. 

Just loading any random page in a browser that does not use the default fonts and resolution of internet explorer (arial on a 96dpi sub 1280x1024 screen) will show web pages authors do not use the correct units and assume all sorts of relations which are not true in real life. Magnifying this mistakes via zooming will only make them worse.

Of course you can always redefine units so they render the same way as in IE (redefine meaning of pixel as microsoft_pixel, dpi as microsoft_dpi, pt as microsoft_pt, etc). You'll be right more often than you're wrong with the current internet state, and you'll also perpetuate this state a few more decades. I'm pretty sure that's what Opera does.

What's the point about standards anyway
(In reply to comment #152)
> > Please post the URL of a Web page which you believe cannot be magnified
> > correctly. 
> 
> Just loading any random page ...
> ...

You are complaining about problems not really related to the magnification zoom covered by this enhancement request. Please file a separate bug report for these problems.
*** Bug 324517 has been marked as a duplicate of this bug. ***
(In reply to comment #3)
> This bug is marked "future" because it is not critical for RTM (Release To 
> Manufacturing). If anyone believes it is critical, please explain why in
> this bug. 

ok this is a criticle bug beacuse of people with bad eye sight that want a safer browser are going to chose oprea over firefox and soo IE over fire, all the major browsers will have it and if firefox doesn't it will just look like a second rate browser compared to IE an oprea.

i think it can be acchived if you zoomed in on an image and then increassed font size so you keep the font clarity but you would lose some to the bitmap but if you keep the text zooming and bitmap zooming in paportion it can be achived 

i haved attached a picture of what i am talking about
(In reply to comment #3)
> This bug is marked "future" because it is not critical for RTM (Release To 
> Manufacturing). If anyone believes it is critical, please explain why in
> this bug. 

ok this is a criticle bug beacuse of people with bad eye sight that want a safer browser are going to chose oprea over firefox and soo IE over fire, all the major browsers will have it and if firefox doesn't it will just look like a second rate browser compared to IE an oprea.

i think it can be acchived if you zoomed in on an image and then increassed font size so you keep the font clarity but you would lose some to the bitmap but if you keep the text zooming and bitmap zooming in paportion it can be achived 

i haved attached a picture of what i am talking about
this is a way to zoom an image using image zoom combined with font increass to create a full page zoom
I just ran IE 7 beta 2. It includes a page zoom capability. The UI is a selection of zoom percentages in the lower-right corner of the window. The text size menu setting is also and works as it does in IE 6.

I've looked at the Firefox roadmaps and I have not seen page zooming listed. I consider this feature more important than many of the other things listed. I hope that Firefox will release this feature before IE 7 is released as I would not like Firefox to fall behind IE in terms of implementing critical features.

Some of the IE 7 features which are not in Firefox are available through Firefox extensions. I tried writing an extension for page zoom. It works better than the existing Page Zoom extension, but it has unacceptably slow performace and doesn't handle all pages correctly. I believe this feature cannot be implemented as an extension and so must be supported by the Firefox team (if it is to exist).
full page zoom requires cairo to be switched on, so it won't be out (if at all) before Firefox 3.0.
Whiteboard: parity-opera → parity-opera parity-IE7
Attached image IE7 Zoom
Screenshot of IE7 page zoom and print zoom. There's some room to best IE because the zoom setting is retained between pages, whereas we could allow for a way to temporarily change the zoom. Also notice the print zoom messed up on the tear-back on the upper-right.

See also:

IEBlog discussed zoom feature: http://blogs.msdn.com/ie/archive/2006/02/07/526805.aspx
IEBlog discussed printing feature: http://blogs.msdn.com/ie/archive/2006/02/06/526010.aspx
Mozillazine Cairo update: http://www.mozillazine.org/talkback.html?article=6498
Is there a reason this bug can't be targeted to mozilla 1.9/firefox 3?  It would be a great boon to accessibility and good for marketing too.
Can I set a new target or does a higher-up need to make such a decision?  (I'm guessing the latter is the case.)
Does this bug need to be confirmed before it can be targeted?
Target Milestone: Future → mozilla1.9beta
Now this is surely a reason to switch back to IE. What good do all the other cool Firefox features do, if I can't read the web pages on my high resolution screen? Simple text resizing doesn't do - try cnn.com with that...
(In reply to comment #163)

Could you please read carefully before commenting? Full zooming is not really possible in a clean way with Gecko 1.8. It's targeted for Gecko 1.9 / Firefox 3 (2007). If you can't wait, feel free to use Opera, IE7 or an extension like Web Developer, which provides zooming (though, as I said, not quite decent).
(In reply to comment #159)
> full page zoom requires cairo to be switched on, so it won't be out (if at all)
> before Firefox 3.0.
> 

So does anybody know what needs to be done to get full-page zooming working on trunk (which has the cairo stuff)?
(In reply to comment #165)
> So does anybody know what needs to be done to get full-page zooming working on
> trunk (which has the cairo stuff)?

"Bug 4821 depends on:  	153080 177805".
*** Bug 351658 has been marked as a duplicate of this bug. ***
We need zoom.

I propose that alt + / -  mean complete page zoom. -- just like the css spec recomends (but does not require-- which is just how opera does it)


and that alt shift + / - does the current behavior ?

--
What I really want:

I want a zoom feature that scales images, and text, while keeping the page width the same... This is going to be basically impossible to do right because of how many ways people can design web pages.  I end up with text overlapping pictures and the like and that just doesn't cut it.. -- The current solution basically does this already, and I have to deal with people who poorley designed their web pages all the time.

-AP
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: parity-opera parity-IE7 → parity-opera parity-IE7 [wanted-1.9]
the plain and simple truth is that using ctrl+= and ctrl+- should be changing the size of the entire content of the page.  this feature is only used when someone can't SEE what they're trying to see, and making the text easier to read but making them still have to squint up to the monitor to see images is moronic, it's bad design, and it's the kind of half-implementation I'd expect from the lowlifes and Microsoft.
the plain and simple truth is that using ctrl+= and ctrl+- should be changing the size of the entire content of the page.  this feature is only used when someone can't SEE what they're trying to see, and making the text easier to read but making them still have to squint up to the monitor to see images is moronic, it's bad design, and it's the kind of half-implementation I'd expect from the lowlifes at Microsoft.
apologies for the double post.  it won't let me delete #171 :(
if the accidental double posting is all you find need to apologize for, you have issues :( have a cup of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
How are you gentlemen? All your dependencies are belong to fixage. You are on the way to implementing full page zoom. You have no chance to zoom make your patch.

A.K.A: All dependencies of this bug have been fixed. We can start implementing full zoom.
I'm working on updating attachment 60121 [details] [diff] [review] to the latest trunk. So far, it's good, I started updating, although I haven't started a build yet (it takes me 4 hours, and that's lots of time for me).
-  float mTextZoom;

Do you really want to drop TextOnlyZoom ? I think it is not very good Idea, because as some peoples more like simple text zoom instead Opera Full zoom.

I think it should be preferable.
I also think that we should not drop the text only zoom.

Because full zoom needs wider area for the all contents. E.g., if a page has fixed width for the container of the contents, the container width becomes wider width by full zoom. That will make the horizontal scrollbar, I think that the case is not better for readability.
@Stefakink: read comment 70. Maybe bug 177805 changed it again.

@Who is complaining about text zoom:
read comment 29.

(In reply to comment #5)
> Note that there are many different types of zooming.  Which one does this
> cover?
> There are:
> 
>  * increasing the default font size (which we can currently do in prefs)
>  * increasing the logical resolution (we also have this in prefs)
>  * increasing the size of all text, no matter how its size was specified, along
> with everything else that depends on text size (I think this is what View |
> Text
> Size does, except it doesn't change things that are sized relative to the text)

This one should stay.

>  * increasing the size of everything (text and images) -- perhaps that's what
> this bug covers?

This one is to be implemented.

>  * increasing all sizes specified by the page author (including or excluding
> the
> default sizes of images)
> 
Just checked what attachment 60121 [details] [diff] [review] is really, and it doesn't worth updating, as it was only a test... We need a proper implementation of page zoom, ad att60121 is definitely not one.
(In reply to comment #176)
> -  float mTextZoom;
> 
> Do you really want to drop TextOnlyZoom ? I think it is not very good Idea,
> because as some peoples more like simple text zoom instead Opera Full zoom.

No, we don't, and the line you quote wasn't.  It was just using the same struct for both full zoom and text zoom, for use within the code that applies a change to child frames.

(In reply to comment #179)
> Just checked what attachment 60121 [details] [diff] [review] is really, and it doesn't worth updating, as
> it was only a test... We need a proper implementation of page zoom, ad att60121
> is definitely not one.

The real implementation shouldn't be all that different, except:
 * the SetCanonicalPixelScale/GetCanonicalPixelScale should be replaced with something else
 * The UI code in viewZoomOverlay.js was just temporary code for testing (and thus replaced text zoom with full zoom) -- the real UI code would probably want to do something like choose one or the other depending on the ratio
And note that the "something different" probably requires changes to the pres context -- perhaps just to add another scale variable along with the PageScale and PrintPreviewScale, and then use it to do some scaling.  But Eli would know for sure.

We'd also need to rev the IID of nsIMarkupDocumentViewer.
(In reply to comment #181)
> And note that the "something different" probably requires changes to the pres
> context -- perhaps just to add another scale variable along with the PageScale
> and PrintPreviewScale, and then use it to do some scaling.  But Eli would know
> for sure.
> 
> We'd also need to rev the IID of nsIMarkupDocumentViewer.

Hmm, if you're going to put a zoom attribute on nsIMarkupDocumentViewer, you'd probably want to remove the one on nsIDocShell.  Other than that, it sounds right.

Implementation-wise, I think the correct way to go about this is probably adding a variable onto the prescontext and adding some logic to nsViewportFrame (or maybe CanvasFrame) to do the scaling.  We'd probably also want to add some logic to scrollbars so that they don't scale with the page.

Unfortunately, our current infrastructure isn't really ready to deal with the implications of this approach at the moment. Currently, it would work about as well as https://bugzilla.mozilla.org/attachment.cgi?id=224965 does. I think we're planning on resolving all the issues with that for 1.9.

Actually, it might be a good idea to use something like that testcase to experiment.  Just add a little bit of UniversalXPConnect magic, and we can experiment with different ways of varying zoom and text zoom.  (Testing that seriously would probably require fixing scrolling in scaled contexts.  I'll whip up a minimal patch to fix that and an experiment framework sometime soon.)

Messing with the DPI would probably work a bit better at the moment, but not perfectly, and it's probably going to break with roc's compositor work.
(In reply to comment #177)
> I also think that we should not drop the text only zoom.
> 
> Because full zoom needs wider area for the all contents. E.g., if a page has
> fixed width for the container of the contents, the container width becomes
> wider width by full zoom. That will make the horizontal scrollbar, I think that
> the case is not better for readability.
> 

I checked out how this is handled in Opera (because I kept hearing they have the best zoom implementation). What happens is almost exactly like our text zoom except it handles images as well. Any flexible container elements are made smaller to stay within the confines of the window and the text is wrapped.

But fixed width elements are a problem as you said. If Opera encounters those then it enables the horizontal scrollbar. Would it be a good idea to not let fixed-width containers go over the edge of the window like what happens with variable-width elements when they're zoomed?
(In reply to comment #183)
> I checked out how this is handled in Opera (because I kept hearing they have
> the best zoom implementation). What happens is almost exactly like our text
> zoom except it handles images as well.

Opera scales anything, including CSS-px widths -- that's a bit more than text zoom + images.
But I suppose you know that, since you wrote elements with a fixed width would be zoomed as well.

> Would it be a good idea to not let
> fixed-width containers go over the edge of the window like what happens with
> variable-width elements when they're zoomed?

Probably not. It would break many sites.
My idea is the following:

1. Retain the current zoom method under the name "Text Size".
2. Add a new menu, "Zoom", for full zoom.

Ctrl++, Ctrl+- and Ctrl+0 should control Zoom, Ctrl+Shift++... should control Text Size.
(In reply to comment #185)
> Ctrl++, Ctrl+- and Ctrl+0 should control Zoom, Ctrl+Shift++... should control
> Text Size.

Currently text zoom in is mapped to both Ctrl++ and Ctrl+=. On US keyboards, = is the unshifted key for +, so for convenience, Ctrl+= is also zoom.

I'm assuming you meant for the common [easier] case to be full zoom.. which should then be Ctrl+=?

Controls for zooming in, out, reset..

Full zoom: =, -, 0
Text zoom: +, _, )
Text zoom?: Shift+=, Shift+-, Shift+0

(the last 2 lines might differ on keyboards)
I'm thinking about using the numpad. That is the easiest way.
Full zoom ("Zoom"): NumPad +,-,0; as well as Ctrl+mouse scroll.
Text zoom ("Text Size"): Shift+the above, as well as Ctrl+Shift+mouse scroll.
The numpad is a bit of a problem since most laptops don't have one.
There is a problem.

On the Windows, we can rise '+' key down/up event if the key *has* '+'. I.g., in the JIS keyboard layout, the key has ';' and '+' (shift + ';' is '+'). When an user use the key, the '+' key down/up event are raised.
http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsWindow.cpp#3391
> 3391 UINT nsWindow::MapFromNativeToDOM(UINT aNativeKeyCode)
> 3392 {
> 3393   switch (aNativeKeyCode) {
> 3394     case VK_OEM_1:     return NS_VK_SEMICOLON;     // 0xBA, For the US standard keyboard, the ';:' key
> 3395     case VK_OEM_PLUS:  return NS_VK_ADD;           // 0xBB, For any country/region, the '+' key
> 3396     case VK_OEM_MINUS: return NS_VK_SUBTRACT;      // 0xBD, For any country/region, the '-' key
> 3397   }
> 3398 
> 3399   return aNativeKeyCode;
> 3400 }

On the Linux and Mac, it is not so. I think that we should change the Linux and Mac behavior if we use Ctrl/Cmd + Shift + '+' key for acceleration.

Note that we may not be able to implement same behavior on Linux and Mac. I think that we should *not* use non-alphabet and non-numeric keys for acceleration. Because the some symbols cannot be inputted without shift key in some keyboard layouts. The spec depends on the keyboard layouts.
Probably we need options like "Ctrl++/- controls:" and "Ctrl+Mouse controls:", with values "Zoom" and "Text Size".
This is a Core:GFX bug -- please save the UI discussion for other bugs (e.g., in Firefox and Seamonkey).  There are already 190 comments here, which is far too many for any of them to actually be noticed by the person fixing the bug.
Ok, this minimal patch tested with seamonkey, FF, on linux GTK2.
This implementation not required changing of .idl interfaces or creating new..
It used preference "layout.full.zoom.mode".

Not sure about System Fonts in other OS (Win, beos, OS/2)
see bug 369684
At least in GTK2 it fixed by:
-        size *= float(gfxPlatformGtk::DPI()) / 72.0f;
+        size *= 1.0f / 72.0f;
and 
-    aFont->size = NSFloatPixelsToAppUnits(fontStyle.size, AppUnitsPerDevPixel());
+    aFont->size = NSFloatPixelsToAppUnits(fontStyle.size, AppUnitsPerCSSPixel() * 96);

See attachment.
Attachment #259586 - Flags: review?
Comment on attachment 259586 [details] [diff] [review]
BUGFIX, full_zoom_implementation with pref need review

I'll go ahead and review this.  (Note that setting review? without setting a requestee is usually bogus.)
Attachment #259586 - Flags: review? → review?(sharparrow1)
Attachment #50475 - Attachment mime type: image/jpeg → image/pjpeg
Attachment #50475 - Attachment mime type: image/pjpeg → image/jpeg
Just for fun,
This is patch for enabling Opera-TrueZoom mode, when Scrollbars and ScrollView also zoomed. ;)
Found crash with first attachment (no check for mPresContext)
attachment 259586 [details] [diff] [review]
......................
+  NS_ENSURE_TRUE(mPresContext, NS_ERROR_FAILURE);
+
   PRBool fullZoom = mPresContext->IsFullZoomModeEnabled();
......................

I will attach fixed version after first review...

Also tested with Xvnc dpi=300/200... 
Comment on attachment 259586 [details] [diff] [review]
BUGFIX, full_zoom_implementation with pref need review

First off, I don't think your approach for scaling is sound.  I think your approach works for most interesting cases, but it's abusive of the app unit to dev pixel ratio, which is supposed to be a constant per-window.  I'm pretty sure it breaks drawWindow for documents which have a subframe with a different zoom level.  And this approach will completely fall apart once bug 374980 is fixed because the same rendering context will be used for the whole window.  If bug 374980 doesn't make 1.9, it might be worth taking a patch using your approach, though.

The correct implementation would be to make the viewport frame use a scaling factor for painting.  However, this approach won't work very well until bug 374980 is fixed.

The other major issue is that your implementation of zoom as a preference that's dependent on text zoom is completely unacceptable.  It should be possible for the UI to set the page zoom ratio separately from the text zoom ratio.  A correct approach would be to add a new attribute to nsIMarkupDocumentViewer.  The UI code can subsequently be modified to take advantage of the feature however the UI designers deem to be appropriate.
Attachment #259586 - Flags: review?(sharparrow1) → review-
(In reply to comment #196)
> The correct implementation would be to make the viewport frame use a scaling
> factor for painting.  However, this approach won't work very well until bug
> 374980 is fixed.

We also need to reflow because the window is effectively smaller.
My first implementation also included zoom property for DomWindow and markupviewer  .
But after some modifications it was broken...
Now it works more less fine, fixed loading next page after zoomed page, fixed Shistory navigation between zoomed pages...

For UI in viewZoomOverlay.js should be used MarkupViewer.fullZoom property.
Attachment #259586 - Attachment is obsolete: true
Comment on attachment 259615 [details] [diff] [review]
Fixed patch, (shistory, next page after zoomed)

>-    if (oldMUDV && newMUDV)
>+    if (oldMUDV && newMUDV) {
>         oldMUDV->GetTextZoom(&zoom);
>+        float fullZoom = 1.0;
>+        newMUDV->GetFullZoom(&fullZoom);
>+        mDeviceContext->SetPixelScale(fullZoom);
>+    }

Do this the same way text zoom does it; there's a SetTextZoom call a few lines down, and you should be calling SetFullZoom in the same spot.  Also, you should only be calling SetPixelScale from nsPresContext.

>-        size *= float(gfxPlatformGtk::DPI()) / 72.0f;
>+        size *= 1.0f / 72.0f;

What exactly is this change supposed to do?

>-    aFont->size = NSFloatPixelsToAppUnits(fontStyle.size, AppUnitsPerDevPixel());
>+    aFont->size = NSFloatPixelsToAppUnits(fontStyle.size, AppUnitsPerCSSPixel() * 96);

Same question here.

>+
>+PRBool
>+nsThebesDeviceContext::SetPixelScale(float aScale)
>+{
>+    if (aScale != 0.0 && mPixelScale == aScale)
>+        return PR_FALSE;
>+    if (mPixelScale == 1.0)
>+        mAppUnitsPerDevNotScaledPixel = mAppUnitsPerDevPixel;
>+    mAppUnitsPerDevPixel = (PRInt32)((float)mAppUnitsPerDevNotScaledPixel / aScale);
>+    mPixelScale = aScale;
>+    return PR_TRUE;
>+}

You need to put in some protection so that mAppUnitsPerDevPixel is guaranteed to be positive and not too huge (where too huge is probably about 2000 or so; in theory not needed, but it's better to be on the safe side.)

>+  CallChildren(SetChildFullZoom, &ZoomInfo);

Hmm, do we really want zoom to propagate to children like that?  It seems like it could be useful to have distinct values for children, plus it'll be a pain to cancal out the zoom for a zoom implementation that scales the rendering context (which is definitely the plan).

>+  mFullZoom = mDeviceContext->GetPixelScale();

Shouldn't be needed; the value should get set from the DocumentViewer.

>Index: layout/generic/nsGfxScrollFrame.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/layout/generic/nsGfxScrollFrame.cpp,v
>retrieving revision 3.299
>diff -p -u -8 -r3.299 nsGfxScrollFrame.cpp
>--- layout/generic/nsGfxScrollFrame.cpp	13 Mar 2007 22:11:14 -0000	3.299
>+++ layout/generic/nsGfxScrollFrame.cpp	25 Mar 2007 21:02:39 -0000
>@@ -423,16 +423,18 @@ nsHTMLScrollFrame::ReflowScrolledFrame(c
>   if (aAssumeVScroll) {
>     nsSize vScrollbarPrefSize = 
>       mInner.mVScrollbarBox->GetPrefSize(NS_CONST_CAST(nsBoxLayoutState&, 
>                                                        aState.mBoxState));
>     availWidth = PR_MAX(0, availWidth - vScrollbarPrefSize.width);
>   }
>   // pixel align the content
>   nsPresContext* presContext = GetPresContext();
>+  if (mInner.mFullTrueZoomMode)
>+    availWidth = availWidth * presContext->FullZoom();
>   nscoord twp = nsPresContext::CSSPixelsToAppUnits(1);
>   availWidth -=  availWidth % twp;
> 
>   if (!aFirstPass)
>     mInner.mScrolledFrame->AddStateBits(NS_FRAME_IS_DIRTY);
> 
>   // We're forcing the padding on our scrolled frame, so let it know what that
>   // padding is.
>@@ -1232,18 +1234,20 @@ nsGfxScrollFrameInner::nsGfxScrollFrameI
>     mIsXUL(aIsXUL),
>     mSupppressScrollbarUpdate(PR_FALSE),
>     mSkippedScrollbarLayout(PR_FALSE),
>     mDidLoadHistoryVScrollbarHint(PR_FALSE),
>     mHistoryVScrollbarHint(PR_FALSE),
>     mHadNonInitialReflow(PR_FALSE),
>     mHorizontalOverflow(PR_FALSE),
>     mVerticalOverflow(PR_FALSE),
>-    mPostedReflowCallback(PR_FALSE)
>+    mPostedReflowCallback(PR_FALSE),
>+    mFullTrueZoomMode(PR_TRUE)
> {
>+  mFullTrueZoomMode = nsContentUtils::GetBoolPref("layout.full.true.zoom.mode", PR_TRUE);
> }
> 
> nsGfxScrollFrameInner::~nsGfxScrollFrameInner()
> {
> }
> 
> NS_IMETHODIMP_(nsrefcnt) nsGfxScrollFrameInner::AddRef(void)
> {

You need to check whether the current frame is the root scroll frame.  You also need a pref listener.


With all that said, I'm not sure we want to take this at the moment, since a lot of it will have to change after bug 374980 fixed.
> >+        mDeviceContext->SetPixelScale(fullZoom);
Here we can't call current implementation nsPresContext::SetFullZoom directly:
1) I think fullZoom value should be restored in back/forward functionality
2) nsPresContext::mFullZoom = aZoom; - will break next testcase:
   ya.ru -> increase zoom -> wikipedia.org -> increase zoom -> back -> forward:
      wikipedia.org has the same zoom as ya.ru, but should be more.
   I guess we should not change PresContext mZoomFull value, only device context scale value.
    
3) If will do reflow on back and forward (with full SetFullZoom) it will break scroll view.
4) I did default parameter  nsPresContext::SetFullZoom(float aZoom, PRBool aRestore = PR_FALSE), aRestore - should be TRUE on restore functionality, and should to do only SetPixelScale for Device context.
 
> >+        size *= 1.0f / 72.0f;
> >+    aFont->size = NSFloatPixelsToAppUnits(fontStyle.size, 
> Same question here.
  This change will drop difference between common DPI, and System Platform Fonts DPI value, and will set common for all.
May be it  wrong, but it was tested on Xserver with different DPI values, with different layout.css.dpi values, and DPI + fullzoom different values.. at least works for me. (see bug 369684)

> >+    mAppUnitsPerDevPixel = (PRInt32)((float)mAppUnitsPerDevNotScaledPixel / aScale);
> You need to put in some protection so that mAppUnitsPerDevPixel is guaranteed
Ok.

> >+  CallChildren(SetChildFullZoom, &ZoomInfo);
> Hmm, do we really want zoom to propagate to children like that?  It seems like
> it could be useful to have distinct values for children, plus it'll be a pain
> to cancal out the zoom for a zoom implementation that scales the rendering
> context (which is definitely the plan).

May be, but now without this call page with [i]frames looks broken :(
http://www.w3schools.com/html/tryit.asp?filename=tryhtml_frame_cols

> >+  mFullZoom = mDeviceContext->GetPixelScale();
> Shouldn't be needed; the value should get set from the DocumentViewer.
You mean something like this:
void SetFullScale(float aScale) { mFullZoom = aScale; }
as it done here:
void SetPageScale(float aScale) { mPageScale = aScale; } ?


> You need to check whether the current frame is the root scroll frame.
> You also need a pref listener.
> 
Got it.

> With all that said, I'm not sure we want to take this at the moment, since a
> lot of it will have to change after bug 374980 fixed.
> 
May be ;),  why not, if you want... But anyway if somebody wants to test it, they can do it now with latest patch, I hope this patch will help to find/fix some FullZooming related bugs right now ...
And I can update it after fixing bug 374980 (which cause some problems with building for me now, but I will check...)
roc just said that bug 374980 is not going to make Gecko 1.9 (bug 374980 comment 6).
(In reply to comment #202)
> roc just said that bug 374980 is not going to make Gecko 1.9 (bug 374980
> comment 6).

Yeah; I don't really like it, but I guess that means we're going with device-pixel scaling.
(In reply to comment #199)

> With all that said, I'm not sure we want to take this at the moment, since a
> lot of it will have to change after bug 374980 fixed.


(In reply to comment #202)
> roc just said that bug 374980 is not going to make Gecko 1.9 (bug 374980
> comment 6).


So, does that mean that we DO "want to take this" now after all?

(In reply to comment #204)
> So, does that mean that we DO "want to take this" now after all?

Yes, we do want to take this, but it's not blocking the release. See the "[wanted-1.9]" keyword in the whiteboard and the blocking1.9- flag.
> So, does that mean that we DO "want to take this" now after all?

A fixed version, yes.
Now with IE7 having this working nicely, this really should block 1.9 release. Real people are ever frustrated by moronic web site designs that degrade to an unusable mess with text zoom or minimum font size enabled. People with average or slightly worse eyesight shouldn't need to use Opera or IE7 for all the web to be usable.
Hear, hear.  I can't believe this could be considered non-blocking at this stage in the game.  An 8-year old bug with this much attention by users and an area where most competing browsers (even IE!) is significantly more advanced?
I also think this should be finally fixed. If some one can help me to set up a test environment i'm delighted to test anything he/she can throw at me.
Someone has already setup an example using the SVG features.
Please stop it; spamming the bug doesn't help.
About how far away from a possible fix to this bug are the developers?  This bug gives me the creeps, if it is so hard to implement after 8 years of developing, doesn't that mean gecko is still built off of a core that is over 8 years old?  Almost like bug fixes are just skin deep, it seems so inefficient. It sends chills down my spine just thinking about it.
About how far away from a possible fix to this bug are the developers?  This bug gives me the creeps, if it is so hard to implement after 8 years of developing, doesn't that mean gecko is still built off of a core that is over 8 years old?  Almost like bug fixes are just skin deep, it seems so inefficient. It sends chills down my spine just thinking about it.
Sorry for the double post, bugzilla seems unresponsive today.
(In reply to comment #211 and #212, quoting comment #174)
> if the accidental double posting is all you find need to apologize for, you
> have issues :( have a cup of
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Q.F.E.

Comment on attachment 259615 [details] [diff] [review]
Fixed patch, (shistory, next page after zoomed)

Requesting review on this one. (Haven't been able to check for bitrot, update if necessary.) I think we *really* need to get this into 1.9.
Attachment #259615 - Flags: superreview?(sharparrow1)
Attachment #259615 - Flags: review?(sharparrow1)
Comment on attachment 259615 [details] [diff] [review]
Fixed patch, (shistory, next page after zoomed)

1. I'm not a super-reviewer.  It's completely inappropriate to ask me for sr.

2. I already reviewed the patch; see my earlier comments.

3. Don't try to volunteer someone else to do the work to fix it.  The proper procedure would be to post to m.d.t.layout asking if this should be made a priority for 1.9 and what needs to be done to make it happen.

4. Fixing both this bug and bug 130078 without compositor likely requires some significant hacking to views.

roc, any thoughts on 4?
Attachment #259615 - Flags: superreview?(sharparrow1)
Attachment #259615 - Flags: review?(sharparrow1)
Attachment #259615 - Flags: review-
Attached patch Updated patch (obsolete) — Splinter Review
Okay, here's a fixed-up version of the hack.  This patch makes Get/SetTextZoom forward to Get/SetFullZoom; that's obviously not going to be checked in, but it makes testing easier because no front-end hacking is required.  I'll leave adding front-end support to another bug.

The nsThebesImage change is a bugfix for an issue with rendering background images which becomes painfully obvious using page zoom.

Outside of that, my basic testing shows it to work reasonably well; no serious issues.  If anyone wants to test it, comments would be appreciated.

Known issues are that plugins might not scale the way you expect and there's a minor rounding issue with background image rendering.

Performance for changing page zoom should be approximately the same as that for text zoom.  The style re-resolve step can probably be sped up if it turns out to be an issue, especially after the fix for Bug 386640 goes in.

This is a little late in the 1.9 cycle to check in a change like this, but it's extremely low-risk, because the effect on the non-zoomed case is basically none.
Assignee: dbaron → sharparrow1
Status: NEW → ASSIGNED
Attachment #273186 - Flags: review?(roc)
Did you test the autoscroll icon? When I tried implementing this, the autoscroll icon would end up in the wrong place when you tried autoscrolling.
(In reply to comment #218)
> Did you test the autoscroll icon? When I tried implementing this, the
> autoscroll icon would end up in the wrong place when you tried autoscrolling.

Oops, yeah, the autoscroll icon is misplaced.  I'll have to take a closer look at it. (Hopefully it won't be too hard to fix; I know my way around the relevant code reasonably well.)
I have a fix for this that basically works, but I'm not very satisfied with it.  The issue is that we're using GetScreenX/Y to figure out the coordinates of an event, and the number returned is in scaled coordinates.  So my fix is to just make GetScreenX/Y return unscaled coordinates.  The reason this isn't really satisfactory is that it's a content-visible change, which I'm trying to avoid.

Another solution would be to add another method onto events that allows chrome to retrieve the appropriate coordinates.  That probably wouldn't be too hard, but I don't really want to make a new API unless we're sure there's no alternative.  roc, any thoughts?

(Note that this issue is inherent to any implementation of page zoom, not just an artifact of this hacky approach.)
How is chrome using screenX/Y? Should that usage also be happening in scaled coordinates? Seems to me that ideally content should never see or use unscaled coordinates. We may need to fix up stuff like the DOM screen APIs.
chrome is using screenX/Y to compute screen coordinates to pass to the popup manager (see popup.xml for example); however, screenX/Y computes screen coordinates using the scale factor of the document where the event was fired.

I just came up with another possible solution: I could make it so that screenX/Y varies depending on the current target for the event.  From the current target, I can get the prescontext and use the right conversion factor to come up with the correct screenX/Y.  This gives scaled coordinates to content listeners and unscaled coordinates to chrome listeners; it has an extremely hacky feel to it, though.
Oh dear. Hmm. It sounds OK to me I guess. Maybe you could collect wider feedback by posting to .layout or something?
What about a rawScreenX/Y for cases when unscaled coordinates are needed? That way, we can use getRawScreenX/Y for the autoscroll icon, and getScreenX/Y for everything else.
Or, we can just divide the output of getScreenX/Y by our active zoom ratio to get the unscaled coordinates.
Attached patch Updated patch v2 (obsolete) — Splinter Review
Okay, updated version with popups fixed. (I checked in the nsThebesImage changes separately.)
Attachment #273186 - Attachment is obsolete: true
Attachment #273872 - Flags: review?(roc)
Attachment #273186 - Flags: review?(roc)
+  virtual PRBool SetPixelScale(float aScale) = 0;
+  float GetPixelScale() const { return mPixelScale; }
+  PRInt32 UnscaledAppUnitsPerDevPixel() { return mAppUnitsPerDevNotScaledPixel; }

Document...

+    mAppUnitsPerDevPixel = (PRInt32)((float)mAppUnitsPerDevNotScaledPixel / mPixelScale);

constructor casts. Also, how about sharing this with SetPixelScale? You probably want to sanity check that mAppUnitsPerDevPixel is at least 1 after this.

+    if (aScale != 0.0 && mPixelScale == aScale)
+        return PR_FALSE;

Shouldn't we just abort immediately if aScale <= 0? With an assertion? And instead of checking the scales for equality, why not check the final mAppUnitsPerDevNotScaledPixel against the old value, so insignificant scale changes will return false here.

+    if (mPixelScale == 1.0)
+        mAppUnitsPerDevNotScaledPixel = mAppUnitsPerDevPixel;

Why?

+    printf("%d", mAppUnitsPerDevPixel);

Remove

You'll take out the Get/SetTextZoom changes before landing?

+  if (rootPresContext != this) {
+    NS_WARNING("Zoom set on non-root prescontext");
+    rootPresContext->SetFullZoom(aZoom);
+  }

Return here instead of just stomping on the face of the child prescontext

+  if (mDeviceContext->GetPixelScale() == aZoom)
+    return;

You get this optimization by checking the result of SetPixelScale already, so you should remove this.

Otherwise good.
http://mxr.mozilla.org/seamonkey/source/dom/src/base/nsScreen.cpp

We probably should also fix nsScreen to return unscaled coordinates. Perhaps we should add a method to nsPresContext that does screen-coordinate conversion so we encapsulate this decision in one place?
Attached patch Updated patch v3Splinter Review
I believe this addresses all the comments.  I'll make sure to take out the Get/SetTextZoom changes before landing.
Attachment #273872 - Attachment is obsolete: true
Attachment #273879 - Flags: review?(roc)
Attachment #273872 - Flags: review?(roc)
Comment on attachment 273879 [details] [diff] [review]
Updated patch v3

+  /**
+   * Set pixel scaling factor; it's a hacky but effective way to implement
+   * page zoom.  Returns whether the ratio of app units to dev pixels changed
+   * because of the scale factor.
+   */

You need to say what the pixel scaling factor means. I suggest

   * Set the pixel scaling factor: all lengths are multiplied by this factor when we convert them to device pixels.

Please file a bug on the nsScreen issue.
Attachment #273879 - Flags: superreview+
Attachment #273879 - Flags: review?(roc)
Attachment #273879 - Flags: review+
(In reply to comment #228)
> http://mxr.mozilla.org/seamonkey/source/dom/src/base/nsScreen.cpp
> 
> We probably should also fix nsScreen to return unscaled coordinates. Perhaps we
> should add a method to nsPresContext that does screen-coordinate conversion so
> we encapsulate this decision in one place?

It already does; it uses the base device context for the window.
Version updated to comments; I'm about to check this in.

For anyone who didn't really understand what was going on: this patch implements the backend support for page zoom.  This patch does not implement any UI.  This means you can't actually test it out until someone adds the appropriate UI to the frontend.  (This functionality is also accessible from extensions, so someone could also make an extension for testing.)
What were you using to test it?
for testing he tied full zoom to text zoom so that the text zoom UI would also drive full zoom. That's not going to be checked in, for obvious reasons.
Checked in.  UI implementation will go into another bug (possibly bug 112018).
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Eli, Roc, dbaron and all the contributors: Congratulations and a big "Thank you" for all your efforts. This was probably one of the top 10 wishes of a lot of moz developers and users. Great to see this marked as "FIXED". Cheers!
(In reply to comment #236)
> Eli, Roc, dbaron and all the contributors: Congratulations and a big "Thank
> you" for all your efforts. This was probably one of the top 10 wishes of a lot
> of moz developers and users. Great to see this marked as "FIXED". Cheers!
> 

We're not done yet ;) Only the backend work was landed, the UI to call that backend code still needs to be decided and implemented so you can use it. Plus there are probably still bugs.
Blocks: 389628
Depends on: 389659
You need to change the IIDs of the interfaces you are changing... _especially_ of the IDL ones, but also the .h one
Depends on: 389720
Updated IID for nsIDeviceContext and nsIMarkupDocumentViewer.
No longer depends on: 389720
Depends on: 389720
Depends on: 389794
No longer depends on: 389794
Depends on: 389824
Depends on: 389828
No longer depends on: 389828
The technet pages look really bizarre after zooming either in or out.

Install http://ted.mielczarek.org/code/mozilla/fullpagezoom.xpi and check with :
http://technet2.microsoft.com/windowsserver/en/library/a2df5eac-2cde-4a83-a181-d1b4eaa8232f1033.mspx?mfr=true

This may look like an evangelization bug, but as the characters don't change size, there seem to be a problem in the zoom function itself.
Shall we open a follow-up bug ?
(In reply to comment #240)
> The technet pages look really bizarre after zooming either in or out.

That page uses frames. There is already bug 389720 filed for it. I think that covers it. So I think you should wait and see if bug 389720 fixes it and then file a follow-up bug if you still see it.
No longer depends on: 389824
Depends on: 389769
Depends on: 389938
Depends on: 390039
Depends on: 390180
I tested it in the latest nightly. The main issue I have found is that the scroll bars don't slide smoothly hen dragging with the cursor. I'm not sure if this was a known issue, I just thought it might be helpful to bring this up. Great work guys!
(In reply to comment #242)
> I tested it in the latest nightly. The main issue I have found is that the
> scroll bars don't slide smoothly hen dragging with the cursor.

That's bug 389659; see https://bugzilla.mozilla.org/showdependencytree.cgi?id=4821&hide_resolved=1
Is there a bug for saving per-site zoom yet? Analogous to bug 378549.
(In reply to comment #244)
> Is there a bug for saving per-site zoom yet? Analogous to bug 378549.

Not yet, but we've been discussing it over in bug 389628.
(In reply to comment #246)
> Created an attachment (id=274838) [details]
> Zoom comparison between browsers.

That's bug 389628.

(In reply to comment #247)
> (In reply to comment #246)
> > Created an attachment (id=274838) [details] [details]
> > Zoom comparison between browsers.
> 
> That's bug 389628.
> 

I think the attachment is aiming on the upscaling quality of images and thats Bug381661 .
Why is that bug not marked as a blocker of this? Upscaling absolutely requires this if it is to look anyware near decent.
I wish I could delete that comment^^, I realize its phrased horribly.

What I meant to ask is shouldn't Bug 381661 be marked as a dependency?
(In reply to comment #250)
> What I meant to ask is shouldn't Bug 381661 be marked as a dependency?

Yes and added.
Depends on: 381661
I'm not sure if this is a browser bug or a problem in the way we are handling
zoom right now (getBrowser().mCurrentBrowser.markupDocumentViewer.fullZoom),
but when there's no document open (i.e. a new tab opens and the page is still loading, not when you are looking at about:blank) the zoom is applied to the whole chrome. I'm not experienced with the browser's JavaScript interface, so I don't know on what part of the above chain this happens, but was that really expected?
No, I don't think that's intentional; could you file a bug?
Depends on: 390970
Filed bug 390970.
I'm using Firefox 3 Alpha 7.

When I zoom the page, images does not go along.
I thought Alpha 7 is full-image-zoom ready, isn't it?
(In reply to comment #255)
> I'm using Firefox 3 Alpha 7.
> 
> When I zoom the page, images does not go along.
> I thought Alpha 7 is full-image-zoom ready, isn't it?
> 

There's no UI for it yet ; ctrl-+/- still uses the old text-zoom, without images. See bug 389628 for the UI, bug 389628 comment 19 contains a link to an extension that provides a temporary UI that you can use to test.
Took Alpha 7 for a spin with the full page zoom. Found that if you take any page (say www.cnn.com) and "minus" zoom enough times (~25 times), the page will turn black. If you click rapidly enough, you can get the browser to crash as well (otherwise pressing "normal" zoom, then refreshing recovers). Not something a "normal" user would experience, but I like trying to break things. Not sure where to report this (I'm still new to this whole bugzilla thing), but I didn't see it mentioned on any of the dependencies. 
(In reply to comment #257)
> Took Alpha 7 for a spin with the full page zoom. Found that if you take any
> page (say www.cnn.com) and "minus" zoom enough times (~25 times), the page will
> turn black. If you click rapidly enough, you can get the browser to crash as
> well (otherwise pressing "normal" zoom, then refreshing recovers). Not
> something a "normal" user would experience, but I like trying to break things.
> Not sure where to report this (I'm still new to this whole bugzilla thing), but
> I didn't see it mentioned on any of the dependencies. 

File a new bug in Core, Layout: Misc Code, and mark it as blocking this bug.
I guess you already know about this, but maybe a reminder is a good idea.

SVG documents like http://www.tapper-ware.net/devel/js/patience2/patience2.svg.php don't zoom at all... I'm not sure if this is actually part of this bug, but I think that a zoom interface should detect different content types and take the appropriate action.

Also, keep in mind that iFrames don't zoom so far... this is more serious than you can imagine as this breaks all pages that use adSense!
Also, keep in mind that there are a few elements which cannot be scaled, below a certain point... for example everything that's skinned by the OS (buttons, input lists, ...) and text... right now zooming out too far breaks everything as it requests a ridiculously small font size... there has to be a limit... 
And finally, I just tested this on my little Solitaire game... which simply crashes the whole browser as soon as I zoom in or out:

http://tapper-ware.net/patience/live/google-ig2.htm

My (uneducated) guess would be that I send FF in a death spiral because I handle window.onresize... but that's really just a guess.
Depends on: 391170
Depends on: 391494
Re "small font size", one could do the same as Adobe Reader and 'Greek' the text, but I have to admit this wouldn't be all that useful. Might convey the message though. On reflection, it might also be more trouble than it's worth.
I put a high value on zooming text to make it more readable, and on zooming graphics separately, but a zoom-everything would certainly be useful.
Depends on: 393648
Depends on: 398853
Keywords: helpwanted, uiwanted
Depends on: 401199
Depends on: 401203
Depends on: 401213
Depends on: 401222
I have a problem to zoom this page: http://starkravingfinkle.org/projects/demo/svg-bubblemenu-in-html.xml

I am not sure what is going wrong.
Can someone who is more experienced check if there is already a bug for this and if not file a new one(please cc me).

The testcase is from Mark Finkle’s Weblog.

Because it's SVG it should be bug 389769 and bug 370006.  And I'll repeat Eli's comment:

> Please hold off on filing more bugs about this until Bug 370006 gets fixed.
Depends on: 402548
Depends on: 402551
Depends on: 402843
Depends on: 403181
No longer depends on: 404830
Depends on: 405548
Depends on: 407495
Depends on: 403565
Depends on: 406577
No longer depends on: 406577
Verified on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2. 
Status: RESOLVED → VERIFIED
Why has this bug not been reopened? Another instance of the problem is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/178653
(In reply to comment #268)
> Why has this bug not been reopened?

Why it should?

> Another instance of the problem is
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/178653

Kernel ATA issues?



(In reply to comment #268)
> Why has this bug not been reopened?

This is marked fixed as of Firefox 3 alpha 8 (Mozilla 1.9 M8); the fact that it still exists in Firefox 2.0.0.x (Mozilla 1.8.1.x) doesn't mean it should be reopened.
Depends on: 410180
Depends on: 410186
Depends on: 376129
Flags: wanted1.9+
Whiteboard: parity-opera parity-IE7 [wanted-1.9] → parity-opera parity-IE7
Depends on: 413433
Depends on: 436278
Running version 3 Beta 2 in both WinXPsp2 and OSX 10.5.2. Works great for everything I do and need. Of course, getting the cataracts fixed in my eyes helps, but these old eyes still need help. Great work and Thanks.

Art
Version 3 (official) does not zoom the flash on my site. Here a testcase: http://jeenaparadies.net/t/fx3-flash-problem.html
(In reply to comment #273)
> Version 3 (official) does not zoom the flash on my site. Here a testcase:
> http://jeenaparadies.net/t/fx3-flash-problem.html

The object element has width="100%", which leads to bug 407495.
Other than that I think it's up to the flash plugin and eventually the flash content itself to fill the available space. Works as expected with Youtube videos.
Just simple jpg, gif etc. must in- and decrease in Mozilla.

Just look at http://www.raclette.nl/raclette/klassiek/help/herkomst.html simply use the <Ctrl> key on your keyboard and simult. the scroll wheel on your mouse. Try it in Mozilla, Opera and Explorer.
The pictures will de- and increase in Opera en Explorer, Mozilla however only modifies the text size. The background-size however stays the same, as expected and should.
Flash is another issue.

(In reply to comment #276)
> Just simple jpg, gif etc. must in- and decrease in Mozilla.
> 
> Just look at http://www.raclette.nl/raclette/klassiek/help/herkomst.html simply
> use the <Ctrl> key on your keyboard and simult. the scroll wheel on your mouse.
> Try it in Mozilla, Opera and Explorer.
> The pictures will de- and increase in Opera en Explorer, Mozilla however only
> modifies the text size. The background-size however stays the same, as expected
> and should.
> Flash is another issue.
> 

That's also because of a width="100%" (for Wallis.jpg), it must also be bug 407495.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.