Bug 7205 – REGRESSION: maps blank on mapquest website

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKit Misc.

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.

[Darin Adler]

I tried this and can't reproduce the problem.

[Alexey Proskuryakov]

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:])
=================

[Darin Adler]

I'd love to tackle this one, but it's still not happening for me.

[Alexey Proskuryakov]

Created attachment 6613 [details]
backtrace

OK, caught it in gdb. Quite surprising a backtrace, to my eyes.

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

Filed the NSURLConnection issue as <rdar://4474791>.

[Alice Liu]

until someone on our team can reproduce this, I'll need to lower the priority.  

[Alexey Proskuryakov]

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.

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.

[Alice Liu]

<rdar://problem/4485459>

[Darin Adler]

I can reproduce this now!

[Darin Adler]

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!

[Maciej Stachowiak]

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).

[Maciej Stachowiak]

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.

[Maciej Stachowiak]

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:

http://www.kryogenix.org/days/2006/01/13/corrected-addevent-function

Apparently MapQuest took their advice too literally and added an Opera-only code path that actually would have worked for all browsers.

[David Storey]

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.  

[Darin Adler]

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 ***