1 2 3 4 Previous Next 45 Replies Latest reply on Jun 14, 2012 10:21 AM by steve_ssh

    IWP, data URL, and browser wars




      I have a simple HTML page (basically, a table) that I'm attempting to display in a web viewer. The solution in question is to be run over both the FileMaker client and over IWP. The script populates the web viewer with the HTML code via data URL, then displays the layout with the web viewer on it. Piece of cake.


      Problem is, it works flawlessly on the FileMaker client, on Safari, and on Google Chrome. But on Internet Explorer and Firefox, I get the layout with a blank web viewer. (Huh?)


      I noticed that the web viewer is rendered as an iframe inside the IWP page, so I thought, "Okay, maybe it doesn't like the document headers." Tried it both with and without. Tried it with a header stylesheet and with inline styles. Same result.


      Any ideas from smart people out there?



        • 1. Re: IWP, data URL, and browser wars

          If it's just a table, have you eliminated everything but the table? Or do you need other elements and have just removed the header?


          The data protocol was/is intended for snippets of HTML.


          Browser limitations generally point to need to test (with JS?) so that alternate code can be used. Same with the CSS. Hard to say without seeing the code.


          What version of FMP/FMS are you using for IWP?



          -- sent from my iPhone4 --

          Beverly Voth


          • 2. Re: IWP, data URL, and browser wars

            On FireFox, you could install the Firebug extension to inspect the code (IWP HTML + embedded HTML of the WV).

            • 3. Re: IWP, data URL, and browser wars

              Hey, Beverly.


              I have a <body> tag enclosing the elements, with inline styles. Here's a snippet (the tables are sometimes a little long):


              <body  style='font-family: tahoma, arial, helvetica, sans-serif; font-size: 12px;'>

              <div  style='text-align:center; font-weight: bolder; font-size; 18px; color: #3b5e33;' >Veterans Enrolled between 1/1/2012 and 12/31/2012</div>

              <br />

              <table style='border: thin #333 outset; border-collapse: collapse; font-size: 10px;' border='none' cellpadding='3' width='100%'>


              <td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>Last Name</td>

              <td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>First Name</td>

              <td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>HMIS #</td>

              <td style='border: thin #333 outset; text-align:center; font-weight: bolder; background-color:#7b9e73;'>Primary Phone</td></tr>

              <tr><td colspan='4' style='border: thin #333 outset; font-weight: bolder; background-color:#7b9e73;'>Notes</td></tr>


              <tr><td  style='border: thin #333 outset;'>(last name)</td>

              <td  style='border: thin #333 outset;'>(first name)</td>

              <td  style='border: thin #333 outset;'>(registration number)</td>

              <td style='border: thin #333 outset; text-align:center;'>(phone)</td></tr>

              <tr><td colspan='4'  style='border: thin #333 outset;'><br /><br /><br /></td></tr>








              I'm on version 12, Pro and Server.



              • 4. Re: IWP, data URL, and browser wars

                Thanks, Martin. Just doing a "view source" gives me this:


                <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">



                <meta http-equiv="content-type" content="text/html; charset=utf-8">


                <link href="res/favicon.ico" rel="SHORTCUT ICON">

                <script type="text/javascript" language="JavaScript1.4" src="res/fmi_iwp.js"></script>

                <script type="text/javascript" language="JavaScript1.4" src="cgi?-getstrings"></script>

                <script type="text/javascript" language="JavaScript1.4">


                if(window.iwp != null && window.iwp.setupTopFrame != null)

                window.iwp.setupTopFrame( false, false );

                // -->



                <meta http-equiv="refresh" content="1; URL=/fmi/iwp/cgi?-noscript">



                <frameset border="0" bordercolor="#D4D0C8" rows="12,*" frameborder="NO" framespacing="0" cols="*" onunload="window.iwp.handleUnload()">

                <frame title="Toggle status area" id="controlFrame" frameborder="no" marginheight="0" marginwidth="0" name="controlFrame2" noresize scrolling="NO" src="res/control_frame.html">
                <frame title="Database contents" frameborder="no" marginheight="0" marginwidth="0" name="bodyFrame2" src="/fmi/iwp/cgi?-open">


                I get basically the same thing on Explorer. It captures my opening and closing <body> tags, but then ... nothing. Would Firebug show me something different?



                • 5. Re: IWP, data URL, and browser wars

                  Not sure about HTML 4.01 and framesets . . .

                  • 6. Re: IWP, data URL, and browser wars

                    Yeah, me neither. Tell FileMaker. That's how they implemented web viewers in IWP.   



                    • 7. Re: IWP, data URL, and browser wars

                      Hello Mike,


                      The sample HTML data was helpful - thanks for including it.


                      I can not speak with respect to IE, but I have observed that Firefox on OSX is choking on the # chars included throughout your HTML code.  This appears to be the case regardless of whether the WebViewer has been configured to encode the URL.



                      A potential workaround appears to be:


                      Escape the # chars yourself, i.e. if the page is being served to a web client, then substitute # chars in your data url with the appropriate escape sequence of:   %23


                      I'll attach a sample file to illustrate.


                      I'd be interested in knowing whether this appears to be a valid workaround for IE, as well.  Since there is always the possibility that there may be a larger set of characters which are going to choke the clients, the work may not yet be done here, but I think it is a start in a good direction.









                      Tested over here using:


                      OSX 10.6.8

                      FMPA 12.0 v1  (IWP served from FMPA, not FMS)


                      Opera 11.64

                      Safari 5.15

                      Google Chrome 19.0.1084.53

                      Firefox 12.0



                      Reference I used to check my thoughts about proper escape sequences in data URL:



                      1 of 1 people found this helpful
                      • 8. Re: IWP, data URL, and browser wars

                        rather than escaping the # throughout, I think I'd add a class to CSS style and call it in the table where needed. but if IE does choke on it, you only have one place to change the style! this also has the advantage of cutting down in the number of characters in the code (helpful with data URLs).


                        Here's my reference on data: (protocol) URLs:


                        data: URLs are defined by RFC 2397 (http://www.faqs.org/rfcs/rfc2397.html) , and are described as:

                        Some applications that use URLs also have a need to embed (small) media type data directly inline. This document defines a new URL scheme that would work like 'immediate addressing'. The URLs are of the form:


                        The URLs allow content creators to embed small files inline HTML documents, without complicated, document level formatting...



                        search for 'RFC2397' and/or 'data urls' for many links in addition to the faq above and Steve's wikipedia link.



                        • 9. Re: IWP, data URL, and browser wars

                          Hey, Steve, thanks. That does indeed help on Firefox. IE, on the other hand, is still blowing up. It echoes the code out to the browser, and View Source reveals the "%23" string in front of every character, just like it should. But the web viewer is still blank.


                          Any other ideas?



                          • 10. Re: IWP, data URL, and browser wars

                            Thanks, Beverly. I did something similar - created a variable at the head and just echoed that out.


                            Still no joy, though. IE is still giving me the royal "STOP" sign.  



                            • 11. Re: IWP, data URL, and browser wars

                              Hi Beverly,


                              Thanks for the extra information.  Until reading your post and taking a look at the RFC that you cited, I never really thought about size restrictions for the data URLs -- that's real helpful to know, and I'm glad to be aware of it.


                              As for centralizing the style definitions into one or two CSS classes, I'm all for that.  I got the feeling from Mike's post that he might have already been doing that, but that in trying to experiment with getting it to work across all browsers he might have switched to the inline styles just to see if it worked any better.


                              Thanks again for the tip on the data URL.





                              • 12. Re: IWP, data URL, and browser wars

                                Yes, Steve, I did have a stylesheet embedded in the document header ... when there was one. Stripped it back out and went to inline styles trying to get it to work across browsers, just like you said.


                                Right now, I'm even having trouble getting the solution to work consistently on Windows 7 - on any browser. I'm really beginning to develop an antipathy for IWP ...



                                • 13. Re: IWP, data URL, and browser wars

                                  Hi Mike,


                                  Originally I was thinking about pursuing the idea that other chars may need to be escaped within the data URL to get this to work with IE.


                                  Then I stopped and re-read the information at:




                                  The above wiki article mentions that IE8 and IE9 provide only limited support for the data URL functionality.


                                  In particular, the claim is that such URLs can be used for a small range of purposes:


                                  • object (images only)
                                  • img
                                  • input type=image
                                  • link (data URI must be base64 encoded)
                                  • CSS declarations that accept a URL, such as background-image, background, list-style-type, list-style and similar.


                                  The implication is therefore that IE will not support the data URL as we are trying to use it, namely, to populate the contents of an iframe element.


                                  I poked around a bit to see if I could find any documentation to confirm this claim.


                                  This page:  http://msdn.microsoft.com/en-us/library/cc848897%28v=vs.85%29.aspx   makes the same claim.


                                  In particular, it states:


                                      "For security reasons, data URIs are restricted to downloaded resources. Data URIs cannot be used for navigation, for scripting, or to populate frame or iframe elements."


                                  The above was kind of a bummer to find out, but at least it means we can avoid banging our head against a wall that isn't going to move.






                                  Message edited by: steve_ssh.  Reason:  Original message was longer and less helpful.

                                  • 14. Re: IWP, data URL, and browser wars

                                    Steve -


                                    I appreciate your help on this. Your first example is right.


                                    If you want to give the Opera checker another shot, by all means. I'd love the help. Right now, I'm getting a vicious hangup on one report that has to be fixed before I go any further. I can ask the users to load Chrome, but I can't deal with the system hanging up when they try to run a report.


                                    Thanks again.



                                    1 2 3 4 Previous Next