978652 - Navigating while new Workers are queued causes all kinds of trouble

Status: VERIFIED FIXED

(Core :: DOM: Workers, defect)

Description

[Jesse Ruderman]

Attachment: testcase

When I load the testcase, one or more things goes wrong:


Crash [@ PresShell::ClearImageVisibilityVisited]

###!!! ASSERTION: This is unsafe! Fix the caller!: 'Error', file dom/events/nsEventDispatcher.cpp, line 447

[Exception... "Component returned failure code: 0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO) [nsIDOMJSWindow.frames]"  nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: resource://app/modules/sessionstore/FrameTree.jsm :: walk :: line 136"  data: no]

###!!! ABORT: How did we get here?  Are we failing to notify listeners that we should notify?: 'mDocument->IsBeingUsedAsImage()', file layout/base/nsPresContext.cpp, line 1909

JavaScript error: chrome://browser/content/tabbrowser.xml, line 3163: NS_ERROR_NOT_INITIALIZED: Component not initialized

Comment 1

[Jesse Ruderman]

###!!! ASSERTION: Inner window no longer correct!: 'outer && outer->GetCurrentInnerWindow() == mLoadInfo.mWindow', file dom/workers/WorkerPrivate.cpp, line 3526

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Can you try this again with the fix in bug 975695?

Comment 3

[Jesse Ruderman]

Attachment: testcase v2

This fixes the error "Constructor Worker requires 'new'".

Comment 4

[Jesse Ruderman]

With "testcase v2", I can reproduce the bug in an old build but not in a new one. So I guess bug 975695 fixed the problem :)

(I'm not sure when Worker was changed to require 'new'.)

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Bug 916644, probably.

Bobby, did we look at crashtest to see if this made any tests inoperative?

Comment 6

[Bobby Holley (:bholley)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #5)
> Bobby, did we look at crashtest to see if this made any tests inoperative?

We did not, no.

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

Marking verified as per Jesse's comment 4.

Comment 8

[Justin Wood (:Callek)]

c#4 suggests fixed by a bug which was fixed in gecko 29, c#5 suggests fixed in a bug which changed behavior/landed in gecko 30.

Either way, I'm not investing tons of time into this for SeaMonkey 2.26.1 which is based on Gecko 29, on the off chance c#4 is correct.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment 5 is a response to the bit in parentheses in comment 4.  This was probably fixed bug the bug referred to in comment 4.