Last modified: 2010-07-22 12:01:25 UTC
Created attachment 6372 [details] blank toolbar This happens on and off, leading me to believe that it is a race issue in the Javascript code. TypeError: Result of expression 'jQuery( 'div#edittoolbar' ).toolbar' [undefined] is not a function. EditToolbar.js:432 See also the attachements.
Created attachment 6373 [details] error message and empty DOM for toolbar
There is a jquery bugticket for this: http://dev.jquery.com/ticket/1319
Hmm, I doubt this is the jquery problem. As a matter of fact, now that the page is loaded for minutes, it still doesn't work. If i run it from console I still get > jQuery( 'div#edittoolbar' ).toolbar undefined So that means that toolbar has failed to have been setup earlier, probably silently failing. I did not that there are a lot of for(in) construct in the EditToolbar.js These are known to be a problem esp. on Safari and Chrome, because Safari doesn't safeguard the user from extended objects (and this is actually correct behaviour). So for(in) will give you EVERYTHING (it is an object iterator) and is not guaranteed to be the same as for( i=0; i<something.length i++ ) (an array iterator). Basically, wherever you have a .length, the usage of for(in) should be avoided, especially when you are extending objects and using jQuery. This might also be related to the issue where the "Help" is showing "undefined undefined undefined".
(In reply to comment #3) > Hmm, I doubt this is the jquery problem. As a matter of fact, now that the page > is loaded for minutes, it still doesn't work. > > If i run it from console I still get > > jQuery( 'div#edittoolbar' ).toolbar > undefined > > So that means that toolbar has failed to have been setup earlier, probably > silently failing. > I did not that there are a lot of for(in) construct in the EditToolbar.js These > are known to be a problem esp. on Safari and Chrome, because Safari doesn't > safeguard the user from extended objects (and this is actually correct > behaviour). So for(in) will give you EVERYTHING (it is an object iterator) and > is not guaranteed to be the same as for( i=0; i<something.length i++ ) (an > array iterator). Basically, wherever you have a .length, the usage of for(in) > should be avoided, especially when you are extending objects and using jQuery. > > This might also be related to the issue where the "Help" is showing "undefined > undefined undefined". > Off the top of my head, we only use for(in) on objects that we define ourselves and aren't related to jQuery, so we should be safe there.
This is probably due to another Webkit bug (which, incidentally, was filed by the reporter of this bug: https://bugs.webkit.org/show_bug.cgi?id=28328 ) about not respecting the order of <script> tags and executing multiple of those in parallel, which is against the suggestion in the HTTP 1.1 standard that the browser not even try to *download* anything else while downloading the src of an external <script> tag.
The problem had also disappeared since the previous major update of wmf-deployment/acaifix code.
