Please provide a distilled and reduced jsFiddle test case, thanks!

Automatically closed due to 14 days of inactivity.

*bump*

Still broken, (os x 10.6 Safari 5.0.4)

#5134 is a duplicate of this ticket.

#3092 is a duplicate of this ticket.

test case. It looks like actually the value of margin-right in webkit/chrome is borked.

That's actually the way webkit handles display: block (as in divs). If something needs that property, it means put it on a line by itself. All browsers do this by giving the element (let's call it element A) full width so that it spans the full width of the element it is relative to in order to knock its next sibling down below, which we've all probably noticed when hovering over an H1 or something in web inspector/firebug and saw that it spanned the whole window. However, if you specify a width for element A, browsers need to do something else. The solution webkit chose was give it the necessary margin on the right to accomplish the same thing, regardless of whether the user specifies a margin-right because it ''usually'' won't matter style-wise if it's display block and all proceeding elements go below.

There is an addendum. If the element is display: block; margin-right: 3px; AND float: left; the element MUST keep its margin. You will see that if you add float: left to your #inner in the test case above, you will get the correct outerWidth. This is not a jQuery bug, but a choice on how to implement display: block in webkit.

Regardless, a possible solution would be to float the element in any direction just long enough to get the correct margins, then put it back to what it was before. I went ahead and made a pull request that utilizes swap in getWH in css.js, and added a test in the dimensions component.

Pull request

#8207 is a duplicate of this ticket.

I think the issue I'm working on relates to this. #4146

https://github.com/jboesch/jquery/commit/bc80f2990741891180d64605d750deaf5cdf9b8c

It's not 100% done, tests pass everywhere except 3 in IE7. Still fixing it up.

I landed a fix for ticket #4146 which I believe fixes this bug as well:

http://bugs.jquery.com/ticket/4146

https://github.com/jquery/jquery/pull/253/files

I belive this issue is WebKit only and fixed in nightlies since Feb 2011

• webkit bug: https://bugs.webkit.org/show_bug.cgi?id=13343
• chromium bug: http://code.google.com/p/chromium/issues/detail?id=23816

• pure JS test case: http://jsfiddle.net/rdworth/XMgur/2/
• jQuery 1.5.1 test case: http://jsfiddle.net/rdworth/JWqAK/1/

As this issue is WebKit only I think #8443 should be reopened and removed as a duplicate. The test case on #8443 shows an issue in both Safari and IE9. The test cases here (mine and jitter's) show an issue in Safari but not IE9.

This issue is blocking a regression in jQuery UI 1.8.11 http://bugs.jqueryui.com/ticket/7084

The best workaround I've found is to set display:inline-block on the element temporarily in order to get the correct computed margin-right value. Though I've only tested so far in Safari 5 on Windows.

• Demo of workaround: http://jsfiddle.net/rdworth/bRyDW/

See: http://bugs.jquery.com/ticket/3333 and http://bugs.jqueryui.com/ticket/7084

Added css hook to work around bug in WebKit computed margin-right. Fixes #3333 - .css("marginRight") is incorrect in WebKit

Changeset: c3c507e900fceb419628157504004ab2813b7d01

related: http://bugs.jquery.com/ticket/11584