Problem/Motivation
This took a while to track down and may not seem like that big of a bug at first, but it's a fairly major one if your site relies heavily on dialogs/modals.
The easiest way to explain the issue is to use the closeOnEscape boolean value as an example.
When this option is passed via AJAX, it passes the actual value of false. This value is subsequently converted into a string representation due to how PHP works when it reaches DialogRenderer or ModalRenderer and becomes "false".
Thus, when it's actually passed back to JavaScript as AJAX commands in a response to actually open said dialog/modal, its actual value (a string) is treated as a positive value. This is because most code, if not all, expects this to be a boolean and treats it as such with statements like if (options.closeOnEscape).
For more details, see #2978392: Mapped option closeOnEscape doesn't work as expected.
Proposed resolution
Filter, sanitize and cast passed dialogOptions to proper values.
Remaining tasks
Create patch- Create test(s)
User interface changes
None
API changes
None
Data model changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3014136-nr-bot.txt | 143 bytes | needs-review-queue-bot |
| #14 | 3014136-9.patch | 3.74 KB | wmcmillian |
| #8 | 3014136-8.patch | 4.57 KB | markhalliwell |
| #8 | interdiff-3014136-5-8.txt | 1.84 KB | markhalliwell |
Comments
Comment #2
markhalliwellHere's a patch that implements the very basic dialogOptions provided by jQuery UI itself. I know that core has its own dialogOptions it also sometimes passes, but not entirely sure if this is the best approach yet. I do like the explicit nature of this, but perhaps a more permissive filter that just checks if values are numeric or boolean like and then automatically converts just those?
Comment #3
markhalliwellComment #5
markhalliwellAfter discussing this with @plach, I think the simplest solution is to just serialize the data as JSON before it's sent and then deserialize it server side. This way it preserves the data types and we don't have to essentially keep a running schema definition which would constantly be under revision.
Comment #7
markhalliwellTagging it to get some more eyes on this. Not entirely sure why those tests are failing...
Comment #8
markhalliwellSeems overriding the existing variable causes some sort of serialization recursion. Using a new dedicated variable instead.
Comment #14
wmcmillian commentedReroll patch for v9.20
Comment #18
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.