named windows opened as content aren't being found

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
17 years ago
15 years ago

People

(Reporter: Dan M, Assigned: Dan M)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

17 years ago
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.
(Assignee)

Comment 1

17 years ago
Created attachment 29297 [details] [diff] [review]
pseudopatch (more readable) adjusting FindItemWithName
(Assignee)

Comment 2

17 years ago
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
(Assignee)

Comment 3

17 years ago
It's been pointed out to me that this patch solves the immediate complaint, but 
still doesn't sandbox correctly...
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 4

17 years ago
could you elaborate?  Why would this still be a showstopper if we took the patch?
(Assignee)

Comment 5

17 years ago
The patch is an improvement, and will cover maybe 90% of DOM compatibility cases, 
but the other 10% wants some attention.
(Assignee)

Updated

17 years ago
Whiteboard: seems partially fixed; investigating edge cases
(Assignee)

Comment 6

17 years ago
Everything checks out; no need to apply the above patch. Nice! Somebody must 
have fixed this while I wasn't looking.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Whiteboard: seems partially fixed; investigating edge cases
(Assignee)

Comment 7

17 years ago
Created attachment 38542 [details]
test case I used to verify (zipped directory)

Comment 8

17 years ago
Verified with 2001-08-28-08 on Win95.
Status: RESOLVED → VERIFIED

Comment 9

16 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

16 years ago
Should we change the Target Milestone to some real value, since 0.9.2 was
released looong-looong ago?

Comment 11

16 years ago
Reseting target, danm@netscape.com, please set any more relevant.
Keywords: testcase
Target Milestone: mozilla0.9.2 → ---

Comment 12

15 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

15 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
Last Resolved: 17 years ago15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.