3 ms·
Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to ex
by ethbro 10y ago
Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to explicitly mark unsafe bits.
For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me.
I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.
- Yoric 10y agoI'm pretty sure that there is some such mechanism. At least, I've seen patches related to such a mechanism. I don't remember the specifics and I can't find the documentation right now, but I seem to remember that there was something called the "WebExtensions Extension API" or something such that let developers access existing unstable APIs. It's probably somewhere. Note that in this case, we're not discussing (only) "unsafe" APIs but also "unstable" APIs that can change from one day to the next without warning.