Opened 12 years ago
Last modified 10 years ago
#18879 new Bug
FilteredSelectMultiple loses data
Reported by: | Simon Litchfield | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | simon@…, travis@…, cmawebsite@… | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Description
If page loading breaks at just the right time, it's possible we've seen that the currently selected options are not transferred from the underlying form's select element into the javascript-powered FilteredSelectMultiple widget.
Then, if the user goes ahead and presses save, the options are wiped/overridden.
A solution here would be to set a flag once the options are safely transferred to the widget, and only pass the widget's selections back into the form's select element during submit if the flag is set.
Change History (9)
comment:1 by , 12 years ago
Cc: | added |
---|---|
Resolution: | → needsinfo |
Status: | new → closed |
comment:2 by , 12 years ago
Resolution: | needsinfo |
---|---|
Status: | closed → reopened |
To test, run up an admin page with plenty of heavy fields intertwined with a few FilteredSelectMultiple widgets that all have long lists of options. Then run it over a slow connection (ie not local).
Unfortunately it's impractical to post a test case with data here- maybe it'd be better to demo this bug via a URL.
comment:3 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Triage Stage: | Unreviewed → Accepted |
I can see how this could happen. The problem is caused because the widget that actually submits the data isn't related to the widget that displays the data, and if you have a partial page load, you could end up with a situation where *some* of the data has been updated into the display widget -- and when you hit submit, that partial information is submitted as new data. The suggestion from the reporter -- i.e., a safety catch that only engages when the page is fully loaded -- sounds like the right fix to me.
comment:4 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
It looks like this was accidentally closed :)
follow-up: 8 comment:6 by , 12 years ago
I am seeing a phenomenon that might be related to this:
An admin change_form with a FilteredSelectMultiple and some js code that triggers form submission by jQuery $("#form").submit will also lose all the data in FilteredSelectMultiple. It seems that the submit handler in SelectFilter2.js:92 is not executed when you are submitting the form from jQuery, no idea why.
comment:7 by , 12 years ago
Status: | reopened → new |
---|
comment:8 by , 11 years ago
Replying to anonymous:
I am seeing a phenomenon that might be related to this:
An admin change_form with a FilteredSelectMultiple and some js code that triggers form submission by jQuery $("#form").submit will also lose all the data in FilteredSelectMultiple. It seems that the submit handler in SelectFilter2.js:92 is not executed when you are submitting the form from jQuery, no idea why.
Yeah, I'd experienced this too, a standalone <button type='submit'>
works while $("#form").submit() won't. Any ideas why?
Closing with "needsinfo". Can you provide the steps for a test case to reproduce this? Please re-open with that information if you can.