Page MenuHomePhabricator

VisualEditor: Deleting the first digit of the size in Media Settings removes the entire value in the both fields
Closed, ResolvedPublic


Steps to reproduce:

1.Open the page in VE
2.Insert an image
3.Go to Media Settings>Advanced Settings
4.Now delete the first digit of the size.For example:if you have size :600*450
Just attempt to make it 500*450

Observed Result:
The Width and the Height both values turned into 0.User have to again type the input of Height value which he might not wanted to change.

Test Environment:
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

Version: unspecified
Severity: minor



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:50 AM
bzimport set Reference to bz61059.

Created attachment 14524


Screen_Shot_2014-02-07_at_2.27.50_PM.png (460×888 px, 43 KB)

Cannot replicate in master.

Changing the size in either width or height (by deleting or changing the first digit or typing from scratch) changes the corresponding input.


  • Inserted an image with initial size 182x150
  • Media settings -> Advanced settings, deleted '1' to result in width: 82
  • Result: Height adjusted to 68 (Expected)
  • Marked the first digit in Width (8) and changed to 9
  • Result: Height adjusted to 76

This works for me in both Chrome and Firefox.

Am I missing any details to replicate?

If the size is "400" and you delete the first character (4), it becomes "00", which instantly becomes "0". Undoing this restores the 4… so it becomes "40" (and there's nothing left on the browser undo stack).

Maybe if you change the value such that it doesn't make sense, rather than cleaning up "00" or "0" and then complaining, we should just blank the field?

The problem is that the size widget constantly adjusts both values numerically, so value "00" in the width is read as the number '0', which actively changes the value in the height input (to 0).

Now, since a change occurred in height, that triggers an automatic change to width, which brings it down to the number 0.

We can fix this by not triggering the adjustment on keypress but rather when you leave the input (so, onChange event) but that has several other issues it may raise. For instance, what happens if I changed a width without moving away from the input (technically no 'change' input event) and then clicked the "Apply" button? The corresponding dimension didn't get updated, and while the 'change' event will trigger when I click the button (because the input loses focus) it will be too late to notify the user of a changed dimension.

I am not sure how this can be fixed without removing the functionality of updating both dimensions simultaneously. We should discuss this further.

What about making any "0" immediately become the wiki's default size?

Right now, there's no way to remove a size and return to unspecified default (see bug 50379).

I'm working on trying to get default size to work. There are several technical problems I am trying to sort through now, but once those are solved, we'll be able to have more options with default size, like a 'default' button and reverting to default on 0 value.

Change 115939 had a related patch set uploaded by Mooeypoo:
[wip] Deal with 'none'/'border' and default size in media edit

Change 115939 merged by jenkins-bot:
Deal with 'none'/'border' and default size in media edit

Verified the fix in test2 environment.