User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ When trying to generate a certificate on a website with the <keygen>-tag, Deer Park's security module prompts to choose a security device. When "Software Security Module" is chosen, it is not possible to press the 'OK' button. Reproducible: Always Actual Results: a certificate is not generated. Expected Results: generate a certificate request and submit it to the ca. <form method="post" action="$_SERVER['PHP_SELF']" ENCtype="x-www-form-urlencoded"> <keygen name="SPKAC" challenge="testkeygen"> <input name="submit" type="submit" value="Next >" /></form>

What if you pick something that isn't the Software Security Device (which I don't think does key generation, its used for the password manager mostly)?

(In reply to comment #1) > What if you pick something that isn't the Software Security Device (which I > don't think does key generation, its used for the password manager mostly)? Hi Mike, I've got an aladdin eToken with a crypto processor inside. So key generation is done on the crypto device. The behaviour is exactly the same as when trying to use the Software Security Device (Nothing happens, when I press OK). BTW: When fixing this bug, it should be taken into consideration to fix Bugzilla Bug 236461 as well. I'm sorry, I'm not in close relation with Mozilla's security module, so it'm not in a position to make a proposal, how it can be done.

-->Security:UI for now, maybe it's also a NSS bug Reporter: Do you mean with "it is not possible to press the 'OK' button." that the OK button is grayed out?

(In reply to comment #3) > -->Security:UI for now, maybe it's also a NSS bug > Reporter: Do you mean with "it is not possible to press the 'OK' button." that > the OK button is grayed out? No, the button looks (and behaves) normal, but there is no reaction.

Do you see any error in JavaScript Console (under the Tools menu) when clicking the OK button?

No, there doen't appear any error.

Does it work with Mozilla 1.7.x ? I would like to know whether we are dealing with an regression. This dialog is implemented in file mozilla/security/manager/pki/resources/content/choosetoken.xul I wonder if this might got broken when Stefan converted it to <dialog> in the context of bug 251991 Looking at the differences between rev 1.9 and 1.10 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=choosetoken.xul&branch=&root=/cvsroot&subdir=mozilla/security/manager/pki/resources/content&command=DIFF_FRAMESET&rev1=1.9&rev2=1.10 you made a case sensitive error, formerly doOK() got called, but now doOk(). I also see that in the old version, the choosetoken.js source file got included before the first reference to the doOK function. I don't know JS good enough to say if that's another problem. Does it matter if the inclusion comes after the reference?

Stefan, do you agree it's a regression from your change?

(In reply to comment #9) >Stefan, do you agree it's a regression from your change? It certainly looks that way to me. I looked again at the patch but I couldn't find any more doOk()s in it.

(In reply to comment #8) > Does it work with Mozilla 1.7.x ? > I would like to know whether we are dealing with an regression. I'm running Firefox 1.0.4 as well. This browser doesn't make problems in the certificate creation dialog.

(In reply to comment #8) > I wonder if this might got broken when Stefan converted it to <dialog> in the > context of bug 251991 > > Looking at the differences between rev 1.9 and 1.10 > http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=choosetoken.xul&branch=&root=/cvsroot&subdir=mozilla/security/manager/pki/resources/content&command=DIFF_FRAMESET&rev1=1.9&rev2=1.10 > you made a case sensitive error, formerly doOK() got called, but now doOk(). Yes, I think this is the cause for this bug. Sorry for causing this regression. :-( > I also see that in the old version, the choosetoken.js source file got included > before the first reference to the doOK function. I don't know JS good enough to > say if that's another problem. Does it matter if the inclusion comes after the > reference? This shouldn't be a problem.

StefanB: I hope you don't mind stealing your bug ;)

Comment on attachment 189658 [details] [diff] [review] Patch Easy review, so r?+sr?

Comment on attachment 189658 [details] [diff] [review] Patch I don't have a way of testing this, maybe kaie can mark r+?

Comment on attachment 189658 [details] [diff] [review] Patch kaie, any chance you could test this patch (also one can probably assume that this patch fixes it)?

Ok, will test it shortly. While I don't have other security tokens available at the moment, so I have to change the code to always display the "choose token" dialog, even if there's only one (the software) token available.

Ok, I tested it with todays trunk and a fresh firefox build. I confirm, after applying the patch, the OK button works. FYI I have a test page at http://kuix.de/misc/test3/ To force the choosetoken dialog to come up, in file nsKeygenHandler.cpp in function GetSlotWithMechanism I changed if (!slotList->head->next) { /* only one slot available, just return it */ *aSlot = slotList->head->slot; } else { to {

Comment on attachment 189658 [details] [diff] [review] Patch r=kaie

Comment on attachment 189658 [details] [diff] [review] Patch wanted, this is a regression fix

Checking in security/manager/pki/resources/content/choosetoken.xul; /cvsroot/mozilla/security/manager/pki/resources/content/choosetoken.xul,v <-- choosetoken.xul new revision: 1.13; previous revision: 1.12 done

fixed then

Verified FIXED using http://kuix.de/misc/test3/ as a testcase. I'm able to hit the OK button using build 2005-08-08-05 on Windows XP SeaMonkey trunk.