Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

Conversation

@amirh
Copy link
Contributor

@amirh amirh commented Aug 14, 2019

Description

Allows inspecting the title of the currently loaded page.

Related Issues

flutter/flutter#37177

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.

@amirh amirh requested a review from mklim August 14, 2019 21:32
Copy link
Contributor

@mklim mklim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ened
Copy link
Contributor

ened commented Aug 15, 2019

Could this possibly be a Stream<String> as the title may change whenever the web view loads the next page?

@ened
Copy link
Contributor

ened commented Aug 15, 2019

Could this possibly be a Stream<String> as the title may change whenever the web view loads the next page?

Actually no need, there's a page listener that's called when a (or any further) page is loaded, so developers could use that. :-) Ignore my original comment.

@amirh
Copy link
Contributor Author

amirh commented Aug 15, 2019

Could this possibly be a Stream<String> as the title may change whenever the web view loads the next page?

Good point, thanks!

I think a broadcast stream makes sense for this case, though I think we would still need this getter for the "current" value (as broadcast streams drop values if there are no listeners).

WDYT?

@amirh
Copy link
Contributor Author

amirh commented Aug 15, 2019

Could this possibly be a Stream<String> as the title may change whenever the web view loads the next page?

Actually no need, there's a page listener that's called when a (or any further) page is loaded, so developers could use that. :-) Ignore my original comment.

Your comment is still valid as the title might change without a new page being loaded (e.g javascript code can change the title).

I do think it still makes sense to to have this getter as I commented above though.

@ened
Copy link
Contributor

ened commented Aug 15, 2019

If JS code can change the title, we'd need to fiddle with the html to get it, unless WebView has some sort of listener we can hook into.

From my point of view, the current PR (to get the title) provides enough of a building block to build a stream of titles later when combining this with the page listener and perhaps other methods (even a Timer.periodic..).

Thx @amirh.

@amirh
Copy link
Contributor Author

amirh commented Aug 15, 2019

If JS code can change the title, we'd need to fiddle with the html to get it, unless WebView has some sort of listener we can hook into.

From my point of view, the current PR (to get the title) provides enough of a building block to build a stream of titles later when combining this with the page listener and perhaps other methods (even a Timer.periodic..).

Thx @amirh.

Yes such listeners are available on Android and iOS.
Anyway going to land this PR as-is it seems that we all agree this getter makes sense.

## 0.3.11+6

* Calling destroy on Android webview when flutter webview is getting disposed.
>>>>>>> master
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@amirh saw this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops

@amirh amirh merged commit 59eeaa8 into flutter:master Aug 15, 2019
amirh added a commit that referenced this pull request Aug 16, 2019
amirh added a commit that referenced this pull request Aug 16, 2019
…#1981)

Reverts #1979

The change broke Fuchsia, as FuchsiaWebViewController implements WebViewPlatformController so it doesn't get the no-op implementation of getTitle. We could change the FuchsiaWebViewController implementation to extend WebViewPlatformController so we can add new methods without requiring roll coordination.

I'm reverting temporarily until we resolve the roll issue.
sungmin-park pushed a commit to sungmin-park/flutter-plugins that referenced this pull request Dec 17, 2019
…#1979)

Allows inspecting the title of the currently loaded page.
sungmin-park pushed a commit to sungmin-park/flutter-plugins that referenced this pull request Dec 17, 2019
…flutter#1981)

Reverts flutter#1979

The change broke Fuchsia, as FuchsiaWebViewController implements WebViewPlatformController so it doesn't get the no-op implementation of getTitle. We could change the FuchsiaWebViewController implementation to extend WebViewPlatformController so we can add new methods without requiring roll coordination.

I'm reverting temporarily until we resolve the roll issue.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants