Steps to reproduce: - Go to http://www.google.com - Tap on the input, type 'tes' --> Google autocomplete results appear below the input, the first 1 being 'test' - Tap on the 'test' autocomplete item Expected result: - The link should be followed and search results should be shown Actual result:- - The autocomplete suggestion is put into the input, nothing else happens.

I can confirm Martijn's results on the 2013-03-05 Firefox Nightly build. Mike - Google mobile autocomplete seems to be broken in Firefox. Can you please help find someone from Google to debug? Thanks.

Same behaviour happens on desktop Firefox with the mobile user-agent, i.e, "Mozilla/5.0 (Android; Mobile; rv:20.0) Gecko/20.0 Firefox/20.0"

Behaviour works as expected in Chrome with the above mobile user-agent.

(In reply to Aaron Train [:aaronmt] from comment #2) > Same behaviour happens on desktop Firefox with the mobile user-agent, i.e, > "Mozilla/5.0 (Android; Mobile; rv:20.0) Gecko/20.0 Firefox/20.0" This is good news, in a way. It means we are not doing something in Fennec, specifically, to cause the bug. It seems like a problem that can happen on any Gecko system. We probably need to reduce a testcase, to see what code is actually executing.

The Google code is very convoluted, I don't know how to make a testcase out of that. One thing I noted is that when I save it offline, the autocomplete suggestion is followed when clicking on it.

It seems part of google.ac (not sure what that is): http://jimbojw.com/wiki/index.php?title=What_Would_Google_Suggest%3F

This is a core bug, not TE. Each menu entry is a BUTTON whose click event handler calls form.submit() (on the form that contains the BUTTON itself). The click event handler also cleans up the page and removes all menu items from the DOM. Firefox fails to obey the form.submit() call when the activated BUTTON element gets removed from the form, so the form is not actually submitted, and search doesn't happen.

(Attaching a slightly more simplified test case)

How should I run the testcase? Doesn't seem to do anything in a desktop build?

Test case should just say "PASS" if things work as expected. If the word "PASS" doesn't appear, the test fails. (Although, come to think of it it does a form submit so might not work as a bugzilla attachment.. http://hallvord.com/temp/moz/google.htm runs better? Compare with other browsers..) (& Sorry about the wrong component, learning..)

Looks related to bug 586329 then?

Certainly looks like a duplicate, yes. Some over-eager sanity check during form submit?

Two further observations: 1. The classic search linked from the bottom of the page doesn't have this problem. Neither does the search offered with an android/chrome user agent. 2. When you pick an autocomplete entry from the list by tapping or clicking, the search box populates but the search does not execute as in comment #0. Then if you the search box and press return (or Go on mobile keyboard) nothing happens. You need to click/press the search button to perform the search. Dunno whether this is another symptom of bug 586329, thought I'd mention it as I'm typing.

Seems the tablet UI doesn't have this problem. I noticed that the search experience is better for firefox 35 on a Nexus 7" than on a 2.3.x phone. So I checked on the android emulator (android 4.4.2 for x86): * Emulated phone - a newly created "Nexus 4" with downloaded aurora 37.0a2 (2015-01-26): Autocomplete links buggy as described above * Emulated tablet - an existing "10.1" WXGA" device with firefox beta 35 Autocomplete links work as expected - tapping a suggestion changes the search results without further action. I know I don't have perfect or exhaustive head to head comparisons, but it does suggest that tablet vs. phone form factor is the difference.

Firefox Mobile 28 (the oldest version I can run on the x86 emulator) on tablet form-factor: WORKS So google search does seem to be offering a working page to tablet users, fwiw.

I can still reproduce this in firefox 52.0 on a phone, and on desktop with the "Responsive Design Mode" and a Mobile UA. It might be another manifestation of bug #975444 if tablet users receive working content but mobile users don't.