[webview_flutter] Fix iOS WebView ignoring SafeArea widget and iOS 13 WebView scroll indicator showing at random location.

[cyanglaz]

Description

The WKWebView defaults to have contentInsetAdjustmentBehavior as automatic. Which means it adjusts its content inset while there is a safe area(notch) on the screen. In Flutter, we use SafeArea widget to handle the safe area. With this default behavior, even without the SafeArea widget, the content is pushed down (portrait mode), which results a bad UI looks like flutter/flutter#25274. This creates an inconsistency with WebView widget and other flutter widgets, the developers might have a hard time figuring out what caused the issue.
By setting contentInsetAdjustmentBehavior false, we always ask flutter to handle the content inset and makes the WebView more consistent with flutter's behavior.
Note: This change might result your WebView content inset pull up if when running your app on an iOS device with a notch (Which is intended). Wrapping around the WebView with a SafeArea widget will resolve the issue.

On iOS 13, the automaticallyAdjustsScrollIndicatorInsets is introduced. To match with our setting for contentInsetAdjustmentBehavior, we will set automaticallyAdjustsScrollIndicatorInsets` to false. This will also fix flutter/flutter#41592

Related Issues

flutter/flutter#41592

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[sky126]

great

[amirh]

Can we test this somehow?

[cyanglaz]

@amirh There are 2 tests we can do.

1. We might be able to add some integration test to make sure the contentInset and scrollIndicatorInset are always (0,0) for the matter. (This will need to have some visibleForTesting method to expose the value of contentInset and scrollIndicatorInset on iOS)
2. However, for the bug that the scroll indicator always showing at the random location, we can't. Because the value of the ScrollIndicatorInset is correct even when it shows at the wrong location. We might be able to add some screenshot test if we have some infra set up to do so.

[cyanglaz]

@amirh I added the tests that we discussed offline. Also waiting for #2346 to be landed before merging this in so we are sure the tests are passing in CI.

[cyanglaz]

@bparrishMines This fixes a nasty UI bug on iOS 13. Do you mind taking a look?

[amirh]

LGTM