With the fix on bug 757340 we have introduced a new regression which is intermittent. In some cases tests fail to switch to the target pane due to a timeout in our test. We probably should increase it. How long was the waiting time before? Remus, can you please take that?
We were using the default timeout (5s). So the waiting time is the same.
The problem is that with the no animation pref of the pref pane, nodeToProcess.style.opacity == 1 will always be false.
Why is that a problem? We do not rely on this CSS style in our test. Why should it then affect the waitFor() call?
That line is the one that makes the waitFor pass on Mac when we the animation is on.
We do not have the animation enabled! We pref it off before changing the panes. What we are waiting for is the target pane to be selected. There is no transition related code in here:
Please try if you can reproduce locally.
I was talking about this waitFor:
Yes, I can reproduce it locally.
Oh wow. Yes, those to lines have to be removed than.
What 2 lines? Please check the whole condtion.
(In reply to Remus Pop (:RemusPop) from comment #8)
> What 2 lines? Please check the whole condtion.
Those two lines you was talking about in comment 2. If you have problems please lets discuss this on IRC. This process here slows us down.
Created attachment 638686 [details] [diff] [review]
patch v1 (aurora)
The style is no longer affected if we don't have animation (which is disabled in the setter of paneId BTW) so I removed it.
Comment on attachment 638686 [details] [diff] [review]
patch v1 (aurora)
That works. Thanks for the patch!
Given that we do not have any tests running on default only which exercise this code path, I pushed it to default and aurora:
If that works I will land on the other branches soon.
Works fine for latest fi locale:
Pushed to other branches: