Last modified: 2012-04-05 19:49:23 UTC
Since a few days I'm noticing (on Commons via HTTPS using Google Chrome), that clicking "Preview" doesn't do anything. It does flicker a bit and moves a pixel up and down, but no action occurs. Clicking again does the expected preview and one can continue. This is a regression and also a fairly major usability issue as WikiLove forces users to use a preview before submission (the submission process or button isn't even visible until preview is successfully done).
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.
Created attachment 10245 [details] Replaced 'blur' with 'mouseover' I have made small changes in jquery.elastic.js. needs review
Created attachment 10246 [details] changes blur to mouseleave The last patch was not right.I m sorry for that.
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.
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.
