830127 - [BB][input_areas] - pointer-events is not correct

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Comment 1

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

Attachment: patch for UX branch

Comment 2

[Sam Joch [:samjoch]]

Landed in uxbranch: https://github.com/gordonbrander/gaia/commit/5c45b41510f34279154a951c3df4b15b4378a81e

Comment 3

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

Not to sure I understand the difference between auto and all, or what this code actually fixes?  I think I'm missing something subtle again.

Comment 4

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

By some reason we have this rule :
button[type="reset"] { pointer-events: none; }

In our case this means that he never reset the form. 
But anyway I do not know why Telefonica guys use of this rule to button[type="reset"] ... but when I have more time I will investigate this more closely.

This patch allows us to use a single form field with button[type="reset"] who can help us to reset the input without any JS.
But if you want to use more form fields and each of them has its own button[type="reset"] you need to use JS to clear each field separately.

Comment 5

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

Unfortunately it doesn't resolve bug 826533...

These are the following that use the building blocks.  I think the button[type="reset"] refers to reseting the field with a little x.  It used to be that email setup cleared all fields, which very much describes the initial issue I saw in bug 826533

It doesn't seem like this would likely break anything... but I'm hesitatant to just qa-verify it...

NH-MBP:apps nhirata$ find . | xargs grep "input_areas.css" *
./browser/index.html:    <link rel="stylesheet" href="shared/style/input_areas.css" type="text/css">
./communications/contacts/fb_import.html:    <link href="/shared/style/input_areas.css" rel="stylesheet">
./communications/contacts/index.html:    <link href="/shared/style/input_areas.css" rel="stylesheet">
./communications/dialer/ussd.html:    <link rel="stylesheet" type="text/css" href="/shared/style/input_areas.css">
./communications/ftu/index.html:  <link rel="stylesheet" type="text/css" href="/shared/style/input_areas.css">
./email/index.html:  <link rel="stylesheet" type="text/css" href="shared/style/input_areas.css"/>
./feedback/index.html:    <link rel="stylesheet" type="text/css" href="shared/style/input_areas.css"/>
./homescreen/save-bookmark.html:    <link rel="stylesheet" type="text/css" href="shared/style/input_areas.css">
./settings/index.html:    <link rel="stylesheet" type="text/css" href="shared/style/input_areas.css"/>
./sms/index.html:    <link rel="stylesheet" type="text/css" href="shared/style/input_areas.css">
NH-MBP:apps nhirata$

Comment 6

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

I think that we need to set on each App(who use [BB][input_areas]) preventDefault() to all button[type="reset"] ... and make logic to clear the correct field.

I will try to do this soon if all of us are ok?

Comment 7

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

(In reply to Naoki Hirata :nhirata from comment #5)
> Unfortunately it doesn't resolve bug 826533...

As sorta covered on my comment https://bugzilla.mozilla.org/show_bug.cgi?id=827727#c4 the problem is just with building blocks trying to pretend that type="reset" has semantics compatible with resetting a single field.

Disabling pointer-events when the reset button is not visible makes sense since otherwise the user may try and click into an input form and accidentally hit the invisible 'clear' button.  Unfortunately, messing with pointer-events on a selector that's only active when ":focused" results in the bug this bug is trying to fix; a 'click' event no longer fires and the button no longer does anything.

To fix e-mail and make building blocks more sane, it probably makes sense to introduce a custom attribute value like type="reset-field" and provide a JS function like hookupResetFieldButtons(domNode) that makes everything work.

The decision for that JS would be whether the JS is in charge of maintaining the visibility of the reset button (in which case, 'click' can be used to handle the clearing), or if the CSS selector stays as it is (and 'mousedown' must be used, like in contacts).

Comment 8

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

Whoa.  Thanks for the explaination, asuth!  I think I would prefer to take what asuth had mentioned instead of messing with the pointer events...

Comment 9

[David Flanagan [:djf]]

Pavel, if you want to fix this as discussed in bug 833300, you can find my JS shim in email/js/input_areas.js.  Feel free to modify that as needed for your more general fix. I'd be happy to review, or I can do the modification myself when your CSS and HTML changes are ready.

Comment 10

[BMO Automation]

Firefox OS is not being worked on