Bug Tracker

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#7986 closed bug (fixed)

Bug in $.support.boxModel if page has DIV-element CSS

Reported by: ALLPRO Owned by:
Priority: high Milestone: 1.7.2
Component: support Version: 1.4.4
Keywords: Cc:
Blocked by: #10413 Blocking:


I have a demo page for a plugin that, for simplicity, has a CSS rule like this...

div { padding: 15px; border: 1px solid #999; }

This div rule BREAKS jQuery's $.support logic. The existing jQuery 1.4.4 code is like this...

div.style.width = div.style.paddingLeft = "1px";
jQuery.support.boxModel = div.offsetWidth === 2;

Because ONLY the leftPadding is specifically set, the DIV inherits defaults for other settings, which causes boxModel, inlineBlockNeedsLayout and shrinkWrapBlocks to be set WRONG in every browser.

It is not common for DIVs to have default styling set, but it is not unreasonable either. Therefore jQuery should handle this use-case by *specifically setting all relevant styles* to avoid errors - ie...

var s = div.style
s.width = s.padding = "1px";
s.border = 0; s.overflow = "hidden";
jQuery.support.boxModel = div.offsetWidth === 3;

In the sample above, padding is applied both left & right, so all tests in this section must be changed from '===2' to '===3'. OR paddingRight could be set to 0, but this requires extra code.

This may be a rare bug, but it takes less than a minute to fix it, so hopefully it won't be ignored.

Change History (15)

comment:1 Changed 6 years ago by jitter

Component: unfiledsupport
Milestone: 1.next1.5
Priority: undecidedblocker
Status: newopen

This test case shows which support properties are affected (in the browser you opened the test case)

comment:2 Changed 6 years ago by john

Milestone: 1.51.next
Priority: blockerhigh

We'll tackle this in the next release, not a blocker.

comment:3 Changed 6 years ago by Rick Waldron

Owner: set to AaronAsAChimp
Status: openassigned

comment:4 Changed 6 years ago by ajpiano

Milestone: 1.next1.7

comment:5 Changed 6 years ago by dmethvin

Owner: changed from AaronAsAChimp to dmethvin

comment:6 Changed 6 years ago by dmethvin

Milestone: 1.71.8

Moving to 1.8 for a comprehensive solution.

comment:7 Changed 5 years ago by dmethvin

Owner: dmethvin deleted
Status: assignedopen

comment:8 Changed 5 years ago by dmethvin

Blocked by: 10413 added

comment:9 Changed 5 years ago by mikesherov

#5520 is a duplicate of this ticket.

comment:10 Changed 5 years ago by Mike Sherov

Resolution: fixed
Status: openclosed

Fix #7986. $.support.boxModel shan't be fooled by page-level CSS.

Changeset: a52391aa1dcf3f28306e274e1b2d7f0affc4e725

comment:11 Changed 5 years ago by dmethvin


comment:12 Changed 5 years ago by mikesherov

#11390 is a duplicate of this ticket.

comment:13 Changed 5 years ago by ALLPRO

The 'fix' to this issue has created a more serious boxModel bug. Now ALL browsers loading a page without a doctype (aka quirks-mode, aka document.compatMode === "CSS1Compat") report $.support.boxModel = false. This is incorrect as non-IE browsers do NOT use the IE box-model in quirks mode. It seems that the correct code should be:

jquery-1.7.2 - line 1455

jQuery.boxModel = support.boxModel = (!jQuery.browser.msie || document.compatMode === "CSS1Compat");

This is a serious bug as any code using $.support.boxModel to decide how to measure and size elements is now broken.

comment:14 Changed 5 years ago by dmethvin

jQuery doesn't support Quirks Mode. http://docs.jquery.com/Won't_Fix#Quirks_Mode

comment:15 Changed 5 years ago by ALLPRO

"jQuery doesn't support Quirks Mode"

Then there would not be a $.support.boxModel property that purports to do so. This is the reason the $.support object exists in the first place. If the code cannot determine what boxModel is in use, how can it be properly handled?

$.boxModel / $.support.boxModel have provided this information since the early versions of jQuery - right up to jQ 1.7.1. The previous boxModel test (create and measure a padded div) made it clear this was the ONLY REASON $.support.boxModel existed. Changing the purpose of this basic property now - without notification - would be ludicrous. It must either be fixed or deprecated.

Note: See TracTickets for help on using tickets.