338963 - accepting certificate in "Website Certified by an Unknown Authority" is not working

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[sonnenstrahl]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060519 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060519 SeaMonkey/1.5a

Accepting a unknown certificate in the "Website Certified by an Unknown Authority" dialog is not working. The OK button doesn't work, Help and Cancel are okay. Neither accepting the certificate permanently nor temporarily works.

This worked in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060517 SeaMonkey/1.5a.

Reproducible: Always

Steps to Reproduce:
1. Go to a HTTPS website with a certificate by an unknown authority
2. Click on OK


Actual Results:  
Nothing happens

Expected Results:  
The certificate should get accepted temporarily/permanently.

Comment 1

[Daniel Veditz [:dveditz]]

So you're proposing a regression window between May 17 and May 19 builds? That would include these checkins:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-17&maxdate=2006-05-19+06%3A00&cvsroot=%2Fcvsroot

A few minor NSS fixes, could they be the cause?

Comment 2

[Kai Engert [:KaiE:]]

The NSS checkins (that you see in the bonsai link) are to the development head of NSS.

However, Mozilla trunk uses a static snapshot of NSS, so the listed NSS checkins can not be related.

The snapshot currently used by Mozilla is listed in mozilla/client.mk as NSS_CO_TAG.

I don't see a change to that file in the regression window.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Don't tell me we've gone back to using a movable, and moving, "static" CVS 
tag for building NSS in mozilla!  :-/

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

If clicking the buttons doesn't dismiss the dialog, 
I don't think NSS can be the cause.  

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> Don't tell me we've gone back to using a movable, and moving, "static" CVS 
> tag for building NSS in mozilla!  :-/

It appears to be a series of non-moving static tags. The current one is NSS_3_11_20060520_TAG.

Comment 6

[Adam Rambousek]

I can confirm this bug in Seamonkey on Linux. When I used latest-trunk (20060525), the dialog is not working.
So I downgraded to 20060518 and it works fine.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> I can confirm this bug in Seamonkey on Linux.

Seamonkey trunk 20060525 on windows is working fine for me. Is it the platform, or some other you vs. me difference?

> the dialog is not working.

what exactly do you mean by that? I was assuming you meant it would go away but the cert didn't actually get accepted. Nelson in comment 4 assumes you meant the buttons don't work on the dialog (which in hindsight makes more sense). Which is it?

Comment 8

[Adam Rambousek]

> Seamonkey trunk 20060525 on windows is working fine for me. Is it the platform,
> or some other you vs. me difference?
 
I'm sorry, I made a mistake. I downloaded seamonkey-1.5a.en-US.linux-i686.tar.bz2 from latest-trunk dir and I thought it's 20060525, but actually it's 20060519. I tried downloading 
 seamonkey-1.5a.en-US.linux-i686-gtk1.tar.gz which is really 20060525. And it works fine. 


> > the dialog is not working.
> 
> what exactly do you mean by that? I was assuming you meant it would go away but
> the cert didn't actually get accepted. Nelson in comment 4 assumes you meant
> the buttons don't work on the dialog (which in hindsight makes more sense).
> Which is it?

When the dialog appears, the OK button doesn't react. It's only possible to click Cancel to dismiss dialog.

Comment 9

[Kai Engert [:KaiE:]]

I can confirm this bug.

It looks like a regression in global user interface code (XUL).

Javascript console shows this error message:

Error: children[i] has no properties
Source File: chrome://global/content/bindings/radio.xml
Line: 90

Comment 10

[Kai Engert [:KaiE:]]

./xpfe/global/resources/content/bindings/radio.xml

Comment 11

[Kai Engert [:KaiE:]]

I found the previous comments confusing and concluded we still have the bug.
Now, after testing, I believe the bug is WORKSFORME.

I confirm, I can see the bug using the build from 05-19.
I have no idea why ftp directory latest-trunk does not contain newer binaries for gtk-2.

Anyway, I downloaded the latest build contained in the directory, which is using the gtk-1 toolkit. No bug, everything works fine.

Finally, I built today's trunk myself, using gtk-2.
It works.

Closing as worksforme.

If I got something wrong, please reopen the bug, and explain what current binary one has to use to see the bug.