No html text input to WebView, serious Show Stopper, fix available

[Psercom]

This addresses the issues in 217 222 and 227, with separate issues to reflect different facets, now all addressed in proposed fixes. It resolves for us a final issue in porting a large complicated app to the magnificence of Ooui, which we are using for a production project.

The problem is that WebView works only with a url passed to iframe src, and not with text input.

This seems a show stopper because the best way to have pretty screens is to use an html editor to produce html text files for importing into Xamarin Forms. Given the limitation, these files could be loaded as files via a url, but it's slow and inefficient poor practice to keep/maintain contents on an external source. It's a real leg up to load these as text directly into WebView, and very frequently needed.

An impediment is that different browsers and versions handle text input to iframe differently. We have experimented with various approaches to this and found many things that don't work (e.g. polyfill) and two solutions that seem reasonable.

We are not presenting the second option, which we prefer for ourselves, to actually detect the browser and respond accordingly. This will support older browsers and has fallback in case useragent syntax should change, but is a bit of black art that we feel is too time=consuming for Frank to evaluate and personally test without very extensive discussins and testing, given all his responsibilities and interests.

The best option, we feel is one that is very simple, i.e. just changing the iframe load from src to srcdoc, which is now html standard and being adopted widely, but not bothering with data:text conventions etc. that can make older versions of browsers work. With this change, text input to WebView will in fact be implemented, but only in a forward looking way. It works with current Chrome, Firefox, etc. and will soon with Edge, where srcdoc is already implemented for next release. It should work with other browsers that properly implement srcdoc. It will not work with legacy versions even where these can be made to work with browser version detection. (Note some caching issues for the latter.) An ugly thing is that it doesn't work with IE 11 that is in Visual Studio 2017!!

If one is satisfied to only support browsers as they support the recent srcdoc standard this approach might recommend itself. If one is doing production and worried about all the browsers not upgraded then our other more involved solution might be preferred. Depending on this and evalution of the fix, issues 217 222 and 227 might be considered closed in a fashion. We leave these judgments to Frank who will want to preserve his elegant architecture and careful software practices. Issues around sandbox might be approached by adopting the most secure option then only backing off as time reveals it to be wise. Note that for ourselves we do not pursue any javascript solutions and the various considerations that they entail.

We present the fix below. Please note that this has been so time consuming on our critical path project that we can't generate a pull request at present. Apologies: if this causes difficulties we may be able to do it in a month or two. We need to concentrate on product first.

1) Code changes in iframe.cs inside the long self-documenting ifdef "BiasIframeToSupportSrcdocOnlyRecentBrowsersNoDetect":

    public string Source
    {
        get => GetStringAttribute ("src", null);
        set => SetAttributeProperty ("src", value);
    }

if DETECTREQUEST || BiasIframeToSupportSrcdocOnlyRecentBrowsersNoDetect

    public string srcdoc //tryfix trynew
    {
        get => GetStringAttribute("srcdoc", null);
        set => SetAttributeProperty("srcdoc", value);
    }
    public string sandbox //tryfix trynew
    {
        get => GetStringAttribute("sandbox", null);
        set => SetAttribute("sandbox", string.Empty);
    }

endif //detectrequest

    public Iframe ()
        : base ("iframe")
    {
    }
}

}

2) Code changes in WebViewRenderer.cs:

if (_iframe != null) {

if BiasIframeToSupportSrcdocOnlyRecentBrowsersNoDetect

_iframe.srcdoc = html; _iframe.sandbox = null; // security but research more, might fail some cases

else // orig code, notBiasIframeToSupportSrcdocOnlyRecentBrowsersNoDetect

 iframe.Source = html;  // generally fails, html text input to webview not implemented

endif // BiasIframeToSupportSrcdocOnlyRecentBrowsersNoDetect

}

[Psercom]

I should emphasize that feeding html text to an iframe via WebView is really important for OOUI because it is the only way to play audio and video, which is essential for such a large proportion of apps. The only way, that is, assuming it's too inefficient and slow and fragile to go to the trouble of hosting any desired html pages on a web server bespoke only for that purpose, which we found necessary without the simple documented fix oriented to the current html standard.