460024 - labels for multiple search results on Google Maps don't show up or re-position map

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Judson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1

When you go to google maps and do a search, the small red labels do not display in the map frame. Also, occasionally the entire map frame will not re-load.

Reproducible: Always

Steps to Reproduce:
1. Search for something in maps.google.com
2. Look for the labels on the map
Actual Results:  
There are no displayed labels.

Expected Results:  
See the labels.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So I've been using trunk builds for a while, but I only started seeing this in the past two days, yet I found a much older regression date.  So it seems to me like something changed recently in Google Maps such that google maps is affected by a regression on the trunk a few months ago.

Steps to reproduce:
 1. Go to http://maps.google.com/ .
 2. Type "restaurants near mountain view, ca" in the search box and hit Enter.

Expected results:
 a. A list of restaurants shows up on the left.
 b. The map zooms in to the mountain view area.
 c. Red pins mark the locations of the restaurants.

Actual results:
 a. A list of restaurants shows up on the left, as expected.
 b. The area shown by the map does not change.
 c. No red pins show up, even if Mountain View is in the area.
 d. A yellow "Loading..." shows up near the top of the viewport.

This regressed between x86_64 Linux nightlies 2008-08-21-04-mozilla-central and 2008-08-22-04-mozilla-central.


Note that this affects only searches that return multiple results; searches that return single results seem fine.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A pushlog query with a wide date range:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-21+00%3A00%3A00&enddate=2008-08-22+06%3A00%3A00
shows that the main thing in the regression window is the tracemonkey landing (i.e., when it initially landed, turned off, I think) -- there's almost nothing else in the window, it looks like.

On that basis, moving to JS Engine, although further testcase reduction would likely be useful.

Comment 4

[Sylvain Pasche]

Another way to trigger the regression is to click on "My Maps" (bug 460236). The error message is: "b.inherits is not a function"

The search does a "WD.inherits is not a function"

Comment 5

[Robert Sayre]

This bug occurs with JIT off.

Comment 6

[Andreas Gal :gal]

Could someone try to post some of the code that is involved? 

I would be extremely surprised if this involves the JIT/tracer. However, TM did bring a bunch of general JS engine changes with it (better bytecode generation etc), so I wouldn't rule out some kind of TM involvement here.

Comment 7

[Sylvain Pasche]

Attachment: testcase

Hmm, dealing with tons of obfuscated JS is really painful.

The testcase passes with 2008-08-21-03 and fails on 2008-08-22-03.

The application is passing the eval function as a callback parameter to a XMLHttpRequest utility function which fetches the main Javascript file (main.js). In that main.js file, the Function.prototype is modified (new inherits function). Then other .js files are lazily loaded when searching or clicking some links. That's in these lazily loaded .js files that the error happens when evaled scripts try to access the added properties.

Comment 8

[Robert Sayre]

This bug first appears in the Aug 21 2008 tracemonkey nightly.

It is not present in the Aug 20 2008 tracemonkey nightly.

Comment 9

[Robert Sayre]

Gecko/20080820020709 Minefield/3.1a2pre: PASS
Gecko/20080821020621 Minefield/3.1a2pre: FAIL

Comment 10

[Robert Sayre]

This regression was caused by changeset

http://hg.mozilla.org/tracemonkey/rev/a5ecf48dd03b

from bug 451154. Confirmed via bisect of tracemonkey repo, and also by backing the patch out of my local m-c build.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Gah.  And in particular it's the js_DefineFunction change in JS_InitClass that causes the problem.

For extra fun, the problem doesn't seem to appear in the JS shell.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Blake says the problem is that we're no longer going through all the inner/outer window classinfo magic for window.Function.

He also says that the patch in bug 456027 might help.

In the shorter term, do we just want to back out the other bug and take the perf hit?

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Duplicate bug 455971 is checked in now, this should also be fixed.

Comment 14

[Bob Clary [:bc] (inactive)]

http://hg.mozilla.org/mozilla-central/rev/37b3fdbb0f07
Checking in js1_5/Regress/regress-460024.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-460024.js,v  <--  regress-460024.js

Comment 16

[Bob Clary [:bc] (inactive)]

v 1.9.1, 1.9.2