Last modified: 2009-09-03 18:14:45 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)
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.
(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.
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());
(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.
(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.
(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?
(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.
(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.
We put complete jQuery code in site JS, and wrapped it with: if (window.jQuery === undefined) { ... } .
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.
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.
