Modify

Opened 5 years ago

Last modified 4 years ago

#5319 new defect

Previous selected checkbox always updates on next submit

Reported by: rjollos Owned by: hasienda
Priority: low Component: TracFormsPlugin
Severity: normal Keywords: needinfo checkbox update refresh wiki documentation
Cc: mkc Trac Release: 0.11

Description

I'm running the Laundry List example.

  1. I select WashClothes and submit - the timestamp for WashClothes updates.
  2. I unselect WashClothes and refresh the page - WashClothes is selected again. I repeat this step but each time I refresh the page it seems to remember that I selected WashClothes on the last submit and reselect the checkbox.
  3. I unselect WashClothes, select FoldClothes, and submit - the timestamp for both WashClothes and FoldClothes update.
  4. I select only WashClothes and submit again. The timestamp does not update.

Is this the expected behavior?

  • Ryan

Attachments (0)

Change History (12)

comment:1 Changed 5 years ago by anonymous

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.

comment:2 Changed 5 years ago by rjollos

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.

comment:3 Changed 5 years ago by rjollos

  • Summary changed from Behavior of LaundryList example to Previous selected checkbox always updates on next submit

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.

comment:4 Changed 5 years ago by rjollos

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.

comment:5 Changed 5 years ago by anonymous

  • Cc mkc added; anonymous removed

comment:6 Changed 5 years ago by anonymous

  • Priority changed from normal to high

comment:7 Changed 4 years ago by rjollos

  • Cc hasienda added

comment:8 Changed 4 years ago by hasienda

  • Cc hasienda removed
  • Keywords checkbox update refresh wiki added
  • Owner changed from rharkins to hasienda

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.

comment:9 Changed 4 years ago by hasienda

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?

comment:10 Changed 4 years ago by hasienda

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.

comment:11 Changed 4 years ago by hasienda

  • Keywords needinfo documentation added

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

comment:12 Changed 4 years ago by hasienda

  • Priority changed from high to low

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

Add Comment

Modify Ticket

Action
as new The owner will remain hasienda.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.