Closed Bug 99453 Opened 24 years ago Closed 24 years ago

additional windows don't show up

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ferdinandw+bmo, Assigned: paulkchen)

References

Details

(Keywords: platform-parity, smoketest)

Using win2k cvs 2001091303 (have tried new profile) After one navigator window is opened, additional windows never show up. ctrl+n, links with target=_blank, running mozilla.exe again, the About features under Help all fail to show new windows. They are loaded in memory however, as the windows that should be shown show up as blank lines in the Tasks menu. If the single window that does show isn't closed with file->exit, i have to use taskmgr to kill mozilla. (This bug stopped me from using the bug report helper too.)
Reproduced, same platform.
*** Bug 99462 has been marked as a duplicate of this bug. ***
WinMe does same.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 99468 has been marked as a duplicate of this bug. ***
*** Bug 99475 has been marked as a duplicate of this bug. ***
bringing over keyword from dup bug 99475
Keywords: nsbranch
Plusing this one because of multiple dupes.
Keywords: nsbranch → nsbranch+
Smoketest B.9 this is.
Keywords: smoketest
Win2K 2001091303 - When Mozilla is loaded from the Mail News (mozilla.exe -mail) or Quicklaunch (mozilla.exe -turbo) shortcuts no browser windows will open. I have to completely end the mozilla.exe process and start from the Navigator (mozilla.exe) shortcut to get just one browser. No additional browsers will spawn from any windows once opened.
Mac cvs build (pulled around 8:30am) won't even launch. Tries to allocate multiple nsDNSServices and crashes. Don't know if it's related to this or not, but I thought I'd mention it just in case.
QA Contact: sairuh → jrgm
Is this on the trunk, branch, or both?
QA Contact: jrgm → sairuh
bill, is this the turb issue you were working on y'day?
QA Contact: sairuh → tpreston
Looks to be on the trunk only, and not on today's branch.
I saw this only on windows and only on the trunk with this mornings builds
I'm updating my tree here at home. I don't see any immediately obvious checkins on bonsai that would cause this.
according to doron on irc, commercial view-source.dtd is missing an entity that's in the mozilla version
Can someone test today's mozilla and commercial builds to see if it only occurs in one and not the other?
My mozilla build just finished, and I have no trouble opening new browser windows or opening the "about" items under the Help menu.
Umm, can I get some help here, especially with commercial builds? I don't have sera access, so I can't get behind the firewall while I'm here at home.
Same here. I have a win2000 build as of this morning and it opens new windows fine.
just chatted w/trudelle who says this is unlikely due to turbo stuff. so, qa back to me. note: my main win32 test box is winNT --i've a couple of presumptions here: (1) this is win32-only, (2) testing on winNT should suffice. pls let me know if either of those are incorrect --thx!
Keywords: pp
QA Contact: tpreston → sairuh
okay, recently grabbed the latest comm trunk bits to satisfy my curiosity: only see it on winNT [linux and mac os x are fine].
WFM using both Mozilla and Netscape Win2k debug builds made from code checked out this morning. I launched into a browser, hit ^N, opened a file containing the lyrical line <a href="javascript:window.open('about:blank','_blank'))">basic</a> <a href="http://www.mozilla.org" target="_blank">target _blank</a> no worries. strange things not encountered. high chance of no risk.
Win98SE is also affected. moz 2001091303
Just tested some nightly builds, 2001-09-12-09-trunk (with build id of 2001091203) doesn't exhibit this problem whereas 2001-09-12-05-trunk (with build id of 2001091303) does. I've already poured over bonsai for yesterday's checkins and haven't found anything that looks like an obvious problem. Aslo, it appears that this might be a installer vs built version issue (or maybe even debug vs non-debug) since dp, danm, and I can't reproduce this on our local debug builds.
I think debug vs non-debug, since I always just grab the ZIP file, and I saw the problem with this morning's build.
Ok, we have a possible suspect. Alecf inadvertently checked in a change to xpfe/browser/makefile.win that removed some directories from DIR. Alecf went ahead and backed out the change since it shouldn't have ocurred. We need to double check this fixes the problem. I didn't see any problems since I didn't perform a clobber build.
Dauphin on irc has verified that the backout of xpfe/browser/makefile.win fixes the problem. Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verifying
Status: RESOLVED → VERIFIED
tested using 2001.09.13.16-trunk comm bits on winNT. looks good!
verified on Win2K - thanks for the fast turnaround!
*** Bug 99542 has been marked as a duplicate of this bug. ***
*** Bug 99463 has been marked as a duplicate of this bug. ***
*** Bug 99658 has been marked as a duplicate of this bug. ***
*** Bug 99884 has been marked as a duplicate of this bug. ***
Encountering these symtoms with RC2, Win98.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.