Closed Bug 36996 Opened 25 years ago Closed 25 years ago

Adding 0 to width or height produces error dialog

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rubydoo123, Assigned: cmanske)

Details

(Whiteboard: [nsbeta3+])

1. Created an html file with an image in it -- used an external editor 2. Opened Composer and accessed the test html file 3. Highlighted the image and selected the image icon from the toolbar, the image dialog box was displayed. 4. Selected Custom Size. Entered a 0 in the width and height boxes. 5. Selected Advanced on the dialog. An error dialog box was displayed: The number you entered is outside of the allowed range. Please enter a number between (?) and 10000. -- Note: the beginning value, where I put the (?) is not displayed. 1. the OK button should be disabled 2. the dialog text could be clearer, such as: "A value of zero (0) is not allowed for the width or height of an image. Please enter a number between 1 and 10000."
Target Milestone: --- → M16
Are you saying we should allow a 0 for the width of an image? I thought we were not supposed to. As to the error message, it could be reworded, but that dialog is used for many edit fields and I'd like to avoid specific reference to the particular input field. We'd have to do it for all and it would add a lot of strings. Why it doesn't fill in the "0" is a bug, I guess. I can't test it because I crash as soon as I click on the "Custom size" button! Also, the "Choose" button doesn't work.
hmm -- well I knew what I was trying to say, but it didn't seem to get across. Zero should not be allowed, and somehow we should disable further editing until that value is changed -- is there anyway you can disable other functions/buttons if a zero value is entered? I didn't realize the dialog was used for other fields -- so scratch that idea!
That would be way to complicated. Our current model is to validate all the fields when you use OK or the Advanced Edit button (since it needs to have the latest values of all attributes before it can change them.) We could try to validate each field separately "onblur" (when you leave the textfield), but we would have to do it for *all* text fields in all dialogs and that would be a lot of work! We could attempt that later as a "bug" if we have the time. Note that after an error occurs, the focus is (supposed to!) set to the offending textfield.
as long as the user 1. knows what they did was incorrect, 2. why it is incorrect and 3. what is incorrect -- then you have done the correct thing for a positive user experience. I would at least try and highlight the offending entry -- can that at least be done?
Note that as I said above, we put the caret back into the "offending" textfield after the error message is dismissed. We are waiting for improvements to selection to also be able to automatically select the existing contents of that textfield, which is stronger feedback, making it easy to immediately type a new value to replace the wrong value. I'm going to keep this bug alive for that issue.
Status: NEW → ASSIGNED
moving this out to m17
Target Milestone: M16 → M17
setting to m19
Keywords: correctness
Target Milestone: M17 → M19
Keywords: nsbeta3
setting to nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: M19 → M18
We now correctly select the out-of-range (or any other "bad") value in all textfield validations, such as this example.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified in 8/15 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.