Filter UI completely broken by Jquery 1.4 commit

I have the exact same environment, I'll see if I can reproduce this error.

subscribing

I wrote that code. Quite heavy code. And hacky.

Hmm.... I do see some of the wackyness that you describe but not all here's what I did to test and the strange behavior that I found.

1. Tested with JavaScript off - everything seemed fine.
2. With JavaScript back on I went to Configuration -> Text Formats without the overlay
3. Tested changing the priority of the text formats and Saved, after navigating away and coming back I see that the change took.
4. Configured the Full HTML text format
a) Changed what roles can use it - Worked
b) Changed what filters were enabled - Doesn't work:

It seems as if it doesn't matter which checkbox is checked here the wrong set of filters appear in the Filter processing order fieldset. I was even able to navigate to admin/config/content/formats/2, click the Save Configuration button without making any changes and get a different set of Filter settings in the fieldset. And if I keep hitting the Save Configuration button the fieldset seems to toggle from one setting to another.

c) Changed he order of the filters in the Filter processing order - Seems to work:

As I said above, I can keep hitting the Save Configuration button and toggle between two different sets of filters shown in the Filter processing order fieldset. If I reorder the processing order, hit the save button and let the page refresh, then hit the save button again...I see the change was saved.

Confirmed on HEAD. Using this page with JS is very unusable and marking as critical.

Subscribing.

Lol, at first I couldn't find it but its rather simple:

$checkbox.trigger('click.filterUpdate');

Causes the checkbox to check. Weird that didn't happen with jquery 1.3.

soory

I don't see how this code changes anything. Note: we have plenty of JS code in HEAD that follows that pattern. If that is broken somehow, then we need to update plenty of code.... but I doubt that

I doubt what you doubt.

$checkbox.trigger('click.filterUpdate');

Means you want to check/uncheck that $checkbox, but that's not what we want. I attached another fix which is shorter (and more obvious).

well, now we're on the same page! :)

Didn't test myself though (trusting your judgement here).

Also, it's probably worth to grep -R '.trigger(' ./* to find, identify, and fix all other code throughout core.

Actually, this is a documentation leak.

.trigger('type.customName') used to trigger that bound and namespaced event only.

http://api.jquery.com/bind/ states:

If the eventType string contains a period (.) character, then the event is namespaced. The period character separates the event from its namespace. For example, in the call .bind('click.name', handler), the string click is the event type, and the string name is the namespace. Namespacing allows us to unbind or trigger some events of a type without affecting others. See the discussion of .unbind() for more information.

Neither this page or http://api.jquery.com/trigger/ or http://api.jquery.com/triggerHandler/ clarifies whether default behaviors are triggered as well. Only the docs about .triggerHandler() mention it in the list of exceptions, but the quoted .trigger() docs above suggest that only this namespaced event will be triggered... (confused)

I've tested this issue as well on Chrome 5 (beta) and Firefox 3.5

Whereas before when I tested in these browsers I found many of the issues that the OP found, now I find that all of these issues have been resolved.

I can confirm the RTBC status of this patch.

Suppose it fixed http://drupal.org/cvs?commit=340852
Now everything is working within FilterUI

Yep that commit changed exactly what we needed: http://drupalcode.org/viewvc/drupal/drupal/modules/filter/filter.admin.j...