I have been running a personal fork of noscript for over a year without issue; however it was recently flagged on Mozilla's AMO with this comment:
This add-on didn't pass review because of the following problems:
1) The add-on makes remote, synchronous XMLHttpRequests which have the ability to lock-up the browser UI and are therefore not allowed in public add-ons. Please use asynchronous requests instead.
nscl/common/SyncMessage.js line 243
nscl/content/patchWorkers.js line 113
These files are unchanged in my fork, so the relevant lines are here and here.
If applied consistently, this policy affects noscript and any add-on using the NSCL. Has it been encountered in the past, and are there plans to remove sync XHRs from the NSCL?
Separately, how critical are sync XHRs to NSCL/noscript's functionality? I may need to remove them at least temporarily from my fork.
nscl/common/SyncMessage.js line 243: It seems the browser.runtime.sendSyncMessage function with the offending line is only used as a fallback to an asyncFetch in StaticNS.js
nscl/content/patchWorkers.js line 113: Could this be converted to an async XHR? Looking at the code, that seems nontrivial, though it also looks like patchWorkers isn't being used by noscript at the moment.
I have been running a personal fork of noscript for over a year without issue; however it was recently flagged on Mozilla's AMO with this comment:
These files are unchanged in my fork, so the relevant lines are here and here.
Synchronous XHRs are also apparently deprecated.
If applied consistently, this policy affects noscript and any add-on using the NSCL. Has it been encountered in the past, and are there plans to remove sync XHRs from the NSCL?
Separately, how critical are sync XHRs to NSCL/noscript's functionality? I may need to remove them at least temporarily from my fork.
browser.runtime.sendSyncMessagefunction with the offending line is only used as a fallback to an asyncFetch in StaticNS.js