History | Log In     View a printable version of the current page.  
Issue Details (XML)

Key: SDK-11256
Type: Minor Enhancement Minor Enhancement
Status: Reopened Reopened
Priority: C C
Assignee: SDK Community
Reporter: boobie star
Votes: 26
Watchers: 19
Operations

If you were logged in you would be able to see more operations.
Flex SDK

Option to pop up the Error Message Tooltip when component has focus

Created: 06/11/07 04:47 PM   Updated: 05/17/09 12:57 PM
Component/s: Validators
Security Level: Public (All JIRA Users )

File Attachments: None
Image Attachments:

1. better_validation_errors.jpg
(16 kb)

2. validation_error_current_behavior.jpg
(11 kb)

Severity: Cosmetic Issue/Spelling Error
Reproducibility: Intermittent
Discoverability: Medium
Found in Version: SDK Flex 3 (Released)
Milestone: SDK Community Fix Candidates
Affected OS(s): Windows - XP
Steps to Reproduce:
When a user is filling out a form and they do it incorrectly the border of the component becomes red. But you only see the Error Message Tooltip if you hold the mouse over the component. What would be nice is to have an option in the Validators to show the Error message tooltip immediately when the user focuses on the component. For example, if they tab to a new component the error message does not show up.

Steps to reproduce:
1. Add validator to component and run application
2. Tab away from component without entering required value
3. Tab back to the component (and show the Error Tooltip immediately)
 
 Actual Results:
 Does not show tooltip unless user hovers mouse over the component field for a specified length of time.
 
 Expected Results:
 Expects the Error tooltip to show immediately upon focus of component (when component has error borders already around it).
 
 Workaround (if any):
 Dispatch MouseOver event manually on component will show the Error message.
 
 
Language Found: English
Bugbase Id: none
QA Owner: Kishan Venkataramana
Participants: Ansury, Aral Balkan, boobie star, borf groandoa, Kris L., Lauren Park, Matt Chotin, Matthew Couch, ronzoni, SDK Community and Swaroop C H


 All   Comments      Sort Order:
ronzoni - [12/13/07 05:48 PM ]
I thought this would be easy, or something built in.
For me, after quite some time, I realized I can do it, but with my form I have to do both:
e.currentTarget.dispatchEvent(new MouseEvent(MouseEvent.MOUSE_OUT));
e.currentTarget.dispatchEvent(new MouseEvent(MouseEvent.MOUSE_OVER));

I call those when doing a focusOut event from my TextInput.

Not sure why the MouseEvent.MOUSE_OUT is required, but when I remove it, it doesn't work....

Aral Balkan - [01/10/08 04:26 AM ]
This is an important usability issue as the current behavior results in mystery meat validation errors that require additional user effort to decipher.

I've written in more detail about this issue on the following blog post:
http://aralbalkan.com/1125

The workaround suggested above is better, but ideally the validation errors should display continuously and you should be able to see multiple validation errors at the same time. I've attached a screenshot, from the blog post above, demonstrating this.

Aral Balkan - [01/10/08 04:29 AM ]
Mystery meat validation errors. This is how validation errors currently look in Flex.

Screenshot taken from my Validating Data Quick Start (http://www.adobe.com/devnet/flex/quickstart/validating_data/)

Lauren Park - [01/22/08 11:47 AM ]
Deferred for this release, but will be considered in the future. Thanks!

Swaroop C H - [08/22/08 07:45 AM ]
Can you please consider this ECR for Flex 4?

Ansury - [09/29/08 12:52 PM ]
I doubt anyone will see this, but we need much more flexibility within Flex for displaying form errors. This behavior won't work for large/complex forms sometimes in applications.

Options should be:
1) Default Flex behavior
2) Permanent error tips, for all fields (optionally)
3) Temporary error tips, which show for a few seconds but revert to look like the Flex default after that time has expired (mouse-over should still show the field again like it does by default)
4) Permanent (or even temporary) error tips for the FOCUSED component only (this option would be compatible with both 1 and 3, and is what is asked for in this ticket)

Kris L. - [02/12/09 01:11 PM ]
Using a custom ToolTipManagerImpl, I was able to force the error indicator to show when a component's "errorString" property is set.

The implementation was painful. Briefly, it involved:

1. Creating a CustomToolTipManagerImpl, inheriting from ToolTipManagerImpl and overriding various event handling bits.

2. Creating a custom application preloader which registers the single CustomToolTipManagerImpl class.
e.g. Singleton.registerClass("mx.managers::IToolTipManager2", CustomToolTipManagerImpl);

I'd also like to see this functionality become an optional feature of the flex framework.

borf groandoa - [04/30/09 05:48 PM ]
Agreed. This bug has been in here for 2 years? Come on Adobe. Just create a method on a TextInput, or someplace that will allow developers to simply "display" the error tip, if an error exists for that form item. I started digging into the code and really we just need a way to manually call the functionality contained within the "ToolTipManagerImpl.toolTipMouseOverHandler" and "ToolTipManagerImpl.toolTipMouseOutHandler" methods rather than you guys just hardwiring everything to the mouseout/mousein events.

Matthew Couch - [05/17/09 10:42 AM ]
Claimed for Indy Bug Quash

Matt Chotin - [05/17/09 12:57 PM ]
Note that this is the sort of thing we expect to be easier with Spark. It's important that any adjustment here be especially careful of the performance implications of popping these error tips, you'll also want to validate that when multiple fields have errors the proper error tips are shown, that mouse and focus behavior continues to be correct (for example when the focus of a textinput ends the tip doesn't clear if the error hasn't been fixed if this property is set), etc. I encourage you to give this a try, but might be good to do a checkpoint to make sure you're on the right track and don't add so much code that we're going to reject.