Last modified: 2013-03-23 20:09:19 UTC
For several weeks now some unti tests continue to fail and pass at random. Initially we were seeing some IE VMs causing test failures due to what I think was a DLL error on the VMs side, however those have been solved.
This is not a bug on our side. When an IE browser window doesn't have focus (i.e. is not in the fore ground. Either minimized or another window in front of it) text can't be selected. Normally this isn't an issue (since a user can't click in a window that he can't see), but when testing en mass people often have a swarm client in the background. This can't be fixed on our end, we need to make sure people supporting the swarm with IE only do so with dedicated VMs or machines, not in the background.
Hm.. appears aside from the test failing if the window doesn't have focus, it also fails on the first "cold" (uncached) hit. I'm consistently seeing that when the jquery.textSelection test is loaded in IE6-8 it downloads a bunch of stuff and fails. Then when I refresh (and get lucky to get the same test again, TestSwarm tries up to 4 times to get a pass), it does pass. Re-opening, we really need to get this sorted out. It might be a valid failure.
Marking as blocking for 1.19.0, either this module is broken (in which case we have real problem for IE6-8 in WikiEditor etc.), or the unit test needs to be fixed.
Disabled the test in question in r113213, to be re-enabled when this bug is fixed (cc-ing brion since he knows more about the bug this test is associated with). Now we can at least use TestSwarm again in a normal way for IE (so far all IE columns were red that made it hard to detect a real regression).
Latest version appears to fail only in IE9 and IE10 (IE6-8 seem to have recovered).
Any relation to bug #40598 ?? (also, bumping to future).
(In reply to comment #6) > Any relation to bug #40598 ?? (also, bumping to future). No, unlikely to be related (other than that both are an exposition of Microsoft's talent to implement annoying bugs and keep them around for years)
In Opera 12 as well.
*** Bug 41931 has been marked as a duplicate of this bug. ***
I'm pretty sure that the Opera thing is not a dupe; I've only noticed it happening on Opera 12.10 (newest version, just released), and it seems to be caused by special-casing Opera in the tests (grep for "window.opera") - the failure is not a randomly thrown error, but wrong output (the insertion point seems to be shifted by one position, resulting in weirdness).
I know it isn't the same original issue (since Opera 12 is a recent version). However it exhibits the same behaviour.
(I looked into it and unmarked that bug as dupe.)
