Bizarre Behaviour when generating HTML to Android Phone

Question

Question

Anthony Harrison · Jan 14, 2019

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

Discussion (16)3

Log in or sign up to continue

Anthony Harrison · Jan 15, 2019

Resolved in my answer to Stefan!

1 0

score 0 · Answer 1 · 2019-01-14T10:07:31-05:00

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

for similar reasons I have set my default browser to Chrome

score 0 · Answer 2 · 2019-01-14T10:58:15-05:00

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!

score 0 · Answer 3 · 2019-01-14T12:09:04-05:00

Anthony Harrison · Jan 14, 2019

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

0 0

score 0 · Answer 4 · 2019-01-14T11:13:07-05:00

Thanks, Timothy!

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

score 0 · Answer 5 · 2019-01-15T11:29:20-05:00

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.

score 0 · Answer 6 · 2019-01-16T07:52:30-05:00

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.

score 0 · Answer 7 · 2019-01-15T15:48:25-05:00

Eduard Lebedyuk · Jan 15, 2019

Please mark Stefan's answer as accepted.

0 0

score 0 · Answer 8 · 2019-01-16T08:43:09-05:00

Also, if you haven't already, use a common CSS reset to remove other browser inconsistencies, such as this one...

https://meyerweb.com/eric/tools/css/reset/

score 0 · Answer 9 · 2019-01-14T10:39:00-05:00

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?

score 0 · Answer 10 · 2019-01-15T19:25:24-05:00

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!

score 1 · Answer 11 · 2019-01-16T13:26:33-05:00

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.

score 0 · Answer 12 · 2019-01-16T19:44:54-05:00

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.

score 1 · Answer 13 · 2019-01-15T08:20:44-05:00

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

score 1 · Answer 14 · 2019-01-15T08:27:16-05:00

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!

score 0 · Answer 15 · 2019-01-16T08:36:38-05:00

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.