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)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: danm.moz, Assigned: danm.moz)

Details

(Keywords: testcase)

Attachments

(2 files)

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...
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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.
Whiteboard: seems partially fixed; investigating edge cases
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
Verified with 2001-08-28-08 on Win95.
Status: RESOLVED → VERIFIED
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 → ---
Should we change the Target Milestone to some real value, since 0.9.2 was released looong-looong ago?
Reseting target, danm@netscape.com, please set any more relevant.
Keywords: testcase
Target Milestone: mozilla0.9.2 → ---
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.
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 ago22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: