966844 - Consider hiding the spin buttons for <input type=number> when its width is too narrow, e.g. at skyscanner.com

Status: NEW

(Core :: Layout: Form Controls, defect, P4)

Description

[muntted]

Attachment: LChromeRFirefoxAurora.png

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140202004003

Steps to reproduce:

Go to www.skyscanner.com.au
Try to adjust number of passengers in the form presented


Actual results:

Firefox presents increase/decrease buttons in the field where you are to enter number of passengers
Pressing these buttons does not change anything - ie. pressing up twice does not pass on the number 2 or 3 to the search perimeters



Expected results:

Should be a box where you can type the number of passengers.
Attached file shows Chrome(L) vs Firefox(R)

Comment 1

[Alice0775 White]

Workaround
set dom.forms.number to false

Comment 2

[Jonathan Watt [:jwatt]]

The file http://css.skyscnr.com/framework/cache/css/core_55860.css explicitly hides the spin buttons for Chrome with:

input[type=number]::-webkit-inner-spin-button,
input[type=number]::-webkit-outer-spin-button {
  -webkit-appearance: none;
}

The equivalent for Firefox would be:

input[type=number] {
  -moz-appearance: textfield;
}

It's worth noting that Chrome also has the same issue with the spinner obscuring the value if the rule in core_55860.css is disabled. That said, we could try and be smarter and auto hide the spinner if there isn't enough room for it and at least one digit, say. But I don't think we should block bug 344616 or bug 946398 on this. Blocking bug 945309 would be more appropriate.

Comment 3

[Jonathan Watt [:jwatt]]

As explained in comment 2 this is something the website should take action on. I don't think we should track for this. I think it might be a useful enhancement to auto hide these buttons, but I don't think that's something that's going to be top of my work list in the near future.

Comment 4

[Jonathan Watt [:jwatt]]

I said and explained above that I don't think this should track. Therefore if marking this as tracking+ please say why, or else I have to assume my comments above weren't read.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Sorry.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] [offline 17-28 April] from comment #3)
> As explained in comment 2 this is something the website should take action
> on. I don't think we should track for this. I think it might be a useful
> enhancement to auto hide these buttons, but I don't think that's something
> that's going to be top of my work list in the near future.

Should we re-shape this into a tech evang bug, then? (And maybe spin off an separate bug for the possible Gecko auto-hiding enhancement?)

Note that Alice0775 White tried to give the site authors a heads-up via a web form, per [duplicate] bug 1000400 comment 10. However, at that point we (or at least I) thought the developers were Japanese, since that bug was filed about the .jp version of the site, so the post may have been in Japanese (not sure).

Comment 8

[Jonathan Watt [:jwatt]]

I think we should keep this open and file separate evangelism bugs. The sites I've seen things go wrong on are sites that want the spinner hidden, period. This bug would still be a useful enhancement for browser users though in the case that a number input's width varies but generally is wide enough to show the spinner (and does).

Comment 9

[Hallvord R. M. Steen [:hallvors]]

The site no longer uses input type=number here, so it's no longer a tech evang issue. It's still a possible core issue, minimal test would be:

data:text/html,<input type="number" style="width:1em">

Comment 10

[Dennis Schubert [:denschub]]

We just received another WebCompat report where a form field is more or less unsuable because the arrow buttons block the content.