Mozilla Firefox 14.01 release notes... | Hacker News Reader

Mozilla Firefox 14.01 release notes...

mozilla.org

85 points01Michael1043 comments

I'm pretty happy about the click-to-plugin. I have to use java on two sites and absolutely hate it when any other page has java content. I already use flashblock to get this behavior with Flash, and having it for the media plugins would be great too.

I like it as well. For those who haven't turned it on:

  1. Go to about:config
  2. Set plugins.click_to_play to true

Really excited about the pointer lock API. Makes the browser a viable gaming platform now.

Edit: There appears to be a bug in the pointer lock code - not sure what's going on, but my mouse is getting locked into the wrong monitor if I move the Firefox window between monitors.

Now that sounds like it could be really annoying. Even more than websites saying "You may not right click".

This is very different. Preventing rightclick can be done silently, without the user intervening. Mouse lock, on the other hand, must be explicitly accepted by the user.

In fact, the current implementation ties this to fullscreen, combining the prompts into one. In other words, the only way mouse lock will happen is if the user clicks on a button for fullscreen and then allows the site to use fullscreen+mouse lock. So there is very little risk of annoyance here like there is with rightclick prevention (but is still exactly what a first person shooter needs).

This is the first browser to ship with this feature enabled, so overall the web isn't quite ready yet. But hopefully other browsers will follow suit soon.

In Chrome: Go to chrome://flags/ and enable it.

Demo: http://media.tojicode.com/q3bsp/

Some docs:

https://developer.mozilla.org/en/API/Pointer_Lock_API

http://www.chromium.org/developers/design-documents/mouse-lo...

Yay, pointer grabs in user-supplied code! What could possibly go wrong?

https://encrypted.google.com/search?q=x11+mouse+grabs+proble...

For those not familiar with the problems: pointer grabs are notorious for being a pain to deal with. They have many strange corner cases and security problems. They also have weird interaction issues with things like modal windows, popups, screensavers and the like.

My understanding is that the app must be fullscreen, and the user can always escape fullscreen and pointer lock with the ESC key. I guess there is a risk that the browser could hang in that state, though, which makes it even more important for Mozilla to focus on their browser's stability.

> My understanding is that the app must be fullscreen, and the user can always escape fullscreen and pointer lock with the ESC key.

It is similar in other windowing systems. But, but...

You are in fullscreen mode with a pointer grab. An important window pops up over the full screen: "10 minutes of battery remaining". What is the state of the grab while this window is shown? Will the code holding the grab be notified of this window? How will the pointer grab behave while the pointer is over the other window? Will the other window able to gain focus with a click? Should windows over other fullscreen windows be allowed at all? In general, how will the pointer grab reflect on the OS windowing system's pointer grab?

Past windowing systems tells us that it is extremely difficult to get all this right if the code doing the grab and doing the window management are the same code, something that is not going to happen with web apps.

Since there's a good chance moving the mouse is moving some gun around in 3D space rather than any visible pointer, the answer should be the same as for normal 3D games: to use the pointer or other windows, you must press ESC.

As mentioned on a comment a little below, this was designed with security in mind. Requesting mouselock can only be done together with requesting fullscreen mode, which is only possible in response to user input (like pressing a button) and after that requires explicit authorization. Afterwards, pressing escape will always leave both fullscreen and mouselock.

Glad to see the screensaver/power save inhibit API https://bugzilla.mozilla.org/show_bug.cgi?id=697132. I was surprised when HTML5 <video> didn't do that from the start

Yes, browsers should take responsibility for doing it without asking the web devs to handle it, with the possibility of messing it up.

Operating systems have spent years dealing with power saving policies and application requests for keeping the display/disk/music/connection on. After about 10 years we are now reaching a point where all this have acceptable defaults and decent GUIs to change the settings to suit one's needs. Now all this will have to be redone again inside the browser.

Shortly people will complain that the browser did not let the monitor sleep at the end of a video/movie. Or, in the future, that the browser did not prevent the computer from going to sleep while the music was playing AND that the browser let the computer to sleep while the music was playing.

No Retina support :( There is a temporary fix for that, but it requires layers.acceleration to be disabled.

Well you saw how long it took to get OSX full-screen support. I wouldn't hold your breath about retina.

Why the "..." ? Am I missing something?

Probably the "big" list of brand new things, like putting another letter ("s") in the call to Google Search, implementing full screen for some of the Apple users, and implementing a feature that was available via plugins (click to play) since version... probably 2 or 1, can't remember.

It probably implies "yet another Firefox release (without many significant user-facing changes)..."

There seems to be a general grudge among somewhat technically-minded people against the entire phenomenon of new Firefox releases since Firefox switched to its frequent release model.

I loved the official announcement of Chrome 20:

http://chrome.blogspot.com/2012/06/yet-another-chrome-releas...

yeah, like there shouldn't be any release logs in shorter development cycles...

Once they stop publicizing version numbers, this will probably die down.

For the past year, Mozilla has never mentioned version numbers in the official announcements of new Firefox releases. For example, the Firefox 14 announcement:

https://blog.mozilla.org/blog/2012/07/17/new-security-and-de...

Right, but the Firefox download page has the version number right on the download page. If/when auto-updating in the background works well, that should go away.

Not at all. Most people don't care about the frequent updates. I certainly don't. I get a daily update. There's simply a section of the geek population that likes to whine loudly. If you don't like Firefox's update cycle switch to Chrome.

If you read my comment slowly, you'll note that I didn't express any dissatisfaction with Firefox updates, and said "somewhat technically-minded people", which corresponds to your definition of "a section of the geek population".

So does this now use SPDY to connect to Google's servers by default?

Yes, Firefox has SPDY enabled by default starting with 13.0: http://www.mozilla.org/en-US/firefox/13.0/releasenotes/

Not just Google's servers, but any server where SPDY is available (e.g. Twitter).

This is handy: https://addons.mozilla.org/en-us/firefox/addon/spdy-indicato...

really though, just google's servers because google is the only spdy-enabled site where https is forced. twitter doesn't come in over spdy unless you type in https.

Twitter does have an "Always use HTTPS" option for when you're logged in.

here's a counterpart for Chrome if anyone's interested: https://chrome.google.com/webstore/detail/mpbpobfflnpcgagjij...

I just installed it, seems to work as expected. Shows the indicator on both Google and Twitter

Favicons are not displaying in the address bar... erm, WonderBar or MarvelousBar or whatever it's called now... AwesomeBar?

Anyway, they show up in the sidebar (e.g. a new bookmark) but not in the AwesomeBar. Maybe a an issue in combination with extension IdentFavIcon (0.3.4.7)?

I know, HN is not a bug tracker. But since the thread's already here.

They were disabled intentionally, now displays the "trusted" status. This was to avoid some malicious sites putting a lock icon, thus pretending to be "safe" sites

I actually had a moment of speculation in that direction, but then figured that it would be contrary to the trends/momentum in... I don't know, "design" and "image" and, well, "looking pretty".

Thanks for the information. And I'm kind of glad to read it. :-)

P.S. Shame on me, for not looking further into the release notes -- although I did take an initial look but didn't note this change.

P.P.S. http://blog.mozilla.org/ux/2012/06/site-identity-ui-updates/

> Full screen support for Mac OS X Lion implemented

Aaaand fuck.

I still don't get why everyone is so pissed off about fullscreen.

OK, sure, with two monitors, it renders the second display useless. I get that.

So why don't you just not use fullscreen mode, and continue doing everything you've been doing with dual monitors since the days of OS X 10.0 ?

You lose nothing, and gain nothing, so it makes absolutely 0 difference in your workflow.

> I still don't get why everyone is so pissed off about fullscreen

1. because it's garbage

2. because applications which used to have a working fullscreen mode — such as firefox — and get converted to the Lion API result in no gain and lots of pain

> So why don't you just not use fullscreen mode, and continue doing everything you've been doing with dual monitors since the days of OS X 10.0 ?

Like use fullscreen mode on Firefox, which has been there forever? Oh wait, now I can't. Just as I can't use fullscreen mode on, say, Quicktime X. Or have movies display on the big screen. I didn't really want them on the 27" anyway, the 15" is so much better isn't it? Pulls you closer to the screen, unless you don't care for the picture.

> You lose nothing, and gain nothing, so it makes absolutely 0 difference in your workflow.

Yes actually: Firefox still had a fullscreen mode which actually worked correctly. Now it does not, unless there is some sort of hidden setting able to toggle back to the "old" API as there is in VLC.

I'm going to try and counter this:

>2. because applications which used to have a working fullscreen mode — such as firefox — and get converted to the Lion API result in no gain and lots of pain

As a Macbook Pro user, I've been looking forward to Firefox's implementation for a while. Applications that take advantage of Lion's fullscreen API allow me to easily swipe between multiple apps with the trackpad, which make using a laptop significantly nicer without needing to use an external mouse.

It is essentially broken for people who have multiple displays and Apple sucks because of it. But it's not broken for everyone and provides significant functionality for a lot of people.

FWIW, Mountain Lion will fix this and comes out in about a week.

It doesn't fix the fact that you're left with one (or more) useless displays in full screen mode, but it does let you choose which display to do the full screening on.

Unless I have missed an article stating otherwise, there is a lot of noise about it not being fixed in Mountain Lion:

http://news.ycombinator.com/item?id=4235432

The problem that remains in Mountain Lion is that you can only use 1 display at a time when in full-screen mode.

It's better than Lion in that you will be able to choose which of your displays is used to go into full-screen mode, rather than always just using the 'main' display.

Disclaimer: I haven't actually tested in Mountain Lion, but this is the only consistent explanation I've been able to gather from careful reading of people's complaints and Apple's description of the feature change.

> You lose nothing, and gain nothing, so it makes absolutely 0 difference in your workflow.

It does to some people. To steal from my comment a few days ago:

"I could care less about Apple's Fullscreen API -- what I hate is that apps are replacing their old Fullscreen behavior (like Chrome has) in favor of the Apple standard. Which led me to make this comment on a Firefox 12 HN post a few months ago: "... it will be a shame when they implement full screen if it takes away the current layered option. Firefox is the last major OSX browser to work in fullscreen while still allowing apps to be above or below it. With Moom's hotkeyed window positions--it's extremely convenient to bring a text editor to focus and still be able to scroll the web in the background. Mozilla, please don't let this happen!" Apple's Fullscreen API just seems like a lazy approach to delegating UI real-estate and the last thing power-users would want."

Reply on news.ycombinator.com