Side navigation
#12008 closed bug (patchwelcome)
Opened July 03, 2012 02:47PM UTC
Closed August 19, 2012 07:47PM UTC
Element is reflowed once $.outerWidth(true) is called (when $.support.reliableMarginRight = false)
| Reported by: | tomasz@durka.pl | 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.
Attachments (0)
Change History (3)
Changed July 03, 2012 06:06PM UTC by comment:1
| owner: | → mikesherov |
|---|---|
| status: | new → assigned |
Changed July 12, 2012 01:57AM UTC by comment:2
| component: | unfiled → dimensions |
|---|
Changed August 19, 2012 07:47PM UTC by comment:3
| milestone: | None → 1.next |
|---|---|
| priority: | undecided → low |
| resolution: | → patchwelcome |
| status: | assigned → closed |
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.