Skip to content
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

fix(android)(8_1_X): call WebView.stopLoading() from main thread #11171

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@
import java.util.HashMap;
import java.util.Map;

import android.os.Handler;
import android.support.annotation.StringRes;
import android.view.ActionMode;
import android.view.Menu;
Expand Down Expand Up @@ -52,6 +53,8 @@
import android.webkit.WebSettings;
import android.webkit.WebView;

import static android.os.Looper.getMainLooper;

@SuppressWarnings("deprecation")
public class TiUIWebView extends TiUIView
{
Expand Down Expand Up @@ -1066,7 +1069,13 @@ public void reload()

public void stopLoading()
{
getWebView().stopLoading();
new Handler(getMainLooper()).post(new Runnable() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't we have a different code pattern for dispatching method calls to happen on the main thread? (like a public handleMessage() method with a switch statement)?

Also, is this the only call that needs to happen on the ui thread? What about goForward(), goBack(), etc?

Copy link
Contributor

Choose a reason for hiding this comment

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

What Gary is solving is not thread related. He is doing the equivalent of a JS setTimeout(function, 0). He's posting a runnable to the end of the event queue, which is something you may to do if the method is being called from the same object's callback (ie: you need to unwind the stack before performing the action). I can see this being an issue with the onlink callback since it needs immediately feedback before loading a URL. Although I wouldn't think our WebView events would have this problem since they're queued and not invoked immediately.

I too am curious regarding goForward(), goBack(), and other APIs.

Regarding Handler, I'd prefer that we use it for cases like this. It's simpler and it's what most native Android devs use. handleMessage() is more complicated and error prone (message ID collision has happened in our code in the past) and its only real advantage is that it allows inherited classes to override the handling of received message, which isn't applicable here.

Side Note:
Gary, you don't need to create a new main handler here. There is a View.getHandler() method that you can use instead.
https://developer.android.com/reference/android/view/View#getHandler()

@Override
public void run()
{
getWebView().stopLoading();
}
});
}

public boolean shouldInjectBindingCode()
Expand Down