4 ms·
It seems like their time would have been better spent forking and improving Greasemonkey, if they thought it wasn't user-friendly enough or whatever, instead of
by stratomorph 17y ago
It seems like their time would have been better spent forking and improving Greasemonkey, if they thought it wasn't user-friendly enough or whatever, instead of re-doing everything.
As I recall, there were significant problems with Greasemonkey's original approach of leaving privileged user scripts in the global namespace while untrusted scripts from the web execute, since it could wrap objects user scripts would later call, potentially turning any normal function call into a state-stealing XMLHttpReq. From a quick read of the jetpack site, it appears that user code does indeed remain accessible while untrusted code executes (since the jetpack.tabs object is noted to be "live"). I wonder how they deal with that problem of hostile-wrapped objects? [Edited for detail and clarity]
- stratomorph 17y agoI see a mention of what differentiates Jetpack: No, that’s not correct. Jetpack has access to the browser chrome - that is, the stuff surrounding the page you’re viewing - with simplifying APIs wrapping the more complex native APIs add-on developers usually deal with. This is about more easily authoring Firefox add-ons, not just tweaking page content. http://www.techcrunch.com/2009/05/20/strap-in-mozillas-jetpack-may-be-the-next-step-in-browser-extensions/#comment-2758706 http://www.techcrunch.com/2009/05/20/strap-in-mozillas-jetpa... [Edit: citation] I still think adding that to Greasemonkey would have been more productive. It sounds like Jetpack users run Firebug just like Greasemonkey users do, so I don't see the added value.