What's new in Firefox 3.5(developer.mozilla.org)
developer.mozilla.org
What's new in Firefox 3.5
https://developer.mozilla.org/en/Firefox_3.5_for_developers
33 comments
Congrats!
The audio and video element support is good for the open web but still needs work to be an alternative to Flash and Silverlight because currently it is too slow. It's not just because of Theora. Ogv videos play noticably better outside Firefox. Safari's video element support (using H.264) is much better.
I can't wait the day I won't have to load a Flash video.
It's such a painfull experience. It'll be the beginning of the end of Flash, which makes me happy.
It's such a painfull experience. It'll be the beginning of the end of Flash, which makes me happy.
I think the support for web worker threads (OS-level, presumably preemptive multithreading for JS) is potentially the most interesting part of this release, although I don't know how lock-free they are.
Moz: https://developer.mozilla.org/En/Using_web_workers WHATWG: http://www.whatwg.org/specs/web-workers/current-work/
Moz: https://developer.mozilla.org/En/Using_web_workers WHATWG: http://www.whatwg.org/specs/web-workers/current-work/
I really dislike this to be honest. Not having threads ensures the language is nice and simple and pure. Threads in what is pretty much an event driven language, make very little sense. What operations 'block' in js? Threads encourage sloppy inefficient programming.
If you start 20 WebWorkers, and it's faster than having 10, you have to ask some serious questions of the interpreter/VM. Like whether it's insane.
It should really be up to the interpreter/VM to be able to spread the work over multiple cores, not the programmer of the js.
If you start 20 WebWorkers, and it's faster than having 10, you have to ask some serious questions of the interpreter/VM. Like whether it's insane.
It should really be up to the interpreter/VM to be able to spread the work over multiple cores, not the programmer of the js.
In terms of the programming model, web workers are processes, not threads. They have no shared state, and use asynchronous message passing as the only inter-process communication - very much like Erlang. This makes them very simple, and fits in perfectly with JavaScript's existing asynchronous event-based model.
"What operations 'block' in js?"
Web workers are important because everything blocks in JavaScript. JS in the browser is single-threaded, which means that if you do anything computationally intensive (reading from a Gears database, sorting a huge array, image manipulation on a Canvas element) then your page can no longer respond to UI events until the processing is finished. Without worker processes, the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0).
(Note: I'm talking about the model exposed to JS programmers, not the underlying implementation which might be based on native threads, native processes, or green threads.)
"What operations 'block' in js?"
Web workers are important because everything blocks in JavaScript. JS in the browser is single-threaded, which means that if you do anything computationally intensive (reading from a Gears database, sorting a huge array, image manipulation on a Canvas element) then your page can no longer respond to UI events until the processing is finished. Without worker processes, the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0).
(Note: I'm talking about the model exposed to JS programmers, not the underlying implementation which might be based on native threads, native processes, or green threads.)
>> "the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0)."
Yeah I much prefer that method personally.
Yeah I much prefer that method personally.
Indeed; I kind of did the spec a disservice in calling it multithreading.
Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.
Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.
Hmmm. Brendan Eich in 2007:
http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre...
'''So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"'''
http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre...
'''So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"'''
From his comments on the same post:
"I think message passing shared nothing beats shared memory preemptively scheduled threads."
So Web Workers are an implementation of his preferred solution.
"I think message passing shared nothing beats shared memory preemptively scheduled threads."
So Web Workers are an implementation of his preferred solution.
Quite feature rich for devs. Geolocation, native video support, XmlHttpRequest across domains and offline/local storage are my favourites. And that is not even the end of the list.
Btw, have you seen this -> http://blog.mozbox.org/post/2009/04/12/Firefox-35:-a-new-exp...
Really excited to try out things with TraceMonkey and the DOM workers. Also:
"The String object now has trim(), trimLeft(), and trimRight() methods."
You know, it's a little thing, and easy to implement yourself, but I'm still glad this finally got added.
"The String object now has trim(), trimLeft(), and trimRight() methods."
You know, it's a little thing, and easy to implement yourself, but I'm still glad this finally got added.
Probably my favorite feature is the much-improved scrolling on OSX. It's just as smooth as Safari now.
Although 3.5 has some interesting stuff, I'm really excited for the Taskfox/Ubiquity integration (https://wiki.mozilla.org/Taskfox). I think it could actually make the Awesome Bar much better. Not to mention, I'm sure we'll see a lot more work on it once it's integrated into Firefox. Hopefully users will still be able to submit commands.
Biggest happiness for me: Improved Synchronous XMLHttpRequest support
Download link to Firefox 3.5 beta 4 (in case you were like me and it wasn't blindingly obvious): http://www.mozilla.com/en-US/firefox/all-beta.html
Did they allow users to disable the "awesome" (ie, "shitty") bar? Serious question, because at some point I'll have to switch to IE or something...
There are firefox extensions that turn it into a normal entry box, although personally I love the awesome bar. I can't switch to any other browser now because I hate having to type out the whole url all the time. I can just type "hac" in my toolbar to go to hacker news.
FYI, in IE8, typing "hac" in the url bar sends you to a google search on "hac". In Safari, you end up at http://hac.com.
FYI, in IE8, typing "hac" in the url bar sends you to a google search on "hac". In Safari, you end up at http://hac.com.
Seconded. The awesomebar is one of the best Firefox features.
How does anyone actually tolerate the awesome bar? When it debuted, I thought it was some kind of prank.
I still kinda do.
I still kinda do.
You can turn autocomplete off or have it only complete history/bookmarks (I just upgraded and checked.)
This turns all completion off though, even URL prefix matching (as opposed to the awesomebar 'anywhere in the URL/page title matching'), which I'm guessing you don't want. There are some entries in about:config (browser.urlbar.match*) that might make it do what you want.
Safari 4 does some subset of the super-matching thing too now; I find it kind of a mixed bag (I end up autocompleting to HN/twitter way too often) but am slightly on the side of it being helpful, although more intentional history search would probably work just as well.
This turns all completion off though, even URL prefix matching (as opposed to the awesomebar 'anywhere in the URL/page title matching'), which I'm guessing you don't want. There are some entries in about:config (browser.urlbar.match*) that might make it do what you want.
Safari 4 does some subset of the super-matching thing too now; I find it kind of a mixed bag (I end up autocompleting to HN/twitter way too often) but am slightly on the side of it being helpful, although more intentional history search would probably work just as well.
Would be nice if they could speed it up a little.
how is it shitty? I personally think its great, since you no longer need to remember urls, since it matches both urls and page titles.
I find that the awesome bar is increasingly awesome with more usage. I didn't like at all at first, but it really grew on me after a while.
As far as I know, there is no official plan to remove the "awesome bar".
Also, I can't until Ubiquity becomes standard. There's a disappointing lack of plugins for it at the moment, and standardization will really help that. :)
As far as I know, there is no official plan to remove the "awesome bar".
Also, I can't until Ubiquity becomes standard. There's a disappointing lack of plugins for it at the moment, and standardization will really help that. :)
The new geolocation feature is creepily accurate. This page found my exact location.
http://channy.creation.net/project/firefox/geolocation.html
http://channy.creation.net/project/firefox/geolocation.html
+ Mibbit as default IRC:// link handler