Closed Bug 527074 Opened 15 years ago Closed 15 years ago

random failures in sessionstore/test/browser/browser_526613.js, then timeout

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3.7a1
Tracking Flags:
Tracking Status
status1.9.2 --- beta3-fixed

People

(Reporter: dholbert, Assigned: dao)

References

Details

(Keywords: intermittent-failure, Whiteboard: [in-litmus-bug-week])

Attachments

(3 obsolete files) 

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257532723.1257534392.20573.gz
WINNT 5.2 mozilla-central opt test everythingelse on 2009/11/06 10:38:43

{
Running chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js...
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Only one browser window should be open initially - Got 2, expected 1
TEST-PASS | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | The sessionstore-browser-state-restored notification was observed
TEST-PASS | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Two windows should exist at this point
TEST-INFO | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Console message: [JavaScript Error: "[Exception... "'JavaScript component does not have a method named: "notify"' when calling method: [nsITimerCallback::notify]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "<unknown>"  data: no]"]
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Timed out
}
Whiteboard: [orange]
Hmm, perhaps related to Mak's latest push to fix bug 518970. These tests have too many problems...
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257535507.1257537577.25626.gz
WINNT 5.2 mozilla-central opt test everythingelse on 2009/11/06 11:25:07

Same failure twice in a row on that column --> Maybe not sporadic... maybe Paul's on to something in comment 1?
Marco, can you back out http://hg.mozilla.org/mozilla-central/rev/fc4702c75a04 ?
I agree with Paul that's the most probable cause of this, at this point.
Summary: sessionstore/test/browser/browser_526613.js fails a test and then times out → failure in sessionstore/test/browser/browser_526613.js: "Only one browser window should be open initially - Got 2, expected 1", then timeout
(In reply to comment #4)
> Marco, can you back out http://hg.mozilla.org/mozilla-central/rev/fc4702c75a04
> ?
> I agree with Paul that's the most probable cause of this, at this point.

Reverted with http://hg.mozilla.org/mozilla-central/rev/f05767494de2. If it goes green, then that was probably it.

As a side not, the opt builds have been giving us problems, with sessionstore tests on Windows especially.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257548618.1257551067.15003.gz
WINNT 5.2 mozilla-central opt test everythingelse on 2009/11/06 15:03:38

This was pre-backout
please annotate any change in Windows Eo build, since what happened is really really interesting. If touching browser_394759.js has caused a test that is about 33 tests later (all passed) we have lot of new data.
ugh, this test always fails for me

Running chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js...

TEST-PASS | chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js | Only one browser window should be open initially

TEST-INFO | chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js | Console message: [JavaScript Error: "uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.clearUserPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://dotnetassistant/content/bootstrap.js :: BootStrapDotNetAsssitantExtension :: line 52"  data: no]"]

TEST-PASS | chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js | The sessionstore-browser-state-restored notification was observed

TEST-PASS | chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js | Two windows should exist at this point

TEST-PASS | chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js | The sessionstore-browser-state-restored notification was observed

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/../browser/browser/components/sessionstore/test/browser/browser_526613.js | Only one window should exist after cleanup - Got 2, expected 1
nevermind, working correctly after an hg pull :\
no, randomly failing again, man these tests are crazy.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257610986.1257618981.12544.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2009/11/07 08:23:06
hm, looks like my cleanup was not involved, notice my comments in bug 526613, these failures are expected... and i think if we could make the notification better, we could solve randomness in ss tests using it.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257682347.1257685562.3525.gz
Linux mozilla-central opt test everythingelse on 2009/11/08 04:12:27
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257711805.1257719485.1412.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2009/11/08 12:23:25  

(though I just noticed that the last three I mentioned were all "Only one window should exist after cleanup" rather than the "should be open initially" of comment 0)
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Only one window should exist after cleanup - Got 2, expected 1

Linux mozilla-central opt test everythingelse on 2009/11/08 23:09:42

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257750582.1257754141.14583.gz&fulltext=1
Attached patch proposal patch v1.0 (obsolete) — — Splinter Review 
this is my proposal, but i don't know ss code deeply.

The only "warning" change is in _sendRestoreCompletedNotifications, i don't know if we could end up calling that method with _restoreCount == 0 and not willing to notify anything.
Paul you know this code better, can you please check if this is fine?
Attachment #411164 - Flags: review?(paul)
includes some cleanup and changes to other 2 tests using setBrowserState, that should wait the notification.
Attachment #411166 - Flags: review?(paul)
Attached patch proposal patch v1.1 (obsolete) — — Splinter Review 
fixed a small glitch: don't decrease restoreCount if the notification call comes from domwindowclosed. should not be hit since the notification comes later, but just in case.
Attachment #411164 - Attachment is obsolete: true
Attachment #411171 - Flags: review?(paul)
Attachment #411164 - Flags: review?(paul)
Hmm, failing on branch shortly after it got checked in there.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1257803684.1257807632.16950.gz
Linux mozilla-1.9.2 test everythingelse on 2009/11/09 13:54:44

Marco - I'll take a look at reviewing that after I finish up some blocker work. Things look OK after a quick look, but I'll take a closer look soon.
changing title since looks like this covers 2 failures:
"Only one window should exist after cleanup - Got 2, expected 1"
"Only one browser window should be open initially"
Summary: failure in sessionstore/test/browser/browser_526613.js: "Only one browser window should be open initially - Got 2, expected 1", then timeout → random failures in sessionstore/test/browser/browser_526613.js, then timeout
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257831842.1257835534.9686.gz
Linux mozilla-central opt test everythingelse on 2009/11/09 21:44:02
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257852413.1257861566.22438.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2009/11/10 03:26:53
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257850991.1257860571.9533.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2009/11/10 03:03:11
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257837295.1257847605.17533.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2009/11/09 23:14:55
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257986345.1257990534.32074.gz
Linux mozilla-central opt test everythingelse on 2009/11/11 16:39:05
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257992626.1257996405.31910.gz
Linux mozilla-central opt test everythingelse on 2009/11/11 18:23:46
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258003723.1258007508.25000.gz
Linux mozilla-central opt test everythingelse on 2009/11/11 21:28:43
(In reply to comment #20)
> changing title since looks like this covers 2 failures:
> "Only one window should exist after cleanup - Got 2, expected 1"
> "Only one browser window should be open initially"

If "Only one browser window should be open initially" fails, this indicates that there's a problem with a test that runs before this one.
OS: Windows NT → All
Hardware: x86 → All
I get "Only one window should exist after cleanup - Got 2, expected 1" every single time even when running browser_526613.js alone. Apparently it counts already-closed windows...
This should fix it, at least it did so for me locally:

http://hg.mozilla.org/mozilla-central/rev/9eeafcb0fc7d
Assignee: nobody → dao
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
(In reply to comment #28)
> (In reply to comment #20)
> If "Only one browser window should be open initially" fails, this indicates
> that there's a problem with a test that runs before this one.

indeed the above problem is due to previous tests using SetBrowserState, my patches above fix all tests to use the new notification

(In reply to comment #29)
> I get "Only one window should exist after cleanup - Got 2, expected 1" every
> single time even when running browser_526613.js alone. Apparently it counts
> already-closed windows...

indeed, my patch above fixes the notification to fire after windows have been closed. Actually SetBrowserState calls window.close() and does not bother checking whether they are closed or not. To provide reliable env we must be sure the state is completely set.

This is not fixed, your fix is just a workaround, we need a reliable notification.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is not a bug in session restore code, if anything it's a bug in nsIWindowMediator::get*Enumerator. This could happen in any other non-session-restore test as well. As far as I can tell, the test is entirely fine, except for the bogus browserWindowsCount return value.
i don't think it's a bug in windows.getEnumerator at all, it is doing its work correctly, if a window is still open, even if it's closing, it should correctly report it.

But the notification we fire happens in the middle of setting a state, new windows have been opened but old windows have not yet been closed, so the required state has not been set.
consider also that this means in optimized builds it's really likely that next tests will run while windows from previous tests still exist, and this is even worst.
Most tests don't care about other windows, and those that do need to use waitForFocus, use the workaround that I pushed or something similar (depending on what they actually do). This is generally the case when we close windows, not just when session restore closes windows.
session restore internally uses windows.GetEnumerator to save states, privatebrowsing uses the notification to consider the state correctly saved.
These 2 toghether are scary enough with a bogus notification.
Generally, i don't see the point of firing bogus notifications if we can fire reliable ones, if the notification tells me "the state has been restored" i think so.
Which notification used by private browsing are you exactly referring to?
sessionstore-browser-state-set the one added with bug 526613 and needed for bug 526194
Right, so I don't know what private browsing is actually going to do with this. Usually and regardless of whether session restore is involved, it doesn't matter that close() isn't entirely synchronous, except for a few tests.
(In reply to comment #33)
> i don't think it's a bug in windows.getEnumerator at all, it is doing its work
> correctly, if a window is still open, even if it's closing, it should correctly
> report it.

Why would you consider a window as still open if window.closed is true?
because getEnumerator does not talk about "open" windows, it will enumerate all existing windows, open or closing, when .closed is set the window object still exists so it's correctly enumerated. Otherwise should exist a GetOpenWindowsEnumerator.
Actually sessionstore should also probably not count windows with .closed set in its getEnumerator use, since only open windows should matter for it.
Yeah, so the solution is to not use getEnumerator as if it returned only open windows.
i think both: the notification should take in count the time needed to close windows before saying "we are done", and ss should stop thinking getEnumerator will return only open windows. The former has patches above, the latter needs to be addressed still.
(In reply to comment #43)
> i think both: the notification should take in count the time needed to close
> windows before saying "we are done", and ss should stop thinking getEnumerator
> will return only open windows.

This is likely over-engineering it, unless the not-yet-existing private browsing code absolutely depends on it, which I don't know but doubt. As soon as window.closed is true, it seems sane to consider it closed and move on.
(In reply to comment #44)
> (In reply to comment #43)
> > i think both: the notification should take in count the time needed to close
> > windows before saying "we are done", and ss should stop thinking getEnumerator
> > will return only open windows.
> 
> This is likely over-engineering it, unless the not-yet-existing private
> browsing code absolutely depends on it, which I don't know but doubt. As soon
> as window.closed is true, it seems sane to consider it closed and move on.

As long as sessionstore saves the state for windows for which window.closed is true, the private browsing service has to assume that those are still existing windows, and has to handle them.  If sessionstore code is fixed to take window.closed into consideration, then the private browsing service doesn't need to worry about such windows.
I was referring to the first part about the notification. I also think window.closed should be checked where sessionstore uses getEnumerator. We should file a bug for that, it might be relevant for tests at least and responsible for existing oranges.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258013970.1258017236.1576.gz
Linux mozilla-central opt test everythingelse on 2009/11/12 00:19:30  

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258023410.1258027342.19012.gz
Linux mozilla-central opt test everythingelse on 2009/11/12 02:56:50
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258025992.1258036508.31851.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2009/11/12 03:39:52
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258038504.1258042100.30018.gz
Linux mozilla-central opt test everythingelse on 2009/11/12 07:08:24
s: moz2-linux-slave12
Comment 47-49 seem to be before I pushed the fix.

However, there's another intermittent fatal failure on Linux, because executeSoon isn't enough to make sure the window is focused... Pushed this for that:
http://hg.mozilla.org/mozilla-central/rev/6562fee0aaa8
(In reply to comment #50)
> However, there's another intermittent fatal failure on Linux,

This one:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258034955.1258041595.24158.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258050282.1258055157.19862.gz
Linux mozilla-central opt test everythingelse on 2009/11/12 10:24:42  
s: moz2-linux-slave02
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258052542.1258056346.1297.gz
OS X 10.5.2 mozilla-central opt test everythingelse on 2009/11/12 11:02:22  
s: moz2-darwin9-slave02
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258052328.1258056633.4864.gz
Linux mozilla-central opt test everythingelse on 2009/11/12 10:58:48  
s: moz2-linux-slave23
And another fix for faster builds / machines, broken by the previous fix: http://hg.mozilla.org/mozilla-central/rev/8c387f11fda1
After that push, we have http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258071130.1258076770.6931.gz which... appears to get clear of the browser_526613.js test, while maybe leaving things screwed up so that browser_420786.js, which apparently hasn't ever had a timeout problem before, gets screwed up? Not sure.
And http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258083619.1258087918.1019.gz which looks the same, and http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258069827.1258082398.6282.gz from a debug run, which may or may not have looked the same, before it got to the amusing "Output exceeded 52428800 bytes, remaining output has been truncated"
Attachment #411166 - Flags: review?(zeniko)
Comment on attachment 411166 [details] [diff] [review]
changes to other tests to use the notification

Simon is also a valid reviewer here.
Attachment #411171 - Flags: review?(zeniko)
Comment on attachment 411171 [details] [diff] [review]
proposal patch v1.1

From the discussion above I'm not quite clear whether it'd be possible to simply fix _forEachBrowserWindow to not run for .closed windows (and making sure that the same applies to _getMostRecentBrowserWindow). If it is, I'd prefer that simpler fix.
Comment on attachment 411166 [details] [diff] [review]
changes to other tests to use the notification

Could you please split this patch in two: one part for the actually required changes and another for the code cleanup that seems to account for most of the changes? That would make reviewing just so much easier.

E.g. I'm not quite sure whether the following change is required or unneeded:

>-  // Remove the sessionstore.js file before setting the interval to 0
>+  // Remove the sessionstore.js file before setting the interval to a low value.
(In reply to comment #56)
> After that push, we have
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258071130.1258076770.6931.gz
> which... appears to get clear of the browser_526613.js test, while maybe
> leaving things screwed up so that browser_420786.js, which apparently hasn't
> ever had a timeout problem before, gets screwed up? Not sure.

Yes, this is still the same problem: the current window gets closed. However, since I can't reproduce this anymore, I'm not sure in which case it's happening. Pushed this to get that info, and also added a test for window.closed in order to get a useful short summary for this failure: http://hg.mozilla.org/mozilla-central/rev/bdf042d88199
Ok, I could reproduce it now. It still happened in the window == fm.activeWindow case, despite the execute soon. Apparently it takes some time until getMostRecentWindow points to fm.activeWindow. So I've replaced this with a pattern that takes this into account:

http://hg.mozilla.org/mozilla-central/rev/56a5e6edac31
Depends on: 528440
Filed bug 528440 for checking window.closed in nsSessionStore.js when using the window mediator.
(In reply to comment #62)
> Ok, I could reproduce it now. It still happened in the window ==
> fm.activeWindow case

Linux mozilla-central opt test everythingelse confirms this:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258098806.1258103499.9561.gz
(In reply to comment #59)
> (From update of attachment 411171 [details] [diff] [review])
> From the discussion above I'm not quite clear whether it'd be possible to
> simply fix _forEachBrowserWindow to not run for .closed windows (and making
> sure that the same applies to _getMostRecentBrowserWindow). If it is, I'd
> prefer that simpler fix.

if you read the discussion above, you'll find we have different ideas about this.
Fixing _forEachBrowserWindow is for sure correct, bug 528440 is about that, but we still fire a notification that setBrowserState has finished when it has not since some window is still closing.

I could for sure split the "other-tests" patch, but at this point if we don't fix the notification i don't see valid reasons to make other tests use it.
i think i'll leave this bug to dao, so he can eventually mark as fixed, file new bugs about making tests wait for the notification and make the notification reliable, and let you take a decision about what to wontfix/take among those bugs. So i'll stop spamming here.
Attachment #411166 - Attachment is obsolete: true
Attachment #411166 - Flags: review?(zeniko)
Attachment #411166 - Flags: review?(paul)
Attachment #411171 - Attachment is obsolete: true
Attachment #411171 - Flags: review?(zeniko)
Attachment #411171 - Flags: review?(paul)
filed bug 528451 and bug 528452, while bug 528440 will cover window.closed
Ok, I think the random orange is actually fixed now.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
No longer depends on: 528440, 528451, 528452
Interesting failure on 1.9.2:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1258127784.1258130695.5411.gz

Thousands of "waiting for the current window to become active" messages, then a timeout, and then it passes after browser_nsIDownloadManagerUI.js which calls window.focus. I'll probably add window.focus() here, although I don't know why it would only be needed sometimes.
(In reply to comment #70)
> Interesting failure on 1.9.2:
> 
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1258127784.1258130695.5411.gz
> 
> Thousands of "waiting for the current window to become active" messages, then a
> timeout, and then it passes after browser_nsIDownloadManagerUI.js which calls
> window.focus. I'll probably add window.focus() here, although I don't know why
> it would only be needed sometimes.

Pushed only to 1.9.2 for now: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0cd5ad553171
Flags: in-testsuite+
(In reply to comment #71)
> (In reply to comment #70)
> > Interesting failure on 1.9.2:
> > 
> > http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1258127784.1258130695.5411.gz
> > 
> > Thousands of "waiting for the current window to become active" messages, then a
> > timeout, and then it passes after browser_nsIDownloadManagerUI.js which calls
> > window.focus. I'll probably add window.focus() here, although I don't know why
> > it would only be needed sometimes.
> 
> Pushed only to 1.9.2 for now:
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0cd5ad553171

Landed on mozilla-central, as I've seen the same thing locally a few minutes ago.
http://hg.mozilla.org/mozilla-central/rev/f09961c1d5fa
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258216470.1258219721.9160.gz#err0
WINNT 5.2 mozilla-central opt test everythingelse on 2009/11/14 08:34:30
"s: moz2-win32-slave26"

Running chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js...
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Only one browser window should be open initially - Got 3, expected 1
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Two windows should exist at this point - Got 3, expected 2
TEST-INFO | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | waiting for the current window to become active
command timed out: 1200 seconds without output

Reopen, or start fresh? I'm sort of bored with this bug, a new number might be nice.
Marco, could your changes in bug 528452 have caused this?
I backed out the change from bug 528452.
Next push after that backout:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258254597.1258257623.5121.gz#err1
WINNT 5.2 mozilla-central opt test everythingelse on 2009/11/14 19:09:57
"s: moz2-win32-slave40"

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_459906.js | rich textarea's content correctly duplicated - Got <br>, expected <b>Unique:</b> 1258255338517
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Only one browser window should be open initially - Got 3, expected 1
buildbot.slave.commands.TimeoutError: command timed out: 1200 seconds without output
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #76)
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js
> | Only one browser window should be open initially - Got 3, expected 1

There's nothing that this test did at that point, so it must be from a test that runs before this one and doesn't close the window properly... Since this is also new, I suspect it's the other landing from bug 528452.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
I filed bug 528776 for this
Is this the same failure mode?
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1274792293.1274793123.4227.gz
it repeats the TEST-INFO line a bunch of times:
TEST-INFO | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | waiting for the current window to become active
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_526613.js | Timed out
Comment 81 is the same failure as comment 79; if those are not this bug, is there another bug for them, possibly one which needs its summary tweaked to help it show up in tbpl's starring helper?
Flags: in-litmus-
Whiteboard: [orange] → [orange][in-litmus-bug-week]
Whiteboard: [orange][in-litmus-bug-week] → [in-litmus-bug-week]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: