850346 - inputmode vs inputMode for nsHTMLInputElement

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Andrea Marchesini [:baku]]

http://www.whatwg.org/specs/web-apps/current-work/#the-input-element

The attribute should be called inputMode instead of inputmode.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

What's up with all these? Please check who implements them...

Comment 2

[Andrea Marchesini [:baku]]

Nothing... just the specs say it should be inputMode, but our implementation has inputmode.

Comment 3

[Andrea Marchesini [:baku]]

Attachment: patch

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Why not just change the spec, then?

Comment 5

[Andrea Marchesini [:baku]]

it seems that any attribute is camelcased. The spec is consistent in the attribute names.
I think this has to be changed in our code.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Do any other UAs implement this property?

If not, why does our property name not match the spec?  Which came first?

Comment 7

[Andrea Marchesini [:baku]]

It seems Webkit doesn't implement this attribute:
https://bugs.webkit.org/show_bug.cgi?id=23588

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK, so back to the second question in comment 6?  ;)

Comment 9

[Andrea Marchesini [:baku]]

Bug 746142 implements this feature. And the reason why is lowercase is because the specs are
http://www.whatwg.org/specs/web-forms/current-work/#inputmode

That draft has been superseded by the Forms chapter of the HTML5 specification:

http://www.whatwg.org/specs/web-apps/current-work/#the-input-element

Comment 10

[Boris Zbarsky [:bzbarsky]]

OK, so gratuitous spec change.  Why is changing our implementation (with the attendant compat risk) preferable to undoing the random spec change?

Comment 11

[Anne (:annevk)]

I think the specification changed to match casing conventions with all other IDL attributes. Is this a major pita?

Comment 12

[Mounir Lamouri (:mounir)]

FWIW, there are/were discussions in whatwg mailing list to change the specs and our behaviour. We do not expect anyone to be using that. It should actually be only in Nightly/Aurora...

Comment 13

[Boris Zbarsky [:bzbarsky]]

> It should actually be only in Nightly/Aurora...

Ah, ok.  Then changing is probably fine.

Anne, it's not hard to change, but I'm wary of web compat stuff nowadays.  ;)

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 724349 [details] [diff] [review]
patch

r=me

Comment 15

[Andrea Marchesini [:baku]]

https://tbpl.mozilla.org/?tree=Try&rev=5a5468f919ef

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2e6f598201ce

Comment 17

[(no longer active)]

So this patch changes nsIDOMHTMLInputElement without changing its UUID, which, because of bug 848624, means that the xpt file may not get updated in a non-clobbered build (which you wouldn't observe on the try server since all builds are clobbered there.)

So, _if_ this fails on inbound, please backout and reland with a UUID change.  Note that the UUID change is not really necessary since this does not change the vtable layout, but our XPIDL compiler is just stupid.

Comment 18

[(no longer active)]

Backed out: https://hg.mozilla.org/integration/mozilla-inbound/rev/15e663a7ee41 and relanded with the UUID change: https://hg.mozilla.org/integration/mozilla-inbound/rev/0b67c5f5cc01

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0b67c5f5cc01

Comment 20

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

So, do we want to backport this?

Comment 21

[(no longer active)]

(In reply to :Ms2ger from comment #20)
> So, do we want to backport this?

Why would we do that?  This has potential compat risk.

Comment 22

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to :Ehsan Akhgari from comment #21)
> (In reply to :Ms2ger from comment #20)
> > So, do we want to backport this?
> 
> Why would we do that?  This has potential compat risk.

Because it's apparently new on aurora

Comment 23

[Andrea Marchesini [:baku]]

(In reply to :Ehsan Akhgari from comment #18)
> Backed out:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/15e663a7ee41 and
> relanded with the UUID change:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/0b67c5f5cc01

Thank you!

Comment 24

[(no longer active)]

(In reply to comment #22)
> (In reply to :Ehsan Akhgari from comment #21)
> > (In reply to :Ms2ger from comment #20)
> > > So, do we want to backport this?
> > 
> > Why would we do that?  This has potential compat risk.
> 
> Because it's apparently new on aurora

Oh, yeah ok in that case it makes sense.

Comment 25

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Mounir, can you please make the call about aurora?

Comment 26

[Mounir Lamouri (:mounir)]

This feature (inputmode) has landed a long time ago and has been backed out from various versions. I would like us to not ship the feature at all so landing the fix in Aurora isn't very important.

Comment 27

[(no longer active)]

(In reply to comment #26)
> This feature (inputmode) has landed a long time ago and has been backed out
> from various versions. I would like us to not ship the feature at all so
> landing the fix in Aurora isn't very important.

This patch just changes the case of the attribute to be lower camel case.  If we don't want to ship this feature, we should back its implementation out from both Aurora and central.  Otherwise I think not taking this patch on Aurora is a mistake since that means that the attribute will change its name between 21 and 22.

Comment 28

[Mounir Lamouri (:mounir)]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #27)
> (In reply to comment #26)
> > This feature (inputmode) has landed a long time ago and has been backed out
> > from various versions. I would like us to not ship the feature at all so
> > landing the fix in Aurora isn't very important.
> 
> This patch just changes the case of the attribute to be lower camel case. 
> If we don't want to ship this feature, we should back its implementation out
> from both Aurora and central.  Otherwise I think not taking this patch on
> Aurora is a mistake since that means that the attribute will change its name
> between 21 and 22.

I would like this feature to be *only* available in Nightly and Aurora actually (to be tested by developers). Until we figure out something that we are fine to ship. Right now, we know that our solution is probably not ready to ship but there has been no work done to restrict it to Nightly + Aurora. The problem being finding someone to do it.

Comment 29

[Kohei Yoshino]

I've added this bug to the compatibility doc. Please correct the info if wrong.
https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22

Comment 30

[(no longer active)]

Is it possible to hide individual methods/attribs behind prefs in Web IDL?  If yes, supporting this only for Nightly and Aurora is trivial, through making the prefs hidden behind RELEASE_BUILD.

Comment 31

[Boris Zbarsky [:bzbarsky]]

> Is it possible to hide individual methods/attribs behind prefs in Web IDL?

Yes, absolutely.  See https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#.5BPref.3Dprefname.5D

Comment 32

[(no longer active)]

OK, great, filed bug 857355 for that.

Comment 33

[Mounir Lamouri (:mounir)]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #30)
> Is it possible to hide individual methods/attribs behind prefs in Web IDL? 
> If yes, supporting this only for Nightly and Aurora is trivial, through
> making the prefs hidden behind RELEASE_BUILD.

That's not really trivial because the backends don't use the IDL attribute but the content attribute and there is no way to hide a content attribute behind a preference so you would have to disable backends individually. If we consider Firefox OS special, that luckily means there is only Android to disable that way.