Issue 2550946
Created on 2017-07-10 14:17 by ced, last changed 2017-07-28 06:44 by ced.
Messages | |||
---|---|---|---|
msg5986 | Author: [hidden] (ced) | Date: 2017-07-10 14:17 | |
When reloading the form of an issue on which for example we have changed the value of a select, the browser remember the previous value selected and ignore the selected option. To prevent this, the select must have autocomplete set to 'off' https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-autocomplete I do not know if it is better to just add it to the form attribute in each templates or if the templating menu() should set it. |
|||
msg5987 | Author: [hidden] (rouilj) | Date: 2017-07-17 20:30 | |
I am confused. As far as I can tell the autocomplete attribute only works for input (mostly text) tags. As you state, menu() creates a select. From what I see at the w3c autocomplete is not valid for selects. The link you posted references input elements. If autocomplete does anything for selects, I think it's a bug. I can reproduce your issue. However in firefox shift refresh does return the original (reset) data for selects at least. This makes me wonder if firefox is trying to prevent data loss (or is pulling from a local cached copy with the change preserved) and causing the issue you report. Refreshing/reloading with Edge, IE, Opera and Chrome are all resetting the select box to the unchanged value. So this looks like some ff issue. Having said that, other types of input (e.g. checkbox) may benefit from setting autocomplete off. However from what I see of autocomplete use, I would not expect the autocomplete type: name, street-address, ... to be set on a checkbox. As a result I am not sure that autocomplete will even do anything useful for a checkbox. Setting autocomplete="off" on the form tag may not be a bad idea. It probably depends on the specific use case of the tracker. As a result specifying it in the html for the specific tracker instance rather than putting it into the code that generates form fields is probably a better idea. So my suggestion at this time sine it only appears firefox is a problem is that there is nothing to change in the released code for this. However an addition to the documentation may be useful. -- rouilj |
|||
msg5988 | Author: [hidden] (rouilj) | Date: 2017-07-17 20:41 | |
Additional links: https://bugzilla.mozilla.org/show_bug.cgi?id=46845#c13 from http://forums.mozillazine.org/viewtopic.php?f=25&t=226839 Apparently keeping values on reload (not shift reload) is intentional to prevent loss of work on reload. |
|||
msg5989 | Author: [hidden] (rouilj) | Date: 2017-07-27 22:29 | |
Cedric, any thoughts on where this could be documented? If not I'm planning on closing this. -- rouilj |
|||
msg5991 | Author: [hidden] (ced) | Date: 2017-07-28 06:44 | |
I have no idea where this could be documented. But maybe it could be set on the default templates? |
History | |||
---|---|---|---|
Date | User | Action | Args |
2017-07-28 06:44:32 | ced | set | messages: + msg5991 |
2017-07-27 22:29:44 | rouilj | set | priority: normal assignee: rouilj resolution: wont fix messages: + msg5989 |
2017-07-17 20:41:32 | rouilj | set | messages: + msg5988 |
2017-07-17 20:31:03 | rouilj | set | status: new -> open |
2017-07-17 20:30:44 | rouilj | set | nosy:
+ rouilj messages: + msg5987 |
2017-07-10 14:17:48 | ced | create |