869878 - [eventsource] When encoding charset=windows-1252, Firefox goes to onmessage() but not onerror().

Status: VERIFIED INVALID

(Firefox :: Untriaged, defect)

Description

[tinazhao]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.10 (KHTML, like Gecko) Chrome/23.0.1262.0 Safari/537.10

Steps to reproduce:

ServerSentEvent latest Editor's Draft 23 April 2013 (http://dev.w3.org/html5/eventsource/) test
- Test wiki: http://www.w3.org/wiki/Webapps/Interop/ServerSentEvents
- Test suite: https://github.com/w3c/web-platform-tests/tree/master/eventsource
- Test case: https://github.com/w3c/web-platform-tests/blob/master/eventsource/format-utf-8.htm


Actual results:

Test case failed:
In Spec, Event streams in this format must always be encoded as UTF-8. But when sending the source:
var source = new EventSource("resources/message.php?mime=text/event-stream;charset=windows-1252&message=data%3A%E2%80%A6")
It goes to the source.onmessage(), throws assert_unreached: Reached unreachable code


Expected results:

It should go to source.onerror().

Comment 1

[Masatoshi Kimura [:emk]]

I couldn't find a sentence saying something like "user agents must fire an error event if the charset parameter is present and the value is not utf-8" in the spec.
I thought user agents would decode Event streams in utf-8 regardless of the meaningless charset parameter.

Comment 2

[Wellington Fernando de Macedo]

Please, clarify if this is really an issue or not. As Masatoshi Kimura wrote above, the spec does not require to fire the error event. 

Except if the tech spec is updated, I would conclude this bug stating that the test case is wrong and, in this case, it should be corrected to make Mozilla and Opera implementations to pass and to make Chrome implementation to fail.

Comment 3

[Wellington Fernando de Macedo]

tinazhao: See comment 2.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Yeah, I agree, nothing in the spec requires firing error.

Comment 5

[tinazhao]

Sorry for the late reply...

The Spec describes that“Event streams in this format must always be encoded as UTF-8”, so my understanding is if the event streams doesn't encode as UTF-8, there should be an error.

(In reply to Wellington Fernando de Macedo from comment #2)
> Please, clarify if this is really an issue or not. As Masatoshi Kimura wrote
> above, the spec does not require to fire the error event. 
> 
> Except if the tech spec is updated, I would conclude this bug stating that
> the test case is wrong and, in this case, it should be corrected to make
> Mozilla and Opera implementations to pass and to make Chrome implementation
> to fail.

Comment 6

[Masatoshi Kimura [:emk]]

(In reply to tinazhao from comment #5)
> The Spec describes that“Event streams in this format must always be encoded
> as UTF-8”, so my understanding is if the event streams doesn't encode as
> UTF-8, there should be an error.

Does it mean "if the sequence in the stream is invalid as UTF-8"? Or "if the charset parameter says that the sequence is not encoded in UTF-8"? I think this is the former because charset parameter has no meanings, as the spec is saying.

Comment 7

[tinazhao]

Hmm...Make sense, unreached is better then onerror in this case. This test case should be updated.

Comment 8

[Arthur Barstow]

(In reply to tinazhao from comment #7)
> Hmm...Make sense, unreached is better then onerror in this case. This test
> case should be updated.

Tina - given your conclusion, would you please submit a PullRequest that fixes the test case bug?

-Thanks, Art Barstow

Comment 9

[Odin Hørthe Omdal (odinho, Opera)]

It's better to restrict it.

As Yaffle pointed out in the GitHub pull request (https://github.com/w3c/web-platform-tests/pull/268), the spec says:

> The charset parameter may be provided. The parameter's value must be "utf-8".
> This parameter serves no purpose; it is only allowed for compatibility with
> legacy servers.

http://dev.w3.org/html5/eventsource/#text-event-stream


Also, the whole reason for this force-utf8 is to disallow craziness on the web. Always having to use utf8 but allowing you to set charset=whatever kinda gives mixed signals. The test is correct, the implementation wrong. IMHO :)

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

the spec still doesn't require firing error. It does say the value should be utf-8 but it also has
no purpose. So I interpret the value is authoring requirement, and the implementation is correct.

Comment 11

[Anne (:annevk)]

Agreed.