inputmode vs inputMode for nsHTMLInputElement

RESOLVED FIXED in mozilla22

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: baku, Assigned: baku)

Tracking

({dev-doc-complete, site-compat})

Trunk
mozilla22
dev-doc-complete, site-compat
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

The attribute should be called inputMode instead of inputmode.
Assignee: nobody → amarchesini
What's up with all these? Please check who implements them...
Nothing... just the specs say it should be inputMode, but our implementation has inputmode.
Created attachment 724349 [details] [diff] [review]
patch
Attachment #724349 - Flags: review?(bzbarsky)
Why not just change the spec, then?
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.
Do any other UAs implement this property?

If not, why does our property name not match the spec?  Which came first?
It seems Webkit doesn't implement this attribute:
https://bugs.webkit.org/show_bug.cgi?id=23588
OK, so back to the second question in comment 6?  ;)
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
OK, so gratuitous spec change.  Why is changing our implementation (with the attendant compat risk) preferable to undoing the random spec change?

Comment 11

5 years ago
I think the specification changed to match casing conventions with all other IDL attributes. Is this a major pita?
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...
> 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 on attachment 724349 [details] [diff] [review]
patch

r=me
Attachment #724349 - Flags: review?(bzbarsky) → review+
https://tbpl.mozilla.org/?tree=Try&rev=5a5468f919ef
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e6f598201ce
Keywords: checkin-needed
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.
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
https://hg.mozilla.org/mozilla-central/rev/0b67c5f5cc01
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
So, do we want to backport this?
(In reply to :Ms2ger from comment #20)
> So, do we want to backport this?

Why would we do that?  This has potential compat risk.
(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
(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!
(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.
Mounir, can you please make the call about aurora?
Flags: needinfo?(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.
Flags: needinfo?(mounir)
(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.
(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.
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
Keywords: dev-doc-complete
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.
Flags: needinfo?(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
Flags: needinfo?(bzbarsky)
OK, great, filed bug 857355 for that.
(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.

Updated

4 years ago
Keywords: site-compat
You need to log in before you can comment on or make changes to this bug.