New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

default dialogs (e.g. date/time) don't work #92

Closed
kassim opened this Issue Mar 12, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@kassim
Contributor

kassim commented Mar 12, 2018

Because the WebView is instantiated using the application context, the default dialogs (e.g. date and time pickers) don't show. So you have to figure out some workaround to make your app work with date/time forms.

This should probably be added as a warning.

Note: WebView should always be instantiated with an Activity Context. If instantiated with an Application Context, WebView will be unable to provide several features, such as JavaScript dialogs and autofill.
https://developer.android.com/reference/android/webkit/WebView.html

@fcatuhe

This comment has been minimized.

fcatuhe commented Mar 20, 2018

Hello @kassim, did you find a workaround? I would be interested !

@lateplate

This comment has been minimized.

Collaborator

lateplate commented Apr 6, 2018

@kassim That's definitely valid documentation but currently (and this is subject to change soon because we ran into issues with Chrome 64) we swap the application context with the current activity's context whenever a new activity is loaded. And so dialogs, such as a <select> or date picker should be OK. We've been using them in Basecamp without issue, so I'm curious what the issue might be. Can you share a visit() call you're making?

When we do eventually make the change to not swap the application context out (which Chrome 64 is going to force us to do, we're investigating now), we we for sure either provide this warning clearly or provide some backup options on how to take care of these dialogs yourself.

Thanks!

@mityakoval

This comment has been minimized.

mityakoval commented Jun 14, 2018

Hi! Any news on when this is going to be implemented? Or any workaround?

@lateplate

This comment has been minimized.

Collaborator

lateplate commented Jun 14, 2018

Hi, are you having trouble specifically with date/time? I confirmed that most web-to-native dialogs work OK (specifically dialogs) but it's possible that date/time fields might have issues.

If it is troublesome, I believe this is more a webview/Chrome interaction issue than it is anything specific to Turbolinks. One solution might be to inject your own Javascript into the webview which can listen for the proper events. There are a handful of posts that show you how to do that.

The Javascript you'd want to inject would look something like this. It would listen for the right type of event, and then pass it off to your own Javascript interface.

$(document).on('click', '[type~=date]', function(event) {
    YourJavascriptInterface.showDatePicker(event.target.id)
    return false
})

Turbolinks gives you the ability to add Javascript interfaces into the webview via the TurbolinksSession...

turbolinksSession.addJavascriptInterface(BasecampJavascriptInterface(this.turbolinksSessionId), "YourJavascriptInterface")

Then in your YourJavascriptInterface file you'd create your own standard Android date dialog, take the values, and push them back into the webview component.

@lateplate lateplate closed this Jun 14, 2018

@mityakoval

This comment has been minimized.

mityakoval commented Jun 15, 2018

Nice! I'll give it try. Thanks!

@svantepolk

This comment has been minimized.

svantepolk commented Sep 14, 2018

The solution suggested by @lateplate seems to only work for the first Activity in the backstack which created an instance of a TurbolinksView.

EDIT:

I worked out how to deal with this.

The problem is that it seems like its only possible to add a javascript interface from the initial Activity, but the javascript execution calling back to the interface defined at the time still works anywhere in the backstack. I ended up keeping a reference to the current top instance of the Activity, so when I needed to start a FragmentTransaction, I just used that reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment