116 comments

[ 3.6 ms ] story [ 193 ms ] thread
Happening to me, too. When searching directly from the address bar, it appears to be loading my Google search results and nothing ever comes up. Going to Google directly and search is still fine.

It appears to be Chrome's ability to translate your text into a search query string. For instance, if I just type "y combinator" in to the address bar, it craps out. But if I type "google.com/search?q=y+combinator" it behaves as one would expect.

Yep. Happening here too. Apparently I don't use that feature as much as I thought.
Disabling all extensions and restarting didn't help me - however, incognito mode did. (And so did Firefox :)
I'm having this issue too. Numerous people are finding that turning off "Instant Search" in Chrome is fixing it, but it was a non-starter for me.
Odd. I actually already had mine turned off so I tried turning it back on and it looked like it was working. I then turned it back off and it continued to work.
(comment deleted)
Oh, didn't know this was a widespread problem. Happened to me as well. The search results display for a fraction of a second then I get the blank screen.
Driving me crazy; just started happening tonight.

Found the only way to get it to stop was to quit the browser completely and restart or to open an icognito window.

I'm using Version 20.0.1132.47 beta.

Same problem here. Seems to happen when you're in a logged out state. Wonder how QA missed this. Maybe we can help out, go star this issue in the Chromium bug tracker in case it affects the FOSS edition as well. http://code.google.com/p/chromium/issues/detail?id=84679&...
That's a different bug. The problem people are seeing today is a redirect to google.com/blank.html which is of course a blank page.

Edit: ah I see reports further down that bug mention blank.html

Not sure if it's related, but as I write this, Google Drive is down for me; gives a "This app is currently unreachable" error.

Perhaps some piece of Google identity/auth infrastructure is down right now.

Just started happening to me, thought it was some weird glitch with the Win8 preview. Good to know.
From the giant thread, user BolshoiBrit:

Found a work around:

Add a new a search engine in wrench >> settings >> search "Manage Search Engines". Under "other search engines" add a new search engine using this address for the URL http://www.google.com/search?q=%s

Name it "Google 2" or whatever you want. Works like a charm.

-B

I suggest trying DuckDuckGo, a search engine that doesn't track you. Same instructions but replace the search url with: https://duckduckgo.com/?q=%s
Unfortunately DDG's results suck. Nobody really cares about Google's 'tracking', people use them because they work.
Interesting, what makes you say that DDG's results suck? I've been using it as my primary search engine for a few weeks now and aside from it not including a map in results unless you give it a very explicit address, I've found it no worse than Google's results.
(comment deleted)
Maybe not for US queries, but they are kinda lacking for the rest of the world.
ghostfish's message is now gray, so I guess he has been downvoted. Can anyone explain why?

My experience with DDG has been very similar to the one cited by aw3c2: I used it as my primary search engine for a couple of months, and eventually found myself always using !g, so I switched back to google.

We've made a lot of relevancy and speed improvements lately. If you have any specifics, we'd love to hear them. A good way is to try it for a week, collect all the ones that suck and send them to https://duckduckgo.com/feedback.html -- we're listening!
No way, DDG results are great. Only about 1 in 10 times do I end up searching again on other engines.
For me it depends.

On programming searches DDG goes better for me (than Google) because it uses the English data. Google insists on using Spanish data even though I disallow results in other languages than English or Catalan.

For other searches, mostly local information but if it's something recent too, Google goes better. So I use DDG at work, and Google at home.

It's not a "search engine". It's a frontend to Bing.
And, presumably Bing tracks users and uses that data to improve its results. When you use DDG, you're just being tracked as "a DDG user" instead of "a Bing user with cookie=0x23987438743". (I don't know if that's true or not, but it's my current understanding of the situation.)

I think the problem with tracking is not the intrinsic action, but rather the fact we call it "tracking". Tracking is the technique you use to hunt and kill animals. Showing Java results to Java programmers and C# results to C# programmers is a little different from that...

I trust Google. I have been moving all my data to Google.
I really want to switch to DDG since I prefer it's results to Google but I always miss the time range filter. I know I'm not alone on this and the answer from DDG is that we can sort by date which is far from an alternative...
Hidden in that long chain are some folks suggesting that turning off instant search fixed the problem. Don't know if that's actually the problem, but it may help those of you experiencing the issue.
It took me around 3 failures to just switch to duckduckgo.
Here's a permanent fix:

- Click on the wrench icon in the upper right. Click "Settings".

- Scroll down to "Set which search engine is used when searching from the omnibox."

- Click Manage search engines

- Scroll all the way down. You'll see three textboxes. Fill the three textboxes in like so:

  Googol Googol http://www.google.com/search?q=%s
- Press enter, so that it adds Googol to your list of search engines. Scroll up and find it in the list, then click "Make default".

You now have a permanent way to search Google from within Chrome. Bonus: the URL is clean... there isn't any embedded tracking code or any other junk.

Google puts the tracking into the results now too, I used to use the 'Undirect' extension but it's currently losing the constant fight to properly detect and remove the tracking from the results. https://chrome.google.com/webstore/detail/dohbiijnjeiejifbgf...

This is a cool concept for many reasons... for example, I should use this to add the pws=0 'temporarily disable personalized search' parameter.

If you're going to go to that much trouble anyway, may I suggest using:

https://encrypted.google.com/search?q=%s

A little bit more privacy, a little bit less trackable (And, for this crowd, I should point out it'll strip the search query from the referrer when you click the search links in the ssl version of Google's SERPs - so the Google Analytics (or any other analytics tools) won't have those inbound search query strings. The website marketer in me hates it when people do that, the privacy-loving-libertarian in me loves it…)

Unfortunately seems to be US-only:

> The server at encrypted.google.com.au can't be found, because the DNS lookup failed

thanks for the tip though, still going to go with this.

Well, more "dot com domain only" than "US-only".

The dns magic underneath encrypted.google.com, www.google.com and www.google.com.au shows that doesn't matter - all three are "in Australia" (at the very least, within 21ms) from where I am (Sydney):

  [Bigs-MacBook-Pro:~] bigiain% traceroute www.google.com.au
  traceroute: Warning: www.google.com.au has multiple addresses; using 74.125.237.87
  traceroute to www-cctld.l.google.com (74.125.237.87), 64 hops max, 52 byte packets
  1  192.168.1.1 (192.168.1.1)  3.558 ms  1.766 ms  1.582 ms
  …
  8  syd01s06-in-f23.1e100.net (74.125.237.87)  20.318 ms  20.009 ms  20.457 ms
  
  [Bigs-MacBook-Pro:~] bigiain% traceroute www.google.com
  traceroute: Warning: www.google.com has multiple addresses; using 74.125.237.81
  traceroute to www.l.google.com (74.125.237.81), 64 hops max, 52 byte packets
  1  192.168.1.1 (192.168.1.1)  1.962 ms  3.753 ms  1.618 ms
  …
  9  syd01s06-in-f17.1e100.net (74.125.237.81)  19.927 ms  20.220 ms  20.404 ms
  
  [Bigs-MacBook-Pro:~] bigiain% traceroute encrypted.google.com
  traceroute: Warning: encrypted.google.com has multiple addresses; using 74.125.237.100
  traceroute to www3.l.google.com (74.125.237.100), 64 hops max, 52 byte packets
  1  192.168.1.1 (192.168.1.1)  17.068 ms  8.808 ms  1.609 ms
  …
  8  syd01s12-in-f4.1e100.net (74.125.237.100)  21.235 ms  20.064 ms  19.237 ms
If I search for something where I might expect a regionally-customised result, like "newspaper", I get "The Sun", "The New York Times" and "The Guardian" from encrypted.google.com, but I get the SMH, "The Australian", etc. etc. from a regular google.com.au search.
I think that's a general feature of encrypted, no location customizations. (I'd have to double-check to make sure though)
Wow, interesting, thanks for the research. I'm in Sydney too and I was surprised at how fast it was, but didn't think to look into it. Cool.
> I should point out it'll strip the search query from the referrer when you click the search links in the ssl version of Google's SERPs - so the Google Analytics (or any other analytics tools) won't have those inbound search query strings.

Last time I looked I don't think it was true. Analytics will get the data from the magic string in the referrer.

Surely there is no refer on a cross-domain navigation from an HTTPS site [1], and so the magic string won't make it there either.

[1] If there was, this could leak, for example, session ID in URL, which would be very bad on a supposedly secure site.

Google does a redirect to http before sending you out because of that... just look in the dev tools from your browser.
Ah, I understand what you mean now - Google deliberately redirect to their own site on http in order to "leak" that information in the referrer header. So we're both right, I just didn't understand you, sorry.
Everything works fine in Chrome Canary (the nightly builds) but it's broken in the standard Chrome release for me.
Dev build does not seem to be having this issue

(21.0.1180.15 dev-m)

Closing and restarting chrome seem to fix the problem for me.
I ran into this a short while ago and restart seems to have fixed it for me as well. Odd
frustrating as hell, just giving bing a try for the night until they get it fixed.
Why do you guys insist on "trying bing"... I "try bing" for about 2 searches a month and consistently get worse results. This is a bug, big deal, get canary. You can also just go to google.com and search there.
Same problem here. Switched to DuckDuckGo as the default search engine and now it works fine.
You know, i was just wondering if the bing team had noticed a spike in traffic as people switch their default searchers today? DDG as well, i guess. I'd love to see gabriel weinberg do a write-up about his stats for today :)
Me too.

I've been getting a lot of redirect timeouts on google searches the last couple of months. Their link tracking is flaky. Irritating as hell.

(comment deleted)
Crazy that this broke, but an interesting reminder of how annoying browsers were when you had to type "www.google.com" before you could search.
Well let's not forget that before this the norm was a search box that was placed next to the address bar. Just saying :p
Right, where (in Firefox) you could just hit ctrl+k / cmd+k to get the cursor into the box (as opposed to ctrl+l / cmd+l to get to the omnibox). Not that much more difficult.
Why do dozens of people feel the need to say "+1" and "me too"? What could they possibly think they are adding to the discussion?
Because the bug-tracking system doesn't have a noise-free way to say "this affects me too", the way that bugzilla and launchpad do. And "this affects me too" can potentially provide useful information, to gauge how many people an issue affects and thus what priority to give it.
Everyone has a google account so they can easily jump in (as opposed to bugzilla/launchpad), and soon the snowball effect kicks in.

This isn't the bug-tracking system, where it's supposed to be done by 'starring' an issue. Even there the concept is not emphasized enough so the same problem occurs.

Edit: someone else found the actual bug, the star is flush left in the blue issue header: http://code.google.com/p/chromium/issues/detail?id=84679

Your answer explained why it is helpful to google. It does not explain why individuals post "me too," or why people are posting "me too" here on the HN page...

There is a similar behavior here on HN with nice- page / I-agree / congrats posts. I'm wary of a general guideline that I should only post to HN if I think the karma reward will be greater than X, but more often than not I think it helps make sure any of my posts actually increase the numerator in the SNRatio.

To make it clear how large the scale of the problem is, and that it is not just affecting one person.
His answer explains that as well.

Since the per post karma have been removed the only way to show you agree is to write an "I agree" post. If I upvote it only the author will see that someone upvoted it, but it is also information that is valuable to others. Hence, the only way to truly support a comment is to write a "me too" or try to rewrite "me too" into some rambling as if you had something else to contribute with but don't (which is arguably even worse).

Not defending it or saying that hiding the per post karma is bad, but it is understandable and one of the drawbacks of hiding the per post karma.

"Me too" is often used as a way to bump a forum thread back to the front page of forum software so that mods and others can have time to participate before the thread rolls off into murky ancient history. For instance, you very often see this in game forums.

Now, my pet theory is that game forums seeded this behavior, and now more people use it even on forums where it is technically unnecessary.

That said, I wonder what the game theoretical explanation is.

That's... absolutely not true. The bug tracker (not the ML) has a star that is meant specifically for that and is a publicly viewable counter.
The star doesn't inherently say "I have this bug too". It just acts like a bookmark to find the bug later. That correlates with the number of people who want the bug fixed, somewhat, but it doesn't directly indicate how many people have experienced the bug.
This isn't the bug tracker. It's a forum for support. Someone should file a bug here: http://code.google.com/p/chromium/issues/list

Once they do that, you can "star" the issue. The Chrome team can sort their bug lists by "number of stars" during prioritization and you'll get e-mails when the bug's status changes if you star the bug.

That rather surprises me as well. I thought there'd be more analysis of what was happening - I looked in WebKit Inspector and noted some odd things. Something about a "hidden socket" in chrome.