Changes between Version 1 and Version 2 of Ticket #16199, comment 3


Ignore:
Timestamp:
Oct 19, 2012, 7:39:29 AM (9 years ago)
Author:
Adrian Vasiliu
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16199, comment 3

    v1 v2  
    99Moreover, even if I do not connect to !WebInspector, the bug also vanishes after the simple addition of console.log (in particular in dijit/registry.getEnclosingWidget, which is called by _WidgetBase.getParent)!
    1010
    11 Hence, instead of relying on console.log for debugging, I collected debug info into a global variable (initialized once per app life time). After running the app till the bug hurts (touching the "Show More" item has no effect), I connect the debugger and inspect the global variable. This way I could get confirmation that, when the bug hurts (and only in this case, getParent returns null.
     11Hence, instead of relying on console.log for debugging, I collected debug info into a global variable (initialized once per app life time). After running the app till the bug hurts (touching the "Show More" item has no effect), I connect the debugger and inspect the global variable. This way I could get confirmation that, when the bug hurts (and only in this case), getParent returns null.
    1212
    1313The strongest sign (although not a formal proof) that this is a Mobile Safari bug is the following: I modified _ItemBase this way:
     
    2929        var parent = this.getParent();
    3030        if(!parent){
    31                 logTxt += " getParent null for this.id: " + id;
     31                logTxt += " getParent null for this.id: " + this.id;
    3232                var myParent = this._myGetParent();
    3333                logTxt += " my parent : " + myParent;
     
    4242That is, when getParent returns null, I call my own version of getParent which is a merge of the code from _WidgetBase.getParent (this calls dijit/registry.getEnclosingWidget(this.domNode.parentNode)) and from dijit/registry.getEnclosingWidget itself.
    4343
    44 Check the global logTxt in the console after reproducing the bug, it shows that the original getParent consistently returns null (in both calls in the code above), while my variant, supposed to produce a similar result, succeeds in finding the parent widget!
     44Checking the global logTxt in the console after reproducing the bug, it shows that the original getParent consistently returns null (in both calls in the code above), while my variant, supposed to produce a similar result, succeeds in finding the parent widget!
    4545
    4646I have also checked:
     
    5151Extracting a minimal sample to reproduce wasn't possible: the context matters...
    5252
    53 All in one, knowing that Safari Mobile in iOS6 clames performance improvements of the javascript engine... these facts seem somehow consistent with the hypothesis that an engine optimization went a bit too far... (which reminds the old times of the childhood of the Java just-in-time compiler, when rewriting code in an equivalent manner was the way to go to workaround Sun's bugs).
     53All in one, knowing that Safari Mobile in iOS6 clames performance improvements of the javascript engine... these facts seem somehow consistent with the hypothesis that an engine optimization went a bit too far... (which reminds the old times of the childhood of the Java just-in-time compiler, when rewriting code in an equivalent manner was the way to go to workaround Sun's JVM bugs).
    5454
    5555Of course, we'll test again when iOS 6.0.1 will be out...