1164783 - <input type="search"> doesn't have border-box box-sizing

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[kermani]

Attachment: boxsizing.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150511143336

Steps to reproduce:

I was designing a webpage, page (http://jsfiddle.net/3qzb7q0d/) has header and inside header there were button(s) and input(s). I didn't know about box-sizing and the page was working grate on other browsers but Firefox had problem. I researched and found out Firefox needs to have some lines of CSS to become like other browsers (and maybe the problem is from other browsers):
html {
  box-sizing: border-box;
}

*, *:before, *:after {
   box-sizing: inherit;
}




Actual results:

When I added the CSS (http://jsfiddle.net/3qzb7q0d/2/)  Firefox rendered the page like other browsers (Grate). 

The below image likes are from the time before I add that CSS to my web page and it show the problem in Firefox:

http://balit.ir/firefox/chrome.png
http://balit.ir/firefox/opera.png
http://balit.ir/firefox/safari.png
http://balit.ir/firefox/firefox.png


Expected results:

As you should know there are a lot of websites that must add that lines of CSS to their websites just for Firefox (I guess) and other people (beginners) who don't know about box-sizing should take a long time to find out what is the problem. 

 (What do you think to) change Firefox box-sizing to become like other browsers?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase from http://fiddle.jshell.net/3qzb7q0d/show/

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase from http://fiddle.jshell.net/3qzb7q0d/2/show/

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

You're probably seeing a difference in the sizing of a particular form control.

No browser since very old versions of IE generally behaved as though box-sizing:border-box was set on all elements.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This bug could use a simple testcase showing what the actual difference is between browsers.

Comment 5

[kermani]

Please remove the box-sizing from http://fiddle.jshell.net/3qzb7q0d/2/ and test it. other browser can show and render it, but Firefox does not!

Test it please

Comment 6

[Boris Zbarsky [:bzbarsky]]

The basic structure of the testcase is as follows:

There is a <div id="search-div"> with a fixed width of 432px set.  This contains three things:

1) A <input type="submit"> with zero margin, border, padding, and a fixed width of 48px.
2) An <input type="search"> with zero margin, 1px left border, 5px left padding, 325px
   fixed width, 5px right padding, 1px right border.
3) A <div> with 49px width and display:inline-block.

The sum of all those widths is 48 + 49 + 325 + 2 + 10 = 434px.  This is more than 432px, so the three things don't fit.

It looks like at least Chrome defaults to "box-sizing:border-box" on the <input type="search">, so there the total width is 48 + 49 + 325 = 422px, which may or may not fit in the 432px div (because it also has to fit the width of the two spaces, which may be more or less than 10px depending on fonts).

Per HTML spec at https://html.spec.whatwg.org/multipage/rendering.html#rendering the only inputs that should have border-box sizing in standards mode are radio, checkbox, reset, button, submit (and <select> and <button> elements).  So it looks like we're following the spec here and Chrome is not.

Comment 7

[kermani]

(In reply to Not doing reviews right now from comment #6)
> The basic structure of the testcase is as follows:
> 
> There is a <div id="search-div"> with a fixed width of 432px set.  This
> contains three things:
> 
> 1) A <input type="submit"> with zero margin, border, padding, and a fixed
> width of 48px.
> 2) An <input type="search"> with zero margin, 1px left border, 5px left
> padding, 325px
>    fixed width, 5px right padding, 1px right border.
> 3) A <div> with 49px width and display:inline-block.
> 
> The sum of all those widths is 48 + 49 + 325 + 2 + 10 = 434px.  This is more
> than 432px, so the three things don't fit.
> 
> It looks like at least Chrome defaults to "box-sizing:border-box" on the
> <input type="search">, so there the total width is 48 + 49 + 325 = 422px,
> which may or may not fit in the 432px div (because it also has to fit the
> width of the two spaces, which may be more or less than 10px depending on
> fonts).
> 
> Per HTML spec at
> https://html.spec.whatwg.org/multipage/rendering.html#rendering the only
> inputs that should have border-box sizing in standards mode are radio,
> checkbox, reset, button, submit (and <select> and <button> elements).  So it
> looks like we're following the spec here and Chrome is not.

Thats good, But why other browsers can show it different and in their parent div without line breaking?

Comment 8

[kermani]

(In reply to Not doing reviews right now from comment #6)
> The basic structure of the testcase is as follows:
> 
> There is a <div id="search-div"> with a fixed width of 432px set.  This
> contains three things:
> 
> 1) A <input type="submit"> with zero margin, border, padding, and a fixed
> width of 48px.
> 2) An <input type="search"> with zero margin, 1px left border, 5px left
> padding, 325px
>    fixed width, 5px right padding, 1px right border.
> 3) A <div> with 49px width and display:inline-block.
> 
> The sum of all those widths is 48 + 49 + 325 + 2 + 10 = 434px.  This is more
> than 432px, so the three things don't fit.
> 
> It looks like at least Chrome defaults to "box-sizing:border-box" on the
> <input type="search">, so there the total width is 48 + 49 + 325 = 422px,
> which may or may not fit in the 432px div (because it also has to fit the
> width of the two spaces, which may be more or less than 10px depending on
> fonts).
> 
> Per HTML spec at
> https://html.spec.whatwg.org/multipage/rendering.html#rendering the only
> inputs that should have border-box sizing in standards mode are radio,
> checkbox, reset, button, submit (and <select> and <button> elements).  So it
> looks like we're following the spec here and Chrome is not.

Please also visit this page http://stackoverflow.com/questions/23888522/box-sizing-border-box-sizing-issue-in-firefox . other browser like chrome will show it different with Firefox, Maybe my question should be, why does Firefox is rendering different with other browsers? (My favorite browser is Firefox)

Comment 9

[Boris Zbarsky [:bzbarsky]]

> But why other browsers can show it different

I explained that for the case of Chrome in the text you quoted.

Comment 10

[Karl Dubost💡 :karlcow]

Confirmed and it creates WebCompat issue.
See https://webcompat.com/issues/1229#issuecomment-110546025

Comment 11

[Karl Dubost💡 :karlcow]

(In reply to Not doing reviews right now from comment #9)
> I explained that for the case of Chrome in the text you quoted.

It's in fact true for 
* Blink browsers (Chrome, Opera, etc)
* WebKit browsers (Safari iOS)

If someone can test on Spartan IE and on MS Edge, that would be nice.

Comment 12

[Karl Dubost💡 :karlcow]

Attachment: useragentstyle-bug1164783.patch

Not sure if it's the right file to modify, but it seemed logical, tell me if I should do something else. Be gentle. :)

Comment 13

[Boris Zbarsky [:bzbarsky]]

You should probably do the whitespace cleanup in a separate changeset from the substantive change.  And raise a spec issue here?

IE11 seems to have border-box sizing here too.  I don't have a simple way to try Spartan/Edge.

Comment 14

[Karl Dubost💡 :karlcow]

ah thanks boris, just noticed the spaces. Sorry about that. I guess my editor clean up the spaces itself. 
I will change the patch.

> And raise a spec issue here?

by "here", you meant on W3C bugzilla on CSS? Or something else?

Comment 15

[Boris Zbarsky [:bzbarsky]]

"here" == "for the whatwg HTML spec", probably.  So yeah, the W3C bugzilla.

Comment 16

[Karl Dubost💡 :karlcow]

Attachment: useragentstyle-bug1164783-2.patch

The new patch with only the added rule.

Comment 17

[Karl Dubost💡 :karlcow]

I opened a bug on HTML spec 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28784

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8617711 [details] [diff] [review]
useragentstyle-bug1164783-2.patch

r=dbaron, although I'd probably skip the comment

You should have a useful commit message (and, in general, you should have the commit message in the patch when you post it for review), such as:

Bug 1164783 - Change default style for input type=search to box-sizing: border-box.  r=dbaron

Comment 19

[Karl Dubost💡 :karlcow]

Hmm I didn't know I had the right to commit. The process I was taught was

 cd /your/path/mozilla-central
 hg status
 hg qpop -a
 hg pull -u
 # cd somewhere in the code
 # edit what I need and save
 hg qnew blahname-bug_number.patch
 # attach the patch
 # ask for r?
 # when r+, put keywords checkin-needed


If there is a better process, I will be happy to comply and indeed provide a better message. Slapping my face with a URI on the appropriate way to do it is fine.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Karl Dubost :karlcow from comment #19)
>  hg qnew blahname-bug_number.patch

This should also have a '-m "Commit message here."' argument, which has the commit message that ends up being used in the patch.  If it's at all complicated, though, you'll want a multi-line commit message, which you can edit with -e instead.  (See "hg help qnew", or "hg help qrefresh".)

Then it will end up being committed to the repository with a useful commit message, rather than one made up by the person who processes the checkin-needed and doesn't necessarily know what the patch does.

Comment 21

[Karl Dubost💡 :karlcow]

Attachment: remove trailing spaces

remove spaces per boris comment.

Comment 22

[Karl Dubost💡 :karlcow]

Attachment: bug-1164783-input.patch

add "box-sizing: border-box;" to input["search"].
Following David's process.

Thanks everyone for the guidance. Let's hope I didn't screw up things

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8617750 [details] [diff] [review]
remove trailing spaces

>Bug 1164783 - Removing trailing spaces.

We usually write commit messages with verbs rather than nouns, so "Remove trailing spaces".

r=dbaron

Comment 24

[Karl Dubost💡 :karlcow]

Thanks everyone for the guidance. Appreciated.

Comment 25

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9de887e53172
https://hg.mozilla.org/integration/mozilla-inbound/rev/f2602400179f

Comment 26

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9de887e53172
https://hg.mozilla.org/mozilla-central/rev/f2602400179f

Comment 27

[kermani]

(In reply to Wes Kocher (:KWierso) from comment #26)
> https://hg.mozilla.org/mozilla-central/rev/9de887e53172
> https://hg.mozilla.org/mozilla-central/rev/f2602400179f
Thanks everyone.
When I submitted this little style problem, some people said this is just your problem and your CSS is not right. But Chrome and other browser working very well with that page, Firefox not.