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)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
M18
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."
Reporter | ||
Updated•25 years ago
|
Target Milestone: --- → M16
Assignee | ||
Comment 1•25 years ago
|
||
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.
Reporter | ||
Comment 2•25 years ago
|
||
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!
Assignee | ||
Comment 3•25 years ago
|
||
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.
Reporter | ||
Comment 4•25 years ago
|
||
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?
Assignee | ||
Comment 5•25 years ago
|
||
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
Reporter | ||
Comment 8•25 years ago
|
||
setting to nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: M19 → M18
Assignee | ||
Comment 9•25 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•