Roundup Tracker - Issues

Issue 2550946

Title: Add autocomplete off on form select
Type: rfe Severity: normal
Components: Web interface Versions:
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: rouilj Nosy List: ced, rouilj
Priority: normal Keywords: wikihint

Created on 2017-07-10 14:17 by ced, last changed 2019-10-11 01:18 by rouilj.

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'
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:

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?
msg6728 Author: [hidden] (rouilj) Date: 2019-10-11 01:18
Closing and marking as wikihint. Something useful to track/remember to handle an issue, but not something to code.
Date User Action Args
2019-10-11 01:18:36rouiljsetkeywords: + wikihint
status: open -> closed
messages: + msg6728
2017-07-28 06:44:32cedsetmessages: + msg5991
2017-07-27 22:29:44rouiljsetpriority: normal
assignee: rouilj
resolution: wont fix
messages: + msg5989
2017-07-17 20:41:32rouiljsetmessages: + msg5988
2017-07-17 20:31:03rouiljsetstatus: new -> open
2017-07-17 20:30:44rouiljsetnosy: + rouilj
messages: + msg5987
2017-07-10 14:17:48cedcreate