Comment by mbrukman | Hacker News Reader

Comment by mbrukman | Hacker News Reader

Hi Mario,

I am an engineer on Google Search frontend.

Thank you for posting this, and I'm really sorry and saddened to see this broken; this is certainly not intended behavior.

I've reproduced the issue you described in the blog (Lynx does not allow clicking on the search results page). Even though Google serves valid HTML to Lynx, it's probably HTML that Lynx cannot parse, and since it used to work before, this is a regression. I filed a bug for our team to look further into it and address the root cause.

Interestingly enough, pressing <L> shows a list of links in the current document, and it does show all the available result links, so Lynx does see and parse them, it's just not rendering the links inline with the search results, so that's something we have to investigate as well.

In the meantime, as a temporary workaround, if you're open to using Chrome with a simple UI that would be amenable to a screenreader and keyboard navigation, you can use a User Agent switcher extension by Google [1] to set the user agent header to Lynx [2] and Google will serve the same HTML that it would have served to Lynx. You can then use the <Tab> key to iterate over the search results, and <Enter> to select a particular result.

I look forward to seeing this bug resolved, and will be personally following up on the status of this bug.

Again, I'm really sorry to see this, and I hope we'll be able to restore your ability to use Google with Lynx shortly!

[1] https://chrome.google.com/webstore/detail/user-agent-switche...

[2] https://developers.whatismybrowser.com/useragents/explore/so...

Thanks a lot for this positive reply! I am thrilled to read that this might be counted a regression and actually fixed. I really hope that can happen.

Regarding 'L', Lynx sometimes "hides" links if the anchor is around a div. Maybe it is just that simple. IIRC, <a href=...><div>...</div></a> will trigger a similar behaviour.

Regarding your Chrome suggestion, that really doesnt help me much since I spend 99% of my workday on a plain virtual console. The context switch of moving to another computer that runs Windows for simple searches is really not practical.

Again, thanks for spotting this and acting on it!

Hi Mario,

Your analysis is correct; the issue was due to <div> tags appearing inside <a> tags. This should be fixed now; I've verified that I can follow result links using Lynx.

Once again, my apologies for you running into this issue! Thank you for reporting & debugging it and thank you for your patience as well.

I hope this is resolved for you now; please try it out and let me know whether or not it works for you, or if you run into any other issues.

Will bet good money this is due to your user-agent based content serving. I have similar issues with non-standard browsers I use. I don't know why google and google based sites (including recaptcha) are the only ones uaving this issue. It really is bad for the web to have this sort of user agent discrimination.

> It really is bad for the web to have this sort of user agent discrimination.

Eh, if the issue really was (as figured out below) that lynx doesn't support divs inside anchor tags, that seems like the best possible solution if you aren't going to drop lynx support altogether. Even IE6 allows that.

It just isn't worth trying to do progressive enhancement by tying everything into knots trying to keep the page strict html 4.

Doesn't matter. Google can make a site that works great with all browsers. Not that you have no point but Google is the only company I struggle to get their products working without conforming to their assumptions about user-agents. Don't break things because only a fraction of users use or don't use a feature (includes JS).

Another win for Hanlon.

Reply on news.ycombinator.com