548012 - Browser zoom should be cancelable to be handled by the webpage

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[:Felipe Gomes (needinfo for replies!)]

A browser zoom should be cancelable to be handled by a webpage to perform its own zoom routine (for example on maps or interactive games).  Maybe not all browser zooms (for example going through the View > Zoom menu), but at least the ones coming from zoom gestures.

Comment 1

[:Felipe Gomes (needinfo for replies!)]

Olli said that in DOM 3 there is an event called "magnify", but it fires after the zooming happened, and is not cancelable. A "beforemagnify" could be used.

Alternatively, this could be the case only for the zoom in the SimpleGesturesEvents, and we would only perform a zoom if it bubbles back without preventDefault() called.  AFAIK that's already the case, but these are not exposed to webpages.  I'll check.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This seems very open to abuse.  Why do we need this?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #0)
> A browser zoom should be cancelable to be handled by a webpage to perform its
> own zoom routine (for example on maps or interactive games).  Maybe not all
> browser zooms (for example going through the View > Zoom menu), but at least
> the ones coming from zoom gestures.
Note the gesture events should be cancelable and they do happen before zoom.

Comment 4

[:Felipe Gomes (needinfo for replies!)]

The main use case is for apps like maps or photo mash-ups on touchscreens. The main reason I brought it up is because when I show to friends the tablet pc running Google Maps for example, their first reaction is to try to zoom in the map by pinching, and instead they see only the text size of the page increasing. It seems very counter-intuitive.

It could be abused but this would only degrade the experience on the webpage. I don't think that an author would explicit want to block zooming on their page. (hmm maybe a bad webdesigner blocking the page so users don't realize their design can't handle zooms?)

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #4)
> The main use case is for apps like maps or photo mash-ups on touchscreens. The
> main reason I brought it up is because when I show to friends the tablet pc
> running Google Maps for example, their first reaction is to try to zoom in the
> map by pinching, and instead they see only the text size of the page
> increasing. It seems very counter-intuitive.
That happens because GMaps doesn't get (so it can't handle) our gesture events.
But it does handle DOMMouseScroll and overrides the default handling.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

(In reply to comment #5)
> That happens because GMaps doesn't get (so it can't handle) our gesture events.
> But it does handle DOMMouseScroll and overrides the default handling.

True. Do you recall what is reason for not exposing the SimpleGesture events?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Because they aren't standardized anywhere, and once we expose them to web,
people do start to use them.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

...which would mean that we'd might need to support them "forever"

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Perhaps we could expose them to web, since they do have the Moz prefix.
And maybe we could even add a warning to error console that
"non-standard-non-stable feature is being used".

Comment 10

[:Felipe Gomes (needinfo for replies!)]

(In reply to comment #7)
> Because they aren't standardized anywhere, and once we expose them to web,
> people do start to use them.

Oh, right. That's a good reason :)

(In reply to comment #9)
> Perhaps we could expose them to web, since they do have the Moz prefix.
> And maybe we could even add a warning to error console that
> "non-standard-non-stable feature is being used".

Yeah, this would be an alternative. I don't know if this cost for the intended use case is too big. I filed the bug to open the discussion on that. I'm building a list of possible enhancements for the touch experience, and if this gets considered valuable I'll revisit. Otherwise we can just wait for the official standard on gestures which will certainly cover this case.

Comment 11

[Willy_ Foo_Foo]

seems very open to abuse
Plus the user should have a control

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.