Last Comment Bug 850346 - inputmode vs inputMode for nsHTMLInputElement
: inputmode vs inputMode for nsHTMLInputElement
Status: RESOLVED FIXED
: dev-doc-complete, site-compat
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla22
Assigned To: Andrea Marchesini [:baku]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-12 12:21 PDT by Andrea Marchesini [:baku]
Modified: 2015-04-02 10:10 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (3.37 KB, patch)
2013-03-13 03:33 PDT, Andrea Marchesini [:baku]
bzbarsky: review+
Details | Diff | Splinter Review

Description Andrea Marchesini [:baku] 2013-03-12 12:21:19 PDT
http://www.whatwg.org/specs/web-apps/current-work/#the-input-element

The attribute should be called inputMode instead of inputmode.
Comment 1 :Ms2ger (⌚ UTC+1/+2) 2013-03-12 12:29:40 PDT
What's up with all these? Please check who implements them...
Comment 2 Andrea Marchesini [:baku] 2013-03-12 17:24:08 PDT
Nothing... just the specs say it should be inputMode, but our implementation has inputmode.
Comment 3 Andrea Marchesini [:baku] 2013-03-13 03:33:09 PDT
Created attachment 724349 [details] [diff] [review]
patch
Comment 4 :Ms2ger (⌚ UTC+1/+2) 2013-03-13 04:52:52 PDT
Why not just change the spec, then?
Comment 5 Andrea Marchesini [:baku] 2013-03-13 05:08:29 PDT
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 [:bz] 2013-03-13 06:20:21 PDT
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] 2013-03-13 07:27:44 PDT
It seems Webkit doesn't implement this attribute:
https://bugs.webkit.org/show_bug.cgi?id=23588
Comment 8 Boris Zbarsky [:bz] 2013-03-13 07:34:50 PDT
OK, so back to the second question in comment 6?  ;)
Comment 9 Andrea Marchesini [:baku] 2013-03-13 07:54:42 PDT
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 [:bz] 2013-03-13 07:57:38 PDT
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) 2013-03-13 08:09:46 PDT
I think the specification changed to match casing conventions with all other IDL attributes. Is this a major pita?
Comment 12 Mounir Lamouri (:mounir) 2013-03-13 08:09:46 PDT
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 [:bz] 2013-03-13 08:12:46 PDT
> 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 [:bz] 2013-03-13 08:13:08 PDT
Comment on attachment 724349 [details] [diff] [review]
patch

r=me
Comment 15 Andrea Marchesini [:baku] 2013-03-13 10:07:08 PDT
https://tbpl.mozilla.org/?tree=Try&rev=5a5468f919ef
Comment 16 Ryan VanderMeulen [:RyanVM] 2013-03-13 12:56:24 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e6f598201ce
Comment 17 :Ehsan Akhgari 2013-03-13 13:02:44 PDT
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 19 Ed Morley [:emorley] 2013-03-14 05:25:11 PDT
https://hg.mozilla.org/mozilla-central/rev/0b67c5f5cc01
Comment 20 :Ms2ger (⌚ UTC+1/+2) 2013-03-14 06:42:12 PDT
So, do we want to backport this?
Comment 21 :Ehsan Akhgari 2013-03-14 08:15:11 PDT
(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 (⌚ UTC+1/+2) 2013-03-14 09:15:51 PDT
(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] 2013-03-14 09:21:54 PDT
(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 :Ehsan Akhgari 2013-03-14 14:14:25 PDT
(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 (⌚ UTC+1/+2) 2013-03-23 08:43:10 PDT
Mounir, can you please make the call about aurora?
Comment 26 Mounir Lamouri (:mounir) 2013-03-25 05:12:56 PDT
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 :Ehsan Akhgari 2013-03-25 07:55:04 PDT
(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) 2013-03-27 10:07:42 PDT
(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 [:kohei] 2013-03-29 10:01:37 PDT
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 :Ehsan Akhgari 2013-04-02 13:56:01 PDT
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 [:bz] 2013-04-02 13:58:28 PDT
> 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 :Ehsan Akhgari 2013-04-02 16:09:20 PDT
OK, great, filed bug 857355 for that.
Comment 33 Mounir Lamouri (:mounir) 2013-04-03 03:29:47 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.