As someone involved in the WebExtensions Community Group who has been (slowly) trying to figure out what, if anything, we should do at the platform level around these use cases, I appreciate you raising and repeating this concern. I'd be obliged if you have any other recommended reading around this topic.
Oh, this is interesting! I assume most of the heavy lifting to identify and filter content is being performed by the content script. In practice have you see any issues with models accessing page content before the extension has been able to sanitize the page?
Do you mean Firefox on iOS? If so, that would require the firefox-ios project to adopt BrowserEngineKit, which is relatively new. Firefox for iOS WebExtension support is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1497374
Just took a quick glance at your extension and observed that it's currently using the "debugger" permission. What features necessitated using this API rather than leveraging content scripts and less invasive WebExtensions APIs?
Simeon from the Firefox Add-ons team here. Sorry about the rocky experience. I realize this is a bit late for your situation, but earlier this year the source code submission docs were updated with information about the default reviewer build environment[1].
It's not a huge improvement, but it sounds like one thing we could do to improve the communications process around build errors is to include a link to this documentation in the notification email sent to developers. I'll create a ticket for this now.
I was about to say "concurrent writes shouldn't be a problem because localStorage is synchronous and JS is single-threaded," but then I started thinking about multiple tabs, WebWorkers, and multi-process browsers and figured I should double-check the spec.
> Warning! The localStorage getter provides access to shared state. This specification does not define the interaction with other agent clusters in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.
reply