Re: Cross origin communication and the navigator.connect API
On Tue, Dec 16, 2014 at 11:00 AM, Alex Russell slightly...@google.com wrote: On Mon, Dec 15, 2014 at 6:25 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell slightly...@google.com wrote: On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell slightly...@google.com wrote: One solution would be to at that point allow the SW from the other origin to install itself, which means that you can then just talk to it as a normal installed SW. However installing a SW could take significant amount of time. On the order of tens of seconds if the user is on a slow connection and the SW represent an app with heavy resources. I'm OK with it taking time. The discovery phase of a n.c() setup is async. This is along time though. I don't imagine these are the same SW's as the main app in the common case. As a result, these can (should?) be custom built, be lighter, and perhaps can communicate with the main app SW (if it's installed). Manually visiting these URLs seems, to me, to be about viewing an admin page for a service endpoint. So yes, install is at least one network RTT (probably several), but I'm not sure that's fatal. At least you can communicate what's going on (to the extent that you have UI up and running). This certainly sounds interesting, but I'm not sure how it fits with the current registration API. Presumably the SW which handles these requests (whether they come from a fetch() call or a .connect() call) would need to be atomically updated with the SW which handles the website itself. So the SW which handles facebook service calls would need to be atomically updated with the SW which handles facebook app UI. Additionally, SW is currently all about the scope argument. But it's not clear what scope you would use for a service SW. I think you'd want to have a scope like: https://example.com/services/name/v1/ As the scope for a SW hosted at: https://example.com/services/name/v1/service.js I'm not sure I understand. This seems like a new way to interpret SW scopes? How do these URLs relate to .connect()? Are these real URLs that actually are fetched over the network apart from the SW script itself? FWIW, I think this shows that basing SW registration entirely on scopes for pages that it serves is causing problems for other uses of SW. I'd definitely be interested to see a proposal which addresses these issues. We've been chatting about this and it feels like there's a pretty big design space that includes permutations of: postMessage/ports to/from a local SW a look-aside fetch() that is local only, e.g. doesn't go to the network if there isn't an existing SW to handle it a look-aside fetch() that could fault to the network if it isn't locally handled They don't seem exclusive, either. We could imagine making more than one of them available. Agreed. There's also an independent choice about the question of installation via headers. We're gonna write these up because it feels like it'd be useful to have some common understanding of the design alternatives. Looking forward to that. It ALSO seems like we should get together and talk with higher bandwidth. Perhaps some F2F time in January would be useful? Is that possible? I can't speak for others, but I'll be in SF in January. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Serious performance regression when setting the background of window to be transparent under win32.
On Tue, Dec 16, 2014 at 6:33 AM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: Please file a bug with a testcase that people can run (e.g. an add-on that creates such a tree on such a window) and look for a regression window using e.g. mozregression ( http://mozilla.github.io/mozregression/ ). It's not clear to me that this is a regression in the usual sense, i.e. the browser performs worse than it used to. If that's right, then mozregression won't be useful. But a test case will be useful! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
Right now, ImageLib provides very general support for multipart/x-mixed-replace images. Each part may contain a different image format (we may even switch between raster and vector images from one part to the next), individual parts may be animated, and each part may have a different size. This has major costs for us. Supporting existing images changing their size requires that layout and content code be aware of multipart/x-mixed-replace images, and requires us to use a design that’s suboptimal for the common case of MJPEG webcam content. Because these changes in size, type, and animation state prevent many invariants we’d like to have in ImageLib from holding, we either can’t assert some things we’d like to assert, or the assertions are quite tricky to write, which leads to more bugs and more maintenance headaches. There’s also just more and uglier code to maintain: over time hacks to multipart/x-mixed-replace have popped up in many places in Gecko, inside and outside ImageLib, and I’d like to remove them. And despite all of this effort, it’s not clear to me that our support is actually very robust, because outside of our limited test suite as far as I can tell nobody uses multipart/x-mixed-replace images for anything except MJPEG! I’ve had to change how multipart/x-mixed-replace is implemented in ImageLib to support other, more important, features. As part of this refactoring, I plan to pare down our support to the minimum required for MJPEG webcams: (1) The individual parts may only be JPEG images. Other formats will not be supported. (2) All of the parts must have the same intrinsic size as the first part - in other words, size changes will not be supported. In case it’s not clear, there’ll be no effect on other uses of multipart/x-mixed-replace elsewhere in the browser. These changes are specific to images and ImageLib. Making these changes will allow me to totally encapsulate MJPEG support inside ImageLib. Other code will see an MJPEG as just another type of animated image. Virtually all of the ugly consequences of our current multipart/x-mixed-replace image support will fall away. If anyone has any concerns about this change, please let me know. We should be fairly safe in doing this since non-MJPEG multipart/x-mixed-replace images are essentially never used, and multipart/x-mixed-replace itself is not universally supported anyway - IE does not even support MJPEG, much less the more general features that we provide. There also does not seem to be any specification that requires support for multipart/x-mixed-replace images at all, although HTML5 does specify multipart/x-mixed-replace support for documents. Thanks, - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
