Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#9484 closed bug (duplicate)

height() returns incorrect value in IE7 for div without top border

Reported by: dwilks Owned by:
Priority: undecided Milestone: 1.next
Component: unfiled Version: 1.6.1
Keywords: Cc:
Blocked by: Blocking:



height() on outer div is incorrectly returning 49 in IE7. .css('height') and innerHeight are also incorrect. outerHeight is correct. DOM's clientHeight is correct.

Correctly returns 50 in IE8, Firefox 3.6, Chrome 11.

The key is that the div has a 1px border but border-top is set to 'none.' JQuery returns correct values if border-top is also set to 0px.

Tested against 1.6 and edge in jsfiddle. Against 1.6.1 in my own project.

Change History (6)

comment:1 Changed 11 years ago by dmethvin

Resolution: duplicate
Status: newclosed

We looked at fixing this in 1.5; due to the rarity and amount of code required decided not to add it.

comment:2 Changed 11 years ago by dmethvin

Duplicate of #7058.

comment:3 in reply to:  2 Changed 10 years ago by alex3683

Replying to dmethvin:

Duplicate of #7058.

Replying to dmethvin:

Duplicate of #7058.

I don't understand how this can be a duplicate. #7058 describes the change of a very low level function returning different values across different browsers, which is sad but where I can understand that it's a wontfix. The browser vendors decided to do that, fine, we have to live with this.

Here we talk about a real bug: A method promising a concrete functionality (i.e. returning the height of an element) has a real bug in that it is returning not inconsistent, but really incorrect results in some browsers. It's right that it's not the right way to let for example css( "borderTopWidth" ) be clever, but the ".height()" and ".width()" methods should check for this case as it is a real bug.

EDIT: Here is a fiddle showing the problem: http://jsfiddle.net/QCUdw/1/ Test it in IE7, IE8 and a current Firefox version.

Last edited 10 years ago by alex3683 (previous) (diff)

comment:4 Changed 10 years ago by mikesherov

It's not about being "concrete" or not. 100% coverage of every single edge case is not the goal of jQuery. The goal of jQuery is to cover as many edge cases as possible while also considering the size, speed, and maintainability of the library. In this case, we've decided that performance, size, and maintainability concerns outweight fixing this rare edge case.

The core team makes calls like this all the time. If every edge case ever detected was covered, jQuery would be twice it's size. I hope you can understand this decision.

comment:5 Changed 10 years ago by alex3683

Thanks for your reply. I can totally understand that. On the other hand this bug annoyed me for about 2 days until I found the cause :) Anyway, for our company library I found a workaround and as long as jquery doesn't change too much this is sufficient for us. If you change your mind and want to fix this any time in the future, here's what I did: https://gist.github.com/2226446

comment:6 Changed 10 years ago by mikesherov

Thanks for that alex3683. I'll definitely keep it in mind.

Note: See TracTickets for help on using tickets.