summaryrefslogtreecommitdiffstats
path: root/tools/qttracereplay
diff options
context:
space:
mode:
authorKent Hansen <kent.hansen@nokia.com>2010-04-09 13:43:35 (GMT)
committerKent Hansen <kent.hansen@nokia.com>2010-04-09 14:31:12 (GMT)
commit06add85eb8a9bd8f53acd162ce665d46e7ebc137 (patch)
treebb9b6d404e1a3e6bedac121096d9a1076eb80655 /tools/qttracereplay
parent8f75ee78746a311434db3fe5a3793c6f725fa210 (diff)
downloadQt-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/qttracereplay')
0 files changed, 0 insertions, 0 deletions