Closed
Bug 6293
Opened 26 years ago
Closed 25 years ago
[PP]window.open() fails to load URL on current window name
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
VERIFIED
FIXED
M10
People
(Reporter: gerardok, Assigned: pavlov)
References
()
Details
(Whiteboard: [TESTCASE] simple testcase already supplied BLOCKER)
Attachments
(4 files)
Version: Seamonkey
Program: Viewer.exe
BuildID: 5/10/99
Platform: Linux Red Hat 5.2
Using window.open to load an URI in current window causes a segmentation fault
if a window name was specified.
It fails on Linux only. The same code runs fine in 4.5 and previous versions.
Steps to reproduce:
1. Create a file with the following contents:
<HTML>
<HEADER>
<TITLE>Parent Window</TITLE>
</HEADER>
<BODY>
<SCRIPT>
// Required just for assigning a window name to child window
window.open('childw2.html', 'childw');
</SCRIPT>
</BODY>
</HTML>
2. Create a second file with the following contents, and name it as
"childw2.html":
<HTML>
<HEADER>
<TITLE>Child Window</TITLE>
</HEADER>
<BODY>
<SCRIPT>
window.open('http://bubblegum', 'childw');
</SCRIPT>
</BODY>
</HTML>
3. Load the first file in viewer.exe
Actual Results: Exits due to Segmentation fault
Expected Results: Default page from bubblegum loaded in second window.
This is blocking automated tests from running on Linux.
Can't reproduce the problem. Second window won't open even if javascript is
enabled and won't coredump.
Tried it again (without changing anything) with dist/bin/viewer, the second
window would appear normally.
using build 1999-05-17-08 on redhat 5.2, i386,
i got 3 totally different stacktraces on this one. one thing is for sure -
it crashes every time for me. I changed the url in childw2.html from
http://bubblegum to http://www.yahoo.com, and launched viewer through gdb.
attatchments of stack traces coming soon...
the moral of the story is:
if the new window doesn't crash, enter a new url into the location control
and hit enter. that should cause the crash.
|
||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Target Milestone: M6
|
|
||
Comment 10•26 years ago
|
||
This seems to work correctly for me on Windows on the 5/17/99 build.
I'm not sure what might have fixed it....
|
Reporter | |
Comment 11•26 years ago
|
||
This is Linux only. The described failure is still happening on 1999-05-17-08
build. Status changed to Reopen.
|
|
Reporter | |
Comment 12•26 years ago
|
||
As per Vidur comments, the cross-platform code for window.open() seems to be
all right. Assigning to Ramiro, as requested. Ramiro, please contact Vidur if
you have any question. Thanks.
|
||
Updated•26 years ago
|
|
||
Comment 13•26 years ago
|
||
adding url. this is a hard one. not sure i can fix it for m6, but ill try
anyway.
|
|
||
Updated•26 years ago
|
Target Milestone: M6 → M7
|
|
||
Comment 14•26 years ago
|
||
its dying in the bowels of netlib. so guess what that means ?
theres really not much i can do until necko lands.
dp: the stack looks a lot like the timer bugs you and mcafee have.
marking m7.
|
||
Comment 15•26 years ago
|
||
Isn't Necko scheduled for M8 not M7? Please move Target Milesonte to M8 if
true.
|
|
||
Updated•26 years ago
|
Assignee: ramiro → dp
|
|
||
Comment 16•26 years ago
|
||
dp, gagan and I spend sometime debuggin this yesterday.
We found that the url exit routine in netlib was being called twice for the same
url.
The problem goes away if you change the name of the javascript windows. In the
example in your test case in the bug, both windows are named the same thing -
'childw'
That is only in the viewer. The apprunner is another story. The code to deal
with this is different in each case. In the apprunner, you dont get a crash,
but the url you want does not load - unlike windows.
According to hyatt, what you are trying to do will not work on Linux at all
until architectural issues are addressed.
Im afraid there is not much we can do until the necko landing.
In the meantime, can you change the scripts so that each javascript window has
a unique name ?
Its not clear why netlib is trying to free the same url active entry twice.
reassigning to dp so that he can deal with it wrt necko.
|
||
Updated•26 years ago
|
Assignee: dp → warren
Summary: window.open() fails to load URL on current window name → [PP]window.open() fails to load URL on current window name
|
||
Updated•26 years ago
|
|
|
||
Comment 17•26 years ago
|
||
Deferring until after necko landing.
Severity: blocker → critical
Whiteboard: BLOCKER
Target Milestone: M9 → M10
|
||
Updated•26 years ago
|
Whiteboard: BLOCKER → [TESTCASE] simple testcase already supplied BLOCKER
|
Assignee | |
Comment 18•26 years ago
|
||
i just get a blank window when i do this. it doesn't seem to load childw2.html
|
|
||
Updated•25 years ago
|
Assignee: warren → pavlov
Status: ASSIGNED → NEW
|
|
||
Comment 19•25 years ago
|
||
I tried to test this, but couldn't get to fateware for some reason. Dr. Pavlov,
can you test this again now with necko? Thanks,
|
||
Comment 20•25 years ago
|
||
I clicked on the URL link, the progress bar
spun for awhile, but no new pages or windows loaded.
Linux, build from this morning.
|
|
||
Updated•25 years ago
|
Hardware: PC → All
|
|
||
Comment 21•25 years ago
|
||
I get a similar no-op response with a
10-day old build on NT.
Marking all.
|
|
||
Comment 22•25 years ago
|
||
oops, yeah fateware is down for me.
ramiro, got a URL that works?
fateware.com is ramiro's site.
|
|
Assignee | |
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 23•25 years ago
|
||
this works today in both viewer and apprunner using the original test case and
not the ramiro one. someone fixed it. marking it so.
|
||
Comment 24•25 years ago
|
||
Bug was reported for viewer.
I'm verifying it on seamonkey apprunner.
Coz thats what we are bothered about now.
Verified with 2000-12-15.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•