Opened 3 years ago

Last modified 8 months ago

#18879 new Bug

FilteredSelectMultiple loses data

Reported by: simon29 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 Changed 3 years ago by tswicegood

  • Cc travis@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to needsinfo
  • Status changed from new to closed

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 Changed 3 years ago by simon29

  • Resolution needsinfo deleted
  • Status changed from closed to 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 Changed 2 years ago by russellm

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Triage Stage changed from Unreviewed to 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 Changed 2 years ago by julien

  • Resolution fixed deleted
  • Status changed from closed to reopened

It looks like this was accidentally closed :)

comment:5 Changed 2 years ago by simon29

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

comment:6 follow-up: Changed 2 years ago by 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.

comment:7 Changed 2 years ago by aaugustin

  • Status changed from reopened to new

comment:8 in reply to: ↑ 6 Changed 20 months ago by yuwang

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 Changed 8 months ago by CollinAnderson

  • Cc cmawebsite@… added

Is this related to #13614 ?

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