Closed
Bug 780546
Opened 12 years ago
Closed 12 years ago
Add simple test for opening named windows inside mozbrowser
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: justin.lebar+bug, Assigned: justin.lebar+bug)
References
Details
Attachments
(1 file)
(deleted),
patch
|
mounir
:
review+
|
Details | Diff | Splinter Review |
I've had this test sitting around for a while, but it was failing intermittently for mysterious reasons. But I think when I fixed the other mozbrowser oranges, I fixed this one too. We should check it in. Patch in a moment.
Assignee | ||
Updated•12 years ago
|
Blocks: browser-api
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → justin.lebar+bug
Updated•12 years ago
|
Attachment #649168 -
Flags: review?(mounir) → review+
Assignee | ||
Comment 3•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/34a7d2909954
Comment 4•12 years ago
|
||
Backed out for causing bug 780761 one push after this landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/2ecf7d9b7580
Comment 5•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/34a7d2909954
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Assignee | ||
Comment 6•12 years ago
|
||
Except Ed backed this out...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 7•12 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #4) > Backed out for causing bug 780761 one push after this landed: > https://hg.mozilla.org/integration/mozilla-inbound/rev/2ecf7d9b7580 https://hg.mozilla.org/mozilla-central/rev/2ecf7d9b7580
Assignee | ||
Comment 8•12 years ago
|
||
This looks like yet another race condition initializing the message manager during window.open.
Assignee | ||
Comment 9•12 years ago
|
||
I don't see how this can be happening. 1) We must be hitting nsFrameMessageManager::SendAsyncMessageInternal's check if (mAsyncCallback) { NS_ENSURE_TRUE(mCallbackData, NS_ERROR_NOT_INITIALIZED); 2) If we're running code in BrowserElementParent.js for an OOP frame, that means nsFrameLoader::ShowRemoteFrame has run and tickled the remote-browser-frame-shown observer: mRemoteBrowser->Show(size); mRemoteBrowserShown = true; EnsureMessageManager(); nsCOMPtr<nsIObserverService> os = services::GetObserverService(); if (OwnerIsBrowserFrame() && os && !mRemoteBrowserInitialized) { os->NotifyObservers(NS_ISUPPORTS_CAST(nsIFrameLoader*, this), "remote-browser-frame-shown", NULL); mRemoteBrowserInitialized = true; } 3) So EnsureMessageManager() has been called with mRemoteBrowserShown == true. 4) ... which gives us very few reasons why the message manager's callback data should be null: nsresult nsFrameLoader::EnsureMessageManager() { NS_ENSURE_STATE(mOwnerContent); nsresult rv = MaybeCreateDocShell(); if (NS_FAILED(rv)) { return rv; } if (!mIsTopLevelContent && !OwnerIsBrowserFrame() && !mRemoteFrame) { return NS_OK; } if (mMessageManager) { if (ShouldUseRemoteProcess()) { mMessageManager->SetCallbackData(mRemoteBrowserShown ? this : nullptr); } return NS_OK; } 5) ...unless this message manager is not the message manager which is failing? Smaug, any pointers here would be appreciated.
Assignee | ||
Comment 10•12 years ago
|
||
> Smaug, any pointers here would be appreciated.
I think I have a handle on this now...
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6c7ed23db4b2
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•