Bug 7205 - REGRESSION: maps blank on mapquest website
Summary: REGRESSION: maps blank on mapquest website
Status: RESOLVED DUPLICATE of bug 9127
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://www.mapquest.com/maps
Keywords: InRadar, NeedsReduction, Regression
Depends on:
Reported: 2006-02-11 19:25 PST by kjb525
Modified: 2006-06-04 10:07 PDT (History)
5 users (show)

See Also:

backtrace (11.01 KB, text/plain)
2006-02-19 11:31 PST, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description kjb525 2006-02-11 19:25:00 PST
Using revision 12765 from SVN.

go to mapquest website, enter an address in the 'maps' section, click on 'search'.  On the resulting page, the part containing the map is blank.
Comment 1 Darin Adler 2006-02-12 21:30:33 PST
I tried this and can't reproduce the problem.
Comment 2 Alexey Proskuryakov 2006-02-12 22:35:05 PST
This is 100% reproducible for me. Just noticed errors in the console:

ERROR: connection:willCacheResponse: was called inside of [NSURLConnection initWithRequest:delegate:] (40676250)
(/Users/ap/WebKit/WebKit/WebView/WebLoader.m:678 -[WebLoader connection:willCacheResponse:])
Comment 3 Darin Adler 2006-02-19 10:47:31 PST
I'd love to tackle this one, but it's still not happening for me.
Comment 4 Alexey Proskuryakov 2006-02-19 11:31:57 PST
Created attachment 6613 [details]

OK, caught it in gdb. Quite surprising a backtrace, to my eyes.
Comment 5 Alexey Proskuryakov 2006-02-26 21:49:54 PST
Using performSelectorOnMainThread:withObject:waitUntilDone: to properly execute willCacheResponse (looks like this is the only callback affected) doesn't fix this problem.

This doesn't necessarily mean that this is not the cause of the bug (even with this fix the order of callbacks remains wrong, and the race condition may affect internal NSURLConnection data), but it adds uncertainty indeed.
Comment 6 Alexey Proskuryakov 2006-03-11 03:15:38 PST
Filed the NSURLConnection issue as <rdar://4474791>.
Comment 7 Alice Liu 2006-03-20 07:18:19 PST
until someone on our team can reproduce this, I'll need to lower the priority.  

Comment 8 Alexey Proskuryakov 2006-03-20 21:38:58 PST
Discussed this with Alice on IRC: it is not really necessary for an Apple employee to reproduce a bug in order for it to be P1 in Bugzilla.

Unfortunately, it is somewhat hard to work on this problem without being an Apple employee, as it seems to be intertwined with an NSURLConnection issue.
Comment 9 mitz 2006-03-21 08:17:03 PST
I cannot reproduce the problem if I delete all cookies from *.mapquest.com and refuse cookies. When I re-enable cookies, the problem returns.

The map is blank because its style attribute is "visibility: hidden;" (there is a script that's supposed to show it which apparently doesn't get called). When I don't have the cookie, there is no inline style on the same element (the <div class="mapwidget mapdefault" id="map1-widget">).

It would help to know if those unable to reproduce are getting the "visibility: hidden" version of the HTML or not.
Comment 10 Alice Liu 2006-03-21 09:29:25 PST
Comment 11 Darin Adler 2006-03-29 15:50:48 PST
I can reproduce this now!
Comment 12 Darin Adler 2006-03-29 16:05:59 PST
Looks like this is another load event capturing handler problem like the one we looked at internally.

Check out this code from <http://www.mapquest.com/js/global.js?v=1.4>

    function addEvent(fObj, fEvent, fn)
        if(window.opera && getBrowserInfo().version < 8)
        else if (fObj.addEventListener)
        {   // moz, w3c
            ((window.opera) && (getBrowserInfo().version >= 8))?fObj.addEventListener(fEvent, fn, false):fObj.addEventListener(fEvent, fn, true);
            return true;

and this from the page:

    addEvent(window, "load", addHidFields);

This adds a capturing listener to the window for the load event. But the load event is targeted to the window itself, so a capturing listener won't fire!
Comment 13 Maciej Stachowiak 2006-03-29 16:22:28 PST
I sent information about this site breaking as a result of complying w/ DOM Events to the Web API working group, which is responsible for the next version of DOM Events (and where there are parties representing Mozilla and Opera).
Comment 14 Maciej Stachowiak 2006-03-29 16:23:38 PST
We should evangelize the site, I think. Passing "false" for useCapture should be right for all browsers, but they make that an Opera-only code path for some reason.
Comment 15 Maciej Stachowiak 2006-03-29 16:42:02 PST
Apparently all modern versions of addEvent use false for useCapture (at least, all the top google hits for addEvent do so), but some older versions used true. Opera has been going around evangelizing those using the older version:


Apparently MapQuest took their advice too literally and added an Opera-only code path that actually would have worked for all browsers.
Comment 16 David Storey 2006-03-30 06:16:47 PST
If you find any more issues with sites like this thne if you let me know or CC me on the bugzilla report that would be great.  
Comment 17 Darin Adler 2006-06-04 10:07:38 PDT
This is a bug in the website, but we've decided to match other browsers rather than the specification as per bug 9127. So the site now works fine.

*** This bug has been marked as a duplicate of 9127 ***