Chrome 59 stable released | Hacker News Reader

Chrome 59 stable released

chromereleases.googleblog.com

136 pointsbd8279 comments

As others have mentioned, the most exciting thing about Chrome 59 is that it is the first release with headless support. I wrote a guide a while back on running headless Chrome with Selenium that someone might find interesting if they're interested in trying out Chrome in headless mode [1]. It's quite a bit easier now that the stable channel is on version 59 and I just updated the guide to specify which steps are no longer necessary.

[1] - https://intoli.com/blog/running-selenium-with-headless-chrom...

Thanks, I enjoyed reading it (in spite of the pop up!). I think sooner or later someone will use this method to crate a (local, self-hosted) tool to manage FB posts without actually using FB. Finally!

Thanks for reading it and I'm glad that you liked it!

Sorry about the pop up... I'm not a huge fan of them as a user myself, but we only show it on the first post that you read and it drives a lot of sign ups for our monthly article newsletter. We try our best to only put out high quality articles and to keep the intrusiveness of marketing widgets to a minimum.

Mmaybe consider collecting sign ups in a different way? Now that you know modals are amongst the most hated strategies.

https://www.nngroup.com/articles/most-hated-advertising-tech...

Hey don't they put that in the release notes.

Ps, great post!

If you're reading Hacker News, the developer release notes are probably more up your alley (they do mention this)

https://developers.google.com/web/updates/2017/05/nic59

https://developers.google.com/web/updates/2017/04/devtools-r...

I subscribe to the blog via RSS.

Lots of people are mentioning headless support, but has it made it to Windows?

Headless in Windows is fully supported in Chrome 60, which is now the Beta. Mac and Linux are in great shape as of 59.

I tried it out yesterday, moving our unit tests from PhantomJS to headless. Short answer is it's not fully working yet, the browser still pops up with a blank interface window, but unit tests work as expected.

I tried out the PDF and screenshot stuff, but they didn't seem to be working on Windows yet. Remote debugging is fine, but as mentioned, you get the blank interface window, so it's not really headless yet.

I came across your blog post while implementing this week. Thanks for writing it!

Did you have any issues with send_keys? There is a bug I ran into with upstream chromium [1] but there is no mention in your examples

[1] - https://bugs.chromium.org/p/chromedriver/issues/detail?id=17...

Does anyone know if they got the WebGL support for headless working? There were issues last time I checked.

So if I'm reading your site correctly we no longer need to compile Chromedriver in order to use headless? 2.29 will work with the headless option?

According to [1] Chrome 59 still is not supported.

[1] https://chromedriver.storage.googleapis.com/2.29/notes.txt

Ok that's what I was thinking. The OP's blogpost was a little confusing in how it was worded. I think I'll be sticking with Phantom until chromedriver stable is updated.

Has there been any research on whether Material Design has superior UX for desktop use?

I've just tried the new settings screen on Chrome 59, and personally I find it far, far worse than what it was previously. I hate this trend of hiding essential top-level navigation behind a hamburger menu, especially on desktop.

It seems like an excellent idea that is only an idea. I was pro at first but most of the time I dread a little. Only advantage is that it suits mobile a little bit, and now google has mostly one UX.

I'm not sure it's "hidden" in this case. In fact, the hamburger seems to just open "shortcuts." The fact that I can click Advanced and see where Passwords are is a big improvement, in my opinion. One of the main reasons I go into settings is to manage my passwords. I always had a hard time visually scanning for them with the old layout. So there's one tiny drop of anecdotal evidence that it's a little better.

Actually on material design, I liked the look though it smells a bit classic as of now.

But what I dislike the most is that I have to navigate and click more than necessary for simple tasks.

I struggle with what things are buttons in material design. Everything looks flat, so clickable things look like labels to me. Especially buttons that aren't rectangles.

Try reading a material design page or app on a shitty old TN display and you are in for a treat. It is virtually impossible to tell forground from background because all the "light gray" colors look the same on such a display and the gray-ness also changes with the viewing angle.

Yes as much as I'm not a designer I dislike the usability of flat designs

actually material design says otherwise it is just Googlers doesn't follow material design specs

https://blog.prototypr.io/mobile-first-desktop-worst-f900909...

I was expecting the easy path to display certificate view (removed in 56) to be returned in 59 [1], but apparently it will be in 60 behind a flag [2].

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=663971

[2] https://textslashplain.com/2017/05/02/inspecting-certificate...

After 5+ years using Chrome, this single change made me move to Firefox.

Hit similar problem and after go through bunch of trouble when I worked to update decade old website with non-UTF8 encoding and it's end up that Chrome removed that trivial encoding selection feature from menu.

So I switched back to Firefox after probably 7 years with Chrome / Chromium and absolutely happy with it. Also end-up that modern web pretty much usable with NoScript and ability to install some YouTube enhancement addons is nice.

You should try umatrix sometimes. It's made by the same person that created ublock origin and has a wonderful script blocking UX

I still don't get why they did this. It's just a huge step back in every single way I can think of.

For now, you can star the issue I linked to.

It is so needless too. Users already had to click "Secure," and then a blue link, all they did was change a useful blue link (to the certificate info) to a useless one (Learn More[0]).

As a technical user, I was using certificate info multiple times a day, even on sites where I didn't want nor need the developer bar open. Now I keep on opening the Developer Bar to check the certificate and it shoots me straight into emulation mode, disrupting my entire workflow.

They should just re-add it at the bottom by "Site Settings."

[0] https://support.google.com/chrome/answer/95617

That's what I was wondering. Whose brilliant idea was this and what was the rationale, does anyone know?

There are quite a few decisions/bugs/lack-of-feature I see in google product that makes me wonder to whom such things make sense or doesn't matter.

You can view the certs on the network tab of the developer tools without flipping any switches, right?

I too wish this was part of the main address bar SSL status UI but was slightly relieved to find that it hadn't completely disappeared but rather been buried.

It's in the "Security" tab of the developer tools actually.

Wow. I thought it's a bug in my copy. I tried furiously clicking around and the popup had no cert-info. That's really bad! Bring the cert info feature back! Why should I trust HTTPS if one cannot even read basic cert info to begin with!? Even IE11 has it, as does FF.

For those interested: headless is coming to Firefox as well. https://bugzilla.mozilla.org/show_bug.cgi?id=1338004

Forgive the ignorance; what is headless?

A browser instance without a graphical interface. https://en.wikipedia.org/wiki/Headless_browser

What's the benefit of this? My uneducated guess would be faster automated testing?

With the new optimizing compiler (Turbofan) landing, JavaScript `Exception` are now usable without significant performance penalty: great news !

A bit of context: v8 used to have troubles optimizing code which contained `try/catch` sections, which led to massive performance issues on hot parts of the code in Chrome and deterred a lot of people from using Exceptions in JavaScript (including node). Glad to see this bug finally fixed !

More infos on the new v8 stack here: https://v8project.blogspot.fr/2017/05/launching-ignition-and...

Can someone explain or point me to a good source of info on why headless Chrome is a big deal? (Not being snarky; I really want to know).

pretty much replaces http://phantomjs.org/

Now when Chrome has headless support and the same feature for Firefox is coming later this year it becomes way easier to run tests using real browsers in CI environments.

Makes it much easier to use in continuous integration scenarios.

For example running tests in a browser in your pull request voter.

Advanced web scraping simplified - the ongoing war between people who want content vs. those who want to make sure only the "right" people can get their content just shifted dramatically!

Is there a good documentation on chrome's remote debugging protocol? I'm trying to implement a python wrapper[1] around the protocol, but I can't find some good docs.

[1] https://github.com/yifeikong/chrome_remote

Sorry I'm not sure. What I am sure of is that you can google as well as me (if not better) on this subject, but here goes:

https://github.com/ChromeDevTools/awesome-chrome-devtools#ch... has a buch of pointers and mentions the Python-based https://github.com/iiSeymour/chromote (235 stars) - if you've got something going, try to add your project to the list!

Also found https://github.com/minektur/chrome_remote_shell (51 stars) and https://github.com/mirumee/chromedebug (26 stars)

Testing and continuous integration are already mentioned, but there's also two features that might be of interest to a lot of people.

Screenshots via --screenshot on the command line.

Dump page to pdf via --print-to-pdf

You no longer have to run X windows (or xvfb) in memory to run and test on chrome. Chrome headless will render completely on it's own.

I thought they were dropping some support of SSL certificates in regards to symantec [0] starting in 59 but I see no mention in this post (unless I missed it). does anyone have further information? I am not familiar with blink process however allowing insecure creation of ssl certificates seems like the wrong way forward.

[0] https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

I am also interested in this. This whole process has been a shitshow. I'd just like a decision to be made and a little warning so that I have time to replace my RapidSSL certs (they are signed by GeoTrust which is owned by Symantec).

Google and Symantec settled on this. Symantec will create new certificate roots which will be cross-signed by both their existing roots and another certificate authority. This allows the trust in the existing roots to be removed in the long term and it has significantly less impact for current Symantec customers than the original proposal.

A good summary of the latest developments can be found on https://www.thesslstore.com/blog/google-and-symantec/

The real update is in the DevTools: https://www.youtube.com/watch?v=PjjlwAvV8Jg

Is there a particular timestamp I should jump to?

Check out the blog if you prefer to read about it

https://developers.google.com/web/updates/2017/04/devtools-r...

Anyone seeing a failure in https://websocketstest.com (Chrome 59.0.3071.86) ?

https://websocketstest.com/result/7629067

It works fine on Firefox 53.0.3 and 55.0a1 (Nightly).

Console says:

scriptaculous.js:31 A Parser-blocking, cross site (i.e. different eTLD+1) script, https://ajax.googleapis.com/ajax/libs/scriptaculous/1.8.3/bu..., is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

WebSocket connection to 'wss://wss.websocketstest.com/service' failed: Error in connection establishment: net::ERR_INSECURE_RESPONSE

EDIT: Disabling "disallow-doc-written-script-loads" has not effect.

Has reverse image search on right click ( Search Google image / Search Google for this image [1] ) been removed off late, from Chrome?

Now all I have on right click is "Copy image address".

That's a fairly heavily used feature. Surely, they couldn't have done away with it.

Didn't find any posts of substance in the product forums either.[2]

Some have suggested that removing Google as the default search engine rids the right click of that feature. However my default search engine has never been not Google.

[1] https://www.andrewhawkes.co.uk/images/articles/search-google...

http://1.bp.blogspot.com/-pYcECahKm44/VLAMW-n7hQI/AAAAAAAAAc...

https://2.bp.blogspot.com/-USmwx_yMwIU/Uheyv5gRzBI/AAAAAAABL...

[2]

https://productforums.google.com/forum/#!topic/websearch/Qa_...

Still there for me.

"Search Google for Image" is still there for me, even on the latest Chrome Beta channel build.

macOS Sierra Version 59.0.3071.86 (Official Build) beta (64-bit)

Thanks to all who replied!

I found the solution to this bug in a post on the Google Chrome Help Forum from way back; 11/28/10 to be precise.

Solution for anyone else who happened on this bug:

https://productforums.google.com/d/msg/chrome/sq-RT8-eIm8/ZM...

The portable version was also posted yesterday: https://portableapps.com/apps/internet/google_chrome_portabl...

It's handy for trying it out without installing the full app and update service on Windows. Or for running Stable, Dev, Beta on the same machine with separate profiles without needing command line switches.

This version of Chrome has support for running headless (without the need for a graphical environment at all). Awesome for automation and testing.

Does Chrome 59 come with Ignition / Turbofan for V8 enabled ?

If i read this correctly, it does ...

https://v8project.blogspot.com/2017/05/launching-ignition-an...

Running Linux and i3wm. After updating to 59, Chrome didn't seem to automatically detect my DPI settings, so I had to manually specify the scale with

   --force-device-scale-factor

Previously did not have to do this.

Nice! APNG is finally supported.

Thanks for the heads-up, now I can remove that extension!

https://chrome.google.com/webstore/detail/apng/ehkepjiconegk...

One I've been looking forward to for a while: native notifications on OSX!

I'd like to make 'screenshots' for different pages on my server. Is there a way to do this with headless chrome without restarting chrome each time? Some sort of easy to use API for this?

Sorry for this, looks like selenium works just fine.

https://github.com/wkhtmltopdf/wkhtmltopdf

I have been using request blocking in developer tools for the last month. It's really made some aspects of development easier for me. I hope Firefox follows suit and adds it.

This finally kills CentOS 6 support...

I have been using the headless mode for a while (on unstable). It's been awesome!

Headless chrome is very exciting

What is the difference between Chrome and Chromium these days?

IIRC Chromium is Chrome without the Google stuff.

Also, chrome has inbuilt flash support maintained by Google.

And Chromium apparently does not ship with H264, interesting!

yea headless for CI!

When will they fix https://bugs.chromium.org/p/chromium/issues/detail?id=423609...! It's really annoying to find this one when you're getting companies to switch to Chrome from IE and end up with this in your lap instead :(

Reply on news.ycombinator.com