Improve the JavaScript bridge

[ariya]

[email protected] commented:

The use of QVariant for QtWebKit bridging causes a lot of problem.

We need to investigate alternative solutions.

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #456.
🌟   4 people had starred this issue at the time of migration.

[ariya]

[email protected] commented:

Some reported problems:

issue 131 (Passing argument to evaluate) is not easy to solve without terrible workaround.

issue 434 (Null is not transported properly)

issue 170 (Object keys order is messed up)

issue 439 (Can't pass array of characters easily)

 
Metadata Updates

• CC(s) added:
  • [email protected]

[ariya]

[email protected] commented:

I meant:

issue 132 (Passing argument to evaluate) is not easy to solve without terrible workaround.

[ariya]

[email protected] commented:

Slightly related is issue 448 (moving to Qt 5). If that is successful, we can hook straight into V8.

Otherwise, we may need to get closer and closer to the metal, right now it's JavaScriptCore.

[JamesMGreene]

[email protected] commented:

Would issue 563 be related to this?
http://code.google.com/p/phantomjs/issues/detail?id=563

[annulen]

AFAIU, there are two approaches to solve this (without resorting to use of different JS implementation for control script):

• Introduce new wrapper class for JS values akin to QScriptValue, and convert bridge APIs to use it instead of QVariant. This will allow JS object to keep their behavior instead of being converted to QVariantMap, will preserve null properly, and maybe fix other issues
• Avoid using Qt bridge and use strongly typed IDL-based bindings, in the same way as all DOM APIs in WebKit are implemented. In addition to type safety and conformance to JS rules this will allow to achieve the best possible performance. Downside is that I don't see a clean way to have generated code outside of Webkit source tree, as it would require exporting many WebCore symbols and scripting machinery. Also, idl sources and their C++ implementations need to be in sync with WebKit code. If CommonJS provides stable well defined interfaces with formal specifications (even better if accompanied by WebIDL), I can consider adding them to QtWebKit code base under runtime flag, so they are not accidentally exposed to Web

/cc @vitallium

[ariya]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be closed. In the future, if we see the need to attend to this issue again, then it will be reopened.
Thank you for your contribution!