1408658 - Web page routes back to login page after password submission

Status: RESOLVED WORKSFORME

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

Description

[Carm]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171013042429

Steps to reproduce:

I am unable to provide the exact site and passwords in an open forum as I do not want our accounts locked up. however it is exactly like here: 

https://muconnect.missouri.edu/pdfs/launch-kiosk-mizzou.pdf

Ours is the same but with different pull-downs obviously.

Using Firefox 56 stable or 57b8 with clean FF profile or on multiple machine 64 bit or 32 bit versions.
Select the Kiosk via the pull-down menu.
Enter the password either right or wrong.


Actual results:

You are bounced right back to the first screen ( Launch the starfish kiosk ) like at the top of the pdf. It is like it does not see you entered anything in and you just refreshed the page. It does not matter if you put the right or wrong password in. 
I first started to notice this in 56 beta, and has carried on through 56 stable and currently Firefox Quantum 57b8. 


Expected results:

If you put the wrong password in it will tell you that the password is in is not correct
If you put the correct one in It will take you to the next page in the starfish kiosk like in the pdf above. 

This works correctly in v55 of Firefox which I had to do a roll back on all my kiosks, Current version of chrome, Internet Explorer and MS Edge works jfine.

I can provide logins to devs here, however please make a note here and the please email me

Thank You

Comment 1

[Kohei Yoshino [:kohei]]

Please contact the site administrator to get help.

Comment 2

[Carm]

This IS NOT A SITE PROBLEM THIS IS A FIREFOX PROBLEM IF IF YOU TAKE THE TIME TO READ THE CONTENTS IT SAYS IT WORKS FINS ON ALL OTHER BROWSERS!

Comment 3

[Kohei Yoshino [:kohei]]

Please understand that "working fine on all other browsers" doesn't necessarily mean there's a bug in Firefox. Also, the form clearly states "If you are unsure of the login information, please talk to your Starfish system administrator." 

However, given that there has recently been a similar issue in Firefox (Bug 1402025), I'm moving this to a better place for further investigation.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Carm, thanks for reporting this. Do you think you could help us get where this regressed from by the mozregression tool [1]?
Thanks.

[1] http://mozilla.github.io/mozregression/

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Here's the regressionwindow I got  
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aff336ac161daa3ea350e59a288963edbd58ed39&tochange=e0b0865639cebc1b5afa0268a4b073fcdde0e69c

My STR:
1) Open your browser and go to: https://mizzou.starfishsolutions.com/starfish-ops/kiosk/index.html  (mentioned in the pdf link in comment 0)
2) Choose "BUSUN Advising office" for kiosk
3) Type a wrong password

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #5)
> Here's the regressionwindow I got  
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=aff336ac161daa3ea350e59a288963edbd58ed39&tochange=e0b0
> 865639cebc1b5afa0268a4b073fcdde0e69c
> 
> My STR:
> 1) Open your browser and go to:
> https://mizzou.starfishsolutions.com/starfish-ops/kiosk/index.html 
> (mentioned in the pdf link in comment 0)
> 2) Choose "BUSUN Advising office" for kiosk
> 3) Type a wrong password

I run mozregression again, and here it is https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5b29bf0b577c67d9486aa95a09f36a39c0a67754&tochange=8f7663ac2068ae33e99bb2ce637b98a9f9c283a2

Jessica, could you please take a look?

Comment 7

[Jessica Jong [:jessica] (inactive)]

Let me take a look.

Comment 8

[Jessica Jong [:jessica] (inactive)]

So this is the case where we work according to the spec but we're not compatible with other browsers (I tested Chome and Safari).

The spec says: The action IDL attribute must reflect the content attribute of the same name, except that on getting, when the content attribute is missing or its value is the empty string, the element's node document's URL must be returned instead. [1]

In this case, there is no 'action' content attribute in the website's form, so we return the document's URL.

Try to run the following test in Firefox, Chrome and Safari:
http://w3c-test.org/html/semantics/forms/the-form-element/form-action-reflection-with-base-url.html
You'll notice that the last test case fails in Chrome and Safari while Firefox passes all.


[1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-fs-action

Comment 9

[Kohei Yoshino [:kohei]]

Moving to TE as mentioned in Bug 1366361 Comment 17.

Comment 10

[Jessica Jong [:jessica] (inactive)]

Unassigning myself since this has moved to TE.

Comment 11

[Alice Smith]

Redirection back to the current page involves saving the current url in the session and then retrieving the url from the session after the user is login. This should be done for GET requests as the other http methods like POST, PUT, PATCH,DELETE are not idempotent and should not be repeated automatically. http://www.alwaysreview.net/reviews/ee-customer-service/

Comment 12

[Karl Dubost💡 :karlcow]

Attachment: Capture d’écran 2020-05-07 à 15.09.09.png

if the site still fails, it also fails on Chrome as chrome passes the same test than Firefox.
Only Safari is failing the tests now.

Closing this as worksforme.