Closed Bug 13357 Opened 26 years ago Closed 26 years ago

modal dialogs shouldn't be added to window menu

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
All
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Brade, Assigned: davidm)

Details

I see asserts when I open/close dialogs: Assertion: "nsMenu::NSStringSetMenuItemText: SetMenuItemFontID failed." (err== noErr at file nsMenu.cpp line 1004 SetMenuItemFontID doesn't seem real happy about having a menuID of 261 (greater than 255?) However, that isn't really what this bug is about; it just made me notice it. This bug is for the problem of modal dialogs being added/deleted from the global window menu. I don't think that dialogs (especially modal dialogs) should be added to that menu.
This can't be a Mac problem as it's currently classified, unless there's something I don't know about. Always a possibility. In trying to track down where the problem happens, I notice windows appearing in the global window list on Linux and Windows, but different windows for each. Could you pin the problem down a little more? I believe it's not related to modality. In any case, the code that makes mention of a window in the system list is davidm's, and I don't understand it. I think he wants this bug.
Assignee: danm → davidm
true; I don't know if this bug is actually mac-specific or xp (as you suspect). I intended this bug to be that modal (and non-modal?) dialogs shouldn't be added to the list of windows for the Window menu. I think there are some other problems going on as well. Reassign to davidm per comments from danm.
Status: NEW → ASSIGNED
Hardware: Macintosh → All
Target Milestone: M16
Wether modal dialogs get added is irrelevant since when a modal dialog is up you can't access the tasks menu. Wether modeless dialogs get added, should depend on wether they are singletons( filter window) or property sheets( address book). Moving to m16 since it would be nice to do but not required for shipping. As for why you are getting that error it is a result of some rdf problems.
dividing up phillips qa contact bugs, he no longer works here
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Added support for window property to determine if a window should be added to the list so if you don't want you window to be added you can set the intaskslist of the window to false. Will post the update documents later.
I don't quite understand what the actual bug is that's been fixed; could someone explain? 1. In the Global History window, I'm still seeing modal dialogs --- and other dialogs --- appear. (e.g. Open Web Location...) Is this a separate issue...? 2. Where is the "Window" menu that brade cites? Is this currently the list of window on the Tasks window? If so, how on earth do you check the menu's content while a modal dialog is open? This should be impossible, as davidm indicated. 2b. Is Preferences supposed to be a modal window? It doesn't behave like one --- other windows can be accessed --- but menu items do nothing while it's active. thanks.
(never mind 2b; answered by bug #23910)
The window menu is the tasks menu. As I said earlier in the bug adding modal windows to the tasks menu is a nonIssue since you can't access the menu while it is up and if you could there is no reason for them not to be there. What I did was add a property so that a window doesn't have to be added. Some programs do this for windows which there should be a single instance. If someone doesn't want there modal window added ( why?) they can exclude it from the list by seting the attribute. The assert is long gone. As far as the pref window goes, I think it is currently nonModal since Ben was having some problems with it being modal on the mac. Spam him for the details
davidm: So, in other words, this is a developer bug and should be verified by another developer?
To verify you should be able to place intaskslist="false" as an attribute on the window you don't want to be in the task list. I just tried it real quick with navigator and it seems to work.
Status: RESOLVED → VERIFIED
In that case, rubber-stamping as Verified/Fixed. Thanks!
You need to log in before you can comment on or make changes to this bug.