It might be trivial but we'd better check the value of the private data in the QWebScriptWorld::world() to prevent the possible crash -- 'd' may have an empty data if USE(JSC) is undefined for some platform. QWebScriptWorld::QWebScriptWorld() { #if USE(JSC) // d can have an empty data if this macro fails d = new QWebScriptWorldPrivate(ScriptController::createWorld()); #endif }
Created attachment 73536 [details] first try
Comment on attachment 73536 [details] first try View in context: https://bugs.webkit.org/attachment.cgi?id=73536&action=review > WebKit/qt/Api/qwebscriptworld.cpp:53 > + return d.data() ? d->world.get() : NULL; huh? how does world depend on data() ? Also we do not use NULL in C++ code.
Created attachment 73593 [details] second try
(In reply to comment #2) > (From update of attachment 73536 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=73536&action=review > > > WebKit/qt/Api/qwebscriptworld.cpp:53 > > + return d.data() ? d->world.get() : NULL; > > huh? how does world depend on data() ? Also we do not use NULL in C++ code. Thanks, you are right. I updated my patch, which returns 0 when the internal pointer to the shared data object is not null.
Comment on attachment 73593 [details] second try This is a purely artificial problem since we always build with USE(JSC) and the V8 port will most likely require large changes to QWebScriptWorld anyway. That said, I don't see any harm in adding this check. r=me
Comment on attachment 73593 [details] second try Clearing flags on attachment: 73593 Committed r71818: <http://trac.webkit.org/changeset/71818>
All reviewed patches have been landed. Closing bug.