CfP submission form loses data when creating an account or logging in

[glyph]

CfP submission form loses data when creating an account or logging in

[glyph]

1. Could you expand on the critical step, 'Go to the "register" link'? Do you mean that you click the "login" link in the upper right-hand corner, or that you follow the CfP (multi-step) form and eventually are asked to log in or register?

The login link in the upper right hand corner is the one I just experienced.

[rixx]

A quick fix to avoid this frustration might be to add a speedbump on any navigation away from the page, "are you sure you don't want to save first"

This exists in pretalx as of the last release, as per #1107 – the instance we're (probably? nbpy?) talking about is lagging by a year / two big releases atm, not much I can do there, sadly.

[rixx]

Hm, yeah, that sucks. Two questions to figure out how to proceed:

1. Could you expand on the critical step, 'Go to the "register" link'? Do you mean that you click the "login" link in the upper right-hand corner, or that you follow the CfP (multi-step) form and eventually are asked to log in or register?
   The reason I'm asking is that these are two very distinct bug reports – we extensively test for the latter, as that's the expected workflow. It's meant to give users a (seamless-ish?) way to log in or register while in the process of filling in their proposal information.
2. What do you mean by "Come back to see the site blanked out." – by "blanked out" you mean empty form fields, not a white page, right? Did you open the login/registration form in a separate tab and switched back to the previous one? On page reload, are you thrown back to the first form of the CfP? Or did you log in then navigate back in the browser (which I could see leading to CSRF errors, hm).

Things I just tested manually:

• Submit first form, be directed to login/register page, log in, continue: works.
• Submit first form, be directed to login/register page, open other login page in separate tab, log in, reload page. See 404 (not ideal!), but on using browser navs to go back a step to the first form and hard-reloading, all info is still there.
• Start filling in first form, do not submit, log in in separate tab, then submit form in first tab: Get CSRF error. Navigating back with browser navigation shows me the previously entered data, and soft refresh retains the data, but that's browser dependent behaviour – Firefox keeps form data across soft refresh, Chrome doesn't.
• Start filling in first form, do not submit, log in in separate tab, refresh: data is lost or not as above depending on browser behaviour.

I feel like forms being emptied of data when reloading without submitting is right on the edge of "expected, correct behaviour, do not mess with it" and "annoying af, do magic with localstorage to prevent". (Any data loss following a form submit is definitely a bug and needs to be treated as such of course.) I do think we need to err on the side of messing with JavaScript and LocalStorage, as much as it pains me, because this isn't the first time I've heard people complain of this, and being useful is more important than being correct etc etc.

[glyph]

2. What do you mean by "Come back to see the site blanked out." – by "blanked out" you mean empty form fields, not a white page, right? Did you open the login/registration form in a separate tab and switched back to the previous one? On page reload, are you thrown back to the first form of the CfP? Or did you log in then navigate back in the browser (which I could see leading to CSRF errors, hm).

Yes, empty form fields. I did not open a new tab; just clicked the link, then ended up on the blank form, hit "back" to see if the state was saved in my page history, and it still wasn't, that one was blank as well.

[glyph]

I feel like forms being emptied of data when reloading without submitting is right on the edge of "expected, correct behaviour, do not mess with it" and "annoying af, do magic with localstorage to prevent". (Any data loss following a form submit is definitely a bug and needs to be treated as such of course.) I do think we need to err on the side of messing with JavaScript and LocalStorage, as much as it pains me, because this isn't the first time I've heard people complain of this, and being useful is more important than being correct etc etc.

Thanks, yeah, I think the LocalStorage option is the one I'd like to see.

(Is PyScript at the point where you could avoid JavaScript, I wonder? Or would that destroy page load performance? :))

[glyph]

A quick fix to avoid this frustration might be to add a speedbump on any navigation away from the page, "are you sure you don't want to save first", but a nice background autosave would be preferable.

[glyph]

the instance we're (probably? nbpy?) talking about

good guess :)

[glyph]

To be fair I have experienced this problem on PyCon several times as well. Glad to know that the speedbump exists.