Skip to content

Javascript return values discrepancies #105

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

Open
TcT2k opened this issue Jan 19, 2020 · 3 comments
Open

Javascript return values discrepancies #105

TcT2k opened this issue Jan 19, 2020 · 3 comments
Labels
bug Something isn't working priority-low We have considered this issue and decided that we will not be able to address it in the near future. tracked We are tracking this work internally.

Comments

@TcT2k
Copy link

TcT2k commented Jan 19, 2020

While I am integrating WebView2 into wxWidgets somebody came across the following discrepancies in javascript return values between Edge and Edge via WebView2 APIs ExecuteScript(). I'm pretty sure these are a problem in the WebView2 API:

A small javascript function f(){var person = new Object();}f(); returns this:

Return undefined
Edge backend: "null"
IE backend: "undefined"
Edge browser: "undefined"

This script returns function f(){var d = new Date('10/08/2017 21:30:40'); var tzoffset = d.getTimezoneOffset() * 60000; return new Date(d.getTime() - tzoffset);}f();:

Return date
Edge backend: "{}"
Edge browser: "Sun Oct 08 2017 23:30:40 GMT+0200 (Central European Summer Time)"
IE 11 browser: "Sun Oct 08 2017 23:30:40 GMT+0200 (Central Europe Daylight Time)"
Firefox: "Sun Oct 08 2017 23:30:40 GMT+0200 (Central European Summer Time)"

wxWidgets/wxWidgets#1700 (comment)

AB#28632017

@pagoe-msft
Copy link

Hi @TcT2k,

This is actually the desired behavior, for now ...

We only support values that can be serialized to JSON, and anything else, including undefined, gets returned as null. We do get more information from CDP, but (especially in the case of errors), we discard it to stay backwards compatible with a previous non-CDP implementation of ExecuteScript that returned null for these kinds of values.

Updating this behavior will be a breaking change, which is something we are more than willing to explore. I'll circle back to this thread if we update this behavior!

@pagoe-msft pagoe-msft added the bug Something isn't working label Jan 22, 2020
@quietfanatic
Copy link
Contributor

Looks like Date objects being returned as {} is a quirk of CDP. I'm not sure there's any way to work around this on the C++ side, but in the Javascript you can work around it by calling toString() on the Date.

@TcT2k
Copy link
Author

TcT2k commented Jan 22, 2020

@quietfanatic

Looks like Date objects being returned as {} is a quirk of CDP. I'm not sure there's any way to work around this on the C++ side, but in the Javascript you can work around it by calling toString() on the Date.

Sure that's an easy workaround, would just be nice to have scripts the same regardless which webview get's used.

@pagoe-msft
Thanks for the answer (not really sure what CDP stands for). I know the ExecuteScript documentation stats that it only returns JSON serialized values, but it was still surprising to me that a simple string was returned JSON encoded. Maybe some variant of ExecuteScript could be added that returns the results more "raw", because that would enable the host application to just use a returned string without having to decode it first.

@champnic champnic added bug Something isn't working and removed bug Something isn't working labels Aug 21, 2020
@champnic champnic added the tracked We are tracking this work internally. label May 10, 2022
@github-actions github-actions bot added the priority-low We have considered this issue and decided that we will not be able to address it in the near future. label Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority-low We have considered this issue and decided that we will not be able to address it in the near future. tracked We are tracking this work internally.
Projects
None yet
Development

No branches or pull requests

4 participants