209082 - Certificate viewer is broken in Win32 build 2003-06-11-05-1.4

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P1)

Description

[John Unruh]

1.) Visit a secure site such as https://www.verisign.com and click on the lock
icon, then on View.
What happens: The cert viewer does not show any info. Trunk build is OK.

Comment 1

[Stephane Saux]

To Kai for investigation.

Comment 2

[Matthew Wilkens]

I'm also seeing this on Linux 20030614.

Comment 3

[Frank Wein [:mcsmurf]]

This seems also be broken on current CVS Trunk builds.

Comment 4

[Kai Engert (:KaiE:)]

My own 1.4 branch build based on 2003-06-03 behaved correctly.
A downloaded 1.4 branch build from 2003-06-12 is broken.

I'm updating my tree now.

Comment 5

[Kai Engert (:KaiE:)]

I see the following new exception on the JS console after having pressed the
view button:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIX509CertDB.findCertByNickname]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://pippki/content/viewCertDetails.js :: setWindowName :: line 93"  data: no]

Comment 6

[Kai Engert (:KaiE:)]

This bug was caused by the checkin from bug 208862.

It sees that unnamed windows no longer carry the name "_blank".

I guess the fix is to test for an empty string?

Comment 7

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 8

[Kai Engert (:KaiE:)]

Comment on attachment 125778 [details] [diff] [review]
Patch v1

Can you please review?

Comment 9

[Dan M]

Comment on attachment 125778 [details] [diff] [review]
Patch v1

Sorry for busting your window. Your proposed change matches my change which
broke you, so that's all well and good. The overall effect will be slightly
different, though.

Currently, any window which was opened either with the name "" or "_blank" will
have a name of "". Previously, windows opened with "" would have been named "".
So your test for "" will catch another class of windows that it wasn't catching
before.

I'm guessing this won't be a problem for you. And glancing over
viewCertDetails.js, actually the new way seems like an improvement. So this is
probably all good, but I wanted to be sure you knew about the new gotcha.

Comment 10

[Kai Engert (:KaiE:)]

Thanks for the explanation. Yes, I think it is fine to execute the same code
block when having an empty window name, regardless whether that was explicitly
chosen or happens to be the default name.

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 125778 [details] [diff] [review]
Patch v1

sr=jst

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 125778 [details] [diff] [review]
Patch v1

sr=jst

Comment 13

[Kai Engert (:KaiE:)]

Fixed on trunk.

Comment 14

[Patrick]

*** Bug 209775 has been marked as a duplicate of this bug. ***

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 125778 [details] [diff] [review]
Patch v1

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 16

[Samir Gehani]

a=adt to land this on the 1.4 branch by 2003-06-19 5am PST and no later please.
 Please mark this with the fixed1.4 keyword once this lands on the 1.4 branch. 
Thanks.

Comment 17

[Kai Engert (:KaiE:)]

Fixed on the Mozilla 1.4 branch, after rc2.

Comment 18

[Kai Engert (:KaiE:)]

*** Bug 209862 has been marked as a duplicate of this bug. ***

Comment 19

[Bruce Davidson]

*** Bug 194714 has been marked as a duplicate of this bug. ***

Comment 20

[Patrick]

*** Bug 209933 has been marked as a duplicate of this bug. ***

Comment 21

[John Unruh]

Verified.

Comment 22

[u60234]

*** Bug 210364 has been marked as a duplicate of this bug. ***

Comment 23

[Matthias Versen [:Matti]]

*** Bug 210432 has been marked as a duplicate of this bug. ***

Comment 24

[u60234]

*** Bug 209709 has been marked as a duplicate of this bug. ***

Comment 25

[Olivier Cahagne]

*** Bug 210758 has been marked as a duplicate of this bug. ***

Comment 26

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.