Bug Tracker

Ticket #4146 (closed bug: invalid)

Opened 6 years ago

Last modified 3 years ago

jQuery width inconsistency with buttons

Reported by: rob.desbois Owned by:
Priority: high Milestone: 1.next
Component: dimensions Version: 1.5.2
Keywords: Cc:
Blocking: Blocked by:

Description

If you have a button-type element on the page then the following code makes it shrink when it seems it should have no effect var w = $("#x").width(); 222 $("#x").width(w); makes element shrink $("#x").width(); 216

This occurs for input[type=button], input[type=submit], input[type=reset] and button elements too.

Attachments

test-jquery-fault.html Download (677 bytes) - added by rob.desbois 6 years ago.
Testcase showing shrinking button
test-4146.html Download (659 bytes) - added by dmethvin 6 years ago.
bizarro buttons width

Change History

Changed 6 years ago by rob.desbois

Testcase showing shrinking button

comment:1 Changed 6 years ago by rob.desbois

Faulty behaviour seen in Firefox 3.0.6 and IE 6.0

Changed 6 years ago by dmethvin

bizarro buttons width

comment:2 Changed 6 years ago by dmethvin

In test-4146 I set up a case with two buttons, both with simple 80px width, 5px border, and 10px padding. You'd expect jQuery to return 80 for width but instead it returns 80-10-10-5-5=50. If you ask jQuery for $("#x1").css("width") it correctly returns 80px. I *think* that means the browsers I tested (FF3 and IE8RC1) include the border and padding in the css width.

comment:3 Changed 6 years ago by dmethvin

  • Summary changed from jQuery.width returns innerWidth but sets outerWidth? to jQuery width inconsistency with buttons

comment:4 Changed 5 years ago by dmethvin

  • Priority changed from major to minor
  • Component changed from unfilled to core

comment:5 Changed 4 years ago by dmethvin

  • Status changed from new to open
  • Milestone 1.3.2 deleted

comment:6 Changed 4 years ago by jboesch

Looks like the browsers are adding padding-left, padding-right as defaults. Then in jQuery, we run it through an $.each loop on line 295 in css.js. It's doing a val -= on the padding... thus taking away padding we didn't explicitly set:

 http://jsfiddle.net/jboesch26/Gtm5H/

comment:7 Changed 4 years ago by jboesch

Here are some more findings... offsetWidth is not taking padding/borders into consideration for quite a few different input types/buttons:  http://jsfiddle.net/jboesch26/Gtm5H/

Try running that jsfiddle in some different browsers... It's a bummer that these results are different in Firefox 3.6 and in Chrome 9.0.597.102

Last edited 4 years ago by jboesch (previous) (diff)

comment:8 Changed 4 years ago by jboesch

This seems like a browser bug. Having offsetWidth work in some browsers for some elements and not for others is very weird. This problem exists when you call outerWidth() on input/button elements too. See my fiddle for examples.

Last edited 4 years ago by jboesch (previous) (diff)

comment:9 Changed 4 years ago by jboesch

Prototype has this problem as well:  http://jsfiddle.net/jboesch26/xW2zW/ I think the only way around this issue is scrapping offsetWidth/offsetHeight.

Dojo does not have this problem:  http://jsfiddle.net/jboesch26/CAUS3/ Dojo is only using offsetWidth/Height when the value of the element is "auto".

I will look into landing a patch.

comment:10 Changed 4 years ago by jboesch

Landed a fix for this:  https://github.com/jquery/jquery/pull/325/files UPDATED: new pull request

Last edited 4 years ago by jboesch (previous) (diff)

comment:11 Changed 4 years ago by dmethvin

  • Priority changed from minor to low
  • Milestone set to 1.6

If this patch is good it would be good to land in 1.6.

comment:12 Changed 4 years ago by jeresig

  • Status changed from open to closed
  • Resolution set to fixed

Fix formatting of pull 325. Fixes #4146.

Changeset: 84712bd624a9a4eeaab9ea9c543bba494f2cc3e1

comment:13 Changed 4 years ago by jboesch

Should be set to invalid. Setting border-sizing: content-box in the CSS fixes it in FF. By default FF uses border-sizing: border-box for buttons.

 http://jsfiddle.net/jboesch26/3qDqV/

comment:14 Changed 4 years ago by timmywil

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Version changed from 1.3.1 to 1.5.2
  • Component changed from core to dimensions

There is still a problem in IE8 returning inconsistent width values for inputs and buttons. The inconsistency is present with both border-box or content-box.  http://jsfiddle.net/timmywil/AFRt7/4/

comment:15 Changed 4 years ago by timmywil

  • Status changed from reopened to open

comment:16 Changed 4 years ago by john

  • Priority changed from low to high
  • Milestone changed from 1.6 to 1.next

comment:17 Changed 4 years ago by timmywil

  • Status changed from open to closed
  • Resolution set to invalid

I've looked into this further and it seems we're fine here. IE8 and Chromium 12 actually have the same setting for box-sizing for buttons, but IE has different default border widths and padding widths, hence the different values. If I set the borders and paddings to equal amounts, all consistent. The reason setting the width to some value might make the button smaller is due to the box-sizing.

Note: See TracTickets for help on using tickets.