Skip to content
This repository has been archived by the owner on Mar 14, 2023. It is now read-only.

Differences between Web and Mobile and usage limitations #27

Open
adrianflutur opened this issue Aug 17, 2021 · 1 comment
Open

Differences between Web and Mobile and usage limitations #27

adrianflutur opened this issue Aug 17, 2021 · 1 comment
Labels
documentation Improvements or additions to documentation

Comments

@adrianflutur
Copy link
Owner

adrianflutur commented Aug 17, 2021

Hello, here I'll try to create a helpful guide with all the differences I can find between the two and a variety of use cases when one can not bypass the intrinsic limitations of the package, since this is not really obvious from the documentation.
This will be updated from time to time. Here we go:

The Web version (iframe):

  • Can accept 3 types of content:

  1. HTML (static or from assets)
  2. normal URLs which support iframe embedding (such as https://flutter.dev/, it allows you to embed it into your iframe)
  3. normal URLs which do not support iframe embedding (such as https://google.com, you need to use SourceType.urlBypass for this). The package treats theese pages as follows:
    • It fetches the page's HTML source using a HTTP call to a Proxy server, which will remove the headers which block iframe embedding
    • It will set the HTML source to the iframe, just like we're doing at point 1) with HTML content
  • At the moment, it behaves much better than the initial version but still, one should NOT use it (especially with SourceType.urlBypass) for security-related stuff, such as OAuth or similar. This is because:

  1. As far as I know now, cookies won't work since that sourceType uses a proxy server and
  2. The default proxy servers are PUBLIC. Please at least provide your own private proxy if you want to try experimenting with this.
  • Calling any method that will interact with the page's source (i.e. call JS methods, callbacks, execute JS etc) from the controller only work when using SourceType.urlBypass or SourceType.html. This is because only in theese 2 situations the package can actually inject that JS code inside the page source. When using SourceType.url, iframe's content does not actually belong to us - it is loaded from a different domain so we're not allowed to do that.

  • You can supply your own list of BypassProxy objects in the WebViewX's webSpecificParams param.

  • The headers only have effect when using SourceType.urlBypass, because that's when the package fetches the page source.

  • 'NavigationDelegate' only has effect when using SourceType.urlBypass because click handlers can only be registered for this type of source (for now, soon they may also work when using SourceType.html - see src/view/impl/web.dart around line 220)

  • In the EmbeddedJsContent param on the WebViewX, if you define JS functions as ES6 variable functions:

    const fn = () => ..., then you also need to add them to the global scope to work: window.fn = fn .

  • URLs which redirect to another URL won't work by using SourceType.urlBypass. Redirects may work only if that website allows iframe embeddings, in which case you should use SourceType.url.

@fechnologies-d
Copy link

Hi. Great package.

I'm not sure if I'm supposed to ask this here but please pardon me. As regards redirects, is there a way we can get an error callback when it fails?

Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants