Slashdot Mirror

[T]here are two APIs. The internal “importer” API, which can only be accessed by [Firefox] extensions, allows you to perform arbitrary network and OS-level operations to get information into the system. The external “content” API, which can be accessed by any web page, allows you to request access to contact data (and then starts the “permission” dialog, where the user can choose what access to grant).

This website seems to be the place to find out more.

As I am curious, can a jetpack extension run a background timer independent of any window(as long as the application is running)?

Honestly, I don't know, but I imagine so.

Can a jetpack extension modify chrome elements and behaviours?

Yes. You can read more on the current version here: https://jetpack.mozillalabs.com/sdk/0.1/docs/ specifically the glossary might be interesting for a quick overview.

Is it just supposed to become a sort of official greasemonkey?

It is supposed to be a much more powerful greasemonkey, with a strong security system.

What happened to Weave, it's been kicking around for years?

It's actually been updated recently; it's at the 1.01 release, but they've changed a lot of the options to customize it or at least access them. I even ditched Xmarks in favor of it because of the tab and history sync, and they're looking to add extensions in future releases.. https://mozillalabs.com/weave/

They're doing that now, via (drumroll)... another extension! Which is going to be built into the browser!

Jetpack is the addon system for Firefox... It aims to allow addons to work in any browser version. It also aims to split apart the browsers performance being impacted with the more addons installed (in the current firefox the more addons the slow the browser is). To find the truth about the new addon system watch this: https://jetpack.mozillalabs.com/

Check out the products list at Mozilla Labs. There are some interesting ideas being tossed around. They are exploring sync technology in a project called Weave. There is a project called Prism that lets you split web apps out from the browser. It seems like Mozilla is also trying to evolve and improve the way people use and develop for their browser system. Take a look at that page and decide for yourself. I think the author of the article should have presented what else is going on with Mozilla's development vision and not just singled out Jetpack. It's only part of the picture. The article is really troll and flamebait.

I checked out the featured "jetpack image editor" and how EASY it is to write such a complicated feature in JUST 14 lines.

Gluing in some one elses code is not coding: $.get("http://developer.pixlr.com/_script/pixlr_minified.js", function(js){ ... } )

In fact, how many levels of derivation could a popular feature possibly use, my plugin references yours, references a library, that includes another external, etc.. all because some kiddies liked another kiddies script ad infinitum.

How many dependencies on servers having uptime, and being secure? Imagine a world of plug-ins that rerference each other so heavily that a cat on a certain keyboard could crash everyones extensions.

>So if this is the future...where's my jet pack?

right here: https://jetpack.mozillalabs.com/

I like the way Opera is doubly secure. Firstly it's a minority platform, secondly Opera are quick at patching vulnerabilities.

Opera kicks the ass of both Firefox and IE in my subjective 'elegance' benchmark too.

The only thing I wish they'd do is to run the Opera process in a low privilege protected mode on Windows like IE7+ uses on Vista and later. That would make it hard for any exploit to get from the browser process into your system.

It's not foolproof of course - see here (this exploit was fixed in Vista SP1)

http://www.uninformed.org/?v=8&a=6&t=pdf

Still nothing is foolproof. Defence in depth is still it good principle. Mozilla are considering it in FF too

http://mozillalabs.com/blog/2006/08/labs-ideas-to-investigate-survey-results/

Harder than what?

Harder than using XUL (which has Javascript in it) with XULConnect and XPCOM. It is kinda like writing software using Notepad/vim/emacs or Eclipse/Visual Studio. It is doable in both, but with the latter it is easier.

News to me. Which features can you not use?

Not all Javascript functions can be bound the Chrome API.

Also true for HTML.

And why is then Chrome did not use HTML to render its UI? Apparently, the UI is still C++.

Given that this is exactly what I'm doing right now, yes, I do wonder. Chromium has been on Linux for awhile, and official builds of Google Chrome exist.

Chromium != Google Chrome. It is like saying Google Chrome == Safari just because they use WebKit. Chromium is not Chrome just like SRWIron is not Chrome. Chromium is like Iceweasel (without the controversy) to Firefox as it is to Google Chrome.

You're assuming that it was UI that was the issue, and that doesn't seem to be the case.

Then please explain why after 1 year and three major version in Windows, why Google Chrome (not derivatives like Chromium) in Mac OS X is still developer preview? Is it really that hard to make a port?

Because Firefox 4 would be a new version of Firefox 3. Chrome was a brand-new browser. To complete your analogy... Wasn't Netscape only for Windows, at first? Certainly, Mozilla took time to get a Linux port working, though they might've had it by public release. It certainly wasn't "free", as they had to develop their cross-platform XUL engine first -- just as Chrome leans on Google's cross-platform GUI libraries and the cross-platform Webkit.

When Firefox 1 was released, it is already available for Linux and OS X. And BTW, Netscape is not written by Mozilla, Netscape is written by Netscape Communication. Mozilla Foundation does not exist until this decade. Netscape doesn't even use XUL until version 6 (prior to that Netscape is completely C++), so where did you find evidence that Netscape is having to create the cross-platform XUL for Netscape 1?

And they already have the faster C++, thousands of lines of which are now cross-platform. In short, I don't see why they'd use XUL for speed, but not C++ for speed. I don't think they chose XUL because of speed. I think they chose XUL because when it was developed, HTML wasn't anywhere near ready to do this kind of thing by itself.

Apple choose WebKit over Gecko for one reason only: cross-platform support. The current Gecko is still not crossplatform-friendly, but better than the early version of the rendering engine. XUL was chosen because using it will simplify Mozilla's heavy burden of making Firefox/Seamonkey cross-platform friendly. Considering the limitations of Gecko when it comes to cross-platform support, Mozilla can be commended for having released Firefox 1 on time for Linux/OSX users, instead of making them wait for 12 months as Google has done. Mozilla use XUL for cross-platform compatibility, not speed. And HTML is never designed to be used as UI anyway, unlike XUL who are explicitly design to be used as UI compositing.

Ok, then. Why not build a variant of XUL which uses HTML + CSS + Javascript, withaccess to XPCOM? It's just replacing the XML part of XUL with HTML. That was my point.

Why would Mozilla replace the perfectly fine XUL with another variant that uses HTML? If you want some HTML action, why do you take a look at Mozilla Jet Pack, which is yet another way to create extensions for Firefox? Look at https://jetpack.mozillalabs.com/

Well, the parts that are done in HTML can just use normal script tags, if that's what you mean by "attached". There are a few places where you can plug in Javascript, but not necessarily HTML/CSS -- but you can certain