3 ms·
You seem to imply that Mozilla's continously-breaking-extensions problem is proof that this is untenable, but I don't see any obvious connection between the two
by gcp 10y ago
You seem to imply that Mozilla's continously-breaking-extensions problem is proof that this is untenable, but I don't see any obvious connection between the two.
Because the breakage is inevitable as internals invariably change. That's why Firefox extensions break: the internals change, and add-ons depend on them. This causes a huge add-on churn each time the browser significantly changes, leads to abandoned add-ons, user and ecosystem frustration. It causes a pushback on the developers to make far-reaching changes (e10s being a clear example). It adds overhead as others try to mitigate the compatibility impact of changes (which was what the original poster was attempting and failing at doing, as was Mozilla's AMO team). The unrestricted power of the add-ons also leads to huge review queues, causing more ecosystem frustration.
Mozilla has given up on it. I would say the burden of proof is now on someone else to say it can work, because there's no more examples left: everyone who came after Firefox saw the problem and enforced a stable add-ons API that limits the internals' exposure.