Closed
Bug 26129
Opened 26 years ago
Closed 26 years ago
Could not open new window with javascript on Linux.
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: desale, Assigned: waterson)
References
()
Details
(Keywords: platform-parity, Whiteboard: [PDT+])
Attachments
(1 file)
|
9.83 KB,
patch
|
Details | Diff | Splinter Review |
Could not open new window with window.open in script tags.
If we try to open new window on certain event then it does open new window. [For
example, if we open new window on button click or something, or onLoad or any
other event then it works.] But if we try to open new window with window.open
mentioned in scrpt tags, then it does not open new window. [This bug was there
for almost two three days now]
This one is blocking our automation on Linux.
BUILDS: 2000-01-31-14.
STEPS TO REPRODUCE:
1] Please visit the URL I mentioned above.
OR
1] Please copy HTML code I'm providing. Save it as HTML file.
2] Open this HTML file with above mentioned builds.
EXPECTED RESUTS:
As soon as you load the page, it should open new window adn load www.yahoo.com
in new window.
ACTUAL RESULTS:
It does not open new window.
TESTCASE CODE START:
<HTML>
<HEAD><TITLE>Continous Window.Open()</TITLE></HEAD>
<BODY>
This is Parent Window which is going to open child window 5 times.
<SCRIPT>
<!--
url = 'http://www.yahoo.com';
testWin = window.open(url, 'testWindow');
//-->
</SCRIPT>
</BODY>
</HTML>
TESTCASE CODE END:
|
Reporter | |
Updated•26 years ago
|
Putting on PDT+ radar, blocking QA.
Whiteboard: [PDT+]
Target Milestone: M14
|
||
Comment 2•26 years ago
|
||
We seem to be spinning in the following loop in nsWebShellWindow::NewWebShell:
while (NS_SUCCEEDED(looprv) && locked) {
void *data;
PRBool isRealEvent;
looprv = subshell->GetNativeEvent(isRealEvent, data);
subshell->DispatchNativeEvent(isRealEvent, data);
newWindow->GetLockedState(locked);
}
Hyatt says that we're supposed to spin until we get an onload notification from
netlib. On Linux (and linux only, which is weird), we're never getting out. Of
course, since we're in a mini event loop, we don't hang. Running the test
multiple times just creates a little stack of event loops.
Passing along to danm to investigate.
P.S. Regular onload handlers seem to work
Assignee: vidur → danm
This bug is one of a handful that have recently popped up involving some sort
of breakage in window content loading. It's related to, or maybe a duplicate of,
26283. But it's a simpler case than that one with clear roots somewhere in
document loading, and I'm punting it on to Chris, the next bastion in line for
situations like this.
Part of the process of loading the above HTML drops Mozilla into a captive
event loop, where it waits for the chrome document to finish loading. That's the
loop Vidur described above. Something about these exact circumstances has the
unusual effect of leaving Mozilla Linux in that loop forever, because it never
receives the OnEndDocumentLoad notification, which implies something amiss deeper
down, in RDF or the parser or necko or timers or not.
Assignee: danm → waterson
|
Assignee | |
Comment 6•26 years ago
|
||
This sound familiar to anyone?
|
|
Assignee | |
Comment 7•26 years ago
|
||
jud: could you read through this bug? I remember you telling me how there would
be awful scenarios where Necko and the UI thread would deadlock each other. This
seems like it might be one of those.
There is a "window.open" call in-lined in script. To deal with this, a nested
event loop has been spun up to allow the new window to open while the script
evaluation blocks.
I'm never seeing an OnEndDocumentLoad fire for the second navigator.xul file.
Still digging...
|
||
Comment 8•26 years ago
|
||
The scenario I described to waterson about UI/necko deadlocking was specific to
the UI thread (which I assume this loop is executing on???) deadlocking, not
necko. The fact that we're spinning in this loop in indication that the UI
thread is not deadlocked (it would be blocked on an inputStream->Read() call
btw).
A common reason we don't get OnEndDocLoads() is because loadgroup add/remove
calls are mismatched (necko/uri loader). Because this works in some events and
not others I believe we're proabably going through different load mechanisms in
the working and non-working cases, and one of the add/remove calls is being
missed in the bad case.
HTTP was firing extraneous OnStopReqeusts() and Gagan's been considering that
problem. I've cc'd him as he may have been playing in this sandbox recently.
Also, the changes warren made a few days ago to the pipe code may have
aggrivated some poor error handling code somewhere in the chain. Can someone
test this w/ builds from today or fresher (which had his pipe change removed due
to a different regression)?
|
|
Assignee | |
Comment 9•26 years ago
|
||
Ok, I just pulled and built (10am, Sat Feb 5), and the problem seems to have
"fixed itself" when the XUL cache is *off*. My previous build was from 10pm, Fri
Feb 4, which did exhibit the problem with the XUL cache on or off. (The
difference being that, when the XUL cache is *off*, the XUL/JS/CSS files are
always reparsed; with it *on*, they are brutally shared.)
Since my 10pm build showed the problem with the XUL cache on and off, my guess
is this is a race condition, not necessarily brutal sharing. Anyway, I'll keep
digging and see what I can find.
|
|
Assignee | |
Comment 10•26 years ago
|
||
|
|
Assignee | |
Comment 11•26 years ago
|
||
The problem seems to have been with using a GTK timer to fire the
OnEndDocumentLoad method while we're "pushed" in a modal event queue.
Specifically, the timer was never firing, possibly because the GTK event loop
wasn't being serviced while were in the "pushed" state.
To fix it, I've changed the code to make use of the nsIEventQueueService. I am a
bit concerned that this may be indicative of a deeper problem with GTK timers
and modal dialogs, but I can't prove it. For example, the cursor blinks in a
password dialog, which is modal.
Anyway, somebody wanna give me an r= on this?
thanks.
|
|
Assignee | |
Comment 12•26 years ago
|
||
fix checked in, r=mscott
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 13•25 years ago
|
||
Verified with 02-09-08. Working fine now.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•