I'm working on an mobile app with Phonegap and jQuery Mobile (JQM).
My index.html (drop point) has a Panel with links to various html pages.
The pages come from local app filesystem (file://) AND remote server (https://).
Since few days i think i've read everything on the topic to make it work correctly but i'm stuck with the "back in history" of the webview (browser) managed by JQM with url hashes.
This problem been related soon when Phonegap born and i found many informations about it on SO and around, whatever i'm stuck at one point.
The most interesting article about it is here, and JQM Docs provides related infos here, i've read all the related questions/answers and applied all the fixes found but i may still ignore something :)
Environment :
Dev platform : Windows, Adobe Phonegap (with Dev app on device & Build site to compile), jQuery 1.11.2, JQM 1.4.5
Sample of index.html, the panel is included with some JS in DOM outsite the data-role="page" div (so it remains on all pages), it contains links to following local & remote files :
Apache server as correct headers for CORS and Phonegap settings are ok for remote access, it's not related to them as i can load the page from panel link, but in case you wonder :
.htaccess :
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
My problem :
If i click/tap the links in the Panel to local & remote pages, it works as expected, but when i use the back in history (hardware button on Android like Back button in browser would), FROM a protocol (file or https) TO another, then the requested URLs are broken because it seems to mix. Samples of 404 errors requests from debug (compiled app on device) :
Request URL:file:///pg_news/
Request Method:GET
Status Code:404 Not Found
Request URL:https://webapp-demo.domain.net/android_asset/www/pageDemoForms.html
Request Method:GET
Status Code:404 Not Found
As you can see, JQM seems to mix things in requested URLs
Important thing: There's a real page (not domain.net of course) behind https://webapp-demo.domain.net/pg_news (cleanurl with Drupal) which just provides a simple html div with data-role="page" attribute.
I'm working on an mobile app with Phonegap and jQuery Mobile (JQM). My index.html (drop point) has a Panel with links to various html pages. The pages come from local app filesystem (file://) AND remote server (https://). Since few days i think i've read everything on the topic to make it work correctly but i'm stuck with the "back in history" of the webview (browser) managed by JQM with url hashes. This problem been related soon when Phonegap born and i found many informations about it on SO and around, whatever i'm stuck at one point. The most interesting article about it is here, and JQM Docs provides related infos here, i've read all the related questions/answers and applied all the fixes found but i may still ignore something :)
Environment : Dev platform : Windows, Adobe Phonegap (with Dev app on device & Build site to compile), jQuery 1.11.2, JQM 1.4.5
File Tree :
Sample of index.html, the panel is included with some JS in DOM outsite the data-role="page" div (so it remains on all pages), it contains links to following local & remote files :
JQM settings (as recommanded for Phonegap) :
Apache server as correct headers for CORS and Phonegap settings are ok for remote access, it's not related to them as i can load the page from panel link, but in case you wonder :
.htaccess :
config.xml :
My problem : If i click/tap the links in the Panel to local & remote pages, it works as expected, but when i use the back in history (hardware button on Android like Back button in browser would), FROM a protocol (file or https) TO another, then the requested URLs are broken because it seems to mix. Samples of 404 errors requests from debug (compiled app on device) :
As you can see, JQM seems to mix things in requested URLs
Important thing: There's a real page (not domain.net of course) behind https://webapp-demo.domain.net/pg_news (cleanurl with Drupal) which just provides a simple html div with data-role="page" attribute.
Thanks all for your help.