Page MenuHomePhabricator

[Regression] WikiLove's preview button only works on second click
Closed, ResolvedPublic


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).

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:18 AM
bzimport set Reference to bz35057.

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:

Expected result:

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


vivekee047 wrote:

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.

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.