Using SLDS from a managed package - fonts & SVG not downloading due to Cross-Origin-Resource-Sharing

mattgoldspink commented 8 years ago

Hi,

We're facing an issue whereby we ship our own scoped version of slds 2.0.2. We provide various components for our clients to use which have been styled with this. We've hit a problem whereby if a user creates a VF page in their org which embeds one of our slds based apex components, the fonts and svg icons do not download due to:

Font from origin 'https://na30.salesforce.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

And

Unsafe attempt to load URL https://my_managed_package.na30.visual.force.com/resource/1469571737000/my_managed_package__slds/assets/icons/action-sprite/svg/symbols.svg#back from frame with URL https://c.na30.visual.force.com/apex/QEFormsAllElementsLightning. Domains, protocols and ports must match.

We've seen this issue with our older non-slds theme and were told it's due to the following:

We discussed the issue with R&D. According to them, you have IE-specific rules in your stylesheet (they are used in filter properties, and look like this: filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);

that are causing the cssparser (3rd party library) to fail.

When it fails, the original source is used, that is why the font-face URLs are not being decorated, and you still see the problem.

There is a known bug for this issue (and one more) logged with the CSSPARSER team

CSS Parser's Bug:

https://sourceforge.net/p/cssparser/bugs/49

The workaround is to move the @font-face rules out of custom.css, into another CSS file in the same directory.

He counted only 8 @font-face rules, so the task is trivial.

I will attach the new files here (custom.css with the removed rules, and custom_font.css with the @font-face rules).

If you can recreate the zip file with custom_font.css in the same directory as custom.css, upload a new version of the package, and install the package on a subscriber org, then the font files will load again.

However I've searched slds and there's no old-school IE filters in there, so I'm wondering why this might be happening? And how can we solve it?

kaelig commented 8 years ago

Thank you for the detailed report, @mattgoldspink. Really appreciate it.

You are correct, there aren't any filter CSS properties in SLDS. The only mentions of the "filter" string are for class names, e.g. .slds .slds-icon-action-filter.

@stefsullrew has recently been working on Lightning / SVG compatibility, I'll leave it to her to get back to you on that.

kaelig commented 8 years ago

@mattgoldspink have you tried using the SVG4Everybody polyfill? It seems to have solved the problem for another developer today.

mattgoldspink commented 8 years ago

@kaelig - yes, this is not an IE issue. We do have it loaded on the page in any case. Also this isn't just affecting svg icons it affects fonts too.

kaelig commented 8 years ago

Thank you for the quick answer. SVG4Everybody is actually not only for IE and provides a workaround for Cross-Origin loading issues in all browsers.

We'll investigate further!

mattgoldspink commented 8 years ago

Let me double check then about the svg4everybody and ensure it is running on chrome and Firefox - I'll update the thread once I've tried.

mattgoldspink commented 8 years ago

@kaelig I just double checked - unfortunately we do call svg4everybody no matter what browser we're using. I have a separate ticket open with Salesforce support for this too, but any extra help would be much appreciated.

I've narrowed it down to simple reproduction with 2 static resources:

svg4everybody in a zipped resource
slds 2.0.3 with a custom namespace (via-slds) created using the lightning tool

We also added a simple Visualforce Component with the following:

<apex:component access="global">
      <apex:stylesheet value="{!URLFOR($Resource.slds, '/assets/styles/salesforce-lightning-design-system-vf.min.css')}"/>
      <apex:includeScript value="{!URLFOR($Resource.svg4everybody, '/dist/svg4everybody.js')}"/>

    <div class="via-slds" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
        <div>

            <article class="slds-card">
              <header class="slds-card__header slds-grid">
                <div class="slds-media slds-media--center slds-has-flexi-truncate">
                  <div class="slds-media__figure">
                    <svg aria-hidden="true" class="slds-icon slds-icon-standard-contact slds-icon--small">
                      <use xlink:href="{!URLFOR($Resource.slds, 'assets/icons/standard-sprite/svg/symbols.svg#contact')}"></use>
                    </svg>
                  </div>
                  <div class="slds-media__body slds-truncate">
                    <h2>
                      <a href="javascript:void(0);" class="slds-text-link--reset">
                        <span class="slds-text-heading--small">Card Header</span>
                      </a>
                    </h2>
                  </div>
                </div>
                <div class="slds-no-flex">
                  <button class="slds-button slds-button--neutral slds-col--bump-left">New</button>
                </div>
              </header>
              <div class="slds-card__body slds-text-align--center">Card Body (custom goes in here)</div>
              <div class="slds-card__footer">Card Footer</div>
            </article>

        </div>
    </div>
</apex:component>

And a simple Visualforce page to ensure this works in our development Org:

<apex:page standardStylesheets="false" showHeader="false" sidebar="false" docType="html-5.0"
            applyHtmlTag="false" applyBodyTag="false">
    <html>
        <head>
            <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        </head>
        <body>
            <c:SldsSvgBugComponent />
        </body>
   </html>
</apex:page>

We then put the above into a Managed Package and install it a new org. On this org we now create a Visualforce Page which uses the component:

<apex:page standardStylesheets="false" showHeader="false" sidebar="false" docType="html-5.0"
            applyHtmlTag="false" applyBodyTag="false">
    <html>
        <head>
            <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        </head>
        <body>
            <managed_package_ns:SldsSvgBugComponent />
        </body>
   </html>
</apex:page>

(replace managed_package_ns with the namespace of your managed package).

You should see no SVG icon and no Salesforce Sans font. And in console you'll see a bunch of errors relating to 'Access-Control-Allow-Origin' errors. Let me know if there's any more information I could provide to help.

kaelig commented 8 years ago

Thank you for the detailed report! (I've taken the liberty to reformat the code snippets)

I'll be investigating and will get back to you with an update very soon.

mattgoldspink commented 8 years ago

Sadly Salesforce support closed my ticket with them as they said it's a bug in SLDS and not something they support. I did get some useful information/suggestions but nothing that helps us solve the issue.

For the SVG icons it was suggested that we use the png images instead. I'm open to that idea, however it involves some challenges:

We'd need to write CSS rules to support them as an alternative - I'm happy to do this, but I'd like to know if I put this together would they likely be accepted back and maintained? I don't want for us to be responsible for them forever going forwards.
The next challenge is how do we modify the color of each icon (right now the png's are white on transparent). I took a look at using the CSS filter property. This would work in all browsers, except for IE11. I even checked out the CSS filter polyfill but that doesn't support colors nor IE11.
An alternative is to create a sprite sheet for each image with it's various color state, but that sounds like it would quickly become big and add to page load
Alternatively the icons could be packaged as an icon font - this sounds like the most feasible option. The only downside to this is that we're then stuck with the font loading issue that we're also seeing with Salesforce Sans.

I'd love to know if anyone else found a suitable workaround for people who are distributing components for clients to use in Managed Packages? Right now we're very stuck!

kaelig commented 8 years ago

Sorry to hear that. Have you tried to include SVGs directly in the document (instead of <use />)? It is not as practical as SVG sprites but it should work.

mattgoldspink commented 8 years ago

Hi @kaelig

Thanks for the response. Just to check what you mean- instead of the <use/> tag with the <svg> element? You mean replace it with the actual full svg path for the icon?

For example for the add_contact icon -

I guess we could do that - it's not ideal, but in theory we could probably hack something together in Angular to replace the tag with this instead for each icon.

Are we the first people to have hit this issue?

I don't believe we're the only company creating Managed Packages with lightning icons in Apex Components for clients to embed in their pages (maybe we really are though!).

Is this issue likely to be considered as bug?

In theory SLDS works and outside of the salesforce platform people have control to move this to the same domain. Unfortunately in the context of Managed Packages on Salesforce there's an obvious issue. I'm just wondering if we're ever likely to see a fix for this and if so where would it come from? I understand there's a number of things causing this:

The choice of the svg <use> tag for icons.
The way managed packages are now hosted on separate domains on Salesforce.
The SVG spec's rules for cross domain behaviour with <use> and how browsers interpret/implement that.

Each of the above is owned by a different team/company (salesforce ux team, salesforce platform team, SVG WG + browser vendors). Getting the SVG WG + browser vendors to change their behaviours is a lot of work. The Salesforce platform team already seems to think this is not their issue, which leaves me asking if the Salesforce UX Team are going to have a solution so that it works out of the box... I guess what I'm saying is... you guys are our last hope!

kaelig commented 8 years ago

I absolutely agree with you!

Including SVGs directly into the source is impractical, so what's usually used is a templating trick (e.g. a partial) or a custom tag that gets replaced. In my experience, injecting SVGs on the client can cause some browsers to stall or even crash (mainly on previous generation mobile and tablet), so you'll want to do as much SVG rendering on the server-side as possible.

In fact we have an internal team who, I believe, is doing just that. @tweettypography is there a recommendation you and your team could make for using icons without relying on <use />?

mattgoldspink commented 8 years ago

Thanks @kaelig for the ideas.

Now I start to think about this a little more - could inject all the SVG spritesheets into the VF Component on the serverside (or maybe even dynamically from Angular on page load if we're not in a component). Then we can stick with the <use/> tag and reference them from within the page?

Assuming the browser penalty you mention isn't too bad on the user experience that could be something that would work for us and wouldn't involve us maintaining a lot of extra code. I'll give it a shot on Monday and let you know how it goes.

In the meantime I'd love to hear how others have worked around this.

Thanks again for the help- we really appreciate it!

stefsullrew commented 8 years ago

@mattgoldspink - do you have access to a Winter'17 pre-release org yet?

stefsullrew commented 8 years ago

@mattgoldspink - Since you're using Angular, have you considered building an ng:icon component that injects the SVG? It seems github is doing something like that. And there will be something more I can talk about in a couple weeks (not Angular-related tho). Have a look at this: https://github.com/blog/2112-delivering-octicons-with-svg

mattgoldspink commented 8 years ago

Thanks @stefsullrew & @tweettypography

This sounds like the best route for us to take. We already have an angular directive for icons, we'll just need to package the SVG icons in our library.

@tweettypography - unfortunately I can't access the above. Is there any chance you could post a snippet of what you have in a gist for myself and others to understand?

@stefsullrew - I don't have access to a pre-release org. I'll get in touch with one of Salesforce contacts to see if we can get access to one. And I'll keep an eye out for your future comments on this.

Thanks for all the help. I'll update the ticket with the results so others can benefit once we've rolled this out properly.

FabienTaillon commented 8 years ago

@mattgoldspink you can get a Winter '17 pre-release org here: https://www.salesforce.com/form/signup/prerelease-winter17.jsp

tweettypography commented 8 years ago

@mattgoldspink Sorry, my bad. Basically we pull the data from the SVG files and export it to json, then pull the data back in via a custom React component. However, some of that is fairly React-specific. What build tool do you use? You should be able to achieve something similar without any custom scripting if you're on Webpack using url-loader.

In your webpack config:

{
  test: /\.(svg)$/,
  loader: 'url?limit=1000000'
}

And in your icons js file something like:

export ADD_CONTACT from '@salesforce-ux/design-system/assets/icons/action/add_contact.svg';

(Or just import the file and use it if you're not trying to export the icons.)

mattgoldspink commented 8 years ago

Hi all - I wanted to give an update since it's been a while and in case anyone else hits this issue. I finally got round to rewriting our angular framework to inject the SVG icons into the DOM directly. We use browserify to build our code, so I customized the 'svgify' plugin here to give us a simple version of each sprite - https://github.com/mattgoldspink/svgify/

The biggest issues we faced was that we needed to set the viewBox="0 0 52 52" property on each SVG element and ensure the "fill" attribute on the paths is set to inherit.

So far this seems to be working fine. I've tested in Chrome, Firefox and IE11.

In terms of the font issue - we've had to modify the versions of SLDS we download to move the font-family rules into a separate stylesheet and use

@import url(slds-fonts.css);

The reason for this bug is that the CSSParser used on SFDC breaks when it see's @keyframe blocks. I'm waiting to hear back when the SFDC side of this will be fixed so we won't have to depend on it.

For now I think we can live with these workarounds.

Thank you all for your help - especially sharing the ideas to help us get past the SVG issues. It's very much appreciated.

Matt

kaelig commented 8 years ago

Thank you for sharing, @mattgoldspink!

Not sure what @keyframe blocks have to do with the webfonts, can you give more background on this?

Also, if you're using Sass to compile the design system, there is a setting that allows you to load fonts separately.

This is how you can disable the output of the font blocks:

$slds-load-webfonts: false;
@import 'path/to/index.scss';

(and then load fonts using the technique of your choice)

mattgoldspink commented 8 years ago

The key frame issue is to do with the way css in managed packages is handled. From what I understand, all urls (e.g. Background images, other css files, font urls) need to be rewritten with an org id so they can be accessible on other domains. The CSS Parser that does this has a bug which causes it to break when it sees a @keyframe block and quits parsing the file, leaving the urls in the wrong format to be accessible.

That's as far as my understanding goes and I know we were hit by another bug in the same parser that caused it to fail on old IE filters and leave broken urls In the file.

Thanks for pointing out the sass hook. For now we've manually done it, but it might be worth us automating it until a fix on the backend is available.

stefsullrew commented 8 years ago

Yes, I just became aware of this bug early this week. Funny it should come up again. I'm going to see if I can get to the bottom of it. Thanks and glad you've got your SVGs working!

kaelig commented 8 years ago

@mattgoldspink ok that's what I understood as well!

stefsullrew commented 8 years ago

@mattgoldspink - I know of this bug in an external parser - https://sourceforge.net/p/cssparser/bugs/61/ I can not find any information on that same bug on our internal parser. Can you point me to more information?

mattgoldspink commented 8 years ago

@stefsullrew I'm still waiting on a Salesforce bug report from our support thread. I can give you our support thread id if thats any help? But it's not an Salesforce bug id.

stefsullrew commented 8 years ago

That would be perfect, thanks!

mattgoldspink commented 8 years ago

@stefsullrew The Case ID is 14297022. Let me know if you need any offer info.

stefsullrew commented 8 years ago

I found your internal bug @mattgoldspink - We're looking at it. :)

wes1278 commented 8 years ago

@stefsullrew Any updates on this bug?

@tweettypography do you have any snippets of the react component you used to solve this?

Thanks for the healthy thread!

stefsullrew commented 8 years ago

The parser bug is marked "In Progress" from our end... stay tuned. :)

koenfaro90 commented 8 years ago

Also ran into this today while building an extension package for a managed package using lightning in VF - would appreciate any updates!

Unsafe attempt to load URL https://webservices-pkg-extension-full-dev-ed--wsone.eu11.visual.force.com/…477631729000/WSONE__SLDS/assets/icons/utility-sprite/svg/symbols.svg#close from frame with URL https://webservices-pkg-extension-full-dev-ed--wsone-data.eu11.visual.force…1DMHpNVlF3TlRvek1Eb3dNQzR5TWpkYSxpLUliNXRXdGd2bVpwajJVdG84YlBKLFlXWmtNR0po. Domains, protocols and ports must match.

It seems Salesforce has added a new subdomain (--data?)

stale[bot] commented 6 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you still need help with your issue, please comment and we will reply to you shortly. Thank you for your contributions to the Salesforce Lightning Design System.

pbergner commented 4 years ago

I'm seeing a very similar issue. One customer of ours is not seeing any of the SLDS icons. I've created a test page in their org and confirmed the icons appear when served from an unmanaged static resource SLDS bundle but fail to load when served from our managed package static resource SLDS bundle.

We've whitelisted all relevant domains.

pbergner commented 4 years ago

@stefsullrew i realize this is a stale issue but any updates?

pbergner commented 4 years ago

@koenfaro90 were you ever able to resolve this?

salesforce-ux / design-system

Using SLDS from a managed package - fonts & SVG not downloading due to Cross-Origin-Resource-Sharing #282