While using webfonts on Marketo LPs can come with a few frustrations, this situation seems like one you've caused yourself.
If you're serving fonts from a non-Marketo webserver, you naturally need to allow cross-origin loading from the Marketo sites (which include both *.marketodesigner.com and your LP domain). This is a setting to make on your side.
My first impulse is to tell you not to worry about this particular issue. It may only be an artifact of the way Marketo's Design Studio is designed to work.
The error you're reporting is coming from within the domain 'marketodesigner.com' which makes me think you're doing a preview. In my experience, very few of Marketo's previews actually work according to plan; if the only issue is you're getting the wrong fonts/icons in the form, it may not be worth the bother of fixing it.
If you want to try fixing it, you have to be able to control the headers sent by the source of the icon font. The server sending the font has to include the header "Access-Control-Allow-Origin:" in it, set in a manner to allow the cross-origin request.
And *that* is where the rub comes in. For example, in our own specific case, we have a custom subdomain created which refers to the Marketo server that serves our forms and the assets they consume. We have no control over that server and Marketo denied our request to set it to enable CORS. Ergo, we *always* get that same error you describe, as the marketodeisgner.com domain is not allowed to make those kind of requests from our custom subdomain. This means if you have no control over the configuration setting on the computer serving the icon font, then you're stuck, the error will be with you always. But the bright side of it is the error will only be present in the Design Studio previews, and not in the real form. (Plus, if you're as easily amused as I am you can get a chuckle every time you see it over the fact that Marketo's own policies not only cause the error but prevent it from being fixed.)
If your answer to "Can I control the headers issued by the server holding the font?" is "Yes," then you're in business. Sources of information, depending upon how much detail you want to get into:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS is a fairly complete source for what needs to go in the new header. (Or headers, as there can be several, depending upon how complex the situation is. In your case, simply the one header should do it, with the value "https://na-sj20.marketodesigner.com" -- The value allowed must be either a wildcard or a match to the origin the User Agent is sending, which is listed in your error message.)
- https://enable-cors.org/ is a site devoted to the ins and outs of the what and why of CORS.
- What is CORS? Is a simple page put up by one of the major CDN providers that gives a good management synopsis of it.
I should note that some people are afraid of CORS because of security issues. It *does* open a wider attack surface in that all that is required is for the asset server to be compromised for all of its client servers to be compromised as well, so be aware of that as you decide whether you want to fix that error.
Hope that helps.
And *that* is where the rub comes in. For example, in our own specific case, we have a custom subdomain created which refers to the Marketo server that serves our forms and the assets they consume. We have no control over that server and Marketo denied our request to set it to enable CORS. Ergo, we *always* get that same error you describe, as the marketodeisgner.com domain is not allowed to make those kind of requests from our custom subdomain.
You're absolutely right, that's a well-known case. But if "http://myurl.com" means the zone apex http://example.com, doesn't apply here, since the apex can't be used as a Marketo LP CNAME.
Anyway, for a long time we've worked around the CORS issue w/r/t webfonts as Marketo assets. Our templates always detect if they're running in the editor and switch to a CORS-enabled gateway. Screenshot of the LP Ed w/Marketo-hosted webfonts:
Have to dig in to how you're doing that, because it never worked for us, including the preview of a test landing page (one I abuse all too often trying strange ideas out) I just checked a few minutes ago. Obviously it's not as simple as, "it works;" there's something more to it in the template code that I'm going to have to appropriate, er, study. Yeah that's the word, study.
I'll share it on my blog soon so you can study it thoroughly. Will update this thread when it's up.