The devtools are indeed dockable on the right now in FF 22, but not responsive yet (so when little horizontal real estate is available, the tools will look and feel very cramped).
The upcoming versions address this issue (in the end, it's all just CSS; for example: [0]).
Also, clipboard data access. With Opera's switch to chromium, Firefox was the last browser without programmatic access to the clipboard[0] (though as usual MSIE has a non-standard implementation) so you had to listen for the paste event and post-process whatever garbage had been dumped in your paste area (and of course couldn't access high-level media types)
[0] Opera, as far as I remember, has neither clipboard access nor a "paste" event, the POS.
Yes and no, the website can access clipboard data specifically when you're pasting as a user-triggered operation (C-v/M-v or "Paste" from a contextual menu) (that is the clipboard data is only accessible from the `paste` event).
This allows an application to access alternative representations (the clipboard can store multiple representations of the same data e.g. text and html and image and whatever, and the application can then pick the most appropriate — or all of them) and to pre-process clipboard data before inserting it programmatically. Very useful with e.g. RTE. Arbitrary clipboard access most definitely isn't allowed.
In firefox, probably by going to about:config and setting `dom.event.clipboardevents.enabled` to `false`. In webkit and MSIE (which have had the feature for ages) I have no idea.
No, not unless you initiate a paste operation manually (literally, as in by hitting ctrl-v or etc.)
This is one of the ways that pasting images from your clipboard into, say, an image hosting site can work.
I had a difficult time finding fuller explanations of the capabilities - mostly because there isn't a standard API across browsers yet - but here[1] are the relevant Safari docs.
There's also a working draft[2] from the W3C for a standardized API.
It's a bit more complex: there are actually 2 flexbox specs with different syntaxes, one from 2009 (now deprecated) and one from 2011[0]. Firefox has supported the old syntax circa Firefox 2 (Safari from 3.1, Chrome from the first version).
Firefox never supported the old flexbox. It has XUL boxes (dating back to 1998 or so), which the old flexbox was syntactically, and somewhat behaviorally based on. But they predate those drafts by 10 years.
I'm not sure why you're asserting that when you're completely wrong. Not only did Firefox support the old flexbox, it still does as of Firefox 22: [0] still works and uses the old (and prefixed) flexbox syntax, and said old (and prefixed) syntax remains documented on MDN with a note that it's deprecated[1]
My point is that the syntax in question is used for XUL boxes, and has been for going on 15 years. It's not used for any sort of implementation of the old flexbox draft.
The old flexbox draft is similar to XUL boxes in some ways, and quite different in other ways. Trying to use XUL boxes and expecting the old-flexbox behavior as a result will land you in trouble, as happens with depressing regularity when people use "display: -moz-box".
The MDN documentation is sadly wrong, because it ignores the fact that the properties _look_ similar but have totally different behavior. Thank you for pointing that out; I'll make sure it gets fixed.
The OdinMonkey engine performance is impressive. The Lua VM benchmark[1] jumped from 110 points in Firefox 21 to 318 points in Firefox 22! Not to mention poor performance of Chrome.
Next, have a look at the Epic Citadel[2], which runs very smoothly in Firefox 22. Well done!
It's a bit unfair to mention Chrome performing poorly on these. Both are asm.js, which OdinMonkey is optimised for, V8 not.
That said, I'm very excited about asm.js (using it, in fact) and the performance in FF 22 blows me away as well. The V8 team appears to be working on asm.js optimisations, so soon we can have a fair contest :)
The best thing about asm.js is that the optimisations are really optional, unless your application is actually CPU-bound. The Unreal Engine probably is, to some degree. A simple 2D game like the one I'm working on certainly isn't. Not seeing it run any faster with FF 22, it's already smooth in older versions.
> It's a bit unfair to mention Chrome performing poorly on these. Both are asm.js, which OdinMonkey is optimised for, V8 not.
Actually Chrome has been optimizing for compiled C++ for a long time - Google even added Mandreel code to the Octane benchmark - and for asm.js specifically (which is a particular type of compiled C++) in recent months, as you can track here
From what I can tell, JavaScriptCore has had typed array support since at least as far back as December 2011 (http://trac.webkit.org/r103637, a random change in JavaScriptCore involving typed arrays).
Thanks for the info. Then I am really curious why awfy does not manage to run them properly. Perhaps it does not build JSC correctly somehow? I think that code is here
That looks like everything's being built and run in the correct way for OS X. Is there an easy way to run the benchmarks from that repository against my own WebKit working copy without having to set up all of the server-side support that the main README talks about? If I can run things locally I might be able to spot what's going awry with the asm.js tests for JSC.
I'm not familiar with building just JSC on Linux, but last time I looked in to it the only way to build JSC was as part of building all of WebKit.
Yeah, basically each benchmark there has a python script to run it. For example in benchmarks/asmjs-apps it is possible to run
python harness.py [SHELL_NAME]
and it runs all the benchmarks in that directory using that shell.
Regarding building, I've tried to build all of the Qt port on Linux (what the online guides mention), but always fail in the dependencies. Perhaps I'll try the gtk port.
Thanks for the pointer on running the tests. I noticed two big issues:
1. Some of the tests use shell functions like "read" that jsc doesn't provide. This is easy enough to address.
2. I was mistaken about the quality of the typed array support in JavaScriptCore. While the interpreter has knowledge of typed arrays, the actual implementation that's used when running in-browser lives in WebCore rather than in JavaScriptCore. When running in the shell only a bare minimum typed array implementation, primarily intended for JSC-only regression tests, is available. This trips up some tests since the implementation is much less complete than the one in WebCore.
Hmm, I am guessing the minimum implementation is also less performant (if it's just meant for regression tests)? So probably it would be unfair to measure on it.
I'm not sure about that. I'll follow up with some of my colleagues to see why typed arrays are in such an state.
Am I correct in assuming that if JavaScriptCore starts successfully executing the tests, it'll automatically start showing up on the relevant part of arewefastyet.com?
I am not sure about automatically showing up, but that would be my guess. I can ask dvander (who runs awfy) for more details if that would be useful. In any case probably it is very easy to change (disable/enable).
On my laptop, I got 419 points for Firefox 22 and 120 points for Chrome 28.
Of course, the Lua VM test is compiled to asm.js, so of course Firefox does really well right now. Exciting nonetheless - this opens so many possibilities.
It would probably be slower with emscripten in non-asm.js mode (asm.js format is more careful to not change types at runtime, etc.), based on benchmarks I've tested in the past. Have not tested on this particular one, though, if you check it out please let us know.
The nice thing about TypeScript is that it compiles to EcmaScript 3, so you can target older browsers and still use these goodies.
Also, TypeScript 0.9 is released, which includes niceties such as generics and type info overloading based on constant values passed in function parameters.
It's pretty slick, if only it could output code optimized for Google Closure's advanced mode, for tree-shaking awesomeness.
If you're a fan of Firefox I recommend using Aurora:
http://www.mozilla.org/en-US/firefox/aurora/
Aurora is basically the beta of Firefox. It seems to get incremental updates more regularly than Firefox. It very occasionally has issues with compatibility with plugins (usually when a version number is bumped) but I can't recall any stability issues in the few years I've been using it.
There is Firefox beta channel, aurora is a bit less stable.
Usually aurora still gets uncooked features pushed in, while beta only receives preffed features, unpreffed stable features or bug fixes
It doesn't update super frequently during the 6-week release cycle. Maybe once a week tops, I think? Hard to be sure, as I restart FF every few days anyway.
Before Aurora there's also http://nightly.mozilla.org/ one update/day. I've run it since shortly after they moved to a six week cycle (I ran Aurora initially) and have never had work loss. Only once in that period have I had to downgrade to Aurora for a day (the nightly build seemed broken, crashed on startup). Overall I'm very happy with getting features and speedups ~18 weeks before general release.
BTW, they must have more or less completely solved the add-ons version compatibility problem that was initially a big pain when they moved to the six week cycle; I haven't noticed any disabled or broken add-ons in a very long time.
A few years back they introduced a "restartless addon" api, so addons didn't use XUL (firefox's internal language) directly. This allows them to be both enabled/disabled while firefox is running, and not need to be rewritten every version. Look for the "restartless" tag on the addon website.
The six-week cycle probably helped as well, since there is less changes between versions; not to mention improved auto-updating.
A small nitpicky correction: XUL is a markup language, but one can certainly write Firefox UI using HTML or XHTML as well. The logic is written JavaScript.
For example, the markup view itself from the Firefox Developer Tools is written in HTML [0] and JS [1]. Other tools like the Network Monitor use XUL.
At the time I was trying Aurora, I kept hitting bugs with FF sync, ended up having to kill my profile a few times.
Also I just happened to occasionally hit plugin/add-on/etc bugs that would require me to kill and downgrade FF, losing ~10 minutes of work and my train of thought. It didn't take long for this to push me to the Beta channel.
Glad to hear Aurora is generally solid for you, though. Maybe I should give it another try.
I've felt like Firefox has been pretty light on features in its releases since it switched to rapid release, but this one is packed with stuff. Awesome!
It's becoming more and more rare for me to have to switch to Chrome to get a website to work correctly/acceptably, and I love it! Great job by the Mozilla team
The only broken-ness I can remember seeing for a long time in Firefox is in those demos and other little projects that pop up here where the developer forgot that browsers other than Chrome exist (or, are using Chrome only features).
I am for all intents and purposes a massive Mozilla fanboy, however I regularly switch to Chromium to use any nontrivial 2D graphics js (e.g. the Python plop profiler).
Not sure why, but Firefox definitely seems to have a weak spot around 2d (SVG?) performance
I submitted three (minor) patches for improving the performance of a couple of filters in Mozilla's SVG code. Those (minor) optimisations should be in this release.
I hope to do a lot more. I too, like you, am a Mozilla fanboy.
Unfortunately, in the last few months, I have a lot of pressure at my day-job (a few sudden departures). Nevertheless, I did contribute when I could spare the time and I urge you to do likewise. If there are enough of us, then there's always someone helping them out. It's a massive project and needs all the hands that kind developers are willing to spare.
If you (or anyone else with time...) want to be a true hero, figure out why font changes for text on canvas is a magnitude or more slower on Firefox than Chrome.
At least on the versions I've tested...
I have an app that places a few hundred text labels on a canvas, and on Chrome I can do that smoothly in a single callback. For firefox I had to use a hack with a queue that is processed a few items at a time with setTimeout() to prevent it from stalling the UI for many seconds... Even so, the experience is still worse on Firefox.
I'm happy to link into this if you point me to a testcase that shows the slowness. If it takes a few tens of seconds so much the better: easier to profile.
I've had some issues with internal sites I use at work that are auto-generated Microsoft stuff. And for a while I couldn't get the new Google Maps to load every time on Firefox. It seems to be have been fixed at some point since it runs fine in Nightly now though.
Flexbox. It's finally almost here. I cannot tell you how long I've waited for this to be supported by default in all of these browsers... as soon as Safari 7 is released, us developer sites will actually be able to make the switch. I honestly think wrangling the hacky current layout solutions is 25% or more of my time spent with CSS on a project, so hopefully we'll be able to build things much more quickly.
Wondering about the Web Speech API and speech input...Chrome does a great job, but doesn't seem to allow hooking up to 3rd party recognizers like Nuance or even something local.
Anyone know how Mozilla is going to handle this? Are they going to use Google's recognizers in the cloud?
There were rumors about third-party cookies being disabled by default in v22. I downloaded it and found this not to be true. Can anyone shed some light on when Mozilla plans on doing this? http://www.pcworld.com/article/2038956/mozilla-postpones-def...
Thanks for the update! We're working to have expected functionality when third party cookies being disabled. I'll keep an eye on when it's planned to be released.
The option has been in firefox as far back as I can remember. It's in the Preferences, under Privacy; you'll need to select "Use custom settings for history". I've never noticed any breakage, and I assume in-part because iOS and Safari set it as their default a few years back.
It's actually a pain in the butt to run anything but release firefox on Arch, because you either need to use a 3rd party repo or some AUR wrapper to auto-update the aur package.
That, and Nightly is kind of painful because its a 60MB update daily. I'm probably going to be skipping a lot of updates on it =P
> because you either need to use a 3rd party repo or some AUR wrapper to auto-update the aur package.
The other option is to `chown` the package directory, and Nightly will handle auto-updating. I only run on a 1 Mbit connection and I hardly notice when Nightly chooses to download the update on my Arch box, even while I'm actively browsing.
> its a 60MB update daily
The entire binary is ~32-33MB...I've never received an update that large.
>That, and Nightly is kind of painful because its a 60MB update daily. I'm probably going to be skipping a lot of updates on it =P
Is that a Linux/Arch specific problem? On OSX it'll download partial updates at just a few MB -- at least so long as you really do keep it updated nightly.
Well if you use the system package manager, and it doesn't support and use differential updates, then you have to download the whole package from your distribution's repository.
I'm being melodramatic is all. The Selenium FF driver lags a little behind Firefox releases (totally understandable).
Not a problem on my actual test boxes as I control the FF version on those, but it will lead to a week or so of devs (with FF auto-update set) complaining that tests are breaking locally. (Despite the fact that this situation and its remedy has been explained to them repeatedly.)
It is possible that S2.33 will work fine with FF22, making all this moot. And it's just a passing annoyance. I have nothing but love for both applications.
Out of curiosity, does this solve the memory issues caused by bad websites? Example, I have open three sites and my firefox memory usage is constantly increasing.
maps.google.com with route determined.
Hackers News, this story.
and the offending site, cycletrader.com where I chose a random ad from the front page that had more than one photo. All I did was cycle through the photos and leave the tab open.
Internet Explorer to the same sites does not even come close to the memory usage. In the time it took me to write this I have seen firefox go from 235m to 1.2g memory and IE stayed steady at 100m
The expectation of this release has been a fun ride for me. We were using long-live HTTP requests in our product for pushing data to the browser, a very elegant method but only implemented by Mozilla. Now were transitioning to websockets which aren't nearly as nice for this use, but I'm enjoying putting the newer, better-supported method in place on front- and back-ends.
Quit Firefox, vi into pentadactyl.xpi in your profile, edit install.rdf inside the xpi file (it's just a ZIP file) and modify the max supported version to 23. Save the install.rdf file, quit vi and start Firefox.
Pentadactyl will work, with some minor regressions (e.g. Google home page search box now steals focus) and 's' (google search) command prints error message: Error: TypeError: keywords in null, but the search works.
Anyone know when it will be possible to remove the title bar on OS X? With tabs on top it's redundant and Firefox uses more vertical space than Safari or Chrome.
There are various extensions floating around that claim to do this but they generally target much older versions of Firefox and don't work very well.
This is a great release! I wonder about this, though:
> The stack trace is now shown as a breadcrumb near the top
Who thought this was a good idea? This leaves room for about 3 items, whereas most stacks nowadays are much larger. A normal vertical list makes much more sense than a horizontal breadcrumb, IMHO.
According to the infographic, Firefox seems to be popular in North Korea, with 33.79% market share. I suppose they don't censor StatCounter in Pyongyang? /jk
Firefox can't do anything to prevent a plugin from crashing. That and I'd wager most of the Flash movies are very poorly coded, resulting in exceptions that could've been prevented. You can tell by browsing the web with a debug build of Flash.
I love Firefox. But, it's about damn time to remove the scroll bars on Mac OS X. This was a Lion feature and we're almost two versions removed from that.
Yup, Firefox is on a 6-week release cycle so it should be in the first week of August. (Right now 22 is "release", 23 is "beta", 24 is "aurora" and 25 is "nightly".)
Aside from compatibility testing, does anyone here really use Firefox much? I use Safari, with Chrome on occasion. That's about it.
I also recall that Firefox leaked a lot of memory, not sure if that's been fixed now.
If it's the case that IE is now a decent browser and Windows people use that or Chrome, and Mac people using Safari, I'm just wondering what spot or niche Firefox fills. I suppose in the Linux world, Firefox and Chrome are the only major options.
Well, if you are a keyboard person and don't want to go to a niche browser (like dwb, vimperator or jumanji), then Firefox+pentadactyl is better than anything available for Chrome.
I use Firefox on both Mac and Windows because of its extensions. Firefox allows its extensions to change more of the browser experience than other browsers do.
Highlights: WebRTC, asm.js, flexbox, and web notifications are present and enabled by default.