Closed
Bug 74176
Opened 25 years ago
Closed 22 years ago
named windows opened as content aren't being found
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: danm.moz, Assigned: danm.moz)
Details
(Keywords: testcase)
Attachments
(2 files)
|
6.62 KB,
patch
|
Details | Diff | Splinter Review | |
|
2.53 KB,
application/octet-stream
|
Details |
Open a named content window
<html><body><form>
<input type=button value="do"
onclick="window.open('http://www.mozilla.org','win')">
</form></body></html>
and do it again. You get a new window.
nsChromeTreeOwner::FindItemWithName wouldn't find a content docshell. This patch
adjusts that, fixes the method's fibonacci indentation and adds a missing
addref.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
It's been pointed out to me that this patch solves the immediate complaint, but
still doesn't sandbox correctly...
Updated•25 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 4•25 years ago
|
||
could you elaborate? Why would this still be a showstopper if we took the patch?
The patch is an improvement, and will cover maybe 90% of DOM compatibility cases,
but the other 10% wants some attention.
Everything checks out; no need to apply the above patch. Nice! Somebody must
have fixed this while I wasn't looking.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Whiteboard: seems partially fixed; investigating edge cases
Comment 9•24 years ago
|
||
Try this - http://www.chel.com.ru/~mik/open/open.html
Double-clock on a lonk, or go on clicking as fast as you can -- you can
get as much same-named windows as you want.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 10•24 years ago
|
||
Should we change the Target Milestone to some real value, since 0.9.2 was
released looong-looong ago?
Comment 11•24 years ago
|
||
Reseting target, danm@netscape.com, please set any more relevant.
Keywords: testcase
Target Milestone: mozilla0.9.2 → ---
Comment 12•22 years ago
|
||
Bug 189374 is a potential duplicate of this (if not then of bug 55784). It
includes a good testcase. If you double click either link quickly, you will get
two windows, whereas clicking and waiting for the window to open fully before
clicking again will only give you one.
| Assignee | ||
Comment 13•22 years ago
|
||
Both those bugs are about a timing issue: the new window apparently can't be
found while it's still being opened. The original comment in this bug stated
that a named window simply couldn't be found. At all.
That was 2.5 years ago. This bug was closed and verified in 2001. The testcase
in this bug works for me using a recent build. This bug was reopened in 2002
(comment 9) but that, like the potential duplicate bugs mentioned above, was
also because of the timing issue. The timing issue will be one of those other
two bugs, not this one. Reclosing.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•