1 2 3 Previous Next 75 Replies Latest reply on Oct 24, 2015 11:15 AM by sfpx

    FMGO 13 , webviewer crashes


      I have a web viewer with the following content

      "data:text/html," & "<!DOCTYPE HTML>



              <script type=\"text/javascript\">

             var Calls=0;

             var LastCall=0;

                  function handler(location) {

                      var messageArea = document.getElementById(\"messageArea\");

                      messageArea.innerHTML=\"Calls:\"+Calls+\"<p>Latitude: \" + location.coords.latitude + \"</p>\";

                      messageArea.innerHTML+=\"<p>Longitude: \" + location.coords.longitude + \"</p>\";

                      messageArea.innerHTML+=\"<p>Accuracy: \" + location.coords.accuracy + \"</p>\";

                      messageArea.innerHTML+=\"<p>Speed: \" + location.coords.speed+ \"</p>\";

                      messageArea.innerHTML+=\"<p>T: \" + location.timestamp+ \"</p>\";



      if (location.timestamp-LastCall>5000 || LastCall==0){














                  function fail() {

                      var messageArea = document.getElementById(\"messageArea\");

                      messageArea.innerHTML=\"<p>Can't get located</p>\";






                 function CallFM(latitude,longitude,accuracy,speed) {

      var body = document.getElementsByTagName(\"body\")[0];

      var a = document.createElement(\"a\");

      a.href = \"FMP://~/MyApp.fmp12?&Script=UpdateCoords&$latitude=\"+latitude+\"&$longitude=\"+longitude+\"&$accuracy=\"+accuracy+\"&$speed=\"+speed;



      a.style.display = \"none\";





                  function getLocation() {



                    navigator.geolocation.watchPosition(handler,fail,{maximumAge: 2000, enableHighAccuracy: true, timeout: 2000});







          <body onload=\"getLocation();\" bgcolor=black >

              <div id=\"messageArea\">









      The updatecoords script  simply puts the parameter values into global variables that are displayed on the layout.


      FmGo13 will crashes randomly...it may take 30 minutes , less or more.


      I suspect a memory leak somewhere.

      Any obvious reason why it would crash ?



      I know FMGo has a location function but the problem is that it's a "blocking" function and can't run in the background ..plus it does not have the speed which is useful for my app.

        • 1. Re: FMGO 13 , webviewer crashes

          There could be several reason a database crashes.  I have seen several solutions that will run without crashing so I would verify that may database is not corrupt.  Run recover on the database, even if recover does not find anything wrong it does not mean the database is not corrupt.  Secondly create a new sample database and test.  This should rule out the database being corrupt as causing the crashes.   It could be a issue with your java code and how you are passing the information to FM.   Here is a list of Open Source Files that have java used in them.  I have not look at every database so I can't say they all use java.  Maybe it will give you some ideas of how the java should be used in FM.  Tim Dietrich | Open Source FileMaker Solutions

          • 2. Re: FMGO 13 , webviewer crashes

            Thanks for taking the time to reply.

            My database is not crashing without the web viewer so I'm pretty sur it's not corrupted.

            I remember having tested my web viewer on a small test database and it crashed too.

            I think the problem is in the Java code or the way FMGO handles the fmp call.

            If anyone spots a problem in this code, please let me know...it's driving me crazy.

            • 3. Re: FMGO 13 , webviewer crashes

              Objects in the database can be corrupt.  The best way to test is to run recover on the database and to test a brand new database without anything being copied from the old database.  You can copy the corrupt object to the new database.


              It may not be an error in your code but how the code is used in your database, which is why I provide links to other software that uses java and passes the information to FMP.

              • 4. Re: FMGO 13 , webviewer crashes

                Prior to the implementation of the web viewer into my database I tested the system on a new database with only one layout and a single table with 1 record. I got some rare random crashes on that database too.


                I still wanted to test the system on my database (thinking that I would fix the instability issue later) but I did not copy the web browser object but created a new one and pasted the script in it. So really, corruption is not the reason for the crash.


                I will do some more tests on the test database to see if there is a pattern.

                I may eventually put it in an attachement in this thread.

                • 5. Re: FMGO 13 , webviewer crashes
                  Markus Schneider

                  Can You test this db with FileMaker Go 14.02? There are no detailled release ntes available - but when it runs fine under 14.02, chances are good that it is/was a problem with Go13


                  Tracy's rigth: A db can turn into corrupt because of one element - so I would run a recover on a copy of the file and read the recover log (be aware that not all entries in that log are errors! Some of them are informational, some can be solved by ungrouping objects, etc.)


                  THat said, there are corrupted db's - but when a Go version crashes and the desktop variant not... mostly an issue with Go (but can be a compatibility thing among the webkit..)

                  • 6. Re: FMGO 13 , webviewer crashes

                    Your javascript is trying to replace whole page with


                    How about using iframe or img or something other than webviewer itself, to load the fmp: call result into it.

                    • 7. Re: FMGO 13 , webviewer crashes

                      I will do some extensive testing tomorrow.

                      For the record, the script uses the watchPosition method.

                      The method is constantly running and checking the gps coordinates.

                      If the phone is moving, the method will call the handler function which will launch the updatecoordinates script on my db if the last call was made more than 5 second ago. Basically if the phone is moving, the updatecoordinates script will be called approximatively  every 5 seconds.


                      I guess it crashes when the handler is called or the filemaker script is called.

                      It makes it tough to test because in both cases the phone has to "move"...and since it can take 30 minutes or more before it crashes....well you get the picture

                      • 8. Re: FMGO 13 , webviewer crashes



                        I think this is a good point that user19752 makes about using a slightly different means to trigger the FMP script.



                        My thoughts:


                          - The code you posted looks fine to me.


                          - I think suspecting a memory leak makes sense.


                          - Would be interesting to test to see if it still crashes if you run the Javascript code, but remove the part that triggers the FM script.  This would help determine if the memory leak is related to prolonged use of watchPosition, or is related to the triggering of the FM script.


                          - Would also be interesting to test a version that uses window.location to trigger the FMP URL.  I realize that you may have good reason for using the anchor element methodology, but it would be nice to determine or rule out if there is a memory leak related to continually adding and removing an element to/from the DOM.



                        HTH, and hope you'll post back with what you find out.


                        Thank you,



                        • 9. Re: FMGO 13 , webviewer crashes

                          First of all, thanks guys. I appreciate your contributions a lot.

                          I use the anchor method to call FM simply  because I read somewhere that the window.location method does not work (in fact I think I tried it without success too). If you have a code that works, let me know. Not a fan of the "fake click" approach anyway.

                          It may be the problem. I just had a crash with my small test db.


                          EDIT: The window.location method works fine. I'm testing it right now.

                          • 10. Re: FMGO 13 , webviewer crashes



                            Thanks for the added info.


                            I've used window.location (or perhaps document.location) to successfully trigger scripts from FMGo v. 13.


                            Might take me a day, but I will look for a code sample to post.


                            Thinking further on what to suspect here:


                            -  the geolocation code on its own could be at fault (running constantly)

                            -  continually triggering a FMP URL every 5 seconds through any means could be at fault

                            -  continually adding and removing a node to the DOM could be at fault


                            I realize that the above is fairly obvious, but the related point that I want to mention is that, fortunately, each of these can be isolated and tested on its own.


                            hth, good luck, and I'll look for a code sample that uses location (not tested with v. 14)




                            - steve

                            • 11. Re: FMGO 13 , webviewer crashes

                              No need for the window.location code Steve, it works fine. I don't know what I tried before...

                              Unfortunately it crashed with the window.location method too (after less than 5 minutes)


                              function CallFM(latitude,longitude,accuracy,speed) {

                              window.location= \"FMP://~/gpstest.fmp12?&Script=UpdateCoords&$latitude=\"+latitude+\"&$longitude=\"+longitude+\"&$accuracy=\"+accuracy+\"&$speed=\"+speed



                              The updatecoords in this test db is very simple and only puts the coordinates into global variables.


                              Next test: No Call to Filemaker

                              • 12. Re: FMGO 13 , webviewer crashes

                                Well it crashed without any filemaker call. This is so frustrating !


                                Next test: fmgo 14

                                • 13. Re: FMGO 13 , webviewer crashes

                                  and guess what ...Filemaker Go 14 crashed too...after only a few minutes.

                                  I really would like to use the watchposition api but it looks like it will not be stable enough..

                                  I think I basically tried everything now

                                  • 14. Re: FMGO 13 , webviewer crashes

                                    First, just a word of thanks:


                                    By posting your updates on how this is going, you are really benefitting all of us, who can watch and learn from your posts.  Thank you.


                                    You are definitely going into new and interesting territory:


                                    If you are really interested in pursuing this, including workarounds, here are a few things to think about:


                                    1) If the code that this causing the crash is the use of the watchposition API, one potential workaround would be to never let this code live on its own for very long.


                                    2) With point #1 in mind, if you are getting at least 20 minutes of non-crash use, you could modify your FM script so that, when it is triggered to store the new coordinates, it also checks to see how long the current webviewer code has been running, and, if it has been for more than 15 minutes, it clears and resets the webviewer, hopefully putting an end to the memory leak, or whatever is causing the problem.  There is no guarantee that this would work, but it is something you could try.


                                    3) Another approach:  Might it be possible to make your Javascript code more sophisticated, so that it periodically kills off and reinstates the position-listening functionality?  I am not familiar with the watchposition API, so I don't know if you can un-register a listener, or if doing so behaves as expected.  If so, this might be another approach, i.e. a variation on point #2 above.



                                    Thanks again for letting us know how this has been working out.  I have learned a lot from it.





                                    1 2 3 Previous Next