Opened 8 years ago
Closed 8 years ago
#12008 closed bug (patchwelcome)
Element is reflowed once $.outerWidth(true) is called (when $.support.reliableMarginRight = false)
| Reported by: | Owned by: | mikesherov | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | dimensions | Version: | 1.7.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
We have problem on Android that calling outerWidth() on element resets its scrollTop position. This is done due to cssHook enabled while $.support.reliableMarginRight = false. cssHook changes display to inline-block, then somehow reflows the element (via curCss), in the end it changes position to previous value.
Below I attach fiddle with error caught - this is reproducable only on browsers without mentioned reliableMarginRight support, e.g. Android. http://jsfiddle.net/sjpqj/4
Change History (3)
comment:1 Changed 8 years ago by
| Owner: | set to mikesherov |
|---|---|
| Status: | new → assigned |
comment:2 Changed 8 years ago by
| Component: | unfiled → dimensions |
|---|
comment:3 Changed 8 years ago by
| Milestone: | None → 1.next |
|---|---|
| Priority: | undecided → low |
| Resolution: | → patchwelcome |
| Status: | assigned → closed |
Note: See
TracTickets for help on using
tickets.
As of right now, the only known way to overcome the reliableMarginRight issue is by setting the display of an element to inline-block. This unfortunately resets the scroll position of the element in question, amongst having other effects on layout.
If you know of a better way to get around this issue (that doesn't just solve your specific case of scroll position), I would love to hear it, and would gladly accept the patch.
In the meantime, you can overcome this by duckpunching $.support.reliableMarginRight = true, and losing the ability to accurately measure margin-right, or you can make sure your elements are inline-block to begin with.