Closed Bug 775456 Opened 13 years ago Closed 3 years ago

Let "apps" opt-in to asynchronously-panned frames

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Project Flags:
blocking-kilimanjaro ?
blocking-basecamp -

People

(Reporter: cjones, Unassigned)

References

Details

(Whiteboard: [tech-p1])

The motivating use-case here is, in something like the Gaia Contacts and Settings apps, we have large unbounded boxes of scrolled content. If we're careful enough we can keep synchronous repainting at 60fps, but it's much easier to use the more general and reliable machinery we have for async panning. In the initial landing of async pan/zoom, we only enabled it for "browser tabs", because in general it interferes with apps that want tight control over their rendering and event handling. This is especially bad for full-window games that use 2d canvas. Webkit has enabled support for this through the CSS rule |-webkit-overflow-scrolling: touch|. The semantics are pretty much what we want here. I don't have much of an opinion on the CSS interface.
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
We discussed this at triage. We decided it's a nice to have but not a blocker.
blocking-basecamp: ? → -
Syntax proposal: overflow: -moz-pan-zoom.
Two Q's from the perspective of the e-mail app: 1) Will this work at all levels of DOM hierarchy? Specifically, e-mail puts HTML e-mails in an iframe, and we would want the contents of that iframe to pan and zoom somehow. 2) Would there be a way to specify an initial zoomed-out state/level of zoom? For HTML e-mails of the newsletter variety, a width of 600px is assumed, but our initial device only has 320px. The current (not yet landed) manual approach forces an iframe width of 600px and uses a 'transform' to scale, starting out zoomed out so the entire width of the e-mail is visible. The gaia UI issue for this is https://github.com/mozilla-b2g/gaia/issues/3022.
Similar to bug 775452, needed to support major content use case, and competitive parity issue.
Whiteboard: [tech-p1]
(In reply to Andrew Sutherland (:asuth) from comment #3) > 1) Will this work at all levels of DOM hierarchy? Specifically, e-mail puts > HTML e-mails in an iframe, and we would want the contents of that iframe to > pan and zoom somehow. Yes. > 2) Would there be a way to specify an initial zoomed-out state/level of > zoom? For HTML e-mails of the newsletter variety, a width of 600px is > assumed, but our initial device only has 320px. The current (not yet > landed) manual approach forces an iframe width of 600px and uses a > 'transform' to scale, starting out zoomed out so the entire width of the > e-mail is visible. AFAIK -webkit-overflow-scrolling:touch doesn't support zoom. We could easily allow it here though. In bug 775452, we'll need to explicitly *turn off* zoom by default for scrollable subframe.
Actually, I take that back. Email would use this for scrolling the list of messages, in which case zoom isn't desired. The display of HTML messages would want to use <iframe mozbrowser remote asyncpanzoom>, which is zoom-enabled by default. That needs bug 761935 though.
The remaining work here is to pick a semantics and syntax (mostly how closely we want to follow webkit), and then plumb that through the style system. The hookup to bug 775452 is pretty simple after that. Option 1: |-moz-overflow-scrolling: touch|. But then we have to prepare to spec it. Option 2: Something like |overflow: [-moz-pan | -moz-zoom | -moz-pan-zoom]|. Breaks from webkit but makes more sense IMHO, since this "mode" makes sense on desktop when controlled by mice too.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #6) > Actually, I take that back. Email would use this for scrolling the list of > messages, in which case zoom isn't desired. The display of HTML messages > would want to use <iframe mozbrowser remote asyncpanzoom>, which is > zoom-enabled by default. That needs bug 761935 though. I'm getting very off-topic for this bug or that bug now, we'll probably want a more specific bug for e-mail's use case. But if you can provide a strategy suggestion so I know what bug to file or not file: We want to keep HTML e-mails pretty inert. Right now we keep our iframe in our same origin so that we can manipulate its DOM and add click event handlers on links; I assume once we go remote that our ability to do things like that is gone or maybe strongly inadvisable. We do the former so that we can rewrite disabled 'img' tags to either reference external URLS *or* Blob createObjectURL's from embedded images that we downloaded. We could probably just re-write a new document if images get turned on and use data URLs for the embedded images. Click handling seems harder. We currently prompt the user to make sure they want to follow a link providing the explicit URL. This both avoids "oh no, I only accidentally touched that link, don't start-up the browser!", as well as providing some anti-phishing capabilities since the link that says "your bank account" would get a prompt that shows the pretty suspicious looking URL. We could also re-write the document itself to just include some JS that postMessage's back to us, but we ideally we not be turning on JS in the e-mail iframe at all. Unless we could maybe use CSP in the iframe in such a way that only our click-handling shim is authorized and all inline JS is still disabled...?
It would be nice to find a solution that gives us the best of both worlds, because currently loading large email threads will jank the UI for seconds at a time. I have one in my inbox that made the UI unresponsive for around 10 seconds.
Chris, is it possible that you could forward me a copy of the e-mail, preferably as an attachment (rather than inline), so I could look at it and see if there's any mitigation we might be able to apply in the sanitizer like engaging in destructive DOM simplification? We're currently trying to put the sanitizer on the worker thread (with ongoing discussion with the security team), which gets rid of one instance of the synchronous HTML parsing. But it still leave the synchronous innerHTML assignment when we display the message. That too might also be able to be mitigated if we are able to let the HTML parser go async, like handing it a createObjectURL?
I can, but it has some internal information so please keep to yourself. /pm me with the address you'd like it sent to. (I don't know how to send as attachment in zimbra, but I can send as "edit as new".) We should also split this into another bug ;).
(In reply to Chris Jones [:cjones] [:warhammer] from comment #7) > Option 1: |-moz-overflow-scrolling: touch|. But then we have to prepare to > spec it. > > Option 2: Something like |overflow: [-moz-pan | -moz-zoom | > -moz-pan-zoom]|. Breaks from webkit but makes more sense IMHO, since this > "mode" makes sense on desktop when controlled by mice too. Also relevant: the touch-action CSS property from the new Pointer Events spec, possibly with some additional -moz values: http://www.w3.org/TR/pointerevents/#the-touch-action-css-property See also discussion in http://www.w3.org/2013/01/22-pointerevents-minutes.html
Looks like it's on the track of what we want. I would differentiate "pan" from "scroll" in that "pan" may not fire onscroll at content for each offset made by the UA when redrawing, and may show unrendered areas transiently (that's an impl detail though).
I believe this bug has some overlap with bug 909877 but I'm not sure if there's an actual dependency or if we should dupe it.
See Also: → gaia-apzc
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.