Response title
This is preview!
Move this topic
Page Transition Problem with Safari and Google Maps API 3.31
in jQuery Mobile
•
8 months ago
Google recently moved to Maps API V3.31. Now in Safari if I select the Back button on any page it does not respond on the first tap. The second tap does seem to work.
- <a href="#" data-rel="back" class="header-btn ui-btn-left"><img src="css/images/white/765-arrow-left.png" />Back</a>
But then any panel (popup, page) that gets closed always goes to the main panel. This does not happen in Chrome.
And it does not make any difference if its the page the map is on. Just having the API loaded causes the issue. API V3.30 does not exhibit this problem.
Anyone have any ideas?
1
Replies(31)
This sounds more like a bug in Google Maps, rather than a JQM bug. Maybe you should try 3.32.
Leave a comment on jakecigar's reply
No. V3.32 has the same issue. 
Hoping someone would have some insight. Not even sure where to point Google to an code issue and I am sure they are not going to be too interested in pursuing an issue with JQM at this point in its life cycle, especially if I cannot point to the specific code issue.
Leave a comment on ccouper's reply
JQM has not been updated in a long time. Even the 1.5 alpha is not getting much attention.
Feel free to report an issue at Issues · jquery/jquery-mobile, but don’t hold your breath.
If you can make a tiny demo that we can visit in IOS Safari, we can take a look. Please keep it simple without extraneous code/html.
Plunker Is a good place to make JQM demos.
JΛ̊KE
Leave a comment on jakecigar's reply
I wonder if Google Maps is fiddling with the history API?
Can you rearrange your pages so that you don't have to use "back", but use an explicit URL instead?
Leave a comment on watusiware's reply
Well now I am confused. I proved over and over again just changing the Google Maps API version from 3.30 to 3.31 caused the issue. Had others test it too on various devices.
I went to make a sample app to demonstrate this effect and could not get it to perform badly. So I went back and update the production app to the new version number of Google Maps again (only change) and it won't fail either. Again others have tested it and reported they could not get it to fail too.
How is this even possible? I don't think Google could or would change a piece of code that was not in beta.
Leave a comment on ccouper's reply
Something is different between the one that failed and the one that didn't. What?
I hope you use Git, (or some other version management software) to manage updates to your code. It sounds like perhaps you don't, though. If you had, then you could easily discover what is different. If you "live update" your site or app, then you will not know if you "fat-fingered" something. (Accidentally changed something other than the Google Maps API version.)
When I ask "did anything change" I mean did ANYTHING change? Not just your code. What about content? What about the user environment? (OS update, different computer, etc. etc. etc.) Did it ever fail for anybody but yourself?
Complicated software is complicated. Causes of problems are often not found in the obvious places. That's why making a simple example or test case often helps find the problem. If you make a simple example, and it does not fail, that means the problem (may) lie somewhere else (or at least the addition of something else causes it to be manifested). You can then continue to partition the problem, perhaps by re-introducing features one by one, or taking the opposite approach of removing code until the problem goes away.
I agree that Google shouldn't/wouldn't change a piece of code that is not in beta - and even in beta they would change the version number. But perhaps it happened. Google probably has a blog about the Maps API, and/or some forum, where you can check.
Did you think to clear the browser cache at any point? Google (and you) should use "cache-busting" when you make changes. But, still, it's always a useful exercise. Of course, you shouldn't have to ask your users to clear the cache. But it is a useful debugging step.
Leave a comment on watusiware's reply
Gremlins. Google does not change a release after it was released. Either you changed some code or the browser is different.
Were you running a beta Safari? I do often, and things break. Then they repair after an update to a new beta.
JΛ̊KE
Or just a different OS version. There was a software update yesterday.
JΛ̊KE
Leave a comment on jakecigar's reply
I literally just toggled the maps api from 3.30 to 3.31. Just changed the 0 to a 1. No need for Git versioning in that scenario. And I did it multiple times as well to insure it.
After this behavior to test the caching theory I also made a tiny UI change too in the app so I could tell that it was not stuck between edits.
Leave a comment on ccouper's reply
We were all on 11.2.5 but thanks for the tip for 11.2.6 
Leave a comment on ccouper's reply
I had this rear it's ugly head again. It may be a timing issue on how Google Maps API gets loaded. Don't know for sure.
I tried doing a dynamic loading of Google Maps API and that actually made matters worse.
- $.getScript('https://maps.google.com/maps/api/js?key=...
I went back to loading the API at the end of the body and it seemed to be OK.
I hope you contacted google’s support.
JΛ̊KE
Leave a comment on ccouper's reply
Once I do some more investigation I will contact Google. I think I need to build a small test case first. Of course that probably won't fail.
That is your history! 
Also try to make it fail without jQuery Mobile or jQuery.
JΛ̊KE
Leave a comment on ccouper's reply
Well of course Google Maps is now at 3.32 and the problem has returned. No changes in the code other than the version number of Google Maps. I guess it is time to open a complaint but as soon as I mention jquery mobile I am sure that will shut down the conversation.
I will also continue to monitor it like last time when it mysteriously corrected itself.
Leave a comment on ccouper's reply
I can only reiterate…
Good luck!Also try to make it fail without jQuery Mobile or jQuery.
JΛ̊KE
Leave a comment on jakecigar's reply
Unfortunately it's the interaction with the jqm framework and Google Maps that is the problem. It's not a Google Maps problem per se. So by themselves they are OK.
Debugging in Mobile Safari is going to be a challenge but unless I get lucky again, that is what I will have to do.
Leave a comment on ccouper's reply
Google maps has a callback that tells you when the code is fully loaded. Do you use it? You have to.
Ex:
This will be called asynchronously, once all of the map code has loaded.
I trigger an event on the page when the callback is called:
If you use scripts that depend on Google Maps being loaded first, you have to load those scripts AFTER Google Maps code is fully loaded. "code that depends on Google Maps being loaded" means your scripts (that use Maps) and any libraries e.g. I use jquery.ui-map and friends.// This has to be a global function in order for the Maps API to make the callbackfunction riverTrailsMapApiLoadedCallback() {//"use strict";console.log("Google maps is fully loaded");// By triggering an event on the current page, we can catch this event and navigate to the// map if we are still on the same page as when the user hit some map button.// But if the user has navigated away from that page, we can just silently ignore// this, but now the map API is available for the next time the user hits a map button.$.mobile.activePage.trigger("mapapiloaded.rivertrails");}
You can use $.getScript() to load scripts after Google Maps is loaded.
My code is several years old, and some things may have changed!
Leave a comment on watusiware's reply
Yep. Doing the callback where I load the other API stuff like places, geocoder and directions.
Leave a comment on ccouper's reply
It's kind of weird. When I navigate to maps page from my main page it works just fine. Then if I load any other panel like a popup it opens, closes but then when I look at the Safari page forward/backward arrows I now have a forward arrow active, where I should only have a back arrow active. From then on the page loads are all screwed up and even using the Safari page forward/backward needs multiple taps and is basically corrupted until I go back and refresh the app from the first panel.
Somehow Google is corrupting jqm page navigation. I I check the page id in the
$("body").pagecontainer({
beforeshow: function( event, ui ) {
event and it always loads the home ID after closing the popup dialog.
Leave a comment on ccouper's reply
Well I ended up creating a issue with Google on this:
Simple two html file in issue report.
If anyone can find a fault with my logic I would appreciate it. It works fine on GM 3.31 but anything higher it fails.
Leave a comment on ccouper's reply
I see several problems with your document, although not likely to be relevant to this:
- You should use the recommended page structure and doctype. Tell the browser you expect HTML5 behavior, not obsolete XHTML!
- Your scripts and styles belong in <head> not in <body>!
- You are missing the viewport meta.
- <!DOCTYPE html>
- <html>
- <head>
- <title>Page Title</title>
- <meta name="viewport" content="width=device-width, initial-scale=1">
- <link rel="stylesheet" href="http://code.jquery.com/mobile/[version]/jquery.mobile-[version].min.css" />
- <script src="http://code.jquery.com/jquery-[version].min.js"></script>
- <script src="http://code.jquery.com/mobile/[version]/jquery.mobile-[version].min.js"></script>
- </head>
- <body>
- ...content goes here...
- </body>
- </html>
(Sorry, that paste didn't go well... See the link I posted.)
Leave a comment on watusiware's reply
Your right. None of that changed the results.
Thanks for the catch on the <html>
I thought the latest approach was to put all the scripts at the bottom after the page content?
Leave a comment on ccouper's reply
That was the "latest approach" about ten years ago! This practice become popular for a while around 2008. Yahoo (remember Yahoo?) spearheaded this.I thought the latest approach was to put all the scripts at the bottom after the page content?
https://stackoverflow.com/questions/143486/unobtrusive-javascript-script-at-the-top-or-the-bottom-of-the-html-code
Online speeds were still slow for many (beep, beep, beep!) and the thought at the time was to allow the document to start rendering as soon as possible, without having to wait for scripts to load.
But with modern Javascript frameworks that "enhance" the document content using Javascript widgets, that would create annoying jumps/changes in the content as the page loads.
It's NEVER been the right way with jQuery Mobile. Use the recommended document layout.
----
Without the viewport meta, your pages won't fit the width on touchscreen devices. You must have done some work-around. (Assuming your site behaves and fits the width on touchscreen devices.)
Leave a comment on watusiware's reply
Well this can be duplicated in Safari for the Mac so perhaps the advanced debugging tools could help there? A bit out of my league if anyone has some suggestions.
Of course the issue is still not assigned in Google land.
Leave a comment on ccouper's reply
Turns out this is a bug in Apple devices that somehow is exacerbated with GM versions > 3.1
The secret was to capture the state during the first page load and then for iOS devices replace it after the page was shown subsequently. Note pay attention to the third parameter which is required.
This also caused a need for two back presses after the first page load so you will need to add that logic too.
This only happens to apps that load a Google Map and then go away from that page and return.
Leave a comment on ccouper's reply
I have the exact same problem. What a pain 
. Did solve it somehow?
. Did solve it somehow?
Leave a comment on poffisu's reply
Yes it did solve the issue. I captured the state on the first panel access since it was not corrupted and then reset it for every access later.
Leave a comment on ccouper's reply
May I ask how you are doing that?
Are you using the back-method of the History API? This would do it somehow, but the history will be in a messy state, since it would than be possible to navigate forward. It is not possible to remove a history entry from the stack.
Leave a comment on poffisu's reply
Here is what I have done:
Next on the before show event for each panel ID I capture the original state which is good.
I have a special routine I call for both the home and my map panel that will reset the state (ios devices only). Here is the one that is used for the map panel. Note the extra back request if it detects the state is null (ie trashed by Google).
I created two global variables to hold the history state. One for my main panel and one for the panel the map is on.
var window_home_history_state;var window_plans_history_state;
Next on the before show event for each panel ID I capture the original state which is good.
if (window_plans_history_state == null) {window_plans_history_state = window.history.state;}
I have a special routine I call for both the home and my map panel that will reset the state (ios devices only). Here is the one that is used for the map panel. Note the extra back request if it detects the state is null (ie trashed by Google).
This is called after I create the map. I need the map to complete before I hack the state because this is when Google trashes it.function setPlansState() { // hack for safari and google maps issueif (idevice) {if (window.history.state == null) {$.mobile.back();}history.replaceState(window_plans_history_state,"",window.location.href);}}
The one for the main panel is called in the show event for the main panel.
Leave a comment on ccouper's reply
Thanks for the clarification.
Leave a comment on poffisu's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to ccouper's question
{"z23585007":[14737000007606202,14737000007610407,14737000007618055,14737000007617031,14737000007619013,14737000007690079,14737000007690081,14737000007819007,14737000007819009,14737000007819011,14737000007819013,14737000007824013,14737000007825001,14737000007827193,14737000007859205,14737000007875105,14737000007882077],"z7664639":[14737000007609249,14737000007621003,14737000007814017,14737000007823007,14737000007823009],"z8404080":[14737000007880111,14737000007879339,14737000007879424],"z2950240":[14737000007611269,14737000007611275,14737000007617029,14737000007617033,14737000007686129,14737000007686131,14737000007816035]}
