Last modified: 2009-09-03 18:14:45 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 20384 - UsabilityInitiative breaks jQuery
UsabilityInitiative breaks jQuery
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UsabilityInitiative (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Trevor Parscal
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-25 12:37 UTC by Liangent
Modified: 2009-09-03 18:14 UTC (History)
5 users (show)

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


Attachments

Description Liangent 2009-08-25 12:37:20 UTC
I have some user scripts depending on jQuery.

They usually works well, but now, after I switched to a new OS (I'm not sure whether there're any connections), they cannot work well on action=edit pages (and only edit). After leaving beta, nothing goes wrong.

In nutshell, the wrong behavior is, jQuery cannot always select correct elements in DOM tree.

Browser + OS: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212 Iceweasel/3.0.6 (Debian-3.0.6-1)
Comment 1 Platonides 2009-08-25 13:00:02 UTC
I suppose the problem is that your scripts don't work with vector skin (you know, elements have been moved...).

You should at least specify which scripts are those that are failing, and if there's any error in the Icewasel console.
Comment 2 Roan Kattouw 2009-08-25 13:02:21 UTC
(In reply to comment #1)
> I suppose the problem is that your scripts don't work with vector skin (you
> know, elements have been moved...).
> 
> You should at least specify which scripts are those that are failing, and if
> there's any error in the Icewasel console.
> 

Yes, not all IDs and classes in Monobook appear in Vector as well. This means that your script is skin-specific, and you can't really expect a Monobook-specific script to magically work on Vector.
Comment 3 Liangent 2009-08-25 13:46:25 UTC
Try this:

1. Register a new user.
2. Go to Chinese Wikipedia (we put jQuery in site javascript) and edit your user javascripts to this:

$(function() {
    alert($('#p-tb ul').text());
});

3. Switch between beta and non-beta, edit and view, and you will see the problem.
4. (Optional) You can try this in beta / edit screen: javascript:alert($('#p-tb ul').text());
Comment 4 Jimmy Xu 2009-08-25 13:58:33 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I suppose the problem is that your scripts don't work with vector skin (you
> > know, elements have been moved...).
> > 
> > You should at least specify which scripts are those that are failing, and if
> > there's any error in the Icewasel console.
> > 
> 
> Yes, not all IDs and classes in Monobook appear in Vector as well. This means
> that your script is skin-specific, and you can't really expect a
> Monobook-specific script to magically work on Vector.
> 

We've already solved this by creating a mapping between those id changes as soon as the vector skin is published on Chinese Wikipedia.

In addition, loading the official jQuery (from Google) will cause the UsabilityInitiative fail to load.
Comment 5 Liangent 2009-08-25 14:05:03 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > I suppose the problem is that your scripts don't work with vector skin (you
> > > know, elements have been moved...).
> > > 
> > > You should at least specify which scripts are those that are failing, and if
> > > there's any error in the Icewasel console.
> > > 
> > 
> > Yes, not all IDs and classes in Monobook appear in Vector as well. This means
> > that your script is skin-specific, and you can't really expect a
> > Monobook-specific script to magically work on Vector.
> > 
> 
> We've already solved this by creating a mapping between those id changes as
> soon as the vector skin is published on Chinese Wikipedia.
> 
> In addition, loading the official jQuery (from Google) will cause the
> UsabilityInitiative fail to load.
> 

There's nothing to do with the mapping.

Loading the official jQuery (from Google) causes UsabilityInitiative's failure because UsabilityInitiative adds $.fn.wikiEditor to jQuery and loading without checking overwrites it.
Comment 6 Jimmy Xu 2009-08-25 14:08:27 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > I suppose the problem is that your scripts don't work with vector skin (you
> > > > know, elements have been moved...).
> > > > 
> > > > You should at least specify which scripts are those that are failing, and if
> > > > there's any error in the Icewasel console.
> > > > 
> > > 
> > > Yes, not all IDs and classes in Monobook appear in Vector as well. This means
> > > that your script is skin-specific, and you can't really expect a
> > > Monobook-specific script to magically work on Vector.
> > > 
> > 
> > We've already solved this by creating a mapping between those id changes as
> > soon as the vector skin is published on Chinese Wikipedia.
> > 
> > In addition, loading the official jQuery (from Google) will cause the
> > UsabilityInitiative fail to load.
> > 
> 
> There's nothing to do with the mapping.
> 
> Loading the official jQuery (from Google) causes UsabilityInitiative's failure
> because UsabilityInitiative adds $.fn.wikiEditor to jQuery and loading without
> checking overwrites it.
> 

So this is a bug, too. Maybe we should perform a test?
Comment 7 Roan Kattouw 2009-08-25 14:22:29 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > There's nothing to do with the mapping.
> > 
> > Loading the official jQuery (from Google) causes UsabilityInitiative's failure
> > because UsabilityInitiative adds $.fn.wikiEditor to jQuery and loading without
> > checking overwrites it.
> > 
> 
> So this is a bug, too. Maybe we should perform a test?
> 
It's not a bug. If you're including jQuery in site JS without checking that it's not already there, *you're* at fault and shouldn't be surprised if it causes things to break.
Comment 8 Liangent 2009-08-25 14:33:55 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > There's nothing to do with the mapping.
> > > 
> > > Loading the official jQuery (from Google) causes UsabilityInitiative's failure
> > > because UsabilityInitiative adds $.fn.wikiEditor to jQuery and loading without
> > > checking overwrites it.
> > > 
> > 
> > So this is a bug, too. Maybe we should perform a test?
> > 
> It's not a bug. If you're including jQuery in site JS without checking that
> it's not already there, *you're* at fault and shouldn't be surprised if it
> causes things to break.
> 

That check exists.
Comment 9 Liangent 2009-08-25 14:34:56 UTC
We put complete jQuery code in site JS, and wrapped it with:

 if (window.jQuery === undefined) { ... }

.
Comment 10 Liangent 2009-08-26 09:15:26 UTC
There's nothing to do with the vector skin.

After removing

 	 Enable enhanced editing toolbar
 	 Warn me when I leave an edit page with unsaved changes

from my user preferences, everything is ok.
Comment 11 Trevor Parscal 2009-09-03 18:14:45 UTC
We are now using noconflict with the $j var to be more inline with the upcoming js2 code. So the issue that including yet another copy of jquery caused breakage should be fixed.

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


Navigation
Links