7 Replies Latest reply on Apr 13, 2015 3:33 AM by nickg

    Webviewer malfunction with latest OS X 10.10.3?




      I have a webviewer that has until now been successfully rendering a Google map with markers and polylines both on OS X and iOS. Since the last OS X update the webviewer (and Safari) on OS X render only a marker popup but no map, when called from a script that exports the HTML in UTF-8 format and calls SetWebViewer or OpenURL respectively. The same file on iOS does open and render the map as expected. Also, if I double-click the html file in the temp directory it opens correctly in Safari.


      So, this appears to be something relating to how FMPA 13.0v5 interacts with OS X 10.10.3 or with the latest Webkit as nothing else has changed than upgrading the OS X. Specifically, nothing has changed in the html or script preparing the code for display.


      Has anyone else experienced this? Any thoughts on how to fix it?





        • 2. Re: Webviewer malfunction with latest OS X 10.10.3?

          Thanks for the example Stacy, I can confirm that your file does display the map correctly on my desktop. I have followed the Google Developer documentation carefully and the webviewer used to display the map as intended. What is odd is that the page has only recently stopped rendering and when only change has been the upgrade to OS X 10.3.3. Even older archived copies of my FM file that always worked correctly no longer render.


          My page code is much more complex than your sample, with inline and external Javascript code. I guess something there is no longer compatible but, before embarking on a potentially tedious debug of the JS, I thought others may have noticed the same problem!


          Thanks at least for confirming that some maps render properly from FM.

          • 3. Re: Webviewer malfunction with latest OS X 10.10.3?

            Hmm, interesting challenge, can't help you with the 10.10.3.  But if schablee's file displays correctly, the question is what is different about his and your implementation.


            Is your implementation using really long urls? Maybe 10.10.3 has a different URL limit.  Can you try your file with a minimum of data?


            You mention external Javascript code... maybe the update has a new security feature blocking access...


            Good luck with the hunt!

            • 4. Re: Webviewer malfunction with latest OS X 10.10.3?

              I don't think it is a url limit.  I understand that safari allows really large urls.  Urls length has been an issue for Windows but not Macs.  I've seen other post that states that Google maps has changed some of their urls   You maybe able to compare the url used in my sample with yours.

              • 5. Re: Webviewer malfunction with latest OS X 10.10.3?

                Well, it turns out that the OS X upgrade is a red herring - I tried it on a friend’s 10.9 iMac and the same error occurs.


                I don’t think this is a Safari problem because if I load the same HTML file from the temp directory directly in Safari it renders correctly. So, URL length and external APIs (which are in the same temp directory) work fine.

                • 6. Re: Webviewer malfunction with latest OS X 10.10.3?

                  Now I have ruled out the OS upgrade as a cause (it doesn’t work on 10.9 either), I am wondering if Google has changed their code recently. There is an error showing in the error console even when the code renders correctly - the URL for the openhand icon is prefixed file:// so it cannot be found. Would an error like this cause the FM - webkit code to break but not prevent Safari from rendering the page?


                  By the way, I am using the Google Maps Javascript API, not the Static Maps version, because I interact with the place-markers.

                  • 7. Re: Webviewer malfunction with latest OS X 10.10.3?

                    I've found the problem - the URL generated by FM in OS X includes the SystemDrive prefix and this breaks rendering in the webviewer or Safari, whereas launching Safari from the HTML in the temp directory does not include the system drive in the URL. Substitute ( $localPath ; Get ( SystemDrive) ; "/" ) did the trick.


                    Quite why this was working before and then stopped I cannot say


                    Thanks for your help