Show Toolbar crashes Chimera [@ _CFBundleCopyDirectoryContentsAtPath]



Camino Graveyard
16 years ago
16 years ago


(Reporter: Thien Pham, Assigned: Mike Pinkerton (not reading bugmail))




(crash signature)


(2 attachments, 1 obsolete attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020809
BuildID:    2002080905

When selecting Hide Toolbar, restarting Chimera, and then selecting Show
Toolbar, the browser crashes. Trashing the Prefs.js file does nothing and
trashing the entire Chimera Directory ing ~/Application Support does nothing also.

Also clicking on the white button on the title bar crashes the browser too.

Reproducible: Always
Steps to Reproduce:
1.Start Chimera
2.Click View | Hide Toolbar
3.Exit Chimera
4.Start Chimera
5.Click View | Show Toolbar (or white button)

Actual Results:  Says: Navigator has unexpectedly quit etc....

Expected Results:  Shown the toolbar.

Comment 1

16 years ago
Created attachment 94716 [details]
Chimera crash log

The newest crashlog for this problem


16 years ago
Attachment #94716 - Attachment is obsolete: true

Comment 2

16 years ago
Created attachment 94719 [details]
Correction: Crash Log

The other crash log included a lot of stuff that I don't think should have been
there. This one should be the one.

Comment 3

16 years ago
reproduced using 08-09 build.  
Blocks: 147975
Ever confirmed: true

Comment 4

16 years ago
This is most probably the same bug that causes bug 161621.

In both cases, the NSCoder implementation we use for our NSTextView 
subclass is clearly not sufficient. Given that we have no source access to 
NSView nor NSTextView, I see no reliable way to make it work correctly.

The only two solutions I see right now are:
1) Switch back to a NSTextField subclass. We can try to achieve the undo 
behaviour anyway.

2) Instead of changing the NSCoding stuff in our 
CHAutoCompleteTextField as we do right now, we could change 
CHLocationBar - simply remove the CHAutoCompleteTextField before 
encoding, and add it back when decoding (add it back = create it on the 
fly). This is some work, but it should be feasible.

Comment 5

16 years ago
Bad bug. User must trash profile to regain toolbar.
Keywords: crash
Summary: Show Toolbar crashes Chimera → Show Toolbar crashes Chimera [@ _CFBundleCopyDirectoryContentsAtPath]

Comment 6

16 years ago
ick, ideas?
Assignee: saari → pinkerton

Comment 7

16 years ago
Actually, scratch my comment 5. Trashing the profile doesn't restore the toolbar. The user must 
trash org.mozilla.navigator.plist or edit the "TB Is Shown" value within it.
Created attachment 94871 [details] [diff] [review]

The problem looks to be with a probable bug in 10.1.5 that we were working
around in a not-quite-correct way.  This is a more correct workaround.

It's related to bug 161621 only in that we needed to work around the OS bug
because our toolbar item with a custom view doesn't seem to realize when it's
already present in the toolbar (probably because of coding issues), so needs to
be forcably removed if it's added twice.

Comment 9

16 years ago
dave, max?

so, um, should we just back all this NSTextView stuff out?


16 years ago
Keywords: patch, review

Comment 10

16 years ago
I vote for backing it out. If we can come up with an undoable NSTextField later,
we can use it. For now, it's causing too many issues.
Patch in bug 161621 changes textview back to a text field & should fix this.
Depends on: 161621

Comment 12

16 years ago
fixed with landing of 161621
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

16 years ago
Verified in the 2002-08-21-05 NB.


16 years ago
No longer blocks: 147975
Crash Signature: [@ _CFBundleCopyDirectoryContentsAtPath]
You need to log in before you can comment on or make changes to this bug.