Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-13 Thread Gervase Markham
On 12/03/15 16:04, Seth Fowler wrote:
> It looks like it doesn’t anymore, because it works fine in Chrome.

It does; it browser-sniffs.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-13 Thread Kyle Huey
On Thu, Mar 12, 2015 at 4:43 PM, Ehsan Akhgari 
wrote:

> On 2015-03-12 6:54 PM, Kyle Huey wrote:
>
>> I've been meaning to rip out the putative support for this from XHR (and
>> all of the complexity that it introduces) for months now.  This would be
>> great.
>>
>
> Henri beat you by two years.  ;-)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=843508
>
>
Nice.  We still have the ridiculous lifetime management in the worker code
that has been the bane of my existence for several years though.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Seth Fowler
On Mar 12, 2015, at 4:42 PM, Boris Zbarsky  wrote:
> 
> On 3/12/15 6:37 PM, Seth Fowler wrote:
>> They made main resources that use multipart/x-mixed-replace trigger 
>> downloads instead of being displayed.
> 
> So what gets downloaded is the entire mixed stream, right?

You know, that’s what the Chromium issue says, but I just tried it and nothing 
happens. I just get an empty page. Safari downloaded the last part and opened 
it in Preview. Only Firefox displays it in the tab. (So that makes Firefox the 
*only* remaining browser to support this stuff.)

Here’s the page I was testing with:

http://blog.dubbelboer.com/2012/01/08/x-mixed-replace.html 

>> The observation that multipart/x-mixed-replace support introduces a lot of 
>> complexity is absolutely true for us as well.
> 
> Does this really introduce a lot of complexity in the loader?  There's the 
> actual stream converter, and the fact that people have to worry about headers 
> on part channels, but apart from that I don't recall much complexity.

There’s some really ugly code involved in making MJPEG streams loaded as 
documents not flicker. Given what a nightmare this stuff has been in ImageLib, 
I assumed that there was even more ugliness in other places, but you’d know 
better than I would.

(I have to say if the docloader’s reputation as hard-to-understand code is 
justified, anything we can do to simplify it is probably a good idea. I’ve only 
touched it a little, though.)

>> so removing it has not resulted in a disaster for Chrome. With so few people 
>> using multipart/x-mixed-replace
> 
> We should use a use counter here, because as far as I know sites decide via 
> server-side sniffing whether to do this.  :(

That might be a good idea, though I will note that I’d be surprised if many 
sites treated Firefox and Chrome differently here, because Chrome only dropped 
support ~9 months ago.

- Seth
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Boris Zbarsky

On 3/12/15 6:37 PM, Seth Fowler wrote:

They made main resources that use multipart/x-mixed-replace trigger downloads 
instead of being displayed.


So what gets downloaded is the entire mixed stream, right?


The observation that multipart/x-mixed-replace support introduces a lot of 
complexity is absolutely true for us as well.


Does this really introduce a lot of complexity in the loader?  There's 
the actual stream converter, and the fact that people have to worry 
about headers on part channels, but apart from that I don't recall much 
complexity.



so removing it has not resulted in a disaster for Chrome. With so few people 
using multipart/x-mixed-replace


We should use a use counter here, because as far as I know sites decide 
via server-side sniffing whether to do this.  :(


-Boris


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Ehsan Akhgari

On 2015-03-12 6:54 PM, Kyle Huey wrote:

I've been meaning to rip out the putative support for this from XHR (and
all of the complexity that it introduces) for months now.  This would be
great.


Henri beat you by two years.  ;-)

https://bugzilla.mozilla.org/show_bug.cgi?id=843508

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Boris Zbarsky

On 3/12/15 7:04 PM, Seth Fowler wrote:

It looks like it doesn’t anymore, because it works fine in Chrome.


Iirc, bugzilla sniffs server-side and sends different things to 
different browsers.  Worth testing in Firefox with multipart/x-mixed 
support disabled.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Seth Fowler
On Mar 12, 2015, at 3:52 PM, Ehsan Akhgari  wrote:
>> Looks like this patch landed in Chromium on June 13, 2013 and has stuck 
>> since then, so removing it has not resulted in a disaster for Chrome. With 
>> so few people using multipart/x-mixed-replace, and since now both IE and 
>> Chrome do not support it, I suggest that we remove support for it from the 
>> docloader as well.
> 
> Doesn't bugzilla use multipart/x-mixed-replace for its search results page?

It looks like it doesn’t anymore, because it works fine in Chrome.

- Seth
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Kyle Huey
I've been meaning to rip out the putative support for this from XHR (and
all of the complexity that it introduces) for months now.  This would be
great.

- Kyle

On Thu, Mar 12, 2015 at 3:37 PM, Seth Fowler  wrote:

> Chrome removed support for multipart/x-mixed-replace main resources in
> this issue:
>
> https://code.google.com/p/chromium/issues/detail?id=249132 <
> https://code.google.com/p/chromium/issues/detail?id=249132>
>
> Here’s their explanation:
>
> > This feature is extremely rarely used by web sites and is the source of
> a lot of complexity and security bugs in the loader.  UseCounter stats from
> the stable channel indicate that the feature is used for less than 0.1%
> of page loads.
>
>
> They made main resources that use multipart/x-mixed-replace trigger
> downloads instead of being displayed.
>
> The observation that multipart/x-mixed-replace support introduces a lot of
> complexity is absolutely true for us as well. It’s a huge mess.
>
> Looks like this patch landed in Chromium on June 13, 2013 and has stuck
> since then, so removing it has not resulted in a disaster for Chrome. With
> so few people using multipart/x-mixed-replace, and since now both IE and
> Chrome do not support it, I suggest that we remove support for it from the
> docloader as well.
>
> - Seth
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Ehsan Akhgari

On 2015-03-12 6:37 PM, Seth Fowler wrote:

Chrome removed support for multipart/x-mixed-replace main resources in this 
issue:

https://code.google.com/p/chromium/issues/detail?id=249132 


Here’s their explanation:


This feature is extremely rarely used by web sites and is the source of a lot 
of complexity and security bugs in the loader.  UseCounter stats from the 
stable channel indicate that the feature is used for less than 0.1% of page 
loads.



They made main resources that use multipart/x-mixed-replace trigger downloads 
instead of being displayed.

The observation that multipart/x-mixed-replace support introduces a lot of 
complexity is absolutely true for us as well. It’s a huge mess.

Looks like this patch landed in Chromium on June 13, 2013 and has stuck since 
then, so removing it has not resulted in a disaster for Chrome. With so few 
people using multipart/x-mixed-replace, and since now both IE and Chrome do not 
support it, I suggest that we remove support for it from the docloader as well.


Doesn't bugzilla use multipart/x-mixed-replace for its search results page?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Chrome removed support for multipart/x-mixed-replace documents. We should too.

2015-03-12 Thread Seth Fowler
Chrome removed support for multipart/x-mixed-replace main resources in this 
issue:

https://code.google.com/p/chromium/issues/detail?id=249132 


Here’s their explanation:

> This feature is extremely rarely used by web sites and is the source of a lot 
> of complexity and security bugs in the loader.  UseCounter stats from the 
> stable channel indicate that the feature is used for less than 0.1% of 
> page loads.


They made main resources that use multipart/x-mixed-replace trigger downloads 
instead of being displayed.

The observation that multipart/x-mixed-replace support introduces a lot of 
complexity is absolutely true for us as well. It’s a huge mess.

Looks like this patch landed in Chromium on June 13, 2013 and has stuck since 
then, so removing it has not resulted in a disaster for Chrome. With so few 
people using multipart/x-mixed-replace, and since now both IE and Chrome do not 
support it, I suggest that we remove support for it from the docloader as well.

- Seth
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform