628112 - test-windows.testWindowTabsObject fails with Firefox 4.0b10pre

Status: RESOLVED WORKSFORME

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

Description

[Nickolay_Ponomarev]

With Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre (http://hg.mozilla.org/mozilla-central/rev/16bd82195df8) and the latest addon sdk (https://github.com/mozilla/addon-sdk/commit/0f9e14ea9d9f3251cbe925e2b69facd31376be8a) a test now fails:

.../packages/addon-kit $ cfx test -f test-windows -v

...
info: executing 'test-windows.testWindowTabsObject'
console: [JavaScript Error: "[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: FullZoom_destroy :: line 185"  data: no]" {file: "chrome://browser/content/browser.js" line: 6841}]
console: [JavaScript Error: "uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: BrowserShutdown :: line 6844"  data: no]"]
info: pass: Only 1 tab open
info: pass: New tab open
info: pass: Correct new tab title
info: pass: Correct active tab
info: pass: Correct title
info: pass: Correct title
console: [JavaScript Error: "uncaught exception: TypeError: "use strict";tab is undefined"]
error: TEST FAILED: test-windows.testWindowTabsObject (timed out)

I suspect this is due to a change in Firefox rather than in the SDK, since this test now fails with older addon sdk revisions as well. I didn't test older Firefox nightlies, sorry.

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I've run into similar issue when working on Bug 628314 on nightly. It seems that Object.getOwnPropertyNames misbehaves when called with objects from other compartments. Here is a little example to reproduce this bug:

var desc = { foo: { value: "bar" } };
var object = Components.utils.evalInSandbox('Object.create({}, desc);', Components.utils.Sandbox('http://mozilla.com'));
Object.getOwnPropertyNames(object).length === Object.getOwnPropertyNames(Object.create({}, desc))

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Created a bug report for js-engine https://bugzilla.mozilla.org/show_bug.cgi?id=628333

Comment 3

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

It looks like this isn't bug 628333 after all, as that bug is an older regression from the original compartments merge, whereas this problem only started occurring on January 21.

Presumably it is being caused by a regression from this tracemonkey merge, although it isn't clear exactly which change(s) cause it:

http://tbpl.mozilla.org/?rev=aa618e93942e

Unfortunately, the resolution on the error message is also really low: there is no filename or line number to reference, so it's hard to figure out what is going on. :-(

Comment 4

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

Attachment: patch v1: resolves problem [never checked in]

It looks like a recent change to the treatment of "use strict" exposes a problem in which an item in the list of tabs tracked by a window is not defined when the window is being closed.

This fix doesn't resolve the problem that the item is not defined, but it resolves the test failure by checking each item before trying to use it.  We should track and figure out the problem that the item is not defined in a separate bug.

Comment 5

[Brian Warner [:warner :bwarner]]

Comment on attachment 506767 [details] [diff] [review]
patch v1: resolves problem [never checked in]

The patch looks safe, and applying it makes one error message go away:

  console: [JavaScript Error: "uncaught exception: TypeError: "use strict";tab is undefined"]

However I still see the same unit test failing through timeout:

 error: TEST FAILED: test-windows.testWindowTabsObject (timed out)
 4263 of 4264 tests passed.
 FAIL

against the latest minefield (4.0b10pre 2011-01-25). There's nothing
glaringly obvious in the test noise, but I can attach it if you think it'd
help.

So r+ from me (can't hurt) but I don't think it resolves the problem.

Comment 6

[Brian Warner [:warner :bwarner]]

Now that the moz-central buildbot is pulling from the right place (bug 627604), it looks like it's red because of this bug. I'm looking at the tail end of http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1296067575.1296067769.27771.gz&fulltext=1 which ran a couple of hours ago on linux.

Comment 7

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

Hmm, I see this timeout too, but intermittently.  I think that's bug 599204, which is being masked by this bug.  So I'll land this patch, and then we can figure out the timeout in that bug.

Comment 8

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

Erm, sorry, no, I'm wrong, bug 599204 is about a timeout in test-window-utils.testActiveWindow, whereas you reported a timeout in test-windows.testWindowTabsObject.  Hmm, so far I haven't been able to reproduce that one.

Comment 9

[Brendan Eich [:brendan]]

TypeError: "use strict";tab is undefined

Yikes. Cc'ing jimb. This looks like a bug recently introduced (which I should have foreseen) where decompiling for blame wrongly inserts "use strict"; if the code being blamed is strict.

Jim, could you please file? I'll review quickly.

/be

Comment 10

[Brendan Eich [:brendan]]

(Comment 9 is a spin-off from comment 5, unrelated to this bug, sorry for dropping it here.)

Comment 11

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

(In reply to comment #9)
> Jim, could you please file? I'll review quickly.

Once you file, can you reference that bug number here?  It's unclear what we need to do here, so I'd like to follow any progress fixing that bug and test its prospective patches for their effects on this test.

Comment 12

[Jim Blandy :jimb]

(In reply to comment #9)
> Jim, could you please file? I'll review quickly.

Filed as bug 629723.

Comment 13

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

Nickolay: can you still reproduce this?

Comment 14

[Nickolay_Ponomarev]

> Nickolay: can you still reproduce this?
No, the tests were passing with later Firefox 4 builds for a while now.