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.
I tried this and can't reproduce the problem.
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:]) =================
I'd love to tackle this one, but it's still not happening for me.
Created attachment 6613 [details] backtrace OK, caught it in gdb. Quite surprising a backtrace, to my eyes.
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.
Filed the NSURLConnection issue as <rdar://4474791>.
until someone on our team can reproduce this, I'll need to lower the priority.
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.
<rdar://problem/4485459>
I can reproduce this now!
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!
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).
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.
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.
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.
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 ***