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

VERIFIED INVALID

Status

()

Firefox
Untriaged
VERIFIED INVALID
5 years ago
4 years ago

People

(Reporter: tinazhao, Assigned: Wellington Fernando de Macedo)

Tracking

23 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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().
See Also: → bug 869432

Updated

5 years ago
Summary: [eventsource] When encoding charset=windoes-1252, Firefox goes to onmessage() but not onerror(). → [eventsource] When encoding charset=windows-1252, Firefox goes to onmessage() but not onerror().
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.
(Assignee)

Comment 2

5 years ago
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.
Flags: needinfo?(ian)
Flags: needinfo?(bugs)
(Assignee)

Updated

5 years ago
Assignee: nobody → wfernandom2004
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 3

5 years ago
tinazhao: See comment 2.
Flags: needinfo?(tina.zhao)
(Assignee)

Updated

5 years ago
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Yeah, I agree, nothing in the spec requires firing error.
Flags: needinfo?(bugs)
(Assignee)

Updated

5 years ago
See Also: → bug 662073
(Assignee)

Updated

5 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Assignee)

Updated

5 years ago
See Also: bug 869432
(Reporter)

Comment 5

4 years ago
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.
Flags: needinfo?(tina.zhao)
(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.
(Reporter)

Comment 7

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

Comment 8

4 years ago
(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
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 :)
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

4 years ago
Agreed.
Status: RESOLVED → VERIFIED
Flags: needinfo?(ian)
You need to log in before you can comment on or make changes to this bug.