Question Anthony Harrison · Jan 14, 2019

Bizarre Behaviour when generating HTML to Android Phone

Hi,

We are using Cache to generate HTML pages (complete with Javascript), which we are reading in an Android phone App's WebView.

If, when we generate HTML as follows:

<html>

<body bgcolor='red'>

Hello World

</body>

</html>

Reading this is iPad gets what you would expect, a red page with Hello World written in it.

However in Android phone, the page is both white and blank.

What stumps us is that for Android, if we intercept the call in the csp page that generates the html, and we redirect the call to another (cache) page's url (ie another csp page), the whole of the content of the new Url is displayed in the Android browser, no matter how complex.

Has anyone had such bizarre behaviour before?

Kind regards,

Anthony

Comments

Robert Cemper · Jan 14, 2019

Did you check it with Chrome or just the default browser ?

for similar reasons I have set my default browser to Chrome

0
Anthony Harrison  Jan 14, 2019 to Robert Cemper

Robert,

I'm just using the default browser, thanks, I'll try and configure the app to use the Chrome browser!

Of course my immediate worry will be whether or not I can inject Javascript across the C# bridge, as the app is reliant upon that capacity, but I'll cross that bridge when it comes!

Thanks!

0
Anthony Harrison  Jan 14, 2019 to Robert Cemper

Hmmmmn, setting the Chrome browser didn't change the phenomenon!

0
Anthony Harrison  Jan 14, 2019 to Timothy Leavitt

Thanks, Timothy!

It happens on the first run when the app is installed, so nothing is cached, I should have mentioned that, but thanks!

0
Stefan Wittmann  Jan 15, 2019 to Anthony Harrison

Glad to hear you were able to make it work. Debugging these issues can be really painful. Emulators help as you can easily work with the debugger, but emulators only tell you half the story...

I usually debugged and tested these scenarios on a real device, connected to the IDE on my laptop, which allows you to see exactly what is going on via the output window and the debugger of your IDE. 

0
Evgeny Shvarov  Jan 16, 2019 to Anthony Harrison

Hi Anthony!

It's a greeting from the DC manager )

This comment looks like an answer for me and because we have a nice feature on DC to convert comments to answers and vice-versa. So I converted it for you and if you want you can mark it as accepted answer now. 

0
Eduard Lebedyuk  Jan 15, 2019 to Anthony Harrison

Please mark Stefan's answer as accepted.

0
Timothy Leavitt · Jan 14, 2019

This sounds like it could be an issue with caching (at the browser level rather than at the CSPGateway level, given that the page loads just fine in a different browser). Perhaps try clearing the cache in the Android browser then reloading the page?

0
Anthony Harrison  Jan 15, 2019 to Stefan Wittmann

Yup, I do a similar thing, switching between Mac and Windows as required, after all of this bother I've finally got it working on all of iOS, Android, MacOS, UWP, and WPF - and that makes the pain worthwhile!

Thanks for your encouragement as well, Cache can be a lonely world without the occasional post of support to prod one along!

0
Anthony Harrison  Jan 16, 2019 to Eduard Lebedyuk

Eduard, sorry, but you miss-read my comment, I marked 'my' answer as accepted, as my explanation of my fix was in my comment 'to' Stefan.

And just to iterate that answer here, I put the pages concerned through an HTML validator and we discovered some tags that were no longer legal (frameset), even though some browsers still accept this in quirks mode, Android (Xamarin) doesn't.

0
Anthony Harrison  Jan 16, 2019 to Evgeny Shvarov

Hi Evgeny -

Re: "

It's a greeting from the DC manager )

This comment looks like an answer for me and because we have a nice feature on DC to convert comments to answers and vice-versa. So I converted it for you and if you want you can mark it as accepted answer now. 

"

... sorry, but I don't know what you mean, nor what you are referring to.

0
Stefan Wittmann · Jan 15, 2019

There are various things which can bite you with the WebView component. Check the following:

  • Verify the WebView is properly sized (e.g. same size as parent container) as the initial content might be sized 0px...
  • Make sure you granted INTERNET permission
  • Explicitly enable JavaScript
0
Anthony Harrison · Jan 15, 2019

Hi Stefan, thanks!

I've just resolved the issue, we used http://validator.w3.org/ to validate the HTML and as it turns out the Android webview is really strict and breaks when validation errors occur.

In our case it was a Frameset tag, which although not being legal, are still currently rendered in the other browsers that we use.

So guess what, I'm context-switching from my usual Xamarin duties where I consume the Cache generated content, to figuring out how to style an iframe instead, to work on all browsers. Tricky, because the iframe has to expand to the viewport, and then the content link has to zoom to the bounds of the iframe so that no scroll bars are shown.

Thanks for your suggestion!

0
Sean Connelly · Jan 16, 2019

Hi Anthony,

Apart from the broken tag, the reason for the different behaviours with different browsers sounds like your page is defaulting to quirks mode.

You might want to try adding a DOCTYPE to the outer HTML to make rendering more consistent in general.

0