Do not show the error message in the tooltip if title is set

RESOLVED FIXED in mozilla2.0b8

Status

()

defect
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: alexander.farkas, Assigned: mounir)

Tracking

({dev-doc-complete})

Trunk
mozilla2.0b8
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

If a form with candidates for constraint validation is generated, there are appearing tooltips with some hints, explaining the constraints of this input. Although they are quite usefull, there should be a way to turn them off.

Either by using the title-attribute or by setting a pseudo-element to display none (::constraint-hint {display: none;}.

Reproducible: Always

Steps to Reproduce:
Use nightly build of Firefox/Minefield (Firefox 4beta7)
1. Create <input required title="" name="test">
2. Hover over element
Actual Results:  
A validation hint appears

Expected Results:  
The validation message should not appear. (Should be "overriden" by the title attribute).

Showing a info bubble, not only on invalid-event (wich is cancelable), but also on mouseover is usefull extension to the specification. But it is an extension and Mozilla is the first browser, with this approach.

Especially, if a developer want's to change the way, the user is informed about the constraints (through creating an info-icon next to the form element) or want's to create custom (i18n)-messages (setCustomValidity is nice, but isn't the right tool to achieve this), he needs a way to disable this feature.

By the way: I'm currenty playing a lot with the constraint validation API and although, you are only supporting a small part (no type=number, type=date etc.). Your implementation is the best/most accurate implementation. 

nice work.

Updated

9 years ago
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser
Mounir, is there a way to do this already?

And I think the last part of comment 0 is something you should read.  ;)
Component: HTML: Parser → Layout: Form Controls
QA Contact: parser → layout.form-controls
Assignee

Comment 2

9 years ago
I'm not sure I understand what you really want:
 1. disable the message when you think it's not relevant ;
 2. or change the message

You already can do (2) with x-moz-errormessage (available in nightlies and next beta (7)) attribute or .setCustomValidity().
For (1), I'm not sure I understand what are the use cases.

The idea of this tooltip is when a form control is invalid, the user might want to know why. The tooltip might prevent the user to submit the form only to know what's happening.

I guess we could only show the tooltip when :-moz-ui-invalid applies (see bug 605124) and also prevent showing it when novalidate is set on the form element.
Version: unspecified → Trunk
Reporter

Comment 3

9 years ago
First of all: I haven't checked the x-moz-errormessage attribute yet. So I can't decide, wether this would be a good workaround. But it looks extremly ugly.

There are two main usecases, neither :moz-ui-invalid nor novalidate would fit for this:

Usecase for 1. "disable the message when you think it's not relevant":

First I often have to implement validation on top of very detailed concept. This means a concept could specify:

"If an input-element has a constraint, there is an info icon next to the element explaining the constraints to the user on hover."

A quick and dirty implementation would look like this:

<form>
	<label for="name">Name</label>
	<input required id="name" name="name">
	<span class="hint-icon" title="The name input is required. Please fill out"></span>
</form>

It would be a violation of the concept, if the input itself shows also a tooltip. In this case: I have to remove HTML5 form validation and have to implement this features going old school.

The second thing has to to with 2. "changing the validation message" (and changing the look and feel of the constraint validation):

The setCustomValidity-API is a really bad method for changing the only the validation-message. This is why:

1. setCustomValidity works only on a single element. If I want to change the validationMessage for required inputs. I have to go through all required inputs and set the validationMessage.
2. setCustomValidity does not only change the validationMessage, it also sets the customError-flag to true. This means, if I only wanted to change the message for required elements. I have to dynamically remove my custom validation message, if the input is not empty anymore. 


This means a lot of code to only change the validation message.

In contrast, in the current implementation of Opera, it is really simple to change the validation message using only the methods defined in the standard (because, they don't show a validation hint on hover). Here is the JS-Code:

<script>
	document.getElementsByTagName("form")[0].addEventListener("invalid", function(e){
		//stop appearing browser validation message
		e.preventDefault();
		//implement customValidation bubble and custom validation message for e.target.validity
	}, true);
</script>

This said, I think a custom event like [on]mozinvalidhint, wich can be prevented would be a great extension.

Hope my point is now much clearer. I hope, that you understand my problems here, they are extremly important.
Assignee

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee

Comment 4

9 years ago
Alexander, if we don't show a validation hint when the title attribute is set, would that be better for you?
Reporter

Comment 5

9 years ago
Yes this would be an suitable solution. Thanks.
Assignee

Updated

9 years ago
Summary: ability to disable validation hints on form-elements (candidates for constraint validation) → Do not show the error message in the tooltip if title is set
Assignee

Comment 6

9 years ago
Posted patch Patch v1 (obsolete) — Splinter Review
If title is set (even to the empty string), the tooltip will not show the error message but the title value (or nothing if the title value is the empty string.

For approval: this is a minor change with no risks that is doing some polish to a feature.
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #490577 - Flags: review?(jonas)
Attachment #490577 - Flags: approval2.0?
Assignee

Comment 7

9 years ago
Posted patch Patch v1Splinter Review
Attachment #490577 - Attachment is obsolete: true
Attachment #490580 - Flags: review?(jonas)
Attachment #490580 - Flags: approval2.0?
Attachment #490577 - Flags: review?(jonas)
Attachment #490577 - Flags: approval2.0?
Comment on attachment 490580 [details] [diff] [review]
Patch v1

>diff --git a/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp b/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp
...
>   if (cvElement) {
>-    cvElement->GetValidationMessage(outText);
>-    found = !outText.IsEmpty();
>+    nsCOMPtr<nsIDOMElement> content = do_QueryInterface(cvElement);
>+    PRBool hasTitle = PR_FALSE;
>+    content->HasAttribute(NS_LITERAL_STRING("title"), &hasTitle);
>+
>+    if (!hasTitle) {
>+      cvElement->GetValidationMessage(outText);
>+      found = !outText.IsEmpty();
>+    }

QI to nsIContent and use HasAttr instead.

r=me with that changed.
Attachment #490580 - Flags: review?(jonas) → review+
Assignee

Comment 9

9 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/344597f66c3e

I think this is fixing the bug. Alexander, if there is another issue, feel free to open a new bug and add me in CC.

Setting dev-doc-needed so we can tell the web authors they can deactivate the tooltip showing the error message by setting title="".
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Keywords: dev-doc-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8

Updated

9 years ago
Blocks: 601091
No longer blocks: 601091
You need to log in before you can comment on or make changes to this bug.