Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-24 Thread Brady Eidson

 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.1% 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


Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-24 Thread Alexey Proskuryakov

24 апр. 2015 г., в 9:06, Brady Eidson beid...@apple.com написал(а):

 Killing the feature would lead to a confusing experience for such users.

Additionally, I think that outright killing multipart main resources would 
cause unnecessarily confusing experience for WebKit developers. One of the 
first things we do when a resource is not displayed correctly is open it in in 
a new window.

It definitely seems appropriate to limit what we claim to support, making the 
main resource code path more like the subresource one, and removing code 
complexity along the way.

Anyway, the evidence of someone on the WebKit team being affected by this as a 
user seems like a fairly strong argument in this case.

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-23 Thread Anders Carlsson

 On Apr 23, 2015, at 1:19 PM, Brady Eidson beid...@apple.com wrote:
 
 
 On Apr 23, 2015, at 1:11 PM, Chris Dumez cdu...@apple.com 
 mailto:cdu...@apple.com wrote:
 
 
 
 On Apr 23, 2015, at 1:07 PM, Brady Eidson beid...@apple.com 
 mailto:beid...@apple.com wrote:
 
 
 On Apr 21, 2015, at 3:39 PM, Chris Dumez cdu...@apple.com 
 mailto: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.1% 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.
 
 Yes, my proposal would break MJPEG as main resource. MJPEG is the main user 
 of 'multipart/x-mixed-replace’ I believe. If we do want to keep supporting 
 it, then we should probably fix support on both Mac (keeps recreating the 
 ImageDocument) and iOS (Only shows the first frame).
 
 I think fixing those two known and obvious issues is a great idea. If there’s 
 bugzillas on them I’d like to be CC’ed (same for Radars)
 
 Thanks,
  Brady

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.

- Anders


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-23 Thread Brady Eidson

 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.1% 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.

Thanks,
 Brady

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-23 Thread Maciej Stachowiak

 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.1% 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.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-21 Thread Chris Dumez
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.1% 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.

[1] https://code.google.com/p/chromium/issues/detail?id=249132 
https://code.google.com/p/chromium/issues/detail?id=249132
[2] https://bugs.webkit.org/show_bug.cgi?id=143979 
https://bugs.webkit.org/show_bug.cgi?id=143979
[3] http://src.chromium.org/viewvc/blink?view=revisionrevision=152363 
http://src.chromium.org/viewvc/blink?view=revisionrevision=152363

Kr,
--
 Chris Dumez - Apple Inc. - Cupertino, CA




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-21 Thread Adam Barth
For what it's worth, we didn't receive any negative feedback from
users or developers when we dropped support for this feature in
Chrome.

Adam


On Tue, 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.1% 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.

 [1] https://code.google.com/p/chromium/issues/detail?id=249132
 [2] https://bugs.webkit.org/show_bug.cgi?id=143979
 [3] http://src.chromium.org/viewvc/blink?view=revisionrevision=152363

 Kr,
 --
  Chris Dumez - Apple Inc. - Cupertino, CA





 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev