Closed Bug 7672 Opened 26 years ago Closed 22 years ago

Cannot simultaneously open >1 new browser window

Categories

(SeaMonkey :: UI Design, defect, P4)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
Mac System 8.6
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: bam, Assigned: trudelle)

References

Details

When attempting opening multiple browser windows (for bugzilla search, bug entry, test, etc.) at once, I find that the menu choice File->New Browser Window does not work reliably. The first time you pick File->New Browser Window it works. If you rapidly choose it again, it will not work until the first browser window's user interface has rendered (which takes quite a while, even on a G3/400MHz, 128M ram macintosh).
Component: Apprunner → XPApps
QA Contact: leger → elig
elig...what do you see on Mac?
Assignee: don → saari
Summary: File->New Browser Window does not work reliably → Cannot simultaneously open >1 new browser window
Yup. Valid/reproducible bug. Reassigning to Chris Saari.
This isn't a menu bug per se. The JavaScript that performs the New Window operation may not yet be ready to run when you select the menu item. I suspect the JavaScript execution fails somewhere, although I havn't actually confirmed that.
Target Milestone: M8
Targeting M8
Target Milestone: M8 → M9
setting M9
Status: NEW → ASSIGNED
I just tried this again, and it seems to work... someone else want to verify?
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Marking worksforme because it does... tested on a G3 300 laptop, and a 450 desktop. Tell me if it doesn't work on slower machines
Hey, Chris --- Oops. Missed your earlier ping; thanks for the flag. I'll raise you 280 and try on a 100 Mhz 603e, that just took 10 minutes to launch Apprunner. ;)
The mere feat of trying to simultaneously open two windows on the 100 Mhz 603e system (24 MB RAM) actually crashed Apprunner. I'll try again on a 133 Mhz 604.
This works...sortof. I'll check more tomorrow morning.
Status: RESOLVED → REOPENED
Re-opening, per discussion with saari. There are two remaining issues. I'd be happy to break #1 into a separate bug report (although I suspect it may be related to the missing chrome that I'm seeing a lot on Mac, dunno if there's a formal bug on it.) #1: The second window drawn lacks all chrome, other than the "Stop" and "Reload" buttons. #2: It only allows you to open two browser windows; when you select the third "New Browser Window" in a row, the menu item doesn't respond until (I believe) the second browser window has drawn.
Resolution: WORKSFORME → ---
Target Milestone: M9 → M10
I doubt I can deal with this without help, and certainly not by midnight, pushing to M10
Target Milestone: M10 → M11
Not critical, pushing to M11
Target Milestone: M11 → M13
I'm pushing this again to M13
mass-moving all m13 bugs to m14
hey Eli, should this one go to me...?
I believe it's fine either way; I'd rather remain QA assigned since I've seen the bug and will be more easily able to verify it.
Target Milestone: M14 → M15
Assignee: saari → trudelle
Status: REOPENED → NEW
why does this have to do at all with xp menus?
Assignee: trudelle → don
QA Contact: elig → paulmac
If the code invoked by the menu item isn't ready to run at the time the menu is provided, then the item should be disabled. reassigning to xpapps.
changing qa contacts back
QA Contact: paulmac → elig
Move to M16 for now ...
Target Milestone: M15 → M16
Reassigning for Don
Assignee: don → danm
Target Milestone: M16 → ---
Target Milestone: --- → M19
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M21 → Future
FWIW, this bug is still here. Tried it with build 2000080508-M18 under Mac OS 9.0.4 on an iMac DV. Menu choice File-->New Browser Window works, but doesn't seem ready for prime time. Very slow, not nearly as fast as NC 4.73.
QA Contact: elig → sairuh
nav triage team: This still happens with NS6 RTM and a mac build from 12-27. Nominating nsbeta1-, p4, mozilla1.0, reassigning to pchen
Assignee: danm → pchen
Keywords: nsbeta1
Priority: P3 → P4
Target Milestone: Future → mozilla1.0
Target Milestone: mozilla1.0 → Future
nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)
Keywords: nsdogfood
As this currently stands, there only two ways to fix this that I can see, 1) hope we can make the execution of js for a new window be blindingly fast or 2) disable the menu item until the new window is created. I don't like #2, but I don't see how we'll get #1 done. Marking nsbeta1- because it's hard, boo, hoo.
Keywords: nsbeta1 → nsbeta1-
Keywords: nsCatFood
Keywords: nsdogfood
nav triage: this is a nsCatFood- bug. not a sufficiently common user behaviour (hitting open new nav window twice in succession) to prevent general market acceptance.
Keywords: nsCatFood → nsCatFood-
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
Target Milestone: --- → Future
As a lot has changed since this bug was last reported seen, I have to ask the obvious, is anyone still seeing this problem?
WorksForMe using Mac/2002080208/9.2.2. Choosing File/New Navigator Window, and then choosing it again before the first window draws, results in two perfectly good, usable Navigator windows. Suggest this be resolved WFM.
No longer blocks: There_can_be_only_1
Depends on: There_can_be_only_1
Resolving as WFM due to comment 32 and cease of development for mac classic.
Realy resolving.
Status: NEW → RESOLVED
Closed: 26 years ago → 22 years ago
Resolution: --- → WORKSFORME
v w4m.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.