document.write() fails when targeted at new window, mfcembed only

RESOLVED DUPLICATE of bug 88229

Status

()

Core
Document Navigation
P1
normal
RESOLVED DUPLICATE of bug 88229
17 years ago
17 years ago

People

(Reporter: Chris Waterson, Assigned: Adam Lock)

Tracking

({testcase, topembed})

Trunk
mozilla0.9.4
x86
Windows 2000
testcase, topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
Created attachment 41713 [details]
test case
(Reporter)

Comment 2

17 years ago
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
(Reporter)

Comment 3

17 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

17 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

17 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
(Assignee)

Comment 6

17 years ago
Dup of bug 88229

*** This bug has been marked as a duplicate of 88229 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Updated

17 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.