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)

x86
Windows 2000
defect

Tracking

()

RESOLVED DUPLICATE of bug 88229
mozilla0.9.4

People

(Reporter: waterson, Assigned: adamlock)

Details

(Keywords: testcase, topembed)

Attachments

(1 file)

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.
Attached file test case
Note that the above test case runs the window.open() in its |onunload| handler,
but that doesn't matter.
Status: NEW → ASSIGNED
Keywords: testcase, topembed
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
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?
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.
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
Target Milestone: mozilla0.9.3 → mozilla0.9.4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: