Fix dropzone JS error when attachment is disabled

[wxiaoguang]

Fix #31485

[silverwind]

What was the JS error? dropzoneInst?.element not existant?

[silverwind]

Actually I'm not sure the fix is correct because querySelectorAll result is always iterable, even if empty. Would the proper fix not be dropzoneInst?.element.querySelectorAll in case the error was that the element did not exist?

[ukct]

The specific error thrown is
un?.element.querySelectorAll is not iterable (cannot read property Symbol(Symbol.iterator))

dropzoneInst is null when it fails.

[silverwind]

I can't seem to reproduce the original issue on either main branch or 1.22 branch with attachment.ENABLE = false.

All I can say for sure is that this ?? [] does nothing because querySelectorAll results are guaranteed to be iterable, so the root cause must be something else.

[wxiaoguang]

I can't seem to reproduce the original issue on either main branch or 1.22 branch with attachment.ENABLE = false.

All I can say for sure is that this ?? [] does nothing because querySelectorAll results are guaranteed to be iterable, so the root cause must be something else.

1. The root regression is Remove jQuery .map() and enable eslint rules for it #29272, it breaks the dropzone uploading, and it caused the null access because dz is null if the attachment is disabled.
2. Some following up changes didn't completely fix the null problem when the attachment is disabled, foo?.bar() always returns undefined if foo doesn't exist, no matter what bar() does.

[silverwind]

Please explain how this addition of ?? [] fixes anything here. As I see it, querySelectorAll can not return null or undefined so that fallback would never activate.

[wxiaoguang]

Please explain how this addition of ?? [] fixes anything here. As I see it, querySelectorAll can not return null or undefined so that fallback would never activate.

I have explained it above:

`foo?.bar()` always returns undefined if `foo` doesn't exist, no matter what `bar()` does.

Could you just try it by yourself?

const el = null; for (const x of el?.foo.bar()) {}

[silverwind]

Ah I understand now. Yes when the optional chain is triggered, we need the fallback.