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).

elig...what do you see on Mac?

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.

Targeting M8

setting M9

I just tried this again, and it seems to work... someone else want to verify?

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.

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.

I doubt I can deal with this without help, and certainly not by midnight, pushing to M10

Not critical, pushing to M11

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.

why does this have to do at all with xp menus?

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

Move to M16 for now ...

Reassigning for Don

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone

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.

nav triage team: This still happens with NS6 RTM and a mac build from 12-27. Nominating nsbeta1-, p4, mozilla1.0, reassigning to pchen

nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)

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.

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.

-> default assignee

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.

Resolving as WFM due to comment 32 and cease of development for mac classic.

Realy resolving.

v w4m.