I have a VFpage that runs perfectly on the web. I do a lot of static resource reference from another static resource. What I mean by this is, I have zipped images and javascripts and uploaded as a static resource. I refer to the images inside the static resource from my javascript. these images load on the web version but not on Salesforce1 app. ( Google developer console throws this notification)
Resource interpreted as Image but transferred with MIME type application/zip: "https://c.ap1.visual.force.com/resource/1412349895678/MyResources3?isdtp=p1/img/Rose.png"

Here is a code sample For example: My Static resource looks like this:

   |      |--Jasmine.jpg
   |      |--Rose.jpg
   |      |--image_load.js

My Visualforce code is <apex:page > <table> <tr> <td id="flower_page"></td> <\tr> <\table> </apex:page>

My Javascript code is
... $("#flower_page").html( "<div class=\"img-flower\"><img src=\""+resourceId+"/"+ Rose.jpg + "\" width=\"50\" height=\"50\" /></div>" ); ...

This would emit the following code. ... <table> <tr> <td id="flower_page"> <div class="img-flower"> <img src="/resource/1412387865123/MyStaticResource/img/Rose.jpg" width="50" height="50" /> </div> </td> ...

I use jquerymobile so that the app looks appropriate on a mobile device.

I read this article and tried using data-src, but didnot work.

Any help is appreciated.


1 Answer 1


The paths can't be concatenated because Salesforce1 adds ?isdtp=p1 to all generated URLs.

To solve this problem, the URLFOR function must used properly instead of concatenating the different parts. I appreciate that may be complicated given that you are generating the markup in jQuery, so you will need some smarts to allow the static resource reference to transcend the JS into your template.

I recommend building what I like to call a Visualforce Bridging Component that runs before your script:

  window.$Resource = window.$Resource || {};
  $Resource.Stuff = '{!$Resource.Stuff}';
  $Resource.MyZip = '{!$Resource.MyZip}';

  window.URLFOR = window.URLFOR || {};
  URLFOR[$Resource.Stuff + '/img/Red.jpg'] = '{!URLFOR($Resource.Stuff, '/img/Red.jpg')}';
  URLFOR[$Resource.MyZip + '/img/Rose.jpg'] = '{!URLFOR($Resource.MyZip, '/img/Rose.jpg')}';

Then your jQuery code in your static resource can look more like this:

  <div class="img-flower">\
    <img src="' + URLFOR[$Resource.MyZip + '/img/Rose.jpg'] + '" width="50" height="50" />\


The idea is to pre-evaluate variables and functions like $Resource and URLFOR. Then you can see them and use them in JavaScript, just as they would look Visualforce, with a minimum mental overhead.

See? The intent is clear; those familiar with VF will spot the analogy; and zip it up and it will still work:

URLFOR[$Resource.Stuff + '/img/Red.jpg'] //JavaScript
{!URLFOR($Resource.Stuff,'/img/Red.jpg')} //Visualforce

(Yes, URLFOR is a JS object; one must squint to pretend it's the same as VF! But you get the idea :-)

  • Are you saying that using the "/resource/1412387865123/MyStaticResource/img/Rose.jpg" pattern is definitely broken and URLFOR must be used?
    – Keith C
    May 15, 2014 at 11:00
  • @KeithC I know it sounds a little pretentious but URLFOR must be used to ensure safety from platform changes. Hand-assembled URLs can fall over on Sites, Portals and Communities due to the path prefix. Here it falls over due to an isdtp=p1 parameter. Gotta use the tools! May 15, 2014 at 11:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .