Open Bug 603190 Opened 9 years ago Updated 2 years ago

No visual cue when input field maxLength reached

Categories

(Core :: DOM: Editor, enhancement)

x86
Windows 7
enhancement
Not set

Tracking

()

People

(Reporter: jan-bugreport, Unassigned)

References

()

Details

Attachments

(2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 GTB7.1 (.NET CLR 3.5.30729)
Build Identifier: 

At least under windows, it is default behaviour that if you attempt to enter text into an input box which is full, you hear a system sound ("ding"). This does not seem to happen with <INPUT> fields that have a maxlength attribute. This means that, for example, if a password box is too narrow and has a length limit, users have absolutely no indication that they cannot enter more text anymore. (This is from a real usability issue from a broken website that seems to allow you to set long passwords but not to enter it. Took two days until someone noticed it.)

In the linked example site, the field is wider than the maximum length, making the problem visible. If the field was less wide, there would be no way to notice.

Reproducible: Always

Steps to Reproduce:
1. Find/make page with length-limited input field (see link)
2. Type into it until length is reached (and further)

Actual Results:  
Nothing

Expected Results:  
Some kind of indication, for example playing the system default sound that is usually played in this case.
Status: UNCONFIRMED → NEW
Ever confirmed: true
If we do that I guess it should be done with the editor given that the editor is blocking the input when maxlength is reached.
If we do that on Windows, can we do that on other platforms? Is there something like that with other platform we support?
Component: DOM: Core & HTML → Editor
QA Contact: general → editor
This is something which the UI and accessibility folks should comment on.  I'm not sure if we want this, and if yes, under which platforms.  I'm also not sure if this is something that other web browsers do.
Keywords: uiwanted
I think we should copy default platform behavior here. Specific Firefox features may intersect with platform default behavior and features of third-party applications like screen readers (like you use a ding sounding close to other ding used for something else).
Copying the default platform behavior is reasonable. I'm also not sure what the other browsers do, although all that is really important is how the platform is supposed to behave.

In addition to the sound, if we wanted to get really fancy we could play around with a quick flash of the field (a visual ding), if I were designing an OS widget set that's something that I would be interested in adding.
Internet Explorer makes no sound or any other indication. A dialog box in MS Office I tried makes a ding sound and shows a balloon popup from the input box. An input box with a size limit in a simple .NET project makes a ding but no visual indication - I believe this is the Windows default platform behavior.
This probably needs some widget support.  Jan, do you want to file a bug in Core::Widget Win32 for widget support necessary here?
Severity: normal → enhancement
Keywords: uiwanted
(In reply to comment #6)
> This probably needs some widget support.  Jan, do you want to file a bug in
> Core::Widget Win32 for widget support necessary here?

I do not know the internal structure of the Mozilla projects and I don't have the slightest clue what I would need to write into that bug, so if there is something to be filed, I would prefer it if someone knowing more about all this could do it. "Win32" sounds like the solution would be plattform-dependent. I suspect linux max have a similar behavior here. Would someone mind to check?
Depends on: 604451
I filed bug 604451 for that.
Version: unspecified → Trunk
Assignee: nobody → netzen
Comment on attachment 558379 [details] [diff] [review]
Patch for playing sound in editor when we reach max length

This will cause the system sound to play both when you exceed the max length limit in an input or textarea element.  Is this the default platform behavior on Windows?  Is this sound played when the maxlength is hit only by typing into the field, or with other operations too (such as pasting or dropping text)?  Also, does this behavior also affect password controls?

Also, the way that this patch works, we ensure that this only happens in Windows by not providing an implementation for EVENT_EDITOR_MAX_LEN in other widget ports, right?  Is this the common practice in widget code?

We should also have a test for this.  In order to test this, the easiest way is to mock the sound component and make sure that the PlayEventSound method is called when you enter text which exceeds the maxlength limit.
> This will cause the system sound to play both when you exceed the max length limit in an input or textarea element.  Is this the default platform behavior on Windows? 

I thought it was for both, but I just made a native test win32 app and it only beeps on max length if the edit box's ES_MULTILINE is NOT set. (so input should beep, but textarea should not beep).  Will fix.

> Is this sound played when the maxlength is hit only by typing into the field, or with other operations too (such as pasting or dropping text)?  

Other operations beep too.  I couldn't easily test drag and drop but pasting beeps so I assume drop would also.

> Also, does this behavior also affect password controls?

Yes both text fields and passwords beep.

> Also, the way that this patch works, we ensure that this only happens in Windows by not providing an implementation for EVENT_EDITOR_MAX_LEN in other widget ports, right? 

Yup that is correct.

> Is this the common practice in widget code?

In this case yes. 
For example on gtk2 PlayEventSound only handles EVENT_NEW_MAIL_RECEIVED:

> NS_IMETHODIMP nsSound::PlayEventSound(PRUint32 aEventId)
> {
>     return aEventId == EVENT_NEW_MAIL_RECEIVED ? Beep() : NS_OK;
> }

I verified the other nsISound implementations and the new constant will not cause a problem.

> We should also have a test for this.  
> In order to test this, the easiest way is to mock the sound component and make 
> sure that the PlayEventSound method is called when you enter text which exceeds 
> the maxlength limit.

OK I'll work on that for next patch which also fixes the multi line beep.
(In reply to Brian R. Bondy [:bbondy] from comment #11)
> > This will cause the system sound to play both when you exceed the max length limit in an input or textarea element.  Is this the default platform behavior on Windows? 
> 
> I thought it was for both, but I just made a native test win32 app and it
> only beeps on max length if the edit box's ES_MULTILINE is NOT set. (so
> input should beep, but textarea should not beep).  Will fix.

If that's the case, we should also figure out what we should do for different text type inputs...

> > Is this sound played when the maxlength is hit only by typing into the field, or with other operations too (such as pasting or dropping text)?  
> 
> Other operations beep too.  I couldn't easily test drag and drop but pasting
> beeps so I assume drop would also.

OK, then from that perspective what this patch does is fine.

> > Also, does this behavior also affect password controls?
> 
> Yes both text fields and passwords beep.

Cool!

> > Is this the common practice in widget code?
> 
> In this case yes. 
> For example on gtk2 PlayEventSound only handles EVENT_NEW_MAIL_RECEIVED:

OK.

> > NS_IMETHODIMP nsSound::PlayEventSound(PRUint32 aEventId)
> > {
> >     return aEventId == EVENT_NEW_MAIL_RECEIVED ? Beep() : NS_OK;
> > }
> 
> I verified the other nsISound implementations and the new constant will not
> cause a problem.
> 
> > We should also have a test for this.  
> > In order to test this, the easiest way is to mock the sound component and make 
> > sure that the PlayEventSound method is called when you enter text which exceeds 
> > the maxlength limit.
> 
> OK I'll work on that for next patch which also fixes the multi line beep.

Awesome, thanks for looking into this!
It would be really nice if we could get the field to visually pulse when we play the system ding.  Otherwise there isn't as clear of an association between the sound and what on the system is creating the sound.  Additionally there's the accessibility case (not to mention the speakers muted case).  We might want to consider just using a visual-only ding for feedback.
For completeness, here is the patch with textarea not ding'ing but input ding'ing when max text is reached.  This matches platform behaviour.  

As per Comment 13 it seems we probably will not be doing this via sound though, so I won't bother doing the test mentioned in Comment 10.
Attachment #558379 - Attachment is obsolete: true
Attachment #558379 - Flags: review?(ehsan)
Do you need me to review attachment 558685 [details] [diff] [review]?
Given Comment 13 I'm not sure if we are doing this anymore via sound.  So if that is the case no review needed.  I'm not sure who's call it is :)

If we do want to do it via sound for now though, then it'd need a review and I will do a separate patch with the unit test you mentioned in Comment 10.
This is mostly a UX call.  I'm not sure if we just want to match platform conventions, or also add a visual cue (or add a visual cue in lieu of the platform default sound).  Throwing this off at Faaborg for now  ;-)
Keywords: uiwanted
faaborg if it is desirable to you, I can finish the unit test for sound in this ticket to match platform behaviour, and then post a new ticket about the visual cue?

Or if you'd prefer no audio I'll obsolete my patch above.
yeah I don't really like the native platform behavior of playing a ding sound.  Especially on XP where the ding is pretty aggressive (vista and 7 toned it down considerably)  Sorry for providing the late UX feedback resulting in you obsoleting a patch, but I think users will generally be happier with a nice visual ding.
No problem, thanks for the feedback.  The task didn't take very long at all so no worries.
Summary: No "ding" sound when input field maxLength reached → No visual cue when input field maxLength reached
No longer depends on: 604451
Assignee: netzen → nobody
Attachment #558685 - Attachment is obsolete: true
Are there any other web browsers or applications which provide a visual cue in the case of exceeding maximum length limits on a text field?  I don't remember ever seeing one.
Most widget sets haven't supported animation so this type of feedback wasn't an option.  Some text editors flash the screen though, so it isn't entirely novel (not that users are likely to have encountered one of those editors, so there is no consistency win, it's just that I've seen it before).
FWIW, we have other bugs open to not block the typing when the maxlength is reached but make the field invalid instead (and blocks the form submission). It might be better for the user experience because most of the time the maxlength is pretty frustrating.
(In reply to Mounir Lamouri (:volkmar) from comment #23)
> FWIW, we have other bugs open to not block the typing when the maxlength is
> reached but make the field invalid instead (and blocks the form submission).
> It might be better for the user experience because most of the time the
> maxlength is pretty frustrating.

Would that not break web content which expects the user to not be able to enter more than maxlength characters?  For example, date input textboxes which might be designed to visually accept no more than 2 (or 4) digits...
(In reply to Ehsan Akhgari [:ehsan] from comment #24)
> (In reply to Mounir Lamouri (:volkmar) from comment #23)
> > FWIW, we have other bugs open to not block the typing when the maxlength is
> > reached but make the field invalid instead (and blocks the form submission).
> > It might be better for the user experience because most of the time the
> > maxlength is pretty frustrating.
> 
> Would that not break web content which expects the user to not be able to
> enter more than maxlength characters?  For example, date input textboxes
> which might be designed to visually accept no more than 2 (or 4) digits...

It will not break those websites. Worst thing it will make it a bit annoying to the user. But we can assume a user will hardly write a 4 digits year when the input field is big enough for a 2 digits one. Anyway, this will be an invalid input field and the user will be prompted to fix it.
We could combine that with the animation.  Also would be nice to have a line showing the input cut off.
I'm going to echo Faaborg here - having a slight pulse of red fade in and out would be awesome.  Happy to review a patch that does this.  Removing uiwanted, feel free to add back when/if further input or review is needed.
Keywords: uiwanted
Duplicate of this bug: 1433728
You need to log in before you can comment on or make changes to this bug.