> On Apr 23, 2015, at 2:38 PM, Maciej Stachowiak <m...@apple.com> wrote: > > >> On Apr 23, 2015, at 1:07 PM, Brady Eidson <beid...@apple.com> wrote: >> >> >>> On Apr 21, 2015, at 3:39 PM, Chris Dumez <cdu...@apple.com> wrote: >>> >>> Hi, >>> >>> I would like to suggest we remove support for 'multipart/x-mixed-replace’ >>> main resources while keeping support for multipart images. >>> >>> Based on Chrome usage data, this feature is extremely rarely used by Web >>> sites (less than 0.00001% of page loads) [1]. This feature adds complexity >>> to the loader and is a source of (security) bugs (e.g. [2] recently), >>> current support also seems buggy. >>> >>> Current support in Safari / WebKit: >>> - Support is not great is WebKit. If you load a Motion JPEG main resource >>> for example, it will keep creating a new ImageDocument and all its DOM tree >>> for every frame (tested on Safari / Mac). >>> - It looks like support is broken on Safari on iOS (I tried a Motion JPEG >>> main resource on iOS8, I see the first frame then a blank page that never >>> finishes loading). >>> >>> Other browsers: >>> - Never supported by IE (including IE11) for any resource >>> - Chrome already dropped support for this (main resources only) almost 2 >>> years ago [3]. >>> - Firefox 37 still supports this based on local testing. >>> >>> Again, I am only proposing dropping support for main resources. For e.g., >>> having an <IMG> element in a page whose src attribute points to a Motion >>> JPEG would still work as intended. >> >> I think it’s fine to drop support for multipart main resources besides MPJEG. >> >> I think loading MJPEG as a main resource and having it be displayed as an >> ImageDocument is a valuable feature, and I object to dropping support for >> it. I’m not sure if that’s what you’re proposing, since it’s both a main >> resource and a multipart image. >> >> I think you might have filed a bug about the new ImageDocument per frame, >> thought I can’t find it right now. I think fixing that bug is a better >> solution than dropping that support. > > Does this feature have non-negligible actual use in the wild? There are far > better ways to do streaming video, so I think we only need to treat this as a > legacy feature, and only support it if use warrants it.
I’d wager “sites in the wild” are the fraction of a fraction of a percent mentioned above. I use a web cam at home most evenings whose “view live video” link takes you directly to an MJPEG main resource when you’re on a Mac, based on the assumption that the default browser on the platform supports it. Was that a poor design decision on their part? Yes. Can they fix it now? No. Killing the feature would lead to a confusing experience for such users. > On Apr 23, 2015, at 1:44 PM, Anders Carlsson <ander...@apple.com> wrote: > > Given that so few browsers support this I think we should get rid of this > feature; it would let us simplify the loader code significantly. I can think of a handful of ways to kill the general “multipart main resource” feature - which is allegedly supported in the code but not *really* supported - and still maintain the ability to have ImageDocument specifically support this one use case. Thanks, Brady _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
