Closed Bug 946398 Opened 7 years ago Closed 7 years ago
Flip the pref to enable <input type=number>
We should enable <input type=number> on Nightly, and I think we should let that uplift to Aurora on the 8th. Once we have feedback we can evaluate whether we need to turn it off on Aurora or if we can leave it turned on. I have a few bugs that I know need fixed before letting it out into the wild, such as bug 946390. These are all tracked by blocking bug 344616. Before actually landing the patch for this bug I intend to land the patches for bug 935508 and bug 945784.
And UI on Linux needs some tweaking. The arrow buttons are very very narrow.
(In reply to Olli Pettay [:smaug] from comment #2) > I think bug 946184 at least need to be fixed before this. The theming patch fixes that.
(In reply to Olli Pettay [:smaug] from comment #3) > And UI on Linux needs some tweaking. The arrow buttons are very very narrow. And that.
Comment on attachment 8342566 [details] [diff] [review] patch Assuming Bug 947728 is fixed.
Attachment #8342566 - Flags: review+
(In reply to Olli Pettay [:smaug] from comment #6) > Assuming Bug 947728 is fixed. Looks very good to me. This screenshot is from today's Nightly on Linux (64bit).
This patch was landed to m-c: http://hg.mozilla.org/mozilla-central/rev/379cddab8d6a Do we have any reason to not close this bug?
Quick question: does the activation of <input type="number"> for desktop (which is this bug if I understood correctly) made the cut for Aurora 28 or is it on Nightly only (for the next 6 weeks)? If it is planned to make ride the trains up to Fx28, we should add it to these release notes.
It should have made the merge (based on commit time), waiting on Aurora to verify (→ ni? me).
Yes, there was a good reason that I didn't want to close this - doing so notified all 100 CC's on bug 344616 which means I have to blog about this now instead of waiting until a few critical follow-ups have landed, which means I have to mention and enumerate those bugs, and if people know there are known bugs they generally won't file bugs about things we _don't_ know about. Oh well.
Sorry, did not anticipate that! But if you don't write a blog post now, people won't know there are known bugs, and file new ones if I follow your logic correctly. ;)
(In reply to Florian Bender from comment #10) > It should have made the merge (based on commit time), waiting on Aurora to > verify (→ ni? me). I can confirm that <input type=number> is in the 28.0a2 Aurora builds at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
(In reply to Florian Bender from comment #12) > Sorry, did not anticipate that! Not too surprising. ;) > But if you don't write a blog post now, people won't know there are known > bugs, and file new ones if I follow your logic correctly. ;) Hah, but then by the time I did it would be old news, which would be annoying. I went with a compromise of blogging and not mentioning the knows bugs. :)
<input type=number> is going to be disabled for v28 (bug 962313), so moving relnote-firefox+ to v29.
removing keyword since input=number will not be on on Firefox 28... The input type=number feature now has a QA owner that is testing in on Firefox 29 and will continue the work there.
(In reply to Ioana Budnar, QA [:ioana] from comment #16) > removing keyword since input=number will not be on on Firefox 28... Updating target milestone to reflect this status.
Target Milestone: mozilla28 → mozilla29
Verified that on Firefox 29.0a2 Aurora (20140314004001) the <input type=number> feature is enabled and works as expected. Used the next OSs for testing: Win 7 64-bit, Win 8 32-bit, Ubuntu 32-bit, Mac OS X 10.8.5.
Status: RESOLVED → VERIFIED
Added this to the site compat doc given the several regressions. https://developer.mozilla.org/en-US/Firefox/Releases/29/Site_Compatibility#HTML https://twitter.com/FxSiteCompat/status/464969389352050689
You need to log in before you can comment on or make changes to this bug.