606007 - TEST FAILED: test-panel.testResizePanel (timed out)

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect)

Description

[Ayan Shah[:ashah]]

SDK: 0.9RC2
Browser: FFx 4.0b6
Platform: Win 7

I ran my integration script against the RC2 and found the following error:

"TEST FAILED: test-panel.testResizePanel (timed out)"
This error was followed by a bunch of failures due to an incorrect number of windows being open.

Logs are available at http://pastebin.mozilla.org/822628

Note: FYI, The command that is executed from inside the integration script is:
"cfx testall -a firefox -b /Applications/Firefox4.0b6/Firefox.app"

Comment 1

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 2

[Alexandre Poirot [:ochameau]]

Attachment: Fix this bug on FF4b7 windows 7

Focus event doesn't fire in test script.
Now it does by calling blur before calling focus :-x

Comment 3

[Myk Melez [:myk] [@mykmelez]]

I'm having trouble reproducing this bug on my Windows 7 machine with both Firefox 4.0b7 and the latest nightly, although other tests fail.

Even if I could reproduce it, though, I'm a bit confused about the proposed fix, since that focus() call should only happen when the browser window is not active, and thus it should not be necessary to call blur() first to force the event to occur.

Why is it necessary to call blur() before focus() in this case?

Comment 4

[Alexandre Poirot [:ochameau]]

It always fails for me on win7 f4b7 when executing this from a plain windows command line:
> cfx test -f test-panel.js

It will success if you use your mouse to select the browser windows.
In fact, it seems to be a platform bug because if you try to type some text, it will appear in the command line when the test execution finish!
BrowserWindow seems to be already focused without being the most recent window, so the focus event is not dispatch without call to blur.
So with this patch, this event is dispatch no matter what platform bug we encounter.

Comment 5

[Alexandre Poirot [:ochameau]]

And to conclude: most recent window seems not necessary related to focused state.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #3)
> I'm having trouble reproducing this bug on my Windows 7 machine with both
> Firefox 4.0b7 and the latest nightly, although other tests fail.

Ok, I can now reproduce the problem on Firefox 4.0b7, 4.0b8, and the latest nightly.  I'm not sure why I wasn't seeing it before, since I didn't change much about my testing environment (except installing 4.0b8, updating to the latest nightly, and pulling the latest changes from the SDK repo).

But now, when I apply the patch, I get more failures:

--------------------------------------------------------------------------------
(Z:\myk\Projects\addon-sdk) Z:\myk\Projects\addon-sdk\packages\addon-kit>cfx test -f test-panel.js --binary="C:\Program
Files (x86)\Minefield\firefox.exe"
Using binary at 'C:\Program Files (x86)\Minefield\firefox.exe'.
Using profile at 'c:\users\myk\appdata\local\temp\tmpykia_b.mozrunner'.
Running tests on Firefox 4.0b9pre/Gecko 2.0b9pre ({ec8030f7-c20a-464f-9b0e-13a3a9e97384}) under WINNT/x86-msvc.
........error: An exception occurred.
Traceback (most recent call last):
  File "resource://addon-kit-addon-kit-lib/panel.js", line 228, in _onShow
    this._frameLoadersSwapped = true;
  File "resource://addon-kit-addon-kit-lib/panel.js", line 93, in null
    .swapFrameLoaders(this._viewFrame);
[Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIFrameLoaderOwner.swapFrameLoad
ers]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: resource://addon-kit-api-utils-lib/secu
rable-module.js -> resource://addon-kit-api-utils-lib/securable-module.js -> resource://addon-kit-addon-kit-lib/panel.js
 :: <TOP_LEVEL> :: line 93"  data: no]
console: Invalid use of the preferences on a background thread!
console: Invalid use of the preferences on a background thread!
console: [JavaScript Error: "Failed to decode base64 string!" {file: "jar:file:///C:/Program%20Files%20(x86)/Minefield/o
mni.jar!/components/nsUrlClassifierLib.js" line: 1193}]
console: Direct3D 9 DeviceManager Initialized Succesfully.
Driver: vm3dum.dll
Description: VMware SVGA 3D (Microsoft Corporation - WDDM)
Version: 7.14.1.42
error: TEST FAILED: test-panel.testResizePanel (timed out)
.error: fail: error was emitted:Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIFrameLoaderOw
ner.swapFrameLoaders]
undefined
info: Traceback (most recent call last):
  File "resource://addon-kit-addon-kit-lib/panel.js", line 231, in _onShow
    this._emit('error', e);
  File "resource://addon-kit-api-utils-lib/events.js", line 129, in _emit
    return this._emitOnObject.apply(this, args);
  File "resource://addon-kit-api-utils-lib/events.js", line 159, in _emitOnObject
    listener.apply(targetObj, params);
  File "resource://addon-kit-addon-kit-tests/test-panel.js", line 137, in null
    test.fail('error was emitted:' + e.message + '\n' + e.stack);
  File "resource://addon-kit-api-utils-lib/unit-test.js", line 113, in fail
    console.trace();
..............error: fail: The panel was resized.
info: Traceback (most recent call last):
  File "resource://addon-kit-addon-kit-lib/panel.js", line 215, in _onHide
    this._emit('hide');
  File "resource://addon-kit-api-utils-lib/events.js", line 129, in _emit
    return this._emitOnObject.apply(this, args);
  File "resource://addon-kit-api-utils-lib/events.js", line 159, in _emitOnObject
    listener.apply(targetObj, params);
  File "resource://addon-kit-addon-kit-tests/test-panel.js", line 84, in null
    "The panel was resized.");
  File "resource://addon-kit-api-utils-lib/unit-test.js", line 164, in assert
    this.fail(message);
  File "resource://addon-kit-api-utils-lib/unit-test.js", line 113, in fail
    console.trace();

22 of 25 tests passed.
FAIL
Total time: 23.561000 seconds
Program terminated unsuccessfully.
--------------------------------------------------------------------------------


(In reply to comment #4)
> In fact, it seems to be a platform bug because if you try to type some text, it
> will appear in the command line when the test execution finish!

Hmm, I don't seem to see that.


(In reply to comment #5)
> And to conclude: most recent window seems not necessary related to focused
> state.

Hmm, that's troubling. :-/

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 499172 [details] [diff] [review]
Fix this bug on FF4b7 windows 7

Marking r- just because it currently doesn't appear to solve the problem (or it creates new ones in the process), although it seems like it should work.  Perhaps there was a change in Firefox nightly builds since the patch was first submitted that broke the fix?

Comment 8

[Alexandre Poirot [:ochameau]]

> But now, when I apply the patch, I get more failures:
> 
> [Exception... "Component returned failure code: 0x80004001
> (NS_ERROR_NOT_IMPLEMENTED) [nsIFrameLoaderOwner.swapFrameLoad
> ers]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame
> :: resource://addon-kit-api-utils-lib/secu
> rable-module.js -> resource://addon-kit-api-utils-lib/securable-module.js ->
> resource://addon-kit-addon-kit-lib/panel.js
>  :: <TOP_LEVEL> :: line 93"  data: no]
We may fill another bug for this error, I noticed this error happens intermitently whether this patch is applied or not.
And during my work on bug 619991 I saw some race conditions that may lead to this error. (when iframe document is not ready and we already call this method)

I double checked for errors and I wasn't able to reproduce the original error.
I had some swapFrameLoad related errors, I was able to reproduce the original error when I played with my mouse/keyboard during the test execution. For example, pressing enter multiple times during test execution.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #8)
> We may fill another bug for this error, I noticed this error happens
> intermitently whether this patch is applied or not.
> And during my work on bug 619991 I saw some race conditions that may lead to
> this error. (when iframe document is not ready and we already call this method)

Yup, good point.  I have filed bug 624903 on this issue.  Can you describe the race conditions you noticed in a comment on that bug?


> I double checked for errors and I wasn't able to reproduce the original error.
> I had some swapFrameLoad related errors, I was able to reproduce the original
> error when I played with my mouse/keyboard during the test execution. For
> example, pressing enter multiple times during test execution.

Hmm, I'm not sure what's going on then.  I'm currently running Windows 7 in a VM, while you're running it on real hardware.  I guess that could make a difference if it's a timing issue.  We should really solve the problem in both cases, however.

I'll test on real hardware soon, and I'll also try Windows XP in a VM to see if the OS version makes a difference.

Comment 10

[Alexandre Poirot [:ochameau]]

Attachment: Yet another try to fix this test!

Another alternative to fix it, but I didn't test its behavior on linux! 
Instead of calling blur(), I use nsIWindowWatcher to get activeWindow which gives differents results from getMostRecentWindow(null) ...

And to follow the discussion we had on last meeting, I think this is one particular test that should not be executed by most developers.
Because theses tests are extremely sensitive to windows focus and active state.
In order to work properly and not throwing false alarms, we need to let the computer alone during this test execution.

Comment 11

[Myk Melez [:myk] [@mykmelez]]

Hmm, now that bug 624903 has landed, I can't reproduce this bug.  If I back out that fix, on the other hand, I can reproduce it again, but then this patch doesn't fix the problem on my Windows 7 VM (although things continue to work fine on Linux).

Do you still see the problem even with the fix for bug 624903?

Comment 12

[Alexandre Poirot [:ochameau]]

This is *really* weird! I'm always seing some difference with/without this patch.
It definitively gives this test stronger. 
Without:
I can easily make the test fail by clicking on cfx command line window during the test execution or simply pressing enter multiple times during the test.
With the last patch:
The test success even if if click on it very very fast.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 509111 [details] [diff] [review]
Yet another try to fix this test!

I was finally able to reproduce this on the train this morning!  Maybe it's something about the rails. ;-)  As soon as I issued the "cfx test" command, I started hitting return until the test and browser windows opened behind the console.  The test then timed out.  But after applying the patch, that doesn't happen anymore.

r=myk!

Comment 14

[Myk Melez [:myk] [@mykmelez]]

https://github.com/mozilla/addon-sdk/commit/a734b6b839f5f206d31c36b75b4365c674a97134