test-panel.testResizePanel fails "panel was resized" test

RESOLVED FIXED in 1.0b1

Status

RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: myk, Assigned: myk)

Tracking

unspecified
1.0b1

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment)

(Assignee)

Description

8 years ago
On the latest Firefox 4 nightly, test-panel.testResizePanel fails the "panel was resized" test:

error: TEST FAILED: test-panel.testResizePanel (failure)
error: fail: The panel was resized.
info: Traceback (most recent call last):
  File "resource://addon-kit-addon-kit-lib/panel.js", line 226, in _onHide
    this._emit('hide', this._public);
  File "resource://addon-kit-jetpack-core-lib/events.js", line 142, in _emit
    listener.apply(null, params);
  File "resource://addon-kit-addon-kit-tests/test-panel.js", line 54, in anonymous
    "The panel was resized.");
  File "resource://addon-kit-jetpack-core-lib/unit-test.js", line 196, in assert
    this.fail(message);
  File "resource://addon-kit-jetpack-core-lib/unit-test.js", line 145, in fail
    console.trace();

Hernán: do you know what might be going on here?
(Assignee)

Comment 1

8 years ago
The line number for the failing test in test-panel.js is slightly different now, but I suspect the failure is the same:

error: TEST FAILED: test-panel.testResizePanel (failure)
error: fail: The panel was resized.
info: Traceback (most recent call last):
  File "resource://addon-kit-addon-kit-lib/panel.js", line 226, in _onHide
    this._emit('hide', this._public);
  File "resource://addon-kit-jetpack-core-lib/events.js", line 142, in _emit
    listener.apply(null, params);
  File "resource://addon-kit-addon-kit-tests/test-panel.js", line 62, in anonymous
    "The panel was resized.");
  File "resource://addon-kit-jetpack-core-lib/unit-test.js", line 196, in assert
    this.fail(message);
  File "resource://addon-kit-jetpack-core-lib/unit-test.js", line 145, in fail
    console.trace();


Note: I can only reproduce this failure when I run all tests.  When I only run the panel tests, it doesn't show up.  And I can't reproduce on Mac or Windows.
Blocks: 604641

Updated

8 years ago
Component: Jetpack SDK → XPConnect
Product: Mozilla Labs → Core
QA Contact: jetpack-sdk → xpconnect
Target Milestone: -- → mozilla2.0b7
Version: unspecified → Trunk

Comment 2

8 years ago
Blocks a b7 blocker.

Same here, how do I run this test?
blocking2.0: --- → ?
(Assignee)

Comment 3

8 years ago
I see this when I run |cfx test| in the packages/addon-kit/ directory.

Updated

8 years ago
blocking2.0: ? → beta7+
Over to Myk for now, we need a reduced testcase here, please reassign appropriately.
Assignee: nobody → myk
OS: Linux → All
Hardware: x86 → All
(Assignee)

Comment 5

8 years ago
I've since run this test a bunch more times and observed test runs where the test did not fail, even when running all tests.  I have also observed a test run where the test did fail when running only panel tests.

So this looks like an intermittent timing-related failure rather than a regression from recent changes to GC compartments.  I'm not sure why it shows up on trunk but not b6.  Perhaps differences in the speed of interpretation under GC compartments reveal the timing-related error?

In any case, given the intermittence, this seems like a non-blocker and an SDK issue rather than a JS/XPConnect one.  Modifying and moving bug accordingly.
Assignee: myk → nobody
No longer blocks: 604641
Component: XPConnect → Jetpack SDK
Product: Core → Mozilla Labs
QA Contact: xpconnect → jetpack-sdk
Target Milestone: mozilla2.0b7 → 0.10
What I now see is this:

(jetpack-sdk)[jst@gandalf addon-kit]$ cfx test -F test --binary=/home/jst/work/tip/fb-rel/dist/bin/firefox
Using binary at '/home/jst/work/tip/fb-rel/dist/bin/firefox'.
Using profile at '/tmp/tmprvRQYd.mozrunner'.
Traceback (most recent call last):
  File "resource://addon-kit-addon-kit-lib/selection.js", line 233, in 
    off: function() this._removeAllListeners.apply(this, arguments)
  File "resource://addon-kit-jetpack-core-lib/traits.js", line 118, in Trait
    return self.constructor.apply(self, arguments) || self._public;
TypeError: self.constructor is undefined
No tests were run
FAIL
Total time: 4.091101 seconds
Program terminated unsuccessfully.

Which looks entirely different, and worse (?). I have fixes for bug 596031 and bug 607767 (newer patch than what's in the bug) in my tree.

Comment 7

8 years ago
(In reply to comment #5)

> In any case, given the intermittence, this seems like a non-blocker and an SDK
> issue rather than a JS/XPConnect one.  Modifying and moving bug accordingly.

This bug still is marked as b7 blocker -> https://bugzilla.mozilla.org/query.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=cf_blocking_20&query_format=advanced&type0-0-0=substring&value0-0-0=beta7&known_name=ff%20b7

Updated

8 years ago
Component: Jetpack SDK → XPConnect
Product: Mozilla Labs → Core
QA Contact: jetpack-sdk → xpconnect
Target Milestone: 0.10 → ---

Updated

8 years ago
blocking2.0: beta7+ → -

Updated

8 years ago
Component: XPConnect → Jetpack SDK
Product: Core → Mozilla Labs
QA Contact: xpconnect → jetpack-sdk
Target Milestone: --- → --
(Assignee)

Updated

8 years ago
Target Milestone: -- → 0.10

Updated

8 years ago
Component: Jetpack SDK → XPConnect
Product: Mozilla Labs → Core
QA Contact: jetpack-sdk → xpconnect
Target Milestone: 0.10 → ---

Updated

8 years ago
Component: XPConnect → Jetpack SDK
Product: Core → Mozilla Labs
QA Contact: xpconnect → jetpack-sdk
Target Milestone: --- → --

Updated

8 years ago
Target Milestone: -- → 0.10
(Assignee)

Comment 8

8 years ago
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".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
(Assignee)

Comment 9

8 years ago
I'm seeing this consistently again on Linux.

Ayan: can you reproduce on your Linux box?
(Assignee)

Comment 10

8 years ago
I dug into this a bit more, and one combination of tests that causes the test failure is context-menu and panel, i.e.:

  cfx test -F 'context-menu|panel'

There seem to be other combinations that cause the same failure, however, since merely excluding context-menu from the list of tests to run doesn't cause the failure to go away.

Also, it looks like the failure happens because the onHide handler gets called without the onShow handler ever getting called.  This suggests to me that a test in another test file is doing some work after that test has supposedly finished running, and that work has the side-effect of aborting the process of the panel being shown, such that the panel never finishes being shown (and thus never calls the onShow handler), but it does get hidden (and thus calls the onHide handler).
(Assignee)

Updated

8 years ago
Assignee: nobody → myk
Status: NEW → ASSIGNED
(Assignee)

Comment 11

8 years ago
Created attachment 491881 [details] [diff] [review]
patch v1: fixes problem

It turns out that the test fails when the window in which the panel is being shown is not the active window.  Activating the window before running the test solves the problem.
Attachment #491881 - Flags: review?(adw)

Comment 12

8 years ago
Comment on attachment 491881 [details] [diff] [review]
patch v1: fixes problem

Looks great.  But how do you know the browser in which the panel is displayed will be the most recent?  Could it be the case that the panel is shown in some other browser window that happens to be open?  Our tests make me weep.  Why does this one need a focused window but the others don't?  Or do they?  Should the harness automatically focus the most recent browser window before starting each test?
Attachment #491881 - Flags: review?(adw) → review+
(Assignee)

Comment 13

8 years ago
(In reply to comment #12)
> Looks great.  But how do you know the browser in which the panel is displayed
> will be the most recent?  Could it be the case that the panel is shown in some
> other browser window that happens to be open?

The Panel API automatically uses the most recent browser window if an anchor is not specified.


> Our tests make me weep.  Why
> does this one need a focused window but the others don't?  Or do they?  Should
> the harness automatically focus the most recent browser window before starting
> each test?

*sign* Indeed.  Such good questions.

https://github.com/mozilla/addon-sdk/commit/2d5d0b113476e111b51476eb69468c1e3cdacb54

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

(rebase/merge bungling)
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Target Milestone: 0.10 → 1.0b1
You need to log in before you can comment on or make changes to this bug.