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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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 !
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.
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.
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.
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.
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).
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.
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.
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?
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.
[1] - https://intoli.com/blog/running-selenium-with-headless-chrom...