Figure out why position tests are failing in IE8

[scottgonzalez]

http://swarm.jquery.org/result/325481

[Krinkle]

One thing that may be related is that position tests always have a very large gap on the bottom of the test page. This is due to this part of the fixture:

<div style="POSITION: absolute; WIDTH: 5000px; HEIGHT: 5000px"></div>

[dmethvin]

It's definitely a strange one, very similar to https://github.com/jquery/testswarm/commit/3288a9b7f38edaca8760991e90027be9aedb1095 .

[mikesherov]

Ill reiterate the run page shouldn't be styled. Leaky styles in IE8

[Krinkle]

That depends. One could argue it is a genuine bug in jQuery / IE8. If the offset returned by IE8 is wrong when it is inside an iframe (and it is not uncommon for iframes to be used on pages that have styling of some sorts), then perhaps jQuery should cover for that bug.

[mikesherov]

@Krinkle, sure. Cover and test for that bug in a controlled way, then. We shouldn't have to be worrying that our local testing environments are different from testswarm. We should strive to make them similar as possible.

[dmethvin]

If there's a way to account for it inside jQuery core that would be great. We can determine whether we're in an iframe via window.parent but if it depends on the parent's CSS, as it did above, we don't generally have access to that. A reduced test case would help of course. Several people tried doing that until @mikesherov somehow figured out that the font size in the parent caused the problem.

At the moment the fact that this really rare situation is only provoked by unit tests via Testswarm is preventing the automated tests from being useful. I don't think anyone has ever reported it in the field, so ideally we could get by without having to invest a lot more effort in tracking it down than we already have.

[mikesherov]

This was the closest thing I ever found to the problem. I caused it to suffer trac-o-bot's fate: http://bugs.jquery.com/ticket/8625

[Krinkle]

We shouldn't have to be worrying that our local testing environments are different from testswarm.

Sure, but this case it isn't a TestSwarm specific thing that is causing it. It is caused by a environmental factor that applies to a significant part of the internet. We just aren't testing for it in the test suite directly (yet).

[scottgonzalez]

Except that this is never reproducible on a normal page load. The failure only occurs through the BrowserStack API.

[Krinkle]

Except that this is never reproducible on a normal page load. The failure only occurs through the BrowserStack API.

Not quite, it is consistently reproducible on IE8 with Windows Vista and Windows 7 as long as the document is an inframe. For example: http://jsfiddle.net/mXruJ/. And not just on browserstack.

CrossBrowserTesting - Windows XP SP3 - IE8

BrowserStack - Windows XP - IE8

CrossBrowserTesting - Windows Vista - IE8

BrowserStack - Windows Vista - IE8

CrossBrowserTesting - Windows 7 - IE8

[scottgonzalez]

Aha, one of those rare situations where the OS comes into play. Good catch.

[mikesherov]

@Krinkle :clap:

[Krinkle]

Thanks :)

@scottgonzalez Indeed, needed a minute to figure it out as I had IE8 pre-selected under Windows XP in my browserstack account, and it was... passing (how dare IE8 pass the test suite). Then I noticed it was also listed under Windows Vista.

[jzaefferer]

@Krinkle just ran your fiddle in IE8 on Win7, and it passes. Win 7 Enterprise, 64bit.

@scottgonzalez doesn't want to just drop that test, so we need to fix it asap in order to start relying on swarm results again.

If anyone here has an idea on how to fix it, please please put in some time.

[danheberden]

Can this issue be moved to the bug tracker so we can close out the 2012-dev-summit issues?