I am unable to reproduce this behavior on normal pages or on Wikilove pages on commons, using HTTP or HTTPS, with Chromium on Ubuntu.

(Demo'd to Mark Mar 8)

I was not able to reproduce at Commons via HTTPS using Chrome 17. Krinkle, can you verify that the bug still exists for you?

I left one part of the reproduction steps. Here they are again:

• A talk page: https://commons.wikimedia.org/wiki/User_talk:12.0.0.1
• Initiative the WikiLove dialog
• Enter a large portion of text into the textarea (or copy the description) - anything to make it autogrow
• Press preview

Expected result:
Preview

Actual result:
Button flickers a bit, but no action. Press again (or twice) and there it is at last.

Confirmed in Firefox as well. Might have something to do with jQuery.elastic (the part that handles the text area expanding).

Confirmed in trunk (1.20alpha) as well. In 1.19 we upgraded jQuery to 1.7.1 and jQuery UI to 1.8.17, either of which could be related to this bug.

Doesn't appear to be related to the jQuery or jQuery UI upgrades.

Hmm, as far as I can tell it seems this bug always existed, but some recent change has made it much more noticable. Specifically, until recently the textarea only expanded if you actually got to the end of it, whereas now it expands with each line of text entered. So this may actually be 2 bugs.

Looks like upgrading jQuery caused the aggressive textarea expansion problem. I
checked to see if there's an upgrade of jQuery.elastic available, but it looks
like there isn't. Haven't tracked down the jumping submit button problem yet.

It looks like the rewrite of the getWH() function in jQuery between 1.6.1 and 1.6.2 is what's causing the textarea expansion weirdness with jQuery.elastic.

I found a work-around for the textarea expansion bug. r113458 solves that problem (at least for Firefox and Chrome). That means the second click bug will now only occur if you actually put a large amount of text into the textarea (more than 2 lines). That gets us back to where we were before 1.19, but the bug is still there, just more difficult to trigger. Changing priority from High to Normal.

The textarea expansion problem is actually a bug in jQuery. The jQuery function getWH is reporting percentage widths and heights as pixel heights. So in this case it was reporting the width of the textarea as 100px rather than 100%, which was causing jQuery.elastic to miscalculate how tall to make the textarea.

vivekee047 wrote:

Replaced 'blur' with 'mouseover'

I have made small changes in jquery.elastic.js.

needs review

Attached:

vivekee047 wrote:

changes blur to mouseleave

The last patch was not right.I m sorry for that.

Attached:

I fixed the jQuery bug in r114013. I'll take a look at the jQuery.elastic patch as soon as I'm back in the US (I'm on vacation right now).

I'm still on vacation, but I just can't stay away from this bug :)

The suggested patch looks good (and explains where the button jumping behavior comes from). I have an even better idea though. I think we should get rid of the 'compact textarea on blur' feature altogether as it is unintuitive behavior and not helpful for the user. I've delete the code for that feature in r114016.

vivekee047 wrote:

IMHO resizing of the text box is better and getting rid of the feature :).
Suggestion 2 - we need not have the extra line in the textarea when we type.