1711352 - Differential behavior happend when new a EventSource with an empty URL compared with other browsers

Status: UNCONFIRMED

(Core :: DOM: Events, enhancement)

Description

[zyscoder]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

Steps to reproduce:

1. Open a tab and navigate to https://www.apple.com;
2. Open Devtools and run the following code in the Console:

new EventSource('')

Actual results:

There is no check for the parameter "URL" if empty or not and an EventSource object will be created by this code.

Expected results:

In my test, when evaluating the code above in Chrome, Webkit, and Opera, all these browsers would throw an exception that says "Uncaught DOMException: Failed to construct 'EventSource': Cannot open an EventSource to an empty URL."
It seems a good way to improve the compatibility of firefox to add a check to tell if the URL parameter is empty or not.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

According to the spec, it may be parsed as relative URL to the API's URL.
https://html.spec.whatwg.org/multipage/server-sent-events.html#dom-eventsource

And it seems that there is no WPT for the empty string case:
https://searchfox.org/mozilla-central/search?q=new+EventSource&path=web-platform&case=true&regexp=false

It seems that the base URL in the console should not be the document's URL, but I'm not sure.

smaug: Do you know who is familiar with this?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops, see the previous comment.

Comment 4

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

Base uri is document's uri (or overridden base URI, if there is base element)
And
new URL("", document.documentURI); works in Firefox and Chrome.

https://html.spec.whatwg.org/multipage/window-object.html#script-settings-for-window-objects:api-base-url

This looks like an odd inconsistency in other browsers.
Could you file bugs on other browsers?