3 Replies Latest reply on Dec 3, 2013 11:09 AM by carlo.m

    How to solve webviewer memory leak?


      As I understand it, for a layout with a webviewer each record is like a "tab". Every record you open/visit on a layout, the webcontent is created.


      I have a solution (running on windows) in which many records are visited and am having issues with Filemaker crashing every 2-4 hours. This is only happening to users that use this particular layout that has a lot of html on it.


      As more records are visited, the memory use goes higher and higher without ever going down until it crashes.


      How can I "clear" or "flush" these "tabs" so it doesn't crash? What techniques can I use besides closing and opening FMP every given period of time or number of records?


      I'm thinking of an ontimer script that does a refresh window/flush cache, but am not sure what effect it will have if it runs when a user is using the layout or if it will effectively clear the cache created with the embedded use of Internet Explorer?


      I added an update in the form of a reply to the main question so as to maintain the evolution of the issue taking into account feedback given by other users. Join the discussion!

        • 1. Re: How to solve webviewer memory leak?

          Hi Carlo,


          I'll bet that you have already taken care of this, but, just in case:


          Assuming you are no longer utilizing MBS WebView.InstallCallback, I'd make sure that there are no traces of invoking that particular code so as to free up any extra resources that feature consumes.


          Like I said -- you have probably taken care of this, but on the off chance that you still have any residual references to that code, it seemed worth mentioning.


          Good luck!   I will be watching this thread with interest to see if anyone has some good advice to offer.


          Very best,



          1 of 1 people found this helpful
          • 2. Re: How to solve webviewer memory leak?

            I had actually missed removing the Install Callback step. Good catch!


            It removed about a 10mb memory overhead.

            • 3. Re: How to solve webviewer memory leak?

              UPDATE TO ISSUE:


              I have done some testing and here is what I have found.


              In my particular case, once the user reaches the layout on which all his work is done, the memory hit is at 111mb. After completing an order cycle in the record (data input, order processing) the memory increases by about 9* mb. After creating a new record and loading the html onto that large webviewer, the memory increases 10mb. I did several iterations, and they all average at about the same increases in memory, rounding of to 20 mb per record creation and capture in a single session.


              * The first time the layout is loaded, there is an additional 10mb of memory that is allocated after the first time any javascript is run.


              I tried to flush cache to disk. No tangible impact.

              I tried to refresh window flushing both options. No impact at all.

              I tried removing the content of the html (data/html) on the webviewer by running a javascript that basically removed the html element from the page in which all javascript, html and css reside. No impact at all.


              Then I tried closing the window. On a single iteration test (one record), the memory increased by 19.6mb during data capture. Upon closing the window, about exactly that same amount decreased in memory.

              Then I ran the exact same test, only instead of closing the window (which would cause a headache for a user to watch the screen flash every time), I changed layouts. This didn't do as much as the previous solution (closing the window), it only cleared 16.5mb, still retaining 3.1mb. I don't know if maybe that is maybe the javascript that is only cleared when the window is closed.


              I will do some more tests later today, but I thought I'd get the ball rolling and see if these tests help spark any ideas that might eventually give us a tangible solution. Knowing exactly how/when/what triggers filemaker to close it's connection with the embedded IE program inside of Filemaker would be ideal... But any and all ideas are welcome.