Closed
Bug 58404
Opened 24 years ago
Closed 24 years ago
javascript: urls that open new windows case strange behaviour
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.8
People
(Reporter: blizzard, Assigned: danm.moz)
References
()
Details
Accessing javascript: urls that open new windows cause strange behaviour. If
you access one you have to mouse over buttons or open a new window manually to
get the new window to come up.
You can see it on the url above. I also have javascript: urls in my bookmarks
that exhibit this problem too. It doesn't happen every time. Also, while that
window is waiting to come up, mozilla has the CPU pegged at 100%.
I know that in the new XUL window creation code there's some
GetNativeEvent/DispatchNativeEvent fun that messes with the JS context at the
same time, that's why hyatt is on the cc list.
|
Reporter | |
Comment 1•24 years ago
|
||
OK, I did a quick experiment. In the embedding widget I put a printf() in the
GetNativeData/DispatchNativeData loop that's the equivelent of the one that's in
the XUL code ( the embedding widget is where it was first pointed out to me. )
The inner loop that's loading the initial chrome:// url never exits until some
other set of events happen. If you are creating a new window then both windows
are created.
|
|
Reporter | |
Comment 2•24 years ago
|
||
Small test case:
<html>
<head>
</head>
<body>
<a href="javascript:window.open('http://www.mozilla.org');">click me</a>
</body>
</html>
Can't reproduce on Win95 build 20000110304 with Christopher's test case. Added
void() to testcase to keep the link for multiple re-tries:
<html>
<head>
</head>
<body>
<a href="javascript:void(window.open('http://www.mozilla.org'));">click me</a>
</body>
</html>
How many times do we have to click this to get the error? I tried 50 times and
did not get an error. Christopher, what is going on?
|
|
Reporter | |
Comment 5•24 years ago
|
||
It's very hard to reproduce in Mozilla. Try to make sure that it's the first
thing that you do when you start the browser. That usually helps. Also, try
TestGtkEmbed. It is much more likely to happen there.
Hi Christopher, I think your aim should be to write a real bastard of a test
case that always fails no matter what. Try things like putting your code into
the HEAD section or into a frameset (using other than mouse click events) or an
unload event passing the window reference to another window that is still open,
something really tough. You know this bug best and at worst you might find
another one but I think the mozilla team is so busy that they might not have the
time do fix a hard-to-reproduce thing like this.
Just a thought.
|
||
Comment 7•24 years ago
|
||
Boy this sure sound similar (or exactly the same) as bug 55032 ( window.open
delayed until toolbar buttons moused over ). There are testcases there showing
this bug.
Also, if you go to http://www.visi.com/~hoju/index.html and click on "List all
links on this page" on the left side of the page, you will get this behavior (
BTW, you will also see no scrollbars show up for javascript generated content
in the new window; bug 55334 ).
Also, I think this problem happens more often if you attempt to alter window
features. Not sure if this this it true, but opening full windows doesn't seem
to display the behavior as much.
Jake
This does look like bug 55032, which in turn seems like bug 56337. I haven't been
able to reproduce this problem with the given URL (http://www.xmms.org/skins.html
- there are a bunch of links on that page, and I had no problems with the couple
that I punched) but hoju's case (http://www.visi.com/~hoju/index.html, above)
fills me with déjà vu. I think we have a fix for this in the works.
Yup. This was more fallout from worker threads' occasionally going AWOL. hoju's
test case, at least, is fixed now.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: M19 → mozilla0.8
|
||
Comment 10•24 years ago
|
||
Verified on WinNT and Linux with 20010109xx nightlies -
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•