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.