diff options
author | Kent Hansen <kent.hansen@nokia.com> | 2010-04-09 13:43:35 (GMT) |
---|---|---|
committer | Kent Hansen <kent.hansen@nokia.com> | 2010-04-09 14:31:12 (GMT) |
commit | 06add85eb8a9bd8f53acd162ce665d46e7ebc137 (patch) | |
tree | bb9b6d404e1a3e6bedac121096d9a1076eb80655 /tools | |
parent | 8f75ee78746a311434db3fe5a3793c6f725fa210 (diff) | |
download | Qt-06add85eb8a9bd8f53acd162ce665d46e7ebc137.zip Qt-06add85eb8a9bd8f53acd162ce665d46e7ebc137.tar.gz Qt-06add85eb8a9bd8f53acd162ce665d46e7ebc137.tar.bz2 |
Regressions in Global Object prototype access
In 4.5, changing the prototype of the (custom) global object used
to "Just Work"(tm).
In the JSC-based back-end, the built-in global object acts as a
proxy if a custom global object is set, because JSC doesn't (yet,
anyway) provide a way to replace the global object.
To complicate this further, we also have a proxy to the original
global object (that bypasses the custom global object proxying (!)).
This is so that properties of the original global object can
still be accessed with the QtScript C++ API when a custom global
object has been set.
Unfortunately, JSObject::prototype()/setPrototype() are not virtual,
meaning that a change of prototype in the source object is not
reflected in the proxy or vice versa.
Work around this for now by syncing the prototype at the appropriate
places (QScriptEngine::setGlobalObject(), QScriptValue::setPrototype()).
This fixes all except the case when a prototype is set from JS,
since such a write doesn't go through our public C++ API. But this
case can be detected and handled by the global object's
JSObject::put() reimplementation. Created a separate report for that
issue: QTBUG-9737.
Task-number: QTBUG-7066
Reviewed-by: Jedrzej Nowacki
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions