Closed Bug 1000400 Opened 6 years ago Closed 6 years ago

skyscanner.com layout broken because site doesn't leave enough room for arrow buttons on <input type="number">

Categories

(Tech Evangelism Graveyard :: English US, defect)

defect
Not set

Tracking

(firefox28 unaffected, firefox29 affected, firefox30 affected, firefox31 affected)

RESOLVED FIXED
Tracking Status
firefox28 --- unaffected
firefox29 --- affected
firefox30 --- affected
firefox31 --- affected

People

(Reporter: alice0775, Unassigned)

References

()

Details

(Keywords: site-compat, Whiteboard: see comment 7; Site needs to add "input[type=number] { -moz-appearance: textfield; }" alongside its webkit spinner hacks)

Attachments

(2 files)

Attached image screenshot
Open url
Last good revision: cb0546838451
First bad revision: d9a7e0906f2a
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cb0546838451&tochange=d9a7e0906f2a

Any of these, as flipping dom.forms.number to false fixes the problem.
(In reply to Elbart from comment #1)
> Any of these, as flipping dom.forms.number to false fixes the problem.

This almost certainly was introduced by Bug 946398 (which flipped the pref to true by default), then.

Having said that, I'm not sure it's a browser bug. We're dutifully following this style rule:
=========
#search-controls .passenger-info input{width:1.2em;text-align:center}
=========
from http://css.skyscnr.com//framework/cache/57818/css/core_57818.css

Reduced testcase:
  data:text/html,<input type="number" style="width: 1.2em" value="5">
which indeed is not wide enough to display the value "5" in the textbox.
Blocks: 946398
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 29 Branch → Trunk
So I think this is likely a tech evang bug.

I think the site authors need to either drop the type="number" attribute (so the arrow buttons go away), or they should increase the specified width so that there's room for the arrow buttons.

I guess ideally they'd like to be able to say "width: 1.2em + width-of-any-arrow-buttons", but I'm not sure there's a way to express that currently.... :-/

(jwatt, any thoughts/suggestions for ways to make this work better? And do you agree this should be Tech Evang, or is there anything we should do here?)
Flags: needinfo?(jwatt)
Interestingly, Chrome doesn't show arrow buttons on the URL, for some reason, so it renders the URL as-expected.

(My Chrome version *does* match firefox on my data URL from comment 2, though. (Arrows buttons present, and they cover up the text). So there may be some additional magic on the actual page that keeps it from showing the arrow buttons there.)

I'm using Chrome Version 36.0.1941.0 dev aura
Summary: layout broken → layout broken because site doesn't leave enough room for arrow buttons on <input type="number">
Do other browsers make the buttons go away when the control is smaller than a certain size?  Do they consider the buttons as being inside or outside the computed 'width'?
Attached file reduced html
The site adds special css for webkit(blink Chrome)


<style type="text/css">
input[type=number]::-webkit-inner-spin-button,
input[type=number]::-webkit-outer-spin-button
{
  -webkit-appearance:none;
  margin:0
}
</style>

<input type="number" value="5" style="width:1.2em;text-align:center;">
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #5)
> Do other browsers make the buttons go away when the control is smaller than
> a certain size?

Chrome doesn't, at least, as noted in my parenthetical in comment 4.

> Do they consider the buttons as being inside or outside the computed 'width'?

Inside.

(In reply to Alice0775 White from comment #6)
> Created attachment 8411331 [details]
> reduced html
> 
> The site adds special css for webkit(blink Chrome) [to hide the spinner]

Ah, thanks!

Actually, it looks like bug 947728 tracked adding a way to do this in Gecko, with style="-moz-appearance: textfield". I can confirm that I can fix this locally by adding that style. (And it still renders as a number frame under the hood, because uparrow/downarrow will still increment/decrement the value.)

So I think we should probably encourage the authors to add:
  input[type=number]
  {
   -moz-appearance: textfield;
  }
to the style block quoted in comment 6.
Flags: needinfo?(jwatt)
Adding dependency on bug 947728 [since that provided the way for web authors to fix this], and converting into Tech Evang bug, per end of comment 7.
Assignee: nobody → japanese
Component: Layout: Form Controls → Japanese
Depends on: 947728
Product: Core → Tech Evangelism
Whiteboard: see comment 7; Site needs to add "input[type=number] { -moz-appearance: textfield; }" alongside its webkit spinner hacks
Skyscanner isn't Japan-only.

visiting http://www.skyscanner.com redirects you to your regional version of it.
At least it does for me.
FYI, I reported the problem from http://www.skyscanner.jp/contactus.aspx.
(In reply to Elbart from comment #9)
> Skyscanner isn't Japan-only.
> 
> visiting http://www.skyscanner.com redirects you to your regional version of it.

Oh, true. Same for me. I'll update the Tech Evang component to en-US, then.  Though maybe Alice0775 White's message on the jp-localized page will still reach the right folks.
Assignee: japanese → english-us
Component: Japanese → English US
It seems that this issue is duplicate of bug 966844.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 966844
Summary: layout broken because site doesn't leave enough room for arrow buttons on <input type="number"> → skyscanner.com layout broken because site doesn't leave enough room for arrow buttons on <input type="number">
I received a reply from the site as follows.

> お客様
> 
> この度はスカイスキャナーをご利用下さいまして誠にありがとうございます。
> また、お手数をおかけしまして誠に申し訳ございませんでした。
> 
> 確認しましたところ、ご指摘のとおり不具合があるようでございましたので、
> 早急に修正するようお手配させていただいております。
> 
> 今後ともどうぞ宜しくお願い申し上げます。
> 
> 
> スカイスキャナー
> 
> 
> Skyscanner Support

Yes, it is Japanese side.
So, I think that it is necessary to report a problem to them(English and other).
Un-duping; per bug 966844 comment 8, jwatt wants to use that bug to track the possibility of making this "just work" by hiding the spinners (or something like that), and in the meantime, we can use tech evangelism bugs (like this one) to suggest that sites use "-moz-appearance: textfield;" for the time being.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Looks like they have added -moz-appearance: textfield.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Keywords: site-compat
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.