Following an involved discussion on, a critical mass of mindshare is starting to gather behind the possible integration of the jQuery javascript package into Drupal core. The questions to be answered are "should we?", "what do we gain?", "what are the risks?" and "how is it best accomplished?". We even have the author of jQuery willing to help us out.

Now let's see those patches!


Steven’s picture

The questions to be answered are "should we?", "what do we gain?", "what are the risks?" and "how is it best accomplished?". We even have the author of jQuery willing to help us out.

Actually, I think most of those questions have already been answered in the discussion. Let's not bring all that here ;). Patches it is!

Frando’s picture

I think Steven is quite right. Instead of discussing the same questions we discussed on groups, we should try to get some code working.

For the fellows who didn't follow the discussion on groups, here's a short summary:

- Why do we want to include a third-party javascript library (i.e. jQuery)?

* jQuery has features that would just be perfect for drupal, namely the really simple DOM query system (both via XPATH and CSS style queries), event system and some basic effects. It could simplify most of the common drupal js tasks a lot. It would also make it much easier to add some basic js functionality for developers who aren't too familiar with js yet (i.e. for UI improvements)

* Of course, it would be possible to develop all these feature for our current drupal.js library. However, we would need heaps of time and effort to catch up with jQuery or similar libraries. Time and effort that could be used to actually make use of js in drupal.

- Why to use jQuery and not prototype/scriptacolous/...

* jQuery is highly modular. We take only the modules we want (i.e. the query system, events, the basic effects, ajax) and can then extend these by our needs. Module developers could even provide their module-specific plugins/extensions to jQuery, so we'll have lots of code reused by having all the required flexibility.

* jQuery is small (~20k compressed).

* jQuery has a great DOM query system that eases most of the common js tasks in drupal.

* The author of jQuery (who seems to be actively interested in helping to integrate jQuery into drupal, which could be a huge plus for us) dropped some hints that he's considering to license jQuery also under a GPL licence (prototype i.e. is only available under MIT-style licences)

- What would be the disadvantages of using an external library?

* We would rely on a third-party product.
However, I think we will mainly get advantages out ofthis, as bugs will get fixed by the jQuery team and we can focus on the usage of js is drupal (usability, ui improvements) and don't have to deal too much with the library behind it.

This should just be some kind of summary, the complete discussion can be found in the drupal.js group.

I think we should not (yet) start this discussion here again but should focus on getting some patches which demonstrate the integration of jQuery into drupal ...

Frando’s picture

small, but important typo: jQuery's compressed size is not 20, but 10kb.

Stefan Nagtegaal’s picture

10 kb is pretty amazing for such a nice application.
Drupal.js is already 12 kb of it's own. I did have a loot at the jQuery page and it doesn't look very hard to port our current situation to jQuery methods/JS.

The only problem I see is the autocomplete.js and the upload.js, but hey... I'm not a JS-guru at all..

I think I'm gonna play with jQuery tomorrow, how about you guys? ;-)

kkaefer’s picture

6.37 KB

Here is a very first patch. I know that it breaks some JS functionality but this will be fixed before the patch is ready for core.

I have not yet replaced the HTTPGet/Post functions as jQuery's XMLHttpRequest model is slightly different from ours (namely, the xmlhttp object is not in the callback functions arguments).

I added some legacy functions that wrap the jQuery functionality. These probably won't be in the final patch and are just here for compatibility issues. Please use jQuery's interface directly.

Steven’s picture

28.88 KB

Just to keep you guys posted... I've been working a lot on timcn's patch. I've removed the legacy functions from drupal.js and replaced them with DOM equivalents everywhere in the other .js files.

I've also replaced a lot of code with compact jQuery-style selectors.

Finally, I prettied up some things:

  • The newly added file fades into the table when you use the Ajax uploader.
  • The autocomplete suggestion box fades out after making a selection (still appears instantly).
  • The collapsible fieldsets animate open/closed (fast enough not to be an annoyance). I've had to remove the 'scroll fieldsets into view' feature though, but I'm going to look into making it scroll along with the animation.

If you're reading this and screaming "aaaah bloat!", well tough ;). Not only do the effects look cool, but they enhance the usability by not having jarring transitions when things change on the page. That's IMO worth having.

In spite of the extra effects and the 'wasteful' codestyle, there are still about 100 lines less Javascript after this patch (not counting the addition of jQuery of course).

There are still a couple of problems though:

  • The Ajax features in jQuery do not allow you to retrieve error information. And if you want to set an onError handler, you need to use the more complicated $.xml method rather than $.get or $.post. So I haven't converted HTTPGet() and HTTPPost() yet.
  • The uploader manipulates table cells in the effects, which is unsupported. I managed to hack this into jQuery, and I'll see if I can get it into jQuery final.
  • The collapsible fieldset animation has a jarring jump after it finishes opening, in Firefox. This is likely due to the way in which fieldsets don't really obey the CSS model closely. Still looking for a fix. If nothing else works, we could just hide the fieldset contents until the animation has completed. Or remove the animation.
  • Finally, and this is a bit of a bummer, the performance in Safari is not so good. Other browsers are snappy as hell though, so it's possible it can be remedied.

I've emailed John Resig with some questions. In the meantime, here's the patch + the hacked copy of jQuery. Note that only the following part was patched:

	// Simple 'show' function = function(){
-		y.display = "block";
+		y.display = (z.el.tagName.toUpperCase() == 'TD') ? "table-cell" : "block"; = true;
Steven’s picture

41.96 KB

hacked, uncompressed jquery (stable).

Steven’s picture

39.93 KB

New patch! I've developed against the newly released jQuery 1.0 alpha.


  • Our own HTTPGet and HTTPPost() have been replaced with jQuery's $.ajax method everywhere (the biggest change).
  • I tweaked autocomplete so it does not get confused when you type during the autocomplete request.
  • Collapsible fieldsets have been improved a lot. The headers are no longer misplaced in Safari, the contents no longer shift around after the animation in some browsers and the fieldsets scroll into view again (even during the animation).
  • I added a freezeHeight() mechanism to avoid unnecessary upwards scrolling when doing DOM manipulations. This used to happen with the file attachments.
  • Tweaks here and there to take advantage of new 1.0 stuff.

A hacked version of jQuery is still needed (though the hacks have been submitted as proper patches to John, and will hopefully go in soon). The differences are:

  • Support for doing effects on table cells.
  • Support for callbacks during animations (instead of only at the end).
Steven’s picture

37.86 KB

jQuery 1.0 alpha, modified.

Heine’s picture

A few minor IE related issues with the latest patch, all about the fancy front of the patch. As an aside; quick animations do make collapsible fieldsets more natural to use.

Fieldsets - collapsed fieldsets lost the line around the legend, except for the very beginning and end.

File attachments - a very jarring transition of the 'Attach new file' title on the the file attachments fieldset when uploading.

Autocomplete - On node submission forms, upon choosing an autocomplete entry with enter an error 'beep' sounds unless the attach button has been used before and receives focus. It is not possible to continue typing in the autocomplete textfield (it just lost focus). The list of entries doesn't fade out.

kkaefer’s picture

39.64 KB

Updated the patch against HEAD. No further changes.

Morbus Iff’s picture


Bèr Kessels’s picture

another subsciption

eaton’s picture

Testing against a clean head. Collapsing fieldsets, resizable textareas, autocompletion of the username field, and file uploads are all working very nicely. Is there any ETA on jQuery 1.0?

webchick’s picture

Status: Active » Needs review

this is a patch

rkerr’s picture

This will be great to get in :)

notabenem’s picture

subscription as well.
what I read so far is ... impressive to say at least.

yched’s picture

Er... subscription...

rickvug’s picture

Subscription. Been playing with jQuery on a 4.7 site and I must say it's impressive.

Steven’s picture

53.7 KB

New patch which namespaces all the Drupal stuff under a global Drupal object to reduce the chance of conflicts with other libraries.

Dries’s picture

Do we know more about the state of jquery, and whether they'll relicense? ETA?

kkaefer’s picture

For some reason, the patch breaks collapsible fieldsets at the moment.

Dave Cohen’s picture

I find that simply adding the latest jquery.js breaks collapsible fieldsets. That is, rather than applying any patch, I simply drupal_add_js('path/to/jquery.js').

Would love to know how to fix it.

eaton’s picture

I believe the solution is to apply this patch. :-)

Dave Cohen’s picture

Which patch exactly do you mean?

My javascript skills are weak, but I believe it has to do with jquery.js adding its own onload event. And its behavior somehow interferes with drupal's onload chain of functions. In my case, where I include jquery.js before any other js that calls addLoadEvent, simply changing the order of load events worked for me. That is, I changed addLoadEvent to read:


instead of the other way around.

I don't expect this to necessarily work for all installations.

Dave Cohen’s picture

I think I see what you mean by "apply this patch" now. I did not think that would solve the problem because of timcn's comment #22. (haven't applied it yet as I'm afraid to break the site).

eaton’s picture

yogadex, when I use the patched copy of jquery in #9 with the drupal patch in #20, things work fine on my end. Collapsing fieldsets, file uploading, etc etc.

kkaefer’s picture

Collapsible fieldsets only break with the latest patch and latest SVN-jQuery because they changed $.set() to $.attr(). You just have to change that in one single place and it works fine again.

scroogie’s picture

Do we know more about the state of jquery, and whether they'll relicense? ETA?

There is some information regarding that in the group ajax-developers at
The developer of jQuery (john resig) is active there. I dont know how much you already read about it, so here are some small quotes:

I was holding off on making jQuery dual-licensed (MIT/GPL) until the full 1.0 release was ready - I didn't realize that there was going to be a demand for it before that point. Do you think I should begin the dual-licensing process now?

My goal for jQuery 1.0 is to have a super-stable release with a stable API that will be available, and supported, for a very long time. It is this release that I'm helping the Drupal devs integrate into drupal.js (et. al). The core of jQuery is very solid at this point, it is for this reason that I'm creating this stable release, giving everyone something that they can continually rely upon.

the 1.0 alpha has already been released:

radev’s picture


eferraiuolo’s picture

interested and subscribing also

forngren’s picture


recidive’s picture

Status: Needs review » Needs work
51.91 KB

Is jQuery definitely going to be on Drupal core?

In general the patch is working fine (tested with jQuery 1.0 alpha), I've updated the patch to sync with lastest changes in and

I have some thoughts/questions regarding the proposed patch:

  1. Are we really going to add some effects by default? What about getting rid of the jQuery effects library from core. This seems not to be working well at this moment, e.g. this is not behaving so smooth;
  2. The core widgets (autocomplete, collapsible, upload, etc) needs some cleanup, e.g. avoiding the use of id-based behaviors like seen in autocomplete.js, changing the name of the methods, e.g. Drupal.jsAC to Drupal.AutoComplete, Drupal.ACDB to Drupal.AutoCompleteDatabase, etc;
  3. The Prototype library have some insteresting tricks that allow us to do basic encapsulating and inheritance (see bellow).

Class based javascript

With this magic function:

var Class = {
  create: function() {
    return function() {
      this.initialize.apply(this, arguments);

We can write JavaScript "classes" this way:

Drupal.Collapsible = Class.create();
Drupal.Collapsible.prototype = {
  // class constructor
  initialize: function(element, options) {
    this.element = $(element);

  setOptions: function(options) {
    // set behavior options

  collapse: function() {
    // collapse widget

  uncollapse: function() {
    // uncollapse widget


Instead of doing repeated code like object.prototype.method = function().

Simple Object inheritance

Another helpful approach in Prototype is the ability to easy extend an javascript object/class though the Object.extend method:

Object.extend = function(destination, source) {
  for (property in source) destination[property] = source[property];
  return destination;

with this approach, the setOptions method for the Drupal.Collapsible class above will look like this:


  setOptions: function(options) {
    this.options = {

      persist   :   true,

      collapse : false


    Object.extend(this.options, options);


Does jQuery have a similar approach for doing things like these?

Observer design pattern example

Giving javascript a class based aspect, we can make use of several useful OO programming design patterns. With the "observer" design pattern we can monitor a widget and easy extends its functionality. E.g.:

Give our Drupal.Collapsible class an aggregation object (Based on scriptaculous' Draggables)

Drupal.Collapsibles = {
  observers: [],
  addObserver: function(observer) {
  removeObserver: function(element) {  // element instead of obsever fixes mem leaks
    this.observers = this.observers.reject( function(o) { return o.element==element });
  notify: function(eventName, draggable) {  // 'onCollapse', 'onUncollapse'
    this.observers.invoke(eventName, draggable);

Add to methods collapse and uncollapse of the Drupal.Collapsible class


  collapse: function() {
   // collapse widget
   Drupal.Collapsibles.notify('onCollapse', this);

  uncollapse: function() {
    // uncollapse widget
   Drupal.Collapsibles.notify('onUncollapse', this);


How to use this from other applications

Creating a Collapsible Observer

UseLessCollapsibleObserver = Class.create();
UseLessCollapsibleClassObserver.prototype = {
  initialize: function(element) {
    this.element   = $(element);
  onCollapse: function() {
    alert('Collapsed' );
  onUncollapse: function() {
    alert('Collapsed' );

Adding the observer to our application

UseLess = Class.create();
UseLess.prototype = {
  initialize: function(element) {
    this.element   = $(element);
    Drupal.Collapsibles.addObserver(new UseLessCollapsibleObserver(element));

In general, as you might see, this looks like the Drupal hooks mechanism, so why not adding this kind of flexibility in javascript too?

With jQuery being core drupal will be quickly gaining nice Ajax functionality. However I don't like to see this thing holding us from doing drupal.js enhancements before the next codefreeze.

scroogie’s picture

The discussion about prototype and other ajax toolkits has been made in the ajax-developers group over at The link is in my post above.

anders.fajerson’s picture

Subscribing (...and missing rss feeds for comments)

kkaefer’s picture

@recidive: jQuery also has something like that: jQuery.extend().

Rok Žlender’s picture


kkaefer’s picture

51.4 KB

Updated the patch to reflect the JavaScript streamlining patch now being in core, the removal of drupal.css and recent changes in the SVN version of jQuery.

This does only work with a recent version of jQuery, the files directly on are outdated. Get a recent version either via SVN or here. For development purposes, take the big file with all the comments in there. The final file that will be included with Drupal is the small one (15kB).

I also noticed that the fieldset collapsing is broken in Safari. The first time, you open a fieldset, nothing show up. When you close it again and reopen it, everything works fine.

kkaefer’s picture

51.23 KB

Reworked the textarea.js. Its done from 3709 bytes (pre-jQuery) over 3422 bytes (jQuery before) to 957 bytes (now). I tested it in Firefox, Safari and Internet Explorer 6 and 7. I'd like to get some other reports, too.

recidive’s picture

Nice work, Konstantin!

I tested the textarea in two other browsers:

Konqueror: broken (the old behavior seems to be disabled in this browser);
Epiphany: working.

Also, your patch is breaking the collapsible fieldset arrow in system.css (line 245):

background: url(../../menu-expanded.png) 5px 75% no-repeat;

The right path is ../../misc/menu-expanded.png.

Are you going to refactor other widgets?

What about extending the collapsible.js to blocks?

Why not writing Drupal widgets as jQuery plugins?

How could we customize the widgets behaviors, e.g. change default effects, change behavior selectors from a theme, etc?

m3avrck’s picture

Subscribing, will help test and debug later today / tmorrow.

m3avrck’s picture

No longer applies :-/

The ideas about JQuery plugins make sense--JQuery is a lot like Drupal, it has tons of great plugins and lots of people working on those, all GPLed. Maybe we can reuse stuff. Will require research since those seem to be spread out all over the net.

kkaefer’s picture

68.72 KB

New patch, now with jQuery included.

eaton’s picture

For plugin management, I think we'd do well to offer a central module that manages them, and allows other modules to say, "I need plugin X to do my thing." Drop in plugins, and they become available to other modules. That would prevent us from running into situations where modules drag along numerous differently versioned jQuery plugins and start colliding.

That's a post-jQuery-in-core issue though, I think.

Crell’s picture

John Ressig (jQuery author) has said that one of his plans for post-1.0 of jQuery is to build a contrib repository on the jquery site rather than plugins being scattered all over the web. Hopefully he'll have the same license requirements that Drupal does (in his case, MIT/GPL dual licensed like jQuery itself), which will be great for us.

I'm not sure how we want to handle contribs, but is there some way we could integrate or tie into that?

Steven’s picture

Err, in textarea.js, all the carefully tweaked measuring and adjustments for the grippie have just been stripped out? There was a reason for all that stuff...

kkaefer’s picture

Well, we could add it back in again, but I tested the textarea grippie in several browsers and could not find one where it was necessary. I have tested with Safari, Firefox and Internet Explorer 6 and 7.

Steven’s picture

Status: Needs work » Needs review
48.1 KB

Hmmm kay... we'll see whether we get any comments about the textarea stuff.

Here's an updated patch, tested with jquery SVN. Most stuff seems to work, but it needs some more looking over and testing.

Steven’s picture

48 KB

jQuery 1.0 is out and I have a tested patch sitting here. Works fine in Firefox, Safari and Opera. Needs some IE looking over.

I did have problems getting the compressed version of jQuery to work, but the uncompressed one works fine. Perhaps there are still some last minute problems with the code packer. But you can test it using: (put in misc/jquery.js)

kkaefer’s picture

Why did you revert the jsEnabled changes? jsEnabled does not need to be a function.

gollyg’s picture


dvessel’s picture

Must be a better way to subscribe.

m3avrck’s picture

5.3 KB

I've put up a dev site so we can test JQuery in multiple browsers:

I tested in IE6 and all seems to work good. Only thing that is off is the resize, it doesn't line up correctly... otherwise no problems.

kkaefer’s picture

Damn, I thought nobody would see that ;) I'm fine with reverting the textarea.js back to what it was before, getting jQuery in and slowly rewriting it after feature freeze or for the next version.

And the fieldset collapsing does now work smoothly on Safari :)

yched’s picture

On :

Editing node/1, adding an attached file and submitting the form crashes my Firefox (1.5, WinXP)
Sometimes I don't even need to submit, I crash during / just after the upload

m3avrck’s picture

Hmm, no problems with FF 1.5 on a Mac

eaton’s picture

I just went through a couple edit rounds, uploaded files, submitted, etc on FF 1.5.6 Windows XP. no problems.

yched’s picture

I just tested again, and I crashed again - Well, maybe this is caused by one of my firefox extensions...

Other thing : the "author" autocomplete field in the node edit form doesn't seem to work

eaton’s picture

Autocomplete, too, is working fine for me on FF 1.5.6 WinXP. Can you try firing up Firefox in 'safe mode', sans extensions, and see if the problem persists?

yched’s picture

4.39 KB

With FF in safe mode :
- OK for file attachment. Are you interested in me digging through my extensions to find the offending one ?
- still no autocompletion for me. The widget just does not seem to react to key press (except it inserts the char, of course...)

someting else :-) :
To test for the autocompletion, I typed a dummy (non existent) author name.
Then I forgot about it and submitted the form.
The validation failed as it should, with the correct error message and the "author" field outlined, but the fieldset below (publishing options) had become "inactive" (plain text, no link to fold / unfold)
See attached screenshot.

Anonymous’s picture

48.15 KB

this fixes 2 things...

1) autocomplete.js - if there are no results, it will now not show the popup and fadeout with no content

2) collapse.js - fixes fieldset collapse after validation (steven fixed this)

pwolanin’s picture

Is there any way to avoid the delay when expanding/collapsing the fieldsets? I find this highly annoying compared to the immediate expansion in 4.7.

webchick’s picture

@pwolanin: I think that effect on the fieldsets is something Ted maybe has done to his test site for illustrative effect... applying this patch to a clean HEAD for me causes them to expand/contract the same as in 4.7.

No problems here in FF 1.5 for Mac. Tested fieldsets, autocomplete, updater, and file uploads.

Will try and dig up some more "obscure" browsers to test with...

Steven’s picture

We already use 'medium' speed, so you could change that to 'fast' in collapse.js. But I find the animation makes it easier to see what moves where, especially with the smooth scrolling during the animation. The old 'snap' wasn't friendly in that aspect.

webchick’s picture

Oh, nevermind. Apparently the old behaviour was cached, so pwolanin is right.

-1 for the slow-speed expansions. :P Everything else you click happens instantaneously, so it's inconsistent. It also seems like added fluff "just because we can." But I guess as long as I can change it with a hook_form_alter or something... mutter, grumble... ;)

Dries’s picture

- I like the animation and I think it's a subtle usability improvement, but it could do being a tad faster. I agree with the others that it is too slow. Normally I go 'click-click', now I have to go 'click-wait-click'.

- I like the fact that the page automatically scrolls as you open a fieldset near the bottom of the page. However, it has to scroll a little bit further: the bottom borders of the collapsible fieldsets are still outside the screen. As a result, you can't be sure that the entire fieldset is visible, and the user still has to scroll. That is, it has to scroll an extra 25 pixels or so.

- If you open the last fieldset on the node edit page, the 'Preview' and 'Submit' button scroll of the page. That's annoying because I'll have to do extra scrolling to get the buttons back. So maybe, we should always scroll an extra 50 pixels or so to avoid that extra scroll. (The fact that the 'Publishing options' is the last fieldset makes this particularly annoying. I need these settings a _lot_.)

- The autocomplete functionality (usernames on the add node form) aren't working for me either. I'm using Firefox on the Mac.

Jaza’s picture

The test site is working very nicely for me. Great work, Ted and co!

A few issues, while testing on WinXP, with FF, IE 6.0, and Opera 9.0:

  1. The grippie bar is misaligned in all 3 browsers (too short in IE and FF, too long in Opera).
  2. When you drag the grippie bar, the text in the textarea doesn't turn grey whilst dragging, UNTIL you either hold the bar still whilst draggin, or you start dragging it in the other direction (problem occurs the same in IE and FF, doesn't happen in Opera).
  3. Attaching a new file raises an ugly JS error message (Opera only).
  4. I agree that the fieldset collapsing could be a bit faster.
Anonymous’s picture

with the animation lengths, instead of using 'medium' or 'fast' .. we should use a number. we can have it like slideUp(600); and that may be better.. some of you try and manually adjust the effects and see what numbers you can come up with.

regarding the fieldsets not scrolling down enough to show everything.. a good idea would be to make it scroll the offsetHeight of the field set + an additional bit.. this could solve that problem.

Dries: not sure why the autocomplete on user names is not working for you on firefox mac. that's exactly what im on and everything is working.. hmm...

I'm going to roll another patch today.

Steven’s picture

Actually it does scroll further than it needs to, but I used Safari to decide the fudge factor. It seems firefox adds more space inside the fieldset, which causes it to be not enough.

I'll look into getting the positions right again, for the grippie and fieldset.

Anonymous’s picture

48.35 KB

ok try this..

this changes the speed to 400. it is a lot faster.

this also changes so the collapseScrollIntoView(node) uses node.offsetHeight to better align the screen with the fieldset and show the entire fieldset.

Anonymous’s picture

the scrolling on fieldsets, its a bit jumpy because of the amount of distance it needs to go and its just the native scrollTo() function which does not have an animation.

I think I'll write us a custom ScrollTo() function just like in the Interface plugin for jQuery so it atleast slides up nicely.

another thing, the speed at 400 for the slide up / slide down effects.. on my version i changed it to 200 now and its even better.

Roll another patch later with hopefully the ScrollTo() function.

m3avrck’s picture

Updated dev site:

webchick’s picture

Status: Needs review » Needs work

Categories fieldset is buggy here:

Firefox 1.5, Mac.

It starts expanded. When I click on the fieldset it "unexpands" as intended. When I click on it to expand it again though, it jumps the whole screen down so you can no longer see the "categories" fieldset, just the "test:".

eaton’s picture

218 bytes

with firefox on winXP, the grippie is misaligned a bit. screenshot attched.

Also, when a fieldset expands, it seems to scroll to the very bottom of the page no matter which one I open.

kkaefer’s picture

As I said before, let's revert back to the old textarea.js to solve the aligning issue. Once we have it in core (hopefully before Sept 1), we can refactor these functions.

Rok Žlender’s picture

8.17 KB

Sth weird happened to me when testing on I tried to add a page and in category field "Test" I typed sth and then pressed backspace until the text was gone and a few times more very fast. The result is in my screenshot. This doesnt happen on any other field not even on another autocomplete field.

Another maybe related thing. How to reproduce:
1. type in sth into "Test" category field delete the text and wait ( the clock is still turning even if there is nothing written)
2. now try to type in "Authored by" field in my case autocomplete feature is not working

This are some errors that I get:
Line: 633
Char: 10
Error: 'getAttribute' is null or not an object
Code: 0

Error: elem has no properties
Source File:
Line: 632

Error: has no properties
Source File:
Line: 1004

I tested this on windows version of FF and IE 6

Dries’s picture

With the latest patch, the scrolling is really bumpy (to the point that it is a regression rather than an improvement).

Stefan Nagtegaal’s picture

I tried to apply the latest patch from Steven Wittens against my fresh HEAD checkout and with one offset it applies cleanly to my install..

But unfortunatly I could not get any JS-related thing to work. All fieldsets are closed by default, and nomatter what I do, they keept closed. Clicking on it doesn't reveal anything..

I was suspecting the fact that my localhost failed to add jQuery or something, but everything seems to be in the right place.
All JS-files are there and doesn't contain any parse errors or whatever..

It's pretty strange imo..

Will checkout and review this once there is a new patch available..

Bèr Kessels’s picture

Not sure if we should really bother, but i'd like to report this anyway: Trying the example in konqueror 3.5.2. makes the uncollapsing behave really weird and un-user-friendly.

The uncollapsing effect is very bumpy (stop-motion effect). (collapsing is fine)
The worst however, is that my window scrolls to the point where the fieldset of the uncollapsed item, sits at the top.

If I am editing the title, then decide to click on the "File attachements" field label, my window scrolls up (putting the title field I was just editing out of the viewport) and the "File attachements" field tries to scroll to the top. If there is a not lot of content, it will scroll up only a few lines, but with lots of content below that field (uncollapse all fields to see this effect at its worst), I am totally lost for a few seconds. After all: All I did was open a fieldset, not scroll up and down, suddenly i see a whole different screen (it seems).


edmund.kwok’s picture

Same here, applied the patch to new HEAD checkout but the fieldset were not clickable. Using Firefox 1.5 on Mac.

Owen Barton’s picture

Priority: Normal » Critical

For those that haven't noticed jQuery 1.0 is out:

In the meantime the code freeze is tomorrow! Most of the problems described above seem to be with the fieldgroup dropdowns (either it not working, or a general dislike for this functionality). Since this functionality could (as far as I see) easily be added by a few lines of code in a contrib module it seems like it is hardly worth holding up the issue for.

I would like to propose we drop this subfeature from the patch, update the code to jQuery 1.0 and concentrate on getting this into core as soon as we can!

I would have a go at fixing this patch up myself - but I have a suspicion that Steven probably has been working on this since the last patch he posted. Any updates?

Steven’s picture

Status: Needs work » Fixed

Okay, I tested and tweaked this patch and it's pretty much ready to go into core.

  • The collapsible fieldset scrolling was indeed a bit choppy at the end of a page due to an oversight. It should be smoother now. I also set the duration a bit lower, which should reduce annoyance which still being smooth on the majority of machines. I still believe that the tiny slowdown due to the annoyance is much more aesthetically pleasing and visually clearer than the old 'snap'.
  • I fixed the resizable textarea grippie alignment in all browsers I could find.
  • Restored the resizable-textarea-inside-a-collapsed-fieldset fix which got taken out by timcn's refactoring.
  • Removed the fade effect from the textarea opacity change because it caused the scrollbar to flick in and out of existance.
  • Tweaked the JS uploader transitions so they work on all browsers.

The only serious issue that I saw in this patch was an error box in Opera when uploading a file for the first time. I couldn't pinpoint the cause of this in the JS code itself, so I'm pretty sure it's a browser bug. I'll get in touch with Opera QA for this, but

The jQuery version I used is jQuery 1.0.1 compressed.

So, I went ahead and committed it to HEAD. jQuery is an essential part of the 4.8 API, and the bugs that are there now and only in the core widgets' usage it. We'll resolve them as they pop up.

Anonymous’s picture

Status: Fixed » Closed (fixed)
GiorgosK’s picture

I tested with IE5.0 on win98 (default browser)
and I get some scripting errors.

Jquery supports IE5.5 and up
Even the site gives some javascript errors

Should we be using something like this
(I could not find something specific to IE5 in the jquery site)

GiorgosK’s picture

(sorry code was stripped from drupal formatter, here it is)

<!--[if IE]> 
<script type="text/javascript" src="misc/jquery.js"></script> 
<script type="text/javascript" src="misc/jquery_dependent_script.js"></script> 
<![endif] -->