dojo.selector.acme loading is not compatible with HTML5 offline cache on iOS

[Ming Zhe Huang]

Please try the test case on mobile Safarai on iOS. I'm using iPad1.

1. Please enable debug console of Safari.
   
2. Please make sure the web server hosting the test case can return correct MIME content type for cache.manifest file. Please refer to this blog post on how-to:
   

• First, connect iOS device to a network and visit the test.html. Check the log and you'll find all is cached at local.
  
• Second, set iOS device offline. Kill Safari mobile and restart. Visit the test.html again. Check the log. You'll find an XHR error.
  

I locate the problem related to amce.js loading. You can try the uncompressed version of dojo.js which I added one logging at line 297, and you will find acme.js shows up in the xhr failure. I'm not sure whether this is specific to acme loading or it's a more generic problem in the new loader.
I could not reproduce the same issue on Chrome 13 desktop. But this bug has already prevented us from developing a mobile web application which is supposed to run in offline mode.
BTW, the built JS files are from dojo nightly build.

[Ming Zhe Huang]

test case

[bill]

It almost sounds like a loader issue but if it only happens for acme.js then must be something to do with the query framework?

[Ming Zhe Huang]

Hi Bill,

I guess I might figure out the problem. You're right, it's a generic problem in dojo loader.

1. In mobile Safari and Chrome, Web app loading and offline cache handling are two independent processes running in parallel. You can check the logging message (use uncompressed dojo.js) on desktop Chrome which can provide more details. That make sense since offline cache manifest can define much more assets than initial page needs.
2. However, mobile Safari seems NOT block JavaScript? execution before the detection of manifest file ends. Check the log message. The error happens before detection is over.
3. By default Dojo will load a module through XHR. That will definitely fail in offline mode.
4. Unfortunately it seems that browser is not totally switched to offline mode before the detection of manifest file ends.
5. And since JavaScript? execution begins before detection is over, that means if Dojo tries to load module through XHR before detection is over, even that module is under local cache, the loading will fail. That's the error in line 297 of dojo.js.

So I think this problem is due to our module loader implementation and subtle behavior in mobile Safari.
Some workaround I can think of:

• Prevent ANY dynamic module loading at initial stage. Try to squeeze them into layer files. That could be difficult for complex web application.
• I found using async loading works, e.g. add "async:true". The async loading uses <script> which seems be treated nicely by browser.

One proposal for dojo loader is that in XHR loader can we delay module loading until the offline cache manifest detection is over?

[Ming Zhe Huang]

Oops, I forgot to attache the link on how to configure manifest MIME type: ​https://www.ibm.com/developerworks/mydeveloperworks/blogs/94e7fded-7162-445e-8ceb-97a2140866a9/entry/offline_web_applications_and_caching_of_web_resources65?lang=en

[Ming Zhe Huang]

That's a loader problem, I guess.

[bill]

I thought XHR didn't work on mobile at all, and the only thing we support is async:true. If setting async:true fixes the problem that seems good enough, but anyway I guess Rawld should look at this ticket.

[Rawld Gill]

I don't understand why we care about XHR not working on mobile. The soln is to simply use the async loader. I strongly suspect this issues exists in the old loader too. Lastly, I'm extremely adverse to any enhancements to sync mode loader...there's already too much cruft there for a dead design pattern.

[zhangyp]

This problem does not exist on dojo 1.6 loader. To some users, it would be considered as regression. I think we need to let users know that if they want to enable offline cache on mobile devices when using dojo 1.7, use the true async loader and use require to load js resources other than dojo.js instead of writing <script> tag.

[Ming Zhe Huang]

Would you please consider this bug again? If a user migrated from 1.6 with offline cache in his app, he may find that his app is broken.

BTW, we've written a post on enabling offline cache with Dojo 1.7: ​https://www.ibm.com/developerworks/mydeveloperworks/blogs/94e7fded-7162-445e-8ceb-97a2140866a9/entry/draft_enable_html5_offline_web_application_with_dojo_1_716?lang=en

[Rawld Gill]

I'm having trouble seeing the behavior is any better on 1.6: the 1.6 sync loader uses XHR. Maybe a built version of some code in 1.6 is using the xdomain loader, and therefore using script injection to load scripts. If that's the case, then use a built version in 1.7 and set async to truthy.

In any event, what is the problem with using the async loader? It uses script injection exclusively and should solve the problem.

[Rawld Gill]

Replying to archerzz:

Would you please consider this bug again? If a user migrated from 1.6 with offline cache in his app, he may find that his app is broken.

BTW, we've written a post on enabling offline cache with Dojo 1.7: ​https://www.ibm.com/developerworks/mydeveloperworks/blogs/94e7fded-7162-445e-8ceb-97a2140866a9/entry/draft_enable_html5_offline_web_application_with_dojo_1_716?lang=en

Hi archerzz!

I read your blog post...very nice work diagnosing all of that.

If you can provide me with a patch that delays until (or fires a callback when) the offline cache manifest detection is over, I'll has-bracket it into the loader.

That said, I really think this is going down the wrong path. Since mobile code should be fairly new anyway, why not just express the application in AMD modules and load asynchronously...then the problem goes away.

Another option is to do a build. Remember, built code can always be loaded asynchronously.

Since we have two workarounds (express in AMD or do a build), I am closing this for 1.7. Again; if you really think it is very important...send me the patch described above and I'll ensure it gets into the loader for the 1.x branch (this whole issue will not exist in 2.0 since there will be no sync loader).