* TITLE/SUMMARY [PP] Menu bar is blank after exiting StdFile dialog * STEPS TO REPRODUCE 0) Launch Apprunner 1) From the File menu, select "Open" 2) Either select a file to load, or click "Cancel". * RESULT - What happened Menu bar is empty, and doesn't respond to any clicks. System otherwise behaves properly (e.g. no crash, and menu bar works fine in other apps that are running. Web browser will no longer follow new links.) Application can be quit and relaunched, at which point the menu bar returns to regular operation. * REGRESSION - Occurs On Mac OS Apprunner (4.5.99 optimized build) - Doesn't Occur On Win32 Apprunner (4.5.99 optimized build [NT 4, Service Pack 3]) Linux Apprunner (4.5.99 optimized build) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.

[Duh, in hindsight, this was probably an unnecessary bug; the Open menu doesn't quite work on any platform, although on Win32/Linux, it doesn't leave any bitter aftertaste like on Mac OS.]

It should work now, assigning to saari to check for regression in m4, and close.

This seems to have cropped up again, I can see it in a build from a few days ago. Investigating.

Standard File doesn't work on MacOS on my 4/7/99 build. However, the print dialog doesn't exhibit this behavior, and that should behave the same as Standard File. So I guess that means I can't reproduce this bug.

Steve, when you get the standard file dialog to come up on Mac, either reassign this to me, or see if this occurs. -Saari

Fix for the file dialog not appearing is checked in to nsBrowserAppCore.cpp

fix for bug #4562 > mozilla/widget/src/mac/nsMacEventHandler.cpp - commented out 3 lines mozilla/xpfe/appshell/src/nsWebShellWindow.cpp - Added 2 #ifdef XP_MAC changes that should go away by M5. The problem is that the nsMenuBar class doesn't know when it is through building a menubar from XUL since nsWebShellWindow actually does the construction today. That will change when menus build themselves, which needs to be done for M5's dynamic menu construction. So the hack would go away sometime soon. Previously, the nsMacEventHandler would get a deactivate event before bringing up a dialog or another window... why this isn't happening anymore, I don't know. Perhaps this is a bug in itself, but I was the only one relying on the behavior, and that reliance was a hack to begin with.

Verified fixed using 4.8.99 PM optimized build on Mac OS 8.5. (Nav Services support --- cool!)