Body textarea disappears (caused by weights)

Confirmed.

To reproduce enable the node_example.module http://api.drupal.org/api/file/developer/examples/node_example.module/6

Edit node_example_form() thus:

 $form['color'] = array(
    '#type' => 'textarea', // change from textfield to textarea
    '#title' => t('Color'),
    '#weight' => 0,  // Add weight here.
    '#default_value' => isset($node->color) ? $node->color : '',
  );

Notice the "Example Body" disappearing.

Is this critical?
This would break many module which implement hook_form() or hook_form_alter() on node forms (CCK?)

The temporary fix is not to use any weight... which is a regression in functionality.

Sounds very similar to this: http://drupal.org/node/193921 but that was fixed :|

Disappears == does not end up in the HTML output OR == does end up in the HTML output, but the JS hides it? This would greatly narrow down to where we should look and it is easy to tell if you reproduced the bug.

Ends in the html output hidden because has the same parent as the teaser:

teaser.js is intented to hide only the teaser, not teaser + body.

    // Set initial visibility
    if ($(teaser).is('[@disabled]')) {
      $(teaser).parent().hide();
    }

Textarea wraps the teaser + body with a span that ends hidden.

Edit: Looks like if there is a textarea before the body, this wrap happens before the procesing of the teaser.

This patch moves the teaser with the grip provided by textarea before the body.

Broken when textarea is not processed before.

Inverted form api processing to do the resizable before the teaser.

Now, this is funny, we have specifically patched one to come before the other and now we need to swap? Why?? Will there be an issue next week asking to be swapped back?

Reproduced, tested with beginner's instructions in #2 on FF2, IE6/7, Opera, Safari3(XP). All good. I'll leave it open for an extra review given the shortness of the criticals queue and this being the second time it's cropped up, but it seems fine.

chx, there's been minor changes to the teaser splitter (button/checkbox in a div, stuff like that) which may have broken the earlier fix (not sure which order they got committed in to be honest). I can confirm that the additional textarea doesn't break the split/join behaviour, and fixes the hiding issue. But yes this needs more eyes on it to make sure we don't go 'round in circles.

Agree totally with chx and catch.

Much more simple patch, avoid processing teasers that have not passed teaser.js filter.

Tested in all browsers I have access to and this one also worked cleanly.

theborg: this latest patch makes a lot of sense. teaser.js already ensures that non-processed textareas are processed near the end of its job, when the the textarea is already marked teaser-processed, so textare.js will run on it well. I committed this latest patch.