827727 - [BB] Input areas: Remove reset button from input when the input is not on :focus but is :valid

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Attachment: The bug!

Comment 1

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Attachment: patch

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Checked out contacts, Mail app, and a few other apps.  Seems like it fixed an issue where clearing a field might clear more than 1 field as well...

Comment 3

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Yep this should be done per each app separately because in the [BB] we don't want to have any JS.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

This fix regressed the behaviour of the reset button in the e-mail app (which was previously too wacky) so that it does not reset anything, resulting in bug 833300.  This does not appear to regress the contacts app because of somewhat weird logic landed in bug 827697.

The selector that causes the reset button to be displayed/active is:
  form p input:focus + button[type="reset"] {
    opacity: 1;
    pointer-events: all;
  }

The key thing is that the button only accepts mouse events when the "input" is focused; attempting to 'click' on the button will take the focus away from the "input", causing "pointer-events: none;" to apply again.

contacts deals with this in communications/contacts/js/contacts_form.js by adding a bubbling 'mousedown' listener that interecepts mousedown on "button" tags of type "reset", assuming previousElementSibling is an "input", and clearing its "value".


The whole widget idiom seems like something better handled by gecko with a XBL binding, but even if we have to just approximate it in content, using CSS that requires use of a 'mousedown' handler and precludes a 'click' handler seems incorrect.  Since type='reset' is semantically incorrect because it wants to reset the whole form anyways and requires JS logic, perhaps we should just leave the enablement issue of the button up to JS logic entirely?

Comment 5

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Hey Andrew,
I think this one is also related 830127

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Pavel Ivanov [:ivanovpavel] from comment #5)
> Hey Andrew,
> I think this one is also related 830127

Yes, bug 830127 would seem to be a suitable follow-up location for this; I'll move my subsequent discussion there.  Thanks!

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

verified : 
Master build : 2013-03-26-07-02-04
"mozilla-central" revision="28b048ffb7a7"
"integration/gaia-central" revision="44f6a17f24d4"
"gecko.git"revision="a800f14ea7022a78966f7fe14a9b0d11c569b151"
"gaia.git" revision="ace1eb32a313da1232bbdf9cff2581a4b036356d"

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/28b048ffb7a7
Gaia   ace1eb32a313da1232bbdf9cff2581a4b036356d
BuildID 20130326070204
Version 18.0
Unagi