Your request is essentially what bug 62178 is about. The reason why I'm listed in the blame is: People wanted to freeze the interface, and I wanted to make sure that interface allows canceling - even though we have not managed to implement it. *** This bug has been marked as a duplicate of 62178 ***

OOps, sorry, you are not complaining about the missing cancel functionality, but you are critizizing the interface. Actually I'm surprised it's not marked as frozen.

However, I guess some applications are already using the current interface, not sure if it's a good idea to change it.

Is this interface commonly used from JS? If not, we should just make the change, since it doesn't change the C++ method signature and makes the interface much clearer.

i don't see a single use of either function in lxr.mozilla.org/mozilla. there is an unrelated getpassword used in roaming, but it logically *returns* the value.

Right, but do embeddors use it?

There are callers in Mozilla. I found it being called from nsSecretDecoderRing::ChangePassword(), and from file ssl/src/nsNSSComponent.cpp Not sure if there are more. I could not find callers from our own JavaScript. The intention of the interface is: Give non-JS programs a way to execute our XUL/JS UI to change or get passwords. Are there embeddors that use the interface from C++: Yes Are there embeddors that use the interface from JS: I have no idea.

Since you are requesting a cosmetical change only, and since there is the possibility that we break application, I'd propose, let's not waste our and other people's time, and make this a wontfix.

This isn't a cosmetic change only -- the interface as written is pain to call from JS even if someone wanted to (and the interface as authored is violating the interface-authoring guidelines we had last I checked). Given the purpose of the interface, I would say that the chance of anyone calling it from JS is pretty low and we should go ahead and make this change; the earlier the better (before someone _does_ start using it).

this should do it. note that there are currently no JS consumers in the tree.

Comment on attachment 184971 [details] [diff] [review] fix the interface I find the XXX comments overly obnoxious. Your XXX comments don't explain what is wrong with the interface. They just blame you for them, and suggest that you know what is wrong, and that you are the gatekeeper to that information. It would be much more valuable if you would take the time to note that information somewhere either in the IDL file or on some wiki page and link to it. otherwise, your comments are pretty useless. does this change warrant a change to the interface's uuid? probably not since C++ consumers won't be affected, but how would a JS consumer figure out the right calling convention? Sure there are no JS consumers in our codebase, but what about some extensions that we don't know about or that may be invented in the future?