1746684 - wowway.net redirect works in Chrome and Safari but not Firefox

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[kentmh]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36 Edg/96.0.1054.57

Steps to reproduce:

Installed version 96 of wowway.net. When "Email" is selected a new window at "http://wowway.net/files/wow/login.php?bounceto=http%3A%2F%2Fwowway.net%2Fzmail%2F%3Fautologin%3Dtrue" is opened with the title "Redirecting to Login" and the sole message "Please wait while we are logging you in."

Actual results:

This page remains on indefinitely without connecting. If I try to open "https://email.wowway.com/modern/" directly on a new window, it connects instead to "https://wowway.net/".

Expected results:

It should have connected to my woway.net email page "https://email.wowway.com/modern/". This page is unavailable from wowway in Firefox.

Comment 1

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

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

Comment 2

[Valentin Gosu [:valentin] (he/him)]

The hanging page shows Cookie “temporalchip” will be soon treated as cross-site cookie against “https://wowway.net/files/wow/login.php?bounceto=http%3A%2F%2Fwowway.net%2Fzmail%2F%3Fautologin%3Dtrue” because the scheme does not match. in the console.

There might also be some interaction with Https-only mode.

Comment 3

[Niklas]

Good news: I don't think this is a samesite breakage. The reported behavior happens with all the samesite prefs (schemeful, none secure, lax by default) set to true or false.

After clicking on "Email" a new window is opened and the following loads occur:

http://wowway.net/zmail/?autologin=true&app=webmail -> 301 -> https://wowway.net/zmail/?autologin=true&app=webmail
https://wowway.net/zmail/?autologin=true&app=webmail -> 302 -> http://premiums.wowway.net/zmail/?autologin=true&app=webmail
http://premiums.wowway.net/zmail/?autologin=true&app=webmail -> 302 -> http://wowway.net/files/wow/login.php?bounceto=http%3A%2F%2Fwowway.net%2Fzmail%2F%3Fautologin%3Dtrue
http://wowway.net/files/wow/login.php?bounceto=http%3A%2F%2Fwowway.net%2Fzmail%2F%3Fautologin%3Dtrue 200 OK

http://wowway.net/files/... returns:

<form name="form1" action="https://login.wowway.com/login.aspx?appid=110" method="post">
[...]
</form>
<iframe style="width: 1px; height: 1px; position: absolute; top -50px; left: -50px;" src="https://login.wowway.com/login_portal.aspx" onload="document.form1.submit();">
</iframe>

The iframe load of https://login.wowway.com/login_portal.aspx redirects to https://login.wowway.com/GenericError.aspx?ErrorType=404 which returns a 404. onload is not triggered and the form post to https://login.wowway.com/login.aspx?appid=110 does not happen.

Valentin, do you know who to ping about the onload behavior here?

Comment 4

[Valentin Gosu [:valentin] (he/him)]

(In reply to Niklas from comment #3)

The iframe load of https://login.wowway.com/login_portal.aspx redirects to https://login.wowway.com/GenericError.aspx?ErrorType=404 which returns a 404. onload is not triggered and the form post to https://login.wowway.com/login.aspx?appid=110 does not happen.

Valentin, do you know who to ping about the onload behavior here?

Thanks for looking into this.
AFAIK when receiving a 404 response, the onerror handler should be called instead.
Moving to DOM::Core for a definite answer to this question. It would be nice to find out if behaves the same in other browsers.

Comment 5

[Chris Peterson [:cpeterson]]

Good news: I don't think this is a samesite breakage. The reported behavior happens with all the samesite prefs (schemeful, none secure, lax by default) set to true or false.

In that case, I'll unlink the schemeful-samesite meta bug

AFAIK when receiving a 404 response, the onerror handler should be called instead.

smaug says there is no onerror handler called for iframe loads, only onload.

This is not a Fission bug: smaug can reproduce this bug with and without Fission.

I can reproduce in Firefox ESR 91, so this is not a Firefox regression.

Comment 6

[Chris Peterson [:cpeterson]]

Chrome is firing onload for the 404 page load, but Firefox is not. Nika says Chrome fires onload instead of onerror for cross-origin load errors to avoid a cross-origin data leak. But does Chrome fire onload or onerror for same-origin loads?

Safari redirects successfully like Chrome.

Nika says there is a spec issue for related <object> issue: https://github.com/whatwg/html/issues/7327 and https://bugzilla.mozilla.org/show_bug.cgi?id=1653014

Comment 7

[Dennis Schubert [:denschub]]

This is breaking the site that's been reported here, but it looks like we have no indication that this is breaking a P1 site for now. Setting WebCompat P2 for now.