6 Replies Latest reply on Apr 7, 2014 5:44 PM by BenKreunen

    13v2 Win7 web viewer interaction with Windows Explorer broken



      13v2 Win7 web viewer interaction with Windows Explorer broken


      FileMaker Pro


      Advanced 13v2

      Operating system version

      Win7 SP1 (Enterprise)

      Description of the issue

      Updated from 13v1 to 13v2. Webviewer displaying contents of a folder using "file:///driveletter:/directory/" schema for URL. Allow interaction with web viewer checked. Interaction of the web viewer is impacted by surrounding fields and buttons. Impacts include
      * Failing to gain focus when the web viewer is clicked on
      * Shifting focus to adjacent fields or buttons when clicking on the web viewer object
      * Toggling checkboxes in an adjacent field when double-clicking on the web viewer

      Steps to reproduce the problem

      Create a directory c:\temp on the local HDD and place some (more than 1) text files in it (any files will do but text files are quick to open for testing). Set the view for the folder in Windows Explorer to be Details.
      Create a web viewer in the body of a layout with a URL pointing to this directory i.e. "file:///c:/temp/"
      Tick "allow interaction with web viewer content" in the Web Viewer Setup
      Place additional fields and buttons around the layout.
      View the layout in browse mode.
      1. Click on the web viewer object
      2. Click on a file in the web viewer
      3. Double click on a file
      4. Right-click on a file

      Expected result

      1. The web viewer gains focus, taking on the In Focus appearance defined in the styles (e.g. outer shadow appears)

      2. Click on a file in the web viewer
      File is selected

      3. Double click on a file
      File/folder opens

      4. Right-click on a file
      Context sensitive menu appears with options for Windows Explorer

      Actual result

      The results of clicking in the web viewer when it is displaying the contents of a folder will depend on the position of the click relative to the web viewer border AND the last file name OR if the click is below the scroll bar. The screen grab shows the results for our database which has several elements around the web viewer. Tests on a completely new database are described at the end.

      1. The first time the web viewer is clicked on it gains focus. After that, it depends on where you click as to whether it gains focus.  Whilst not 100% repeatable, the most reliable area is at least ~135 pixels from the left hand edge of the web viewer AND below the centre of the line with the last file name. (see red outline on the screenshot)  Outside of this area, the web viewer fails to gain focus. Tested with different web viewer widths, all resulting in the same ~135px left margin.

      2. Click on a file in the web viewer
      You can only select files in the region where the web viewer successfully gains focus.  In this example, that means only the last file.
      Clicking outside of this region will shift focus back to the Filemaker record OR an adjacent field (Clicking within the cyan outline in the screenshot would shift focus to the upper checkbox to the left of the web viewer, arrowed)

      3. Double click on a file
      If the double click occurs outside of the region described in 1, the currently selected file will open and the web viewer will lose focus, unless the double click occurred in a region where the focus is shifted to another field, in which case the field will gain focus and receive an additional mouse click (hence toggling checkbox or activating buttons)

      4. Right-click on a file
      The results for this will depend on where the focus for the click goes as described in 1 and 2.

      Focus goes to web viewer: context menu for Windows Explorer appears depending on what was clicked on in the web viewer.

      Focus goes to an adjacent object: Filemaker context menu appears depending on the type of object clicked on.

      Focus goes to the Filemaker record: The Filemaker context menu appears CENTERED on the mouse click, resulting in Delete Record being selected when the mouse is released presenting the user with a confirmation dialogue to delete the record. After cancelling out of that, the context menu reappears, centered on the mouse click

      REPEATING with a FRESH database.
      Web viewer as the only object on a layout. Everything works except for the top half of the first filename.

      Add a field to the layout and the areas of the web viewer begin to change. The area of the web viewer where clicking does not focus the web viewer will change depending on the position of the adjacent field. Try moving the field around the web viewer to see what changes.

      Exact text of any error message(s) that appear

      No error messages appear. (apart from unexpected dialogue boxes)

      Configuration information

      Tested with both IE10 and IE11 on the system.


      Only suitable workaround is to have the web viewer in a layout on its own (kinda defeats our usage). (Will try reinstalling 13v1 tomorrow)


        • 1. Re: 13v2 Win7 web viewer interaction with Windows Explorer broken

               Looking again at the annotated screen grab above it looks like the web viewer has been offset (apart from the scroll bar). If this is correct then clicking below the cyan rectangle should select the second checkbox.  This is indeed what happens. It is possible in this example to select the second and third checkbox by clicking in the relative position below the cyan rectangle, and I can click on the buttons above the web viewer by clicking in their relative positions along the top of the web viewer. The check boxes and buttons work as expected when you click directly on them.

               Taking it a step further, I overlayed the screengrab on itself to see if I could accurately map the regions of the web viewer to the adjacent fields and buttons they selected. It wasn't a direct fit, but scaling the image up I could get things to match predictably. The scaling factor was 125% which happens to be the text size I have set in the Win7 Display control panel.

               And therein lies the answer/workaround. Resetting the text size to 100% in the Display control panel got everything working as expected. Luckily I just got reading glasses so it shouldn't be too much of a problem but hopefully it will be fixed in the next update.

               This can be added to the known bug list item: http://forums.filemaker.com/posts/ad61a7e781?commentId=285270#285270 although it's more than just a nuisance. The integration of Windows Explorer within Filemaker layouts is a great productivity feature but this issue breaks the functionality.

          • 2. Re: 13v2 Win7 web viewer interaction with Windows Explorer broken

                 Note, Issue reports are linked to Known Bugs List entries (in both a downloadable database and a report an issue thread) when I see confirmation from a TS person that they can reproduce the issue. Specifiying "Nuisance" in the risk level designation is:

                 a) Very specific to the level of risk to databases and their data integrity as a whole. "Nuisance" level means zero or nearly zero chance that a typical database file will be damaged or that data will be modified incorrectly in your database. Low means one or a very few records might be affected by a single encounter with the bug. High is typically specified for bugs that cause crashes (which can corrupt a file) or that where a single encounter can incorrectly alter the data in massive numbers of records in your database, such as an import records or replace field contents operations might do should there be a bug in such a tool.

                 b) Because of a) above, a bug listed as "nuisance" might be a very major bug for your solution rendering it completely unusuable, but since it doesn't meet the specified criteria, it's listed as "nuisance" because the Importance is specific to your particular project, not projects as a whole.

                 c) the rating is my personal, subjective opinion, it does not reflect how FileMaker Inc rates it, and as far as I know, this rating has no affect on how FileMaker prioritizes any decision on when or if to issue a fix for it.

                 d) If you feel that a bug should be ranked with a higher risk level setting, you are welcome to post your reasons for disagreeing in a private message to me or in the original issue report. If I agree, I'll update the rating accordingly. I just ask that you not post such a comment to the actual Known Bugs List threads so that I can keep them tightly focused on listing brief descriptions of the bug with a link to the originating issue report where one kind find the rest of the details on a given bug.

            • 3. Re: 13v2 Win7 web viewer interaction with Windows Explorer broken

                   Ben Kreunen:

                   Thank you for your posts.

                   Our Development and Testing departments are aware of the High DPI settings under Windows, and the effects it has on FileMaker Pro.  I have attached your post to the original issue.  When any additional information becomes available, I will let you know.

                   FileMaker, Inc.

              • 4. Re: 13v2 Win7 web viewer interaction with Windows Explorer broken

                     Thanks for the info Phil. I'll keep it in mind and send you a PM  with my thoughts on the risk level.  edit: Sent but I got logged out afterwards. Hope you got it



                • 5. Re: 13v2 Win7 web viewer interaction with Windows Explorer broken

                       I did not get any private message from you though you are welcome to post here on that subject as well.

                       That random auto-log out is driving everyone crazy and any posted reply or PM will almost always be lost for good by the log out. The only way that you can protect yourself is to copy the message to your ciipboard so that you can log back in and paste to restore the missing message.

                       And this is a real pain in the but if you try to post an issue report as you can only copy one text box at a time....

                  • 6. Re: 13v2 Win7 web viewer interaction with Windows Explorer broken

                         Thanks Phil.  The email notification from your post alerted me to the absence of a followup post by me as well so I'll try again.

                         I've run another test with a different layout we have that scrapes data from web pages (a more standard use of the web viewer)  This also behaves exactly the same as I described above.  There are 2 consequences to this.

                    1.           Interaction with the web viewer is practically impossible (e.g. we use it to search our library catalogue and then scrape data from the source code when we find the right record)
                    3.           Buttons and fields adjacent to the web viewer may be activated when clicking in the web viewer.  This can lead to inadvertent changing of data if the fields are checkboxes or radio buttons or as a consequence of triggering scripts associated with buttons

                         We did experience alteration of data as a result of this but I was lucky that our database is on a server and it was easy to roll back.

                         Resetting the text size to 100% in the Windows control panel, whilst a workaround for this particular issue, presents OHS issues for those who chose a larger text size for a specific reason.

                         Final edit:  I've made a new database to clearly demonstrate this issue. The web viewer links to a page with a single image that was constructed by cropping a screengrab of the application window to remove the status bar and window edges. This was then duplicated and scaled 125% and then cropped to the area enclosed in the original web viewer. If you set the Display control panel to enlarge text 125% and then open the database, you can activate each of the fields and buttons by clicking on their corresponding portion of the image in the web viewer.