I ran into an issue today. It seems that FMPA 15.03 and FMPA 16.02 may return slightly different versions of the Web Viewer content. In the case of 15, some of the HTML elements have single quotes. In the case of 16, those exact same elements from the extact same web page have double quotes around the element value.
OS: OS X 10.11.6
Hosted file, on FMS 15.03
Here's a brief outline:
- I have a web viewer in a popout window; it's fairly full fledged - the user can go to various pages with some built in bookmarks
- When the user gets to the page they want, there's a button to scrape that web page for specific data and add it to the system
- I have opened this file in 15.03 and 16.02, opened the web viewer, and navigated to the same web page in both programs
When I execute this function:
GetLayoutObjectAttribute( "web"; "content" )
In the case of 15, one particular element is returned as:
<span class='display-name '>Bob Hope</span> </h1>
In the case of 16, the exact same line in the HTML source, that same element is returned as:
<span class="display-name ">Bob Hope</span> </h1>
The problem arises from the fact that my parsing routine searches for the double-quote version
and so it is messing up when running under 15 because it doesn't find that.
The web content in 15 also has different headers (starting at the very beginning of the string - yes, the blank lines are part of the actual returned string):
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
And in 16 the same page starts out like (again, starting at the very beginning of the string; there are no blank lines in this one, in addition to other differences):
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Not ALL elements of the page source is all double-quote or all single-quote in 15 vs. 16. As you can see from the different headers shown above most elements are using the same quoting style (double or single).
So is it a bug in 15? A bug in 16? Or just some under-the-hood change in how web viewers are handled, causing a slightly different result?
Yes, as a workaround I could check the version of the client that is running. I may have to do that in the short run. Our client base may not be able to update to 16 for a while, though, and I'd like to not have to worry about coding around differences all over the place.