I’m trying the tabbed webbrowser example (located in Example Projects/Desktop/Container Controls) with Google Docs. It doesn’t open links in a new tab. It just shows a blank page in the new tab. Is there a fix for this? Here’s a sample document: https://docs.google.com/document/d/1y71C85KZpy_dpFcakgTxK8lvXZ5SkSJGq5i74vs_dK0/edit?usp=sharing
For comparison, this one does work:
I’m using MacOS 10.15.6 with Safari 13.1.2 and Xojo 2021, Release 1
Any thoughts appreciated.
WebHTMLViewer is an iFrame. Chances are Google does not want to show docs in an iFrame.
I just tested this here. Clicking the link to Wikipedia works for me. Could be a WebKit version issue as I’m on Big Sur.
WebKit renderer has many problems. I found a website where you can’t log in if the CancelLoad event is added even if there’s nothing in it. Can even reproduce with AddHandler. Xojo has made it clear they do not want any feedback, so I haven’t filed the specifics to be looked into.
What a mess,
To be honest, I suspect some of this lie with Google and Apple too.
For instance: Safari on Big Sur can no longer render local pages, it won’t load css or images from HTML files on the disk. Googling for it reveals a lot of complaints, but I couldn’t find a working solution.
I recently came across a web page on Google’s servers that would only display in Chrome, not FireFox or Safari.
Seems like the 90s are back.
I have a workaround for loading local images that I use in GraffitiHTMLEditor, so it can be done with Apple’s WebKit renderer. You have to set a plist value and a couple of other things. When they first made the change I spent way too much time in documentation and on SO tracking down everything that was needed.
Ah, looks like I ran in to more issues with a later build of macOS and resorted to converting images to BASE64 according to my notes. Sorry for the noise.
I just made a simple test:
drop a wikipedia saved file onto Safari empty window,
drop a home made (with Xojo) document with local images onto Safari empty window
Resuls: consider this was rejected. Also, Firefox do that to me, sometimes. I do not care because I do that differently.
With File → Open from Safari, my custom made file is loaded and the images are displayed and so is the simple “style” (look below) is used.
I do not checked double-clicks since Firefox is my default browser.
<tr style="background-color: rgb(255, 179, 255);" valign=top><td>
I get a pink colored background as asked.
I recently came across a web page on Google’s servers that would only display in Chrome
I remember a time (not so long ago) where it was difficult to connect (usually download files) from Microsoft when you were trying to do that from a non Windows OS (usually, a macOS computer from Apple…)
This is my experience:
Safari test above done a minute ago on the last released Big Sur / M1
Same test some weeks ago with Safari / El Capitan…
About the test html file:
it was built wth a Desktop application I created using Xojo 2015r1 (these last months), “as if I wrote it by hand”. At the first trouble while developing the “create html” code, I created the target file wth TextEdit (the macOS application), save it and use it as a memory reminder; so my resulting file works fine. I used Firefox to check eventual error(s) (cmd-u to get the source in a Firefox window).
Back to the op question:
maybe Google made some changes recently and this may lead to what you discover.
This may or may not matter:
from what country are-you trying to access google docs ?
what is your OS default language ?
(locales, etc. if different from OS language default)
Did you try to access with a VPN and set that VPN to be located in the USA ?
I didn’t try that, I right-clicked the HTML file and selected “Open With” → Safari. I was actually trying to debug an issue with Mobile Safari and had hoped that it would show in “Responsive Design Mode”, but because it wouldn’t load the css or images the layout was completely wrong.
In the end I got Safari to display the page from my server, and entered “Responsive Design Mode”, but it didn’t show the problems that appear on an actual iPhone.
Thank you for your previous entry. While I was on Safari, I fooled around in it and discovered (in the Development Menu) many things I never saw or look at previously.
If it does use an iFrame, then this is why the Google Doc from the OP doesn’t work indeed. Manually making an iFrame in a html document en opening it in Chrome does show in the console:
Refused to display ‘https://docs.google.com/’ in a frame because it set ‘X-Frame-Options’ to ‘sameorigin’.
This is set on the server side by google.
A reminder that OP is asking about using the Desktop HTMLViewer.
Example Projects/Desktop/Container Controls
You would see the same X-Frame-Options error if you can see the console in the HTMLViewer I guess.
Except the example doesn’t load the URL in an iframe. It loads it in a new instance of a desktop HTMLViewer.
I went out from the assumption that WebHTMLViewer is an iFrame itself (or acts like one), as stated earlier. Anyway, if google has set this ‘sameorigin’, whatever it is, CORS policy can’t be bypassed.
Michael made a mistake. This isn’t about WebHTMLViewer or iframes at all. OP specifically mentions that he’s using the Desktop example for a tabbed browser.
You are right… Sorry for the confusion. Perhaps setting the user-agent to Chrome or something would enable Google Docs to run.
The userAgent string can be taken from Safari too (search in the Development menu)