Related feature: XWALK-4917 Description & Implementation Plans :
1. Background: In current implementation, when user who invoke "alert", "confirm" and "prompt" javascript API, it will finally invoke onJavascriptModalDialog API and dispatch the message by a "switch-case" and delegate the task to onJsAlert, onJsConfirm and onJsPrompt which are all private methods currently. And according to embedding API design draft (https://docs.google.com/document/d/1Jg_S1taivNjTkcNRGSjH-auzG_NB3wpsyFhA2yJAWl4/edit#heading=h.po36fndkupqk), we need to publish onJsAlert, onJsConfirm and onJsPrompt API in version 6.0. And it cause some problems. 2. Problems: Just change onJsAlert , onJsConfirm and onJsPrompt methods from private to public is not proper. Pls to see the situation that we have onJavascriptModalDialog, onJsAlert, onJsConfirm, onJsPrompt APIs as public APIs at the same time, which means user could override them as they wish. And Pls review that onJavascriptModalDialog solve all "alert", "confirm" and "prompt" calls from javascript sides and dispatch to onJsAlert, onJsConfirm, onJsPrompt, the problem is clearly: If , take an example, user override onJavascriptModalDialog and onJsAlert in the same subclass , what will happen? It seems that unless user call onJsAlert in his overridden onJavascriptModalDialog method, the overridden onJsAlert could never be reached. I think this is unexpected performance and feel strange. 3. Plan: Now there are two candidate plans, one is radical and the other is mild. I'll describe them separately and I support the radical plan. * Radical Plan This plan is based on the truth that onJsAlet, onJsConfirm and onJsPrompt API are all support by android.Webkit.WebChromeClient but onJavascriptModalDialog seems not in both WebChromeClient or WebViewClient (the refer page: WebChromeClient: http://developer.android.com/reference/android/webkit/WebChromeClient.html and WebViewClient: http://developer.android.com/reference/android/webkit/WebViewClient.html) So the plan is deprecate onJavascriptModalDialog API with deprecated annotation and rewrite the "alert", "confirm" and "prompt" solving logic by directly call onJsAlert, onJsConfirm and onJsPrompt APIs. But there will be some compatible strategy: I plan to make onJavascriptModalDialog an empty method and call it in onJsAlert , onJsConfirm and onJsPrompt implementation for some possible app which override onJavascriptModalDialog. However, these app will receive a warning. Since I think this type of API about "alert", "prompt" and "confirm" is not so critical and I think keep them the same as android default usage is important, I support this plan. But I wish you know that it will affect several files. * Mild Plan Based on the truth that the situation which override onJavascriptModalDialog and onJsAlert-like API at the same subclass is rare, We could simply publish onJsAlet, onJsConfirm and onJsPrompt APIs simply and warning users that if they want to override onJavascriptModalDialog and onJsAlert-like API, they should call onJsAlert-like API in the overridden onJavascriptModalDialog. This plan seems like some temporary thing But the modified scope is limited, just XWalkUIClientInternal will be affected. What's more, the test case needs modified for creating onJsAlert, onJsConfirm and onJsPrompt tests. But the modified scope is limited, just XWalkUIClientInternal will be affected. Pls give your advices, thx. If you agree with the Radical Plan, pls give LGTM and I'll start implementation work. Thx. BR, Yan,Shaobo
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
