Closed
Bug 90067
Opened 23 years ago
Closed 23 years ago
document.write() fails when targeted at new window, mfcembed only
Categories
(Core :: DOM: Navigation, defect, P1)
Tracking
()
mozilla0.9.4
People
(Reporter: waterson, Assigned: adamlock)
Details
(Keywords: testcase, topembed)
Attachments
(1 file)
1.08 KB,
text/html
|
Details |
This is from http://bugscape.netscape.com/show_bug.cgi?id=6902. I'll attach the test case. This code: newWindow = window.open("","newWin","height=200, width=200, resizable=0") newWindow.document.write("<HTML><HEAD><TITLE>Did you close a window</TITLE></HEAD><BODY>You must have closed a window if you're seeing this window.</BODY>") appears to work fine when run in Mozilla, but fails in mfcEmbed and other embeddings.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Note that the above test case runs the window.open() in its |onunload| handler, but that doesn't matter.
Reporter | ||
Comment 3•23 years ago
|
||
I've stepped through the JS interpreter loop to figure out what's going on. |window.open()| is succeeding; however, the new window has no |document| property (because |GlobalWindowImpl::mDocument| is null at the time that |GetDocument()| is called. cc'ing danm. How do we set up the document object in Mozilla?
Reporter | ||
Comment 4•23 years ago
|
||
Okay, I think I see what's happening. mfcEmbed is not setting up the new document until it gets a callback from the URI loader. Unfortunately, that's too late, because the |write()| call wants the document _immediately_ after the window is created.
Reporter | ||
Comment 5•23 years ago
|
||
When running in Mozilla, the |parentTreeOwner| in |nsWindowWatcher::OpenWindowJS()| is an |nsContentTreeOwner| object. This (apparently) knows about creating a XUL window, which knows about spinning up a nested event loop to process the content load *before* returning from |window.open()|. When running in mfcEmbed, the |parentTreeOwner| is an |nsDocShellTreeOwner| which apparently lacks this savvy. Maybe we need to do something like what |nsXULWindow::CreateNewContentWindow()| is doing, <http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/nsXULWindow.cpp#1293> and spin up another event loop. I don't think _we_ can do that (e.g., in |nsDocShellTreeOwner|), because we may drop events that are meant for the embedding app on the floor. So, is this something we need the embedder to do? Anyway, I'm over my head here: this seems like a core embedding API problem to me...
Assignee: waterson → adamlock
Status: ASSIGNED → NEW
Component: DOM Level 0 → Embedding: Docshell
QA Contact: desale → adamlock
Dup of bug 88229 *** This bug has been marked as a duplicate of 88229 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
You need to log in
before you can comment on or make changes to this bug.
Description
•