Munchkin tracking code being blocked in Firefox 35

[Anonymous]

I've noticed for some time that Munchkin visitWebPage pixel is being blocked by the latest version of Firefox with the following warning:
 

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://253-xld-026.mktoresp.com/webevents/visitWebPage

This doesn't seem to impact lead tracking, as the "Visit Web Page" event is still showing up in the lead's Activity Log, but it is registering as an error on the page, which bothers me. Without doing too much troubleshooting, I'd guess the issue is a stems from the tracking pixel response trying to set a cookie, but not sending the "access-control-allow-credentials" header, or the request not using "with-credentials", or something similar to that...

 

[Anonymous]

We see the same issue in both FireFox 35 & IE11

[Anonymous]

Interesting. Have you raised it with support? 

[Anonymous]

Yes - I have a ticket in. 

Interestingly enough, I got this message from firefox when putting together a sample script for testing the requests:

A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true.

A quick glance at the munchkin script (https://munchkin.marketo.net/149/munchkin.js) looks like it is asking withCredentials and the response header of trackWebPage is a wild card for Access-Control-Allow-Origin

[SanfordWhiteman]

@Scott M where you see withCredentials in the code, that's feature detection: if a new XMLHttpRequest has the withCredentials property set to true or false that means the browser supports XMLHttpRequest2.  IE 8 doesn't support XMLHttpRequest2 but has its own flavor, XDR.  Earlier browsers can't use XHR to load the tracking pixel, but they can still load it using old-school methods.  Munchkin uses feature detection to determine what kind of browser it's running in. That doesn't mean the request is made withCredentials.

As @Than Taintor was intuiting, what's actually happening when you see this error is the remote server has responded with a Set-Cookie header (from Marketo's load balancer).  As a result, the browser reconsiders the request and acts like it was made withCredentials, though in fact no credentials (cookies) were even attempted to be sent.  The browser only reclassifies the request after the response is received, though, thus no outbound data can actually be blocked: it's already been sent and Munchkin has already logged the activity at that point, since that happens all during the initial request.

So what the browser is really saying is, "Don't think I didn't notice the cookie coming back.  Nice try getting me to read that inbound cookie, but the server didn't send a valid Access-Control-Allow-Origin header for that." But the cookie is not necessary for operation.  It's basically off-topic.

[Anonymous]

Thanks for the explanation Sanford - that is very helpful. I was worried about the 0kb responses for visitWebPage (or cancelled in chrome) but it sounds like that is OK. 

[SanfordWhiteman]

It's definitely not user-friendly for those of us who open up Developer Tools!  And though almost none of our clients would ever notice it I think @Than Taintor is right to want it to go away.  I wonder what Marketo support will come back with.  It may be difficult for them to get the load balancer to not set that cookie for certain requests (it's an affinity cookie -- lets the same browser keep going to the same back-end server behind the F5 BigIP).