Closed Bug 977645 Opened 6 years ago Closed 6 years ago

Remove dom.forms.number customization from mobile.js

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

Attachments

(1 file)

Ever since dom.forms.number was created, it's been "true" in mobile.js [1], though it was originally "false" in all.js.

Now that it's been changed to "true" in all.js in bug 946398, we don't need to set it in mobile.js anymore.

(Somewhat similar to bug 977643.)

[1] http://hg.mozilla.org/mozilla-central/rev/60ba9b28408c#l4.12
Attached patch fixSplinter Review
Assignee: nobody → dholbert
Attachment #8383089 - Flags: review?(wjohnston)
I think we should hold off on this. If we end up flipping the all.js pref to false for some reason we don't want to forget to turn it back on in mobile.js. In fact I'm not really sure there's much point in removing it from mobile.js/b2g.js rather than just waiting for a cycle or two of number being out in the wild before removing it altogether.
Why was it enabled separately on mobile.js in the first place? Is the idea that typing on mobile is harder than tapping a spinner, so the risk/reward payoff was different?
Ohhhh, right -- from looking at bug 771492 comment 1, it sounds like we enabled this on Android because there, <input type="number"> didn't need to render any differently; it could just pop up a numeric keyboard instead of the standard one.
Attachment #8383089 - Flags: review?(wjohnston)
...and it still seems to render that way (like a standard <input>), in my fennec nightly.

So it makes sense that, hypothetically, if we decided to turn off this pref in all.js due to some issue with the desktop experience, it'd make sense to still keep it enabled on android.

Cool, I agree with comment 2 then.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.