js 传输过长的问题
https://bugs.chromium.org/p/chromium/issues/detail?id=884100
Hi Huawei Team:This is an intended behavior , which means developers may using the wrong API.For your reference, the change was made here: https://chromium-review.googlesource.com/c/chromium/src/+/1112471In short, developers should not rely on prompt() as a means of passing data from JS to Java. There are other APIs that are properly suited to this task. If the message is that long (even longer than 10240 bytes), Ideally you should use the postMessage APIs, or addJavascriptInterface (which has a lower minsdk). You can also use the androix.webkit support library to expand the coverage of postMessage.@JavascriptInterface methods and postMessage are the actual mechanisms for communicating data between your web code and native code; the limits there are determined just by the IPC implementation.The onJs* callbacks are intended solely to implement standard web browser style dialog boxes to communicate with the user, not for internal communication with your program, and they're subject to change as browsers' handling of these functions change (most browsers are treating these as legacy functions and restricting their usage).Best Regards!Guangwei
https://chromium-review.googlesource.com/c/chromium/src/+/1112471
Truncate JavaScript dialog message strings before IPC.
This moves message size metrics to be before IPC (and before
truncation) and removes three metrics.
JSDialogs.CountOfJSDialogMessageCharacters is removed;
JSDialogs.CharacterCount.MainFrame/Subframe is replacing it.
JSDialogs.CountOfJSDialogMessageNewlines is not useful as
we do rectangular truncation.
JSDialogs.CharacterCountUserSuppressed was just broken as it
was gated by "if (did_suppress_message)", and
"did_suppress_message" was a non-null bool pointer.
BUG=804081
if (is_main_frame_)
UMA_HISTOGRAM_COUNTS("JSDialogs.CharacterCount.MainFrame", message_length);
else
UMA_HISTOGRAM_COUNTS("JSDialogs.CharacterCount.Subframe", message_length);
// 10k ought to be enough for anyone.
const base::string16::size_type kMaxMessageSize = 10 * 1024;
base::string16 truncated_message = message.substr(0, kMaxMessageSize);
谷歌这个修改是解决这个804081的bug：
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Steps to reproduce the problem:
- Open https://jsfiddle.net/ha0o2d67/
- Click "Choose file" and pick any file bigger than 100 Mb
- Wait few seconds
What is the expected behavior?
Tab isn't crashed
What went wrong?
Tab is crashed: Aw, Snap!
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 63.0.3239.132 Channel: stable
OS Version: 10.0
Flash Version: