Andrea Marchesini [:baku] Assignee
	Description • 11 years ago

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

The attribute should be called inputMode instead of inputmode.

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 1 • 11 years ago

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

	Andrea Marchesini [:baku] Assignee
	Comment 2 • 11 years ago

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

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 4 • 11 years ago

Why not just change the spec, then?

	Andrea Marchesini [:baku] Assignee
	Comment 5 • 11 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 11 years ago

Do any other UAs implement this property?

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

	Andrea Marchesini [:baku] Assignee
	Comment 7 • 11 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 11 years ago

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

	Andrea Marchesini [:baku] Assignee
	Comment 9 • 11 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 11 years ago

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

	Anne (:annevk)
	Comment 11 • 11 years ago

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

	Mounir Lamouri (:mounir)
	Comment 12 • 11 years ago

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...

	Boris Zbarsky [:bzbarsky]
	Comment 13 • 11 years ago

> 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.  ;)

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 11 years ago

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

r=me

	Andrea Marchesini [:baku] Assignee
	Comment 15 • 11 years ago

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

	Ryan VanderMeulen [:RyanVM]
	Comment 16 • 11 years ago

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

	(no longer active)
	Comment 17 • 11 years ago

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.

	(no longer active)
	Comment 18 • 11 years ago

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

	Ed Morley [:emorley]
	Comment 19 • 11 years ago

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

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 20 • 11 years ago

So, do we want to backport this?

	(no longer active)
	Comment 21 • 11 years ago

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

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

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 22 • 11 years ago

(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

	Andrea Marchesini [:baku] Assignee
	Comment 23 • 11 years ago

(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!

	(no longer active)
	Comment 24 • 11 years ago

(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.

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 25 • 11 years ago

Mounir, can you please make the call about aurora?

	Mounir Lamouri (:mounir)
	Comment 26 • 11 years ago

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.

	(no longer active)
	Comment 27 • 11 years ago

(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.

	Mounir Lamouri (:mounir)
	Comment 28 • 11 years ago

(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.

	Kohei Yoshino [:kohei]
	Comment 29 • 11 years ago

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

	(no longer active)
	Comment 30 • 11 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 31 • 11 years ago

> 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

	(no longer active)
	Comment 32 • 11 years ago

OK, great, filed bug 857355 for that.

	Mounir Lamouri (:mounir)
	Comment 33 • 11 years ago

(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.