> On Dec 17, 2014, at 10:08 PM, James May <m...@fowlsmurf.net> wrote: > * Is there telemetry for this?
There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. > * I'm assuming this is for all of <img>, <object>, top level documents (and > css src()? was that ever supported?) This wouldn’t change the behavior of top level documents, which are handled by other code. The only special case code for loading multipart image documents we have is a hack in nsDSURIContentListener to avoid replacing the document for every part in the case of MJPEG streams. That’s necessary to avoid flicker, and it will stay since we’re continuing to support MJPEG. > * What is the end user experience? > * In the case of differing formats - The first image displaying and then a > broken image icon? The presentation is different depending on the context in which the image is used, but we will treat non-JPEG parts as broken, yes. Even the first part. (We know that we’re dealing with a multipart/x-mixed-replace image as soon as we start receiving data.) > * Differing dimensions - image is scaled to first image's dimensions? Are > scaling CSS hints (aspect, interpolation mode) applied? Parts with differing intrinsic sizes will be treated as broken. I don’t want to encourage people to use them. (And nobody does, in any case.) > I can imagine at least a small "loading" first frame might be sent followed > by actual camera images. That’s not what happens in practice. Generally the MJPEG stream is just a sequence of shots from the webcam. Any other UI or context like a “loading” screen is usually built using other techniques. Thanks, - Seth _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
