Closed
Bug 133156
Opened 24 years ago
Closed 23 years ago
window.open with feature "chrome" delays document loading
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
INVALID
People
(Reporter: dherndl, Assigned: jst)
Details
following testcase with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:0.9.9) Gecko/20020311
produces strange behaviour using window.open().
when the window feature "chrome" is used, the document
load process seems to be delayed. the returned window object
is unusable immediately after the call to window.open.
the same call without the "chrome" feature, returns an
immediately usable window object.
is this behaviour intended?
------- testcase.html -------
<html>
<head>
<script>
function createWindow(name, feature)
{
document.testform.state.value = "";
document.testform.wndName.value = "";
var newWin = window.open("http://www.mozilla.org", name, feature);
document.testform.state.value = "before/chrome";
document.testform.wndName.value = newWin.name;
document.testform.state.value = "after/chrome";
}
</script>
</head>
<body>
<form name="testform">
<input type="button" value="create with-chrome"
onclick="createWindow('with-chrome', 'chrome')" />
<input type="button" value="create no-chrome"
onclick="createWindow('no-chrome')" />
<p/>
state:<input type="text" name="state" />
wndName:<input type="text" name="wndName" />
</form>
</body>
</html>
|
||
Comment 1•24 years ago
|
||
i cant see any visible delay on my system, can you try again with a newer build ?
i tried this one:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523
the problem is still there. it is not a visible
delay. if you compare the contents of the
fields "state" and "wndName" after running with
either button, there are these two situations:
1) button "create no-chrome"
everything runs as expected. the field "wndName"
contains the name of the new created window
and field "state" holds the value "after/chrome".
so the whole function executed completely.
2) button "create with-chrome"
the field "wndName" is empty and field "state" holds
the value "before/chrome". so the function
"createWindow" seems to be aborted at this line of
code:
document.testform.wndName.value = newWin.name;
i also placed an exception handler around this
line, but this didn't change anything.
in both cases the actual window is created
and visible, but i seems this happens especially
for variant 2 in an asynchronous way, so
the javascript window object (or the wrapped
native window object) is not immediately
usable in the next statements after window.open().
so the behaviour of window.open() is different
depending on using the window feature 'chrome'
or not. maybe this is platform-specific
(windows-only)? i have currently no chance to test
it on another plaform (e.g. Linux).
hope this helps.
|
||
Comment 3•23 years ago
|
||
I can reproduce the reports described results consistancy, but I don't think
this is a bug.
If the code is altered to display the newWin variable's string representation
(putting "newWin.toString()" instead of "newWin.name") the following happens:
with-chrome:
state: before/chrome
wndName: [object ChromeWindow]
no-chrome:
state: after/chrome
wndName: [object Window]
I think that the problem is now fairly clear - when you specify the "chrome"
feature to window.open you actually get a different object back - and it's an
object that doesn't support the "name" property, or so it seems.
One thing I don't understand is why accessing "newWin.name" when you specify
"chrome" doesn't give any error on the JavaScript console, yet the line of code
following it is not executed.
I suggest either this bug is marked INVALID or WONTFIX (depending of whether the
observed behavour is what should be happening; or, we 'hijack' this bug and use
it for the apparent problem of no JavaScript error, but no continuation of code
execution (since it seems partially related).
.
Assignee: asa → jst
Component: Browser-General → DOM Mozilla Extensions
QA Contact: doron → lchiang
|
|
||
Comment 5•23 years ago
|
||
to clear up confusion, a ChromeWindow is simply a Window with some more
properties (see
http://lxr.mozilla.org/seamonkey/source/dom/public/idl/base/nsIDOMChromeWindow.idl)
So a ChromeWindow has a name properties.
|
|
||
Comment 6•23 years ago
|
||
Fabian,
how does that IDL file show either of your two points? I see no indication
that it's the same as (inherited or otherwise) the normal Window object, or that
it supports the name attribute.
|
|
||
Comment 7•23 years ago
|
||
I wrote the code, I should know :-)
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.h
321 * nsGlobalChromeWindow inherits from GlobalWindowImpl. It is the global
322 * object created for a Chrome Window only.
323 */
324 class nsGlobalChromeWindow : public GlobalWindowImpl,
325 public nsIDOMChromeWindow
|
|
||
Comment 8•23 years ago
|
||
Ok, so that means "name" is a supported propertly of a ChromeWindow object... so
I guess this bug should really be looking at why the JavaScript execution seems
to stop without any errors when trying to read this "name" attribute.
Unlike a content window, a chrome window's contents are created asynchronously.
So unhandily the window isn't completely functional immediately after the
window.open call returns. It's by design.
However an attempt to access properties on the nascent window shouldn't cause
the script to abort silently and uncatchably. Please don't morph this bug into a
new one. It's difficult to know that you need to skip the first three pages of a
bug report before you get to the salient part. See bug 164975. Closing this one
as "as designed."
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
|
||
Updated•13 years ago
|
Component: DOM: Mozilla Extensions → DOM
|
|
||
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•