Re: Issue 30583 in chromium: Zoom level get/set API

chro...@googlecode.com

unread,

Jan 24, 2010, 3:33:17 PM1/24/10

to chromi...@chromium.org

Comment #4 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I would like to have this API to enable gesture-based zooming

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

chro...@googlecode.com

unread,

Feb 5, 2010, 6:34:11 PM2/5/10

to chromi...@chromium.org

Comment #7 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

It's not exactly what the original request was for, but here's a patch that
exposes
the tab zoom functions for use by extensions:

http://codereview.chromium.org/570048

No unit tests, but I can work on them if there's traction.

Here's a fork of smoothgestures that implements the API (see zoomapi
branch):

git://github.com/brson/smoothgestures-chromium.git

I use this to zoom on right click+scrollwheel.

chro...@googlecode.com

unread,

Feb 5, 2010, 8:34:58 PM2/5/10

to chromi...@chromium.org

Comment #8 on issue 30583 by scottfujan: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I support this addition to the extension api. There have been many requests
for this
feature to be added to Smooth Gestures, but I don't have access to a zoom
api to add
it.

There have also been requests for many other features that extensions don't
have
access to. Is posting a bug in this issue tracker the best way to address
it? Or are
patches to the extension system reasonable to get accepted? (I have not
been involved
in large-scale open source before)

chro...@googlecode.com

unread,

Feb 8, 2010, 6:30:02 AM2/8/10

to chromi...@chromium.org

Comment #9 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Hi,
despite the fact that zoom in Chrome 5 is much better, there is still no
such thing as a suitable GUI (necessary for tablets),
or text only zoom. In my opinion this can be done by extension writers.

I wrote the extension for AutoZoom Chrome 4 (~6500 users, shortlink:
http://go.szsz.pl/autozoom).
Unfortunately, without proper api's functionality is limited to tricks with
CSS.

chro...@googlecode.com

unread,

Feb 8, 2010, 6:49:34 AM2/8/10

to chromi...@chromium.org

Comment #10 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Hi,
despite the fact that zoom in Chrome 5 is much better, there is still no
such thing as a suitable GUI (necessary for tablets),
or text only zoom. In my opinion this can be done by extension writers.

I wrote the extension AutoZoom for Chrome 4 (~6500 users, shortlink:
http://go.szsz.pl/autozoom).
Unfortunately, without proper api's its functionality is limited to tricks
with CSS.

It would be great if extensions will have ability to interact with chrome
zoom and/or override it.
Ability to catch/cancel event from page will be even greater (think about
maps or image hosting)..

(sorry for doubleposting)

chro...@googlecode.com

unread,

Feb 15, 2010, 8:16:31 PM2/15/10

to chromi...@chromium.org

Comment #13 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Couldn't you just use the "zoom" property of CSS with a content script?

chro...@googlecode.com

unread,

Feb 15, 2010, 8:43:41 PM2/15/10

to chromi...@chromium.org

Comment #14 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

@aa css zoom isn't very good.
I'm using this css trick in AutoZoom extension and it's very problematic in
practice.
It doesn't work on iframes, there are also multiple problems with drag&drop.

I've checked this patch and it's look like good solution, even if its not
complete.
(for example it will require ability to register to "onZoomChanged" events)

chro...@googlecode.com

unread,

Feb 15, 2010, 9:56:37 PM2/15/10

to chromi...@chromium.org

Comment #15 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

@GrreenZZ - I see. Out of curiosity can you give some examples of the
problems with
drag&drop?

chro...@googlecode.com

unread,

Feb 15, 2010, 10:24:54 PM2/15/10

to chromi...@chromium.org

Comment #16 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

@aa You can easily check on every page using Drag&Drop
(Google Reader, and Google Calendar are the best examples of multiple
problems when using css zoom)

For simple test try this page
http://jqueryui.com/demos/draggable/default.html
You can change zoom level by entering javascript:document.body.style.zoom=2
in address bar

When you start dragging, you'll notice that the MouseMove event returns
coordinates using a screen resolution without
taking scaling into account.

Apart from this problem, using CSS in the extensions is also confusing to
the user, because it means introducing two
independent scaling mechanisms.

chro...@googlecode.com

unread,

Feb 22, 2010, 10:23:43 PM2/22/10

to chromi...@chromium.org

Comment #20 on issue 30583 by scottfujan: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I would not call the example above a bug. It is more the result of web
applications
that assume that the scale of their elements are consistent. This is
reasonable,
since usually websites have full control of their elements.

javascript:document.body.style.webkitTransform="scale(1.3)" also zooms and
works on
that page. But it has it's own problems. -webkit-transform transforms the
coordinates
of event.pageX, but it still doesn't transform event.clientX,
window.innerWidth,
document.width, etc. All of which could easily break things if set by an
extension.

And I see no way around this from a webkit design point of view.

Additionally, it doesn't make sense for an extension to create a whole new
zoom
control domain when one already exists -- probably confusing the user in
the process.

I can understand ignoring this bug if you think extension controlled zoom
isn't
important -- but I believe that it is _very_ important because it is one of
the most
requested features for my extension. And I think that an extension
dedicated to
actual browser-level zoom control could be awesome.

chro...@googlecode.com

unread,

Feb 23, 2010, 12:27:05 AM2/23/10

to chromi...@chromium.org

Comment #21 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I agree with @scottfujan, creating whole new zoom by extensions is _very_
confusing for the user.

Having perfect CSS, does not solve problem here... it is only one piece of
the puzzle.

Some users want to scale pages using ctrl +/- keys, other want to use GUI /
gestures because their Tablets simply have no
keyboard. Chrome5 remember zoom level for domains only (for unspecified
amount of time) and sometimes it is not sufficient.

chro...@googlecode.com

unread,

Feb 23, 2010, 8:51:47 AM2/23/10

to chromi...@chromium.org

Comment #22 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I think whole this discussion about Css was missleading and simple missing
the point.

So allow me clarify...

Using CSS for page zoom is not (what you called) "web platform api", it's
just a dirty hack.
It's a messing with webpage, if something goes wrong, there will be no
place to report bug. Just imagine this bug report: "Google
Reader/Mail/Maps/Calendar not working after changing CSS".

Without common API we will end with multiple independent implementations…
SmothScroll will have its own zoom, AutoZoom another… none of them will be
able to coexist.

Of course I can create external API for AutoZoom (for both web page and
extensions), why not? But I don't feel to be in position to
make this some kind of standard.

chro...@googlecode.com

unread,

Feb 26, 2010, 10:57:15 PM2/26/10

to chromi...@chromium.org

Comment #23 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Here are maybe my final thoughts on this issue. If an extension's zoom
doesn't behave
identically to the browser's zoom it defies user expectations.

These are the things I can think of that must behave like the browser:

*Page rendering - from what the posters above say this is a big concern

*Page behavior - not sure about how these zoom hacks might affect
scripting

*The zoom increment - extensions should zoom in and out by the same
amount as the
browser zoom

*The min and max zoom

*Zoom persistence - when the browser saves the zoom level we also need
to save
the extension's zoom level

chro...@googlecode.com

unread,

Apr 3, 2010, 9:55:58 PM4/3/10

to chromi...@chromium.org

Comment #24 on issue 30583 by qufighter: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

It's absolutely necessary to access the current user set zoom level via
javascript,
setting it is also kind of a nice feature but less of a must. An event
when this
changes is a must. There is no other suitable method for detecting this
that works
reliably or consistently. The example here breaks if you resize the
window, plus
relies on polling, and also breaks if you start the page at anything other
than the
default zoom level, so it's essentially useless, and only detects changes
from
default. Take the instance of using captureVisibleTab and trying to figure
out which
pixel the mouse pointer is over, without knowing the current page zoom this
becomes
impossible.

http://tests.novemberborn.net/browsers/gecko/fullzoom/percentages.html

CSS zoom is useless when what needs to be done is detecting the current
zoom of the
page that the user set. Also extension popup seem to get zoomed randomly
and there
is no way to control this. This is ESPECIALLY furstrating when they don't
size
themselves properly in the first place, and hard-coding a specific size is
required,
and then they get zoomed somehow and cease to function properly because the
auto
adjustment of size doesn't account for zoom.

chro...@googlecode.com

unread,

Jun 6, 2010, 10:58:05 AM6/6/10

to chromi...@chromium.org

Comment #25 on issue 30583 by kepicz: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I think that closing this bug isn't right. As qufighter said, we need this
functionality to be able to work with captureVisibleTab

chro...@googlecode.com

unread,

Aug 31, 2010, 8:07:40 AM8/31/10

to chromi...@chromium.org

Comment #29 on issue 30583 by Grree...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

It's the best news I have read today.
I'm going to update AutoZoom extension to use this api ASAP ;)

chro...@googlecode.com

unread,

Sep 6, 2010, 9:25:48 PM9/6/10

to chromi...@chromium.org

Comment #30 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

http://codereview.chromium.org/570048

I updated the previous patch to work with the latest source. This patch
only adds zoomIn(tabId) and zoomOut(tabId) functions. I'm looking at how to
implement get/set now.

chro...@googlecode.com

unread,

Sep 12, 2010, 2:51:30 AM9/12/10

to chromi...@chromium.org

Comment #32 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I'll be away for a week, but I've experimented with getting and setting the
zoom level. Set is implemented, get only partially. My git repo is:

git://github.com/brson/chromium.git

And my test extension:

git://github.com/brson/zoomapitest.git

chro...@googlecode.com

unread,

Sep 12, 2010, 7:58:22 PM9/12/10

to chromi...@chromium.org

Updates:
Labels: -Pri-2 Pri-1

Comment #33 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

(No comment was entered for this change.)

chro...@googlecode.com

unread,

Sep 13, 2010, 4:17:04 AM9/13/10

to chromi...@chromium.org

Comment #34 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Anders, can we change this to be more like getZoomLevel(), setZoomLevel()?
I think that would be more useful than zoomIn(), zoomOut().

chro...@googlecode.com

unread,

Sep 13, 2010, 7:19:00 AM9/13/10

to chromi...@chromium.org

Comment #35 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Yes. Do you have any other suggestions?

chro...@googlecode.com

unread,

Oct 10, 2010, 10:08:21 PM10/10/10

to chromi...@chromium.org

Comment #38 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I've uploaded another patch to http://codereview.chromium.org/570048, but
it's not close to finished. This patch eliminates zoomIn/Out methods in
favor of get/setZoomLevel. A negative zoom level indicates zoom percentages
less than 100%, and positive are greater than 100%.

I have some concerns.

* Should the zoom extension API be browser-oriented, tab-oriented, or
domain-oriented, or a mixture? The chrome internals have a bit of
everything: there are browser-level and tab-level zoom in/out/reset
commands, but the zoom level is also set on a per-domain basis, so zooming
one tab can trigger events in multiple tabs. My inclination is to make all
the extension methods tab-oriented.

* Setting the zoom level directly is a capability that the browser itself
doesn't have. The browser just does in/out/reset. This required adding a
new IPC message (ViewMsg_SetZoomLevel).

* Just being able to get and set the zoom level isn't enough to use zoom
correctly. Extensions also need to be able to know the minimum and maximum
zoom level and the zoom percentage. We can expose more extension functions
to provide that information, maybe getZoomPercent and getZoomLimits.

* I'm not sure the best way to provide a tabs.onZoomed callback. It's a
little tricky because zooming one tab may zoom multiple tabs, based on the
domain. There's already an IPC message, ViewHostMsg_DidZoomURL, that can be
used for this, but I'm not exactly sure how to get to each TabContents
object from the handler in resource_message_filter.cc.

Here's what's currently implemented:

chrome.tabs.getZoomLevel(tabId, function(tabId, zoomLevel) {...});
chrome.tabs.setZoomLevel(tabId, zoomLevel);

Other things that may be needed:
chrome.tabs.onZoomed(function(tabId, zoomLevel) {...});
chrome.tabs.getZoomPercent(tabId, function(tabId, zoomPercent) {...});
chrome.tabs.getZoomLimits(function(minZoomLevel, maxZoomLevel) {...});

chro...@googlecode.com

unread,

Oct 11, 2010, 5:59:34 AM10/11/10

to chromi...@chromium.org

Comment #39 on issue 30583 by mknart: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

My suggestion is to have text only zoom work like the full page zoom. That
is:

1. Check if there is a user zoom level for the domain.
2. If not, set to user default text zoom level.

Personally, I think zoom level per tab sounds confusing and a bit overkill.

Cheers
M.

chro...@googlecode.com

unread,

Oct 11, 2010, 1:36:05 PM10/11/10

to chromi...@chromium.org

Comment #41 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Ah, I didn't think of percentage! That seems like a much simpler
format to think in, right? Why don't we just make the API
setZoomPercentage/getZoomPercentage? It seems like the lowest-level
primitive, and therefore most flexible.

I think tab-oriented makes most sense. Browser and domain-level can be
implemented by extension developers in JavaScript.

That seems fine.

If we change the API to getZoomPercentage and setZoomPercentage, would
we need anything else? It seems like the limits can just be in the
documentation.

Yeah, providing an onZoom event looks more complex. You may want to do
that in a separate change.

ViewHostMsg_DidZoomURL() eventually ends up at ZoomHostMap
(chrome/browser/zoom_host_map.*) and that sends out a notificaiton
(ZOOM_LEVEL_CHANGED). Currently it doesn't send any details, but it
could send the URL and render_view_id. The extension system could
catch that. In the case of "temporary" zoom levels, you can just use
the render_view_id to get the associated tab contents.
(RenderViewHost::FromID(),
RenderViewHost::delegate()::AsTabContents()). In the case of
"permanent" zoom levels, you'll need to iterate through open tabs and
fire extension events in each that matches the specified URL.

One other question I thought of while looking at this code. The
internals have support for SetZoomLevelForCurrentURL() as well as
SetZoomLevelForLoadingURL(). This seems like something you may need to
take into account. It will be common for extension developers to call
setZoom() directly after getting a url change event. We don't want
them to have to wait until the page has loaded to set the zoom, as
that would lead to annoying flickering.

- a

chro...@googlecode.com

unread,

Oct 11, 2010, 1:48:20 PM10/11/10

to chromi...@chromium.org

Comment #42 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

+pkasting, who appears to be owner of the zoom functionality in Chrome.

Peter, please verify my suggestions are not crazy.

chro...@googlecode.com

unread,

Oct 12, 2010, 3:26:21 AM10/12/10

to chromi...@chromium.org

Comment #44 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

It looks like the code already deals with this because Plugins can
already set the zoom to arbitrary values. For example, see this
comment:

http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=chrome/renderer/render_view.cc;h=26739472c862be664ff285447e225e4388db1d7a;hb=HEAD#l4109

The 20% stepping logic seems pretty simple. I'm not too concerned
about developers who want to emulate it reimplementing it. It's like 3
lines of JavaScript, right?

That was the use case I had in mind. I don't think we should expose
the concept of zoom for a particular URL or anything (like I said
earlier, I think per-tab zoom is fine). I just meant that it should be
possible to call chrome.tabs.setZoom(tabId) when the tab is loading
and have it take effect once the load is complete.

HTH,

- a

chro...@googlecode.com

unread,

Oct 12, 2010, 8:17:45 PM10/12/10

to chromi...@chromium.org

Comment #45 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Thanks for working this through with me, Aaron.

The only code that can handle arbitrary zoom percentages is inside the
render process. Inside the browser process everything is done in terms of
zoom level. So we could do like the RenderView::OnZoom method is doing and
accept arbitrary zoom percentages, but report back to the HostZoomMap the
closest zoom level.

I'm not sure what all the consequences of that are, but at the very least
the HostZoomMap won't preserve the correct zoom level - the extension might
request 125%, but HostZoomMap would remember 120%. This doesn't apply to
plugins because they are special-cased to not remember the zoom level.
Also, setting the zoom for google.com to 125% in one tab would result in
other google.com tabs zooming to 120%.

It still looks to me that, to really be correct, allowing anything on the
browser side of the process boundary to use zoom percentages would require
changing all the zoom-related IPC and the HostZoomMap.

chro...@googlecode.com

unread,

Oct 13, 2010, 11:43:49 PM10/13/10

to chromi...@chromium.org

Comment #46 on issue 30583 by a...@chromium.org: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Np, sorry for being slow to respond.

I'm sorry to be obstinate here, but are you sure that zoomlevel can't
be non-integral? I haven't tried it, but looking at the code, I don't
see what would stop it. In fact, I thought I saw somewhere in the code
that plugins could already cause this to happen.

- a

chro...@googlecode.com

unread,

Oct 17, 2010, 6:10:44 PM10/17/10

to chromi...@chromium.org

Comment #48 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

mknart,

Remembering the text zoom level sounds like a reasonable feature to me. I
think it deserves its own bug ticket.

We need to keep in mind that any zoom extension api might need to support
text zoom as well. So far I've just been considering page zoom.

chro...@googlecode.com

unread,

Oct 17, 2010, 6:18:49 PM10/17/10

to chromi...@chromium.org

Comment #49 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

mknart again,

If per tab zoom is overkill, is there an alternative that you prefer?

chro...@googlecode.com

unread,

Oct 17, 2010, 6:30:54 PM10/17/10

to chromi...@chromium.org

Comment #50 on issue 30583 by qufighter: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

andersrb, that's a lot more data to store! If each domain you ever visit
has a float value stored with the 'exact' zoom percent that's a lot of data.

re window.devicePixelRatio it's interesting if a script reacts to these
values because it could create an infinite zoom conflict that keeps
resetting the zoom as the page also keeps resetting it's zoom to correct
for the user's specified zoom, then the float value will loop at some
point, and the user will have to scroll a lot to see anything since it's
zoomed to an insane amount.

The nice thing about the settings now is that at least there are a finite
number of zoom possibilities enforced that are also rather tiny to store
the most common ones.

chro...@googlecode.com

unread,

Oct 17, 2010, 8:43:40 PM10/17/10

to chromi...@chromium.org

Comment #51 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

aa, I think you're right. Zoom levels are handled as doubles even though
they appear to almost always be integral, so maybe allowing fractional zoom
levels is ok.

qufighter, the mechanism to store zoom level looks like it already uses
doubles, so I don't know if storage space is a concern. I do agree that
keeping zoom limited to a few levels is attractive.

chro...@googlecode.com

unread,

Oct 18, 2010, 2:26:14 AM10/18/10

to chromi...@chromium.org

Comment #52 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I posted a new patch. In this one the extension functions are defined:

chrome.tabs.getZoomPercent(tabId, function(tabId, zoomPercent) {...});

chrome.tabs.setZoomPercent(tabId, zoomLevel);

When setting the zoom to less than 50 or greater than 300 it is silently
limited. Setting the zoom to a negative value does nothing.

chro...@googlecode.com

unread,

Nov 5, 2010, 10:57:10 PM11/5/10

to chromi...@chromium.org

Comment #53 on issue 30583 by downchuck: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Did you expose chrome.tabs.getZoomPercent to all extensions? Does it
require tabs permissions? It doesn't seem like a security risk to allow an
untrusted site to get the current zoom level on its window. But that said,
privacy concerns have come up before with a11y.

chro...@googlecode.com

unread,

Nov 7, 2010, 7:16:15 PM11/7/10

to chromi...@chromium.org

Comment #54 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

It currently requires tab permissions.

chro...@googlecode.com

unread,

Nov 14, 2010, 7:00:18 PM11/14/10

to chromi...@chromium.org

Comment #55 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Aaron,

Not sure if you saw the most recent patch I posted two weeks ago, but it's
there.

I'm not feeling so confident about the direction it's going though. Most of
my concerns are about how complicated the asynchronous interactions are
getting and whether they are correct. The current patch seems to work for
getting and setting the zoom percentage, though I think it potentially
generates a fair amount of new zoom-related IPC traffic on page load. Also,
correctly duplicating zoom in/out in an extension by explicitly setting the
zoom percentage requires duplicating much of chrome's zoom logic (90 lines
of verbose JavaScript).

I also suspect that it reports the wrong zoom level for full-page plugins,
though I haven't tested it because I don't know how to get such a plugin
(on Linux).

The Flash crashes I reported in the code review were just typical Flash
suckage, not a regression.

I've taken a stab at exposing a per-tab zoom event but haven't succeeded
yet. What makes it difficult is that the UI can only request a page zoom,
but doesn't know if it actually succeeds until the render process responds.
If the zoom did succeed then the UI moves forward with zooming all the
other tabs for that same URL, and we have to wait again to know if they
succeeded. My first attempt sometimes resulted in infinite message loops. I
fear that it will require even more extensive restructuring to get
something that works correctly and preserves existing behavior, but so far
I haven't thought of anything that isn't full of ugly.

This patch has gotten a lot more complicated than my original zoom in/out
use case and I admit I've lost some motivation.

Any suggestions?

Regards,
Brian

chro...@googlecode.com

unread,

Nov 19, 2010, 4:25:00 PM11/19/10

to chromi...@chromium.org

Comment #56 on issue 30583 by downchuck: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

getZoomPercent is something that should be made available through the DOM.
http://msdn.microsoft.com/en-us/library/ms533721(VS.85).aspx

Things considered, setZoom is something that's already available in
practice.
document.body.style.zoom = 2

With that in mind: How about implementing the .screen extensions that MS
has proposed, and getting rid of this .tabs extension?

http://msdn.microsoft.com/en-us/library/ms535868(v=VS.85).aspx

Logical/device DPI always allow me to test the zoom ratio relative to the
device pixels.

They're very quick to implement into window.screen, already present in IE9
PR, and being proposed in the w3c process as fix to an accessibility
issue/defect.

Thoughts?

chro...@googlecode.com

unread,

Nov 19, 2010, 4:49:18 PM11/19/10

to chromi...@chromium.org

unread,

Nov 24, 2010, 7:28:37 AM11/24/10

to chromi...@chromium.org

Comment #63 on issue 30583 by downchuck: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

I agree, that a simple zoom API should be exposed to extensions. I feel
like it's not necessary to have "tab" permissions. Zoom is set and
remembered on a per-domain basis: needing "tab" permissions is overkill.

Sorry if I caused confusion there. I do understand that body.zoom has a
collection of issues, and I do think the getZoom/setZoom semantics are fine
as they relate to browser extensions.

I'm still pushing within the WHATWG mailing list, to see if there's room
for agreement on the DPI issues I'm facing. Mozilla insists that they've

implemented and change window.devicePixelRatio during zoom in FF4. I

haven't tested this yet. MS is pretty firm about their window.screen
object. The MS method allows different X and Y scaling, which may make some
sense in the long term.

One item that again, I couldn't quite clear up is the behavior of
window.innerWidth vs window.outerWidth. That's how I currently grab zoom in
Chrome (which breaks of course, if there's a side bar). I compare
innerWidth, which gets smaller with zoom, as it's in css pixels, to
outerWidth, which is measured in screen pixels.

I still believe MS has covered all the bases, by exposing so much data. Moz
sees following suit as a liability. I can't get them to budge on that end.
I haven't contacted Apple nor WebKit upstream.

So, that's the current status on my end.

Would one of you be willing to file a bug report with WebKit upstream
bringing up the question as to whether a "zoom" event should alter
window.devicePixelRatio ? They seem like a reasonable bunch, and may have
good input on the issue.

Thanks for keeping up on this.

-Charles

(sorry if my posts caused dupes/email notices; had some editing issues).

chro...@googlecode.com

unread,

Nov 27, 2010, 2:52:27 PM11/27/10

to chromi...@chromium.org

Comment #64 on issue 30583 by downchuck: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Following up:

The current getZoomPercent/setZoomPercent proposal looks good to me. This
thread has gotten a bit lengthy, and I regrettably didn't read through it
before posting. Having done that, in a more responsible way, I'd say that
the main issue here is documentation. As long as we have due documentation
(regarding the "20%" increments, and so forth), I think it's good to go.

I've hit a dead end with the WHATWG mailing list on trying to expose the
current zoom level via a public getter. Mozilla has refused to expose the
data to an untrusted scripting context: that is, they only allow access to
it from browser extensions. Because of that, the WebKit development group
is going to have to wait and see what comes of the w3c process.

Sharing that information to let you know, that my concerns are best left to
a future bug report, which I'll file when there's a change in the
specs/standards.

What's the status on getting this Zoom set/get API patch into a milestone
schedule?

chro...@googlecode.com

unread,

Nov 29, 2010, 12:11:10 AM11/29/10

to chromi...@chromium.org

Comment #65 on issue 30583 by andersrb: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Patch 7 is up for code review. I think this one is nearly ready for
inclusion. The functions are now defined:

chrome.tabs.getZoomPercent(tabId, function(zoomPercent) {...});
chrome.tabs.setZoomPercent(tabId, zoomPercent, function(zoomPercent) {...});

With setZoomPercent returning the resulting zoom percentage in a callback.

chro...@googlecode.com

unread,

Dec 14, 2010, 8:22:55 AM12/14/10

to chromi...@chromium.org

Comment #67 on issue 30583 by mar...@djernaes.dk: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Are there any plugins which can make the zoom level tab dependent? I really
don't like the zoom level to be depending of what I look at, but rather
what screen I view it on (dual screen setup).

chro...@googlecode.com

unread,

Dec 16, 2010, 1:48:38 PM12/16/10

to chromi...@chromium.org

Comment #70 on issue 30583 by downchuck: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Issue #31763 (side tabs) will break the hack I currently use to get css
pixel ratios: ((window.outerWidth-16) / window.innerWidth)

Issue #66656 brings something of a fix for detecting ratios properly.

chro...@googlecode.com

unread,

Dec 21, 2010, 1:32:33 PM12/21/10

chro...@googlecode.com

unread,

Dec 27, 2011, 3:12:59 AM12/27/11

to chromi...@chromium.org

Comment #87 on issue 30583 by keithtar...@gmail.com: Zoom level get/set API
http://code.google.com/p/chromium/issues/detail?id=30583

Web pages are typically written by people who have no idea what it is like
to be middle aged and have presbyopia (age related far sightedness).

Yes when I was young I could see 1024/768 and a 14" monitor (a really big
monitor back in the late 1980s), but now at age 57 I'm constantly zooming.

So we need a simple zoom tool that remembers on a site-by-site basis,
independent of tabs.

Weird fixes, I've been in IT for 35 years and I suppose I could figure them
out. But I'm a rarity. You need something that works for completely
non-technical people without the need for them to go searching high and
low, without the need for them messing around with configuration files.

Sadly applications are the same way, but that is beyond the scope of your
project, except to say that if you use Windows7's (or WindowsXP's) DPI
scaling the applications won't work, the tags will overflow and be
truncated, which rules what could be part of the problem out. (Of course
no zooming by Windows is going to be customizable to web page anyways.)

That is my 2 cents worth as a fairly new Chrome user.

Firefox has "no squint" and it works well. It is what Chrome has to
compete with.

chro...@googlecode.com

unread,

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@277153
0039d316-1c4b-4281-b951-d872f2087c98

chro...@googlecode.com

unread,

Jul 5, 2014, 3:10:02 PM7/5/14

to chromi...@chromium.org

Comment #113 on issue 30583 by bugdro...@chromium.org: Zoom level get/set
API
http://code.google.com/p/chromium/issues/detail?id=30583#c113

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/63d1f9b9a1fb0e67739fdfe59d4aa5a978bf95ac

commit 63d1f9b9a1fb0e67739fdfe59d4aa5a978bf95ac
Author: wjma...@chromium.org
<wjma...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Sat Jul 05 19:09:03 2014

Implementation of a Zoom Extension API as an addition to the chrome.tabs
API, as outlined in
https://docs.google.com/a/chromium.org/document/d/1sCZjx1J3_M2a02T8NXd-ufGKZDoBHI5Ixis1DaGLQCA/edit?usp=sharing.

Based on code from https://codereview.chromium.org/232773011/, with various

fixes and rebased against changes in
https://codereview.chromium.org/287093002/

Depends on changes in https://codereview.chromium.org/302603012/

BUG=30583

Review URL: https://codereview.chromium.org/301733006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@281468

chro...@googlecode.com

unread,

Jul 5, 2014, 3:12:04 PM7/5/14

to chromi...@chromium.org

Implementation of a Zoom Extension API as an addition to the chrome.tabs
API, as outlined in
https://docs.google.com/a/chromium.org/document/d/1sCZjx1J3_M2a02T8NXd-ufGKZDoBHI5Ixis1DaGLQCA/edit?usp=sharing.

Based on code from https://codereview.chromium.org/232773011/, with various
fixes and rebased against changes in
https://codereview.chromium.org/287093002/

Depends on changes in https://codereview.chromium.org/302603012/

BUG=30583

Review URL: https://codereview.chromium.org/301733006

-----------------------------------------------------------------

chro...@googlecode.com

unread,

Jul 7, 2014, 4:21:43 PM7/7/14

to chromi...@chromium.org

Updates:
Status: Fixed

Comment #116 on issue 30583 by wjmacl...@chromium.org: Zoom level get/set
API

http://code.google.com/p/chromium/issues/detail?id=30583

(No comment was entered for this change.)

chro...@googlecode.com

unread,

Aug 23, 2014, 6:46:38 AM8/23/14

to chromi...@chromium.org

Comment #119 on issue 30583 by jur...@juriansluiman.nl: Zoom level get/set
API
https://code.google.com/p/chromium/issues/detail?id=30583

Like #117, I am also looking for an API method to change the default zoom
level. It has a different use case, more explained on SO
(http://stackoverflow.com/questions/25413424/access-default-zoom-level-from-google-chrome-api).

Is there any progress on this aspect?

chro...@googlecode.com

unread,

Aug 25, 2014, 10:12:37 AM8/25/14

to chromi...@chromium.org

Comment #120 on issue 30583 by wjmacl...@chromium.org: Zoom level get/set
API
https://code.google.com/p/chromium/issues/detail?id=30583

I'm in the process of landing a CL that (amongst other things) decouples
default zoom in an app/webview from that in the main browser. Once the CL
lands, then presumably it should be relatively easy to add it to the API.
One caveat: the webview would need to be in its own storage partition so
that changes to its default zoom level don't affect the default in other
webviews.

The CL is here: https://codereview.chromium.org/393133002/

chro...@googlecode.com

unread,

Aug 26, 2014, 11:30:30 AM8/26/14

to chromi...@chromium.org

Comment #122 on issue 30583 by Nak...@gmail.com: Zoom level get/set API
https://code.google.com/p/chromium/issues/detail?id=30583

Oh I got it: https://developer.chrome.com/extensions/tabs#method-setZoom

Reply all

Reply to author

Forward