Last modified: 2010-07-22 12:01:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 19847 - Blank toolbar.
Blank toolbar.
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
UsabilityInitiative (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Trevor Parscal
: upstream
Depends on:
Blocks: 24493
  Show dependency treegraph
 
Reported: 2009-07-20 18:53 UTC by Derk-Jan Hartman
Modified: 2010-07-22 12:01 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
blank toolbar (11.02 KB, image/png)
2009-07-20 18:53 UTC, Derk-Jan Hartman
Details
error message and empty DOM for toolbar (31.23 KB, image/png)
2009-07-20 18:54 UTC, Derk-Jan Hartman
Details

Description Derk-Jan Hartman 2009-07-20 18:53:31 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.
Comment 1 Derk-Jan Hartman 2009-07-20 18:54:05 UTC
Created attachment 6373 [details]
error message and empty DOM for toolbar
Comment 2 Derk-Jan Hartman 2009-07-21 14:58:28 UTC
There is a jquery bugticket for this: http://dev.jquery.com/ticket/1319
Comment 3 Derk-Jan Hartman 2009-07-21 19:50:02 UTC
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". 
Comment 4 Roan Kattouw 2009-07-25 15:32:21 UTC
(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.
Comment 5 Roan Kattouw 2009-08-17 20:57:52 UTC
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.
Comment 6 Derk-Jan Hartman 2009-08-18 00:08:39 UTC
The problem had also disappeared since the previous major update of wmf-deployment/acaifix code.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links