Chrome 13 | Hacker News Reader

Chrome 13

googlesystem.blogspot.com

26 pointsGarbage19 comments

Finally, the Omnibox gets some love with partial URL/title matching. I switched from Firefox to Chrome for a while, and the Omnibox was my number one gripe: the URL matching was frustratingly poor, and it seemed to have no concept of sorting by recency or most visited. By comparison, the sort order in Firefox's AwesomeBar is so well-thought out that most of the time I can find the site I want in only a couple of keystrokes - yesterday, I needed to pull up a URL I'd used the day before, but all that came to mind was that it contained a '|' character... when I typed in '|', it appeared.

Maybe it's time for me to give Chrome another go, but it's got a high bar to beat.

There is also introduced css3 bugs on chrome 12 lion (corrected in v13), backface-visibility stopped working, and this was working on snow leopard (v12)

The only problems I've had with Chrome 12 were random pages crashing (especially on, coincidentally, google.com).

This was on Chrome 12 on OSX 10.7 I'll have to see how 13 behaves.

I've been having the same issue on 13 as well. Refresh usually fixes the issue though.

The same problem exists in 14 on Lion

13 is a really high version number. One thing I love about chrome is how silent the updates are. Other browsers tend to nag you about downloading the latest version, running an installer, etc..

Chrome updates much more silently + in the background, which is one of the many reasons it's my favorite browser.

I love Chrome, but it's almost unusable on Lion for me at the moment. Full screen support isn't very good, it doesn't work with desktop/spaces and it's felt more unreliable than in the past (though that's anecdotal).

How is it unusable for you? I'm on Lion too, and I find Chrome to behave pretty much the same as it did on Snow Leopard.

Edit: typo.

I get that dark blue "Aw, Snap" page quite a bit since upgrading to Lion.

I see prefetching of doom again. I hope they have thought about the obvious problem this can cause when the browser spiders all the links on the page:

People using the GET verb for deletions. Bad practice but common as dirt.

Ouch!

The article suggests that the page author has to explicitly request prerendering of a link with a "rel" attribute, possibly to avoid this problem.

Ack. Further research confirms your information:

http://code.google.com/chrome/whitepapers/prerender.html

Thanks for the heads up :)

Bust if you read the next section...

"Even if you do not proactively trigger prerendering yourself, it is still possible that another site will instruct Chrome to prerender your site. If your page is being prerendered, it may or may not ever be shown to the user (depending on if the user clicks the link)"

I posted similar concerns in a thread here yesterday which got little response.

Oh great - so non-deterministic behaviour adopted by the browser from instructions elsewhere. That's not good. Bring on the exploits!

Good job I've got a low IQ and use IE9 :)

I don't think it's actually any more powerful in that regard than, say, <iframe> tags. If your application lets users perform destructive actions with a GET request, you were already vulnerable.

This is true, but look at the state of most applications out there.

That makes sense, but it raised a question on my mind: What about malicious sites? Could this be used to do something without the user knowing?

One could mark a link as prefetch and that URL would be downloaded without prompting the user. Does that impose a genuine threat, or is that something that malicious sites can already do?

This can already be done by using a script or img tag load an arbitrary URL.

And if you have a well designed web app that can handle the extra volume, you can prefetch everything and get amazing response times.

Reply on news.ycombinator.com