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 Travis Swicegood, 12 years ago

Cc: travis@… added
Resolution: needsinfo
Status: newclosed

Closing with "needsinfo". Can you provide the steps for a test case to reproduce this? Please re-open with that information if you can.

comment:2 by Simon Litchfield, 12 years ago

Resolution: needsinfo
Status: closedreopened

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 Russell Keith-Magee, 11 years ago

Resolution: fixed
Status: reopenedclosed
Triage Stage: UnreviewedAccepted

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 Julien Phalip, 11 years ago

Resolution: fixed
Status: closedreopened

It looks like this was accidentally closed :)

comment:5 by Simon Litchfield, 11 years ago

Russ- you got it mate. I'll spin up a fix.

comment:6 by anonymous, 11 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 Aymeric Augustin, 11 years ago

Status: reopenednew

in reply to:  6 comment:8 by Glenn Wang, 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?

comment:9 by Collin Anderson, 10 years ago

Cc: cmawebsite@… added

Is this related to #13614 ?

Note: See TracTickets for help on using tickets.
Back to Top