307446 - New security UI doesn't work when built against 10.4 SDK

Status: RESOLVED FIXED

(Camino Graveyard :: Security, defect)

Description

[Mark Mentovai]

Using Camino built with gcc 4.0 and the 10.4 SDK, static non-debug build:

When visiting a site with an untrusted certificate, the UI is messed up.  The
"Details" label and its disclosure triangle overwrite the certificate icon, and
the certificate icon is cut off.  If you use the disclosure triangle, the app
becomes unstable and unusable: although it doesn't crash (since smfr fixed a
dealloc), performing most functions (including quitting) is impossible.  The
following output appears when the disclosure triangle is actuated:

2005-09-07 22:09:29.493 Camino[21844] Failed to load pipnss string bundle
2005-09-07 22:09:29.497 Camino[21844] *** Assertion failure in -[NSTextFieldCell
_objectValue:forString:errorDescription:], AppKit.subproj/NSCell.m:1298
2005-09-07 22:09:29.497 Camino[21844] Invalid parameter not satisfying: aString
!= nil

(That looks bad.)

I haven't tested other compilers or SDKs, I'm waiting for the nightly to do the
time-consuming part of that for me.

(If this is 4.0/10.4-specific, it doesn't affect the official PPC release, but
it still affects Intel compatibility.)

Comment 1

[Mark Mentovai]

Attachment: Picture of the messed-up certificate dialog

Comment 2

[Mark Mentovai]

Attachment: Fix for apparent stringbundle load failure

Heehee, I bet you were at -O0, relying on lucky use of r3!

This doesn't fix the problems we're up against now, but it will fix whatever
problems we'd be up against next.

Comment 3

[Simon Fraser [no longer active]]

Checked in, thanks! Naughty me for not heeding the warnings.

Comment 4

[Mark Mentovai]

Still more trouble, this patch was just the tip of the iceberg.  There are
bigger problems than the apparent failure to load the stringbundle.  When
hitting a secure site, the certificate dialog pops up, and I get this output:

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/Users/mark/lizard/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
2005-09-08 09:12:00.130 Camino[4428] NSImageCell's object value must be an NSImage.
2005-09-08 09:12:00.481 Camino[4428] *** WARNING: Method
runModalForWindow:relativeToWindow: in class NSApplication is obsolete and will
be removed in release GM ***

When I hit the disclosure triangle: I get this:

mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/Users/mark/lizard/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/Users/mark/lizard/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/Users/mark/lizard/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/Users/mark/lizard/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/Users/mark/lizard/trunk/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
2005-09-08 09:12:06.870 Camino[4428] *** Assertion failure in -[NSTextFieldCell
_objectValue:forString:errorDescription:], AppKit.subproj/NSCell.m:1298
2005-09-08 09:12:06.871 Camino[4428] Invalid parameter not satisfying: aString
!= nil

Comment 5

[Mark Mentovai]

(The funny-looking dialogs were fixed separately, bug 307499.)

The assertions were a failure to load the stringbundle.  It turned out to be a
problem version numbering problem, a result of working with a depend build. 
chrome.rdf pointed to urn:mozilla:package:pipnss at pipnss.jar 1.9a1 and
embed.jar 1.8b2.  Making all of the version numbers match (at 1.9a1) fixed this.
 So did removing the reference to pipnss.jar entirely.

pipnss.jar only contains contents.rdf, nothing else.  All of the pipnss stuff we
use is contained in embed.jar.  Do we still need to bundle pipnss.jar?  I'm
anxious to get rid of it now.

I'm CCing Benjamin, so that he can tell us something like "yeah, version numbers
aren't bumped like they should be in a depend build."

Comment 6

[Benjamin Smedberg]

yeah, version numbers aren't bumped like they should be in a depend build

Comment 7

[Mark Mentovai]

Note bug 178008.

Comment 8

[Mark Mentovai]

There's really nothing more to do here other than advise builders to clobber. 
Followups on what to do with the extra jar file: bug 178008.