Previous selected checkbox always updates on next submit

I assume that refreshing the page means using the Reload-Button of the browser.
There might be an interference with the cache of the browser.
I'm using firefox and there holding the shift-key while clicking Reload re-fetches the
instead of taking it from the cache.

Assume a checkbox is enabled (meaning submitted, in trac's sql database).
When i disable it (without submitting) and reloading the page, the the checkbox stays disabled.
If i do a shift-reload the checkbox jumps back to enabled (as in trac's sql database).

Maybe this helps understanding the described behaviour.

On Firefox, I'm seeing the same behavior as you with regard to the checkbox and reload vs shift+reload.

That is, if I select and submit item A, then:

• Unselecting item A and reloading the page, item A remains unselected.
• Unselecting item A and shift+reloading the page, item A goes back to selected.

However, if I select and update item A, uncheck A, select and update item B; then both items A and B update.

I'm changing the summary because I've been able to reproduce this behavior in multiple cases and it is definitely not specific to the Laundry List example.

I've tested this on Firefox and Opera and see the same behavior. In fact, after testing on Firefox, I moved over to Opera and observed that the third item in my list was selected on first navigating to the page. I unselected the item and selected the second item; both the second and third items updated on submit.

Thanks for all the testing done by now. Most probably I'll have to ask for more details about your test cases, but this need definitely to be fixed soon.

Coming back to your question now after much more code reading and testing.

As triggering a checkbox change is an on/off|1/0 value change, I think the observed behavior is the expected one. In fact what is implemented right now is a dumb bi-stable switch. Please discuss, if this is (or what else), what you want to happen.

I think, you're discussing more towards a trigger behavior with "self-resetting on commit" capability, or something else?

Another suggestion: Since 0.3 now has an extensive history review similar to ticket changes, you could just add the keep_history command in the form header, do some changes and look at what is going on in the history afterwards. In fact it should be almost self-explaining. Give it a try, please.

Still need to know, if there is something to fix. But by now I seriously doubt, it is code - documentation at most.

Step down priority since right now it seems like it should work this way. Comments?