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) 6.Crashes Actual Results: Says: Navigator has unexpectedly quit etc.... Expected Results: Shown the toolbar.
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.
reproduced using 08-09 build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Bad bug. User must trash profile to regain toolbar.
Summary: Show Toolbar crashes Chimera → Show Toolbar crashes Chimera [@ _CFBundleCopyDirectoryContentsAtPath]
Assignee: saari → pinkerton
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] fix 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.
dave, max? so, um, should we just back all this NSTextView stuff out?
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.
fixed with landing of 161621
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified in the 2002-08-21-05 NB.
Status: RESOLVED → VERIFIED
Crash Signature: [@ _CFBundleCopyDirectoryContentsAtPath]
You need to log in before you can comment on or make changes to this bug.