Judson Valeski wrote: > > As we all know, nsIPromptService provides an interface for driving raw > UI methods like alert and confirm.
The API has major problems at the moment, and there is a bug on fixing it -- `nsPromptService doesn't know how to produce error alerts' <http://bugzilla.mozilla.org/show_bug.cgi?id=95649>. I'd really like to see this fixed before the API freeze, otherwise Mozilla will be communicating the visual equivalent of `Danger! Danger! The text you entered was not found!' (to pick just one example) for some considerable time to come. > There is no information baked in > re: what the context of the dialog is (other than assumptions made by > the method name; for example I could not impl alerts, but only impl > confirms if I wanted). I can see how such a distinction would be useful -- e.g. for kiosks where the developers didn't want to pester users with `You are entering an encrypted page [sic]' and the like, but still had to put up confirmation alerts from a Web page in order to get a Cancel or OK response where that response determined which page to go to. > I think we need the ability to provide more context (an nsresult). I'm >... > if (reason == NS_ERROR_DNS_FAILURE) { > nsCOMPtr<nsIPromptService> ps = do_GetService(nsIPromptService); > ps->Alert(...); > } >... > You could imagine a set of error categories (or better yet, allow the > categories to be defined at runtime) that one could wrap a general > nsresult macro around (like NS_FAILED). >... I'm not sure how useful this would be -- the massive number of possible uses for alerts mean you might end up reinventing the Roget's Thesaurus category system in an attempt to explain to embedders the reason for each alert. This alert is because a critical file is missing, this alert is because you've run out of disk space, this alert is to let you know that your PayPal account has increased, this alert is because a server was not found, this alert is someone inviting you to chat with them ... It might be practical if the API was only ever going to be used for Mozilla, but if that was the case you wouldn't be worrying about embeddors in the first place. :-) One thing we do need, for security reasons, is a means for specifying whether the alert is coming from local or remote code. (We can't use the title for that, since alert implementations on many platforms don't have title bars.) -- Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing <http://mozilla.org/>
