587452 - google.com - Some search thumbnails do not appear when Google Instant not turned on

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Hugh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Firefox 3 Beat 3

See http://forums.mozillazine.org/viewtopic.php?f=23&t=1957721 for more info and a video.

Google web search thumbnails are not displayed (also happens for video search. 

Reproducible: Always

Steps to Reproduce:
1. Go to google site
2. Search for dogs
3. notice blank image place holders where thumbnails have not been displayed



Have reproduce the problem on many different PC's and OS'.

Comment 1

[Matthias Versen [:Matti]]

This is a google issue and not a Firefox one.
Easy to check if you change general.useragent.extra.firefox to something else.

THe image properties are changed to something like this :
data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

Comment 2

[Chris Lawson (gone)]

Matti, can you explain *exactly* what's going on here? I've never seen this problem (and I use Google image search fairly often), and the referenced MZ forum thread is less than helpful in explaining it.

I've fixed the summary as best I can, but it would be helpful to know what, if anything, Google is actually sniffing for, as it seems you're implying in comment 1.

Comment 3

[Matthias Versen [:Matti]]

1) open FF4.0b3
2) type www.google.com (I'm getting redirected to google.de and have to switch to google.com with the link "google in Englisch" one)
3) type "dogs" as search term.
4) notice empty images at the top under the label "Images for dogs"
The images are data links as posted in comment #1

5) close the google tab/window
6) change the UA.extra to something else. I changed it from Firefox/4.0b3 to FF
7) repeat 1-5 and the images will work
THe images URL is now a google URL instead of a data URL

That the UA makes the difference is the reason why I couldn't reproduce the issue with Seamonkey trunk. It's possible that this happens only if you are from a foreign country because the reporter is using google.com.au.

Comment 4

[Hugh]

The useragent thing might explain why it has never worked in any of the Firefox 4 BETA versions so far but has always worked in Minefield.

Might be worth noting that a user from the UK who also posted in the mozillazine forum has the same issue and that google images searches work fine (as opposed to web search). Also once you have changed your search from a web search to an image search (using the links on the left of the page, see video in referenced mozillazine thread) clicking on web search again you will notice the thumbnails are there.

Comment 5

[Chris Lawson (gone)]

(In reply to comment #3)
> 6) change the UA.extra to something else. I changed it from Firefox/4.0b3 to FF

So Google is sniffing specifically for "4.0b" (or something very similar to that) and serving up incorrect content?

cl

Comment 6

[Matthias Versen [:Matti]]

I need help with this one.

You can make it work if you either change the UA from Firefox to something else ("4.0b3" doesn't matter, "Firefox" is the key) and google sends a page with direct image links

OR

You can disable the HTMl5 parser.
You get the data images but they work in this case.

I tried to save the page as html only but the images are working if I load the resulting html file.

I'm moving this to the parser

Comment 7

[Hugh]

Just confirming above post. 

I installed the user agent switcher add-on set my user agent as IE7, verified user agent at http://whatsmyuseragent.com/ which reports my user agent as 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)'.

With my user agent set to IE7 the Google search results seem to work fine.

Disabling HTML5 also enables the page to work as expected

Comment 8

[Johnny Stenback (:jst)]

This is not a browser bug, google's browser sniffing isn't detecting us correctly here (and our UA string is still changing too, to add to the fun).

Comment 9

[Matthias Versen [:Matti]]

jst: The question is why disabling the html5 parser makes this also working. Is that a browser bug or is google sending wrong html ?

Comment 10

[Henri Sivonen (:hsivonen)]

Google's initial HTML response doesn't include the images at all. However, by the time the page has loaded, the images have been somehow inserted into the document with data: URLs that encode single-pixel GIFs.

Then, at the end of the document, a bunch of scripts will have appeared from somewhere. There scripts replace the .src of each of the single-pixel GIF <img>s with a new data: URL that encodes an image thumbnail as a JPEG.

The interesting questions are: Why don't these scripts run? Or, if they do run, why do their getElementById calls fail to find the <img>s?

At this point, it doesn't seem particularly productive to investigate heavily obfuscated JS myself, so I'll ping someone from Google.

Comment 11

[Henri Sivonen (:hsivonen)]

Assigning to self to indicate that I've contacted Google.

Comment 12

[voracity]

Bug 582465 a duplicate?

I had this issue in 3.6 when I was testing out the html5 parser. It disappeared in the 4.0 betas (so I assumed something had been fixed) but reappeared recently, apparently with the useragent change.

Seems odd that more people aren't noticing this --- even if it only affects 'foreign' countries. Here's a random list I tested where the previews break (presumably affects all country tlds):

http://www.google.com.au/#q=trees
http://www.google.co.nz/#q=trees
http://www.google.co.uk/#q=trees
http://www.google.ca/#q=trees
http://www.google.com.ar/#q=trees

and of course the one version where they don't:

http://www.google.com/#q=trees

Also, all the javascript links are broken as well. e.g. Try clicking the 'More search tools' link in the left sidebar on (say) the first link above and it won't work.

Comment 13

[Hugh]

Now that you mention it I too had this problem in 3.6 when it first got HTML5.

Also for what it's worth using the IE9 Beta I do not have this problem (strangly the search results are not always identical).

Comment 14

[Fabien M]

I confirm the problem too.
I could reproduce it on MacOS, Windows XP and Windows 7, all with 4.0b7.

But I also noticed something weird :
I do the research, the pictures don't appear. I then click on Image on top of page, and i see everything OK. Now, if i click on Web, i come back to the first page, but the pictures are there.

Another thing :
it seems to work fine when Instant Search is on (in France, it is enabled only if you are connected to your Google account)

Comment 15

[Henri Sivonen (:hsivonen)]

Confirming that the problem partially persists when Google Instant isn't in use (e.g. on google.fr without login).

Assigning to nobody, since my attempt to report this to Google hasn't been acknowledged. Others should feel free to try.

Comment 16

[Henri Sivonen (:hsivonen)]

Also, this is still UA string dependent. Setting the UA string to Chrome's UA string makes the problem go away.

Comment 17

[Johnny Stenback (:jst)]

Chris, do you know someone we could reach out to here?

Comment 18

[Kev Needham [:kev]]

I've reached out to Google PSO, as well.

Comment 19

[Henri Sivonen (:hsivonen)]

Bug 614864 is another case where Google search results break in Firefox 4 but work if Chrome's UA string is used.

Comment 20

[Joey Hurst]

Google software engineer here.  Thanks for reaching out to us with this bug.  We've identified the root cause of the problem and are working on getting a fix into production.

The issue, if you're interested, has to do with a change in the way that scripts are evaluated with the new HTML5 parser.  To reproduce:
1) create a new element
2) add a script node to the element via an innerHTML assignment
3) append the element to the document

The script created in step (2) will be evaluated iff the old (pre HTML5) parser is used.  I'll attach a small test case in a minute that demonstrates this change.

There was some discussion on the thread that this bug was due to faulty UA parsing.  We are correctly classifying FF4 as such; the problem was alleviated by changing the UA because FF4 now behaves like IE and Webkit in regards to the script evaluation change noted earlier.

This issue was also the cause of 614864.  (I'll ping that thread in a second.)

Let me know if you have any further questions.

Comment 21

[Joey Hurst]

Attachment: innerhtml script execution test case

Comment 22

[Kev Needham [:kev]]

tchung: could you have a look at comment #21, and see if there's anything we need to/can do to integrate this into testing?

Comment 23

[Carsten Book [:Tomcat]]

(In reply to comment #22)
> tchung: could you have a look at comment #21, and see if there's anything we
> need to/can do to integrate this into testing?

we could add this testcase to our manual testsuite litmus, so that this is
tested for release testing etc

Comment 24

[Henri Sivonen (:hsivonen)]

(In reply to comment #20)
> the problem was alleviated
> by changing the UA because FF4 now behaves like IE and Webkit in regards to the
> script evaluation change noted earlier.

Firefox now behaves like WebKit, because the HTML5 spec requires that behavior. That is, the behavior is deliberate and not a bug. However, we made createContextualFragment to create executable script nodes. See bug 599588.

Comment 25

[Joey Hurst]

FYI this has been fixed.

Comment 26

[Henri Sivonen (:hsivonen)]

(In reply to comment #25)
> FYI this has been fixed.

Great! Thank you.

It seems the fix hasn't been deployed to google.de yet, so I'm leaving this open until the fix has been deployed.

Comment 27

[Hugh]

Still not fixed more me either (Australia).

Comment 28

[denk]

This has been solved for me with Firefox 4 beta11 (at least on google.de and google.com)!

Regards
denk

Comment 29

[Christopher Blizzard (:blizzard)]

Marking fixed based on comments.