Closed Bug 456155 Opened 16 years ago Closed 16 years ago

Camino shows no browser window

Categories

(Camino Graveyard :: General, defect)

All
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
Camino2.0

People

(Reporter: suishouen, Assigned: stuart.morgan+bugzilla)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.3pre) Gecko/2008091909 Camino/2.0a1pre (like Firefox/3.0.3pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.3pre) Gecko/2008091909 Camino/2.0a1pre (like Firefox/3.0.3pre)

After landing the patch - "Set up and manage a manual keyboard loop in the main window, part 1",
Camino shows no browser window in my own build (10.4.11).
And then Console logs:
-----
Camino[324] *** -[NSCFArray objectAtIndex:]: index (0) beyond bounds (0)



Reproducible: Always
I delete two files and then Camino works.
~/Library/Application Support/Camino/bookmarks.plist
~/Library/Application Support/Camino/bookmarks.plist.bak
Hmm, looking at BrowserWindow.nib, it seems like the "Oldest Target" is set to 10.5.

Let me attach re-saved BrowserWindow.nib that has the target set to 10.4.  Eiichi, can you add it to your build, replace the two bookmarks.plist files you removed and see if that combination works?
No, it doesn't work.
I deleted bookmarks.plist & bookmarks.plist.bak then import bookmarks from my backup,
then Camino works.
Apparently the "Oldest Target" has been set to 10.5 since we landed OpenSearch, with no ill effects.

Is it just coincidence that the bookmarks went corrupt after this patch (and why didn't our "corrupt bookmarks" code detect this corruption, or did the exception kill that code, too)?
Just for reference.

diff -u /Users/eiichi/Desktop/bookmarks.plist /Users/eiichi/Library/Application\ Support/Camino/bookmarks.plist 
--- /Users/eiichi/Desktop/bookmarks.plist       2008-07-23 21:04:44.000000000 +0900
+++ /Users/eiichi/Library/Application Support/Camino/bookmarks.plist    2008-09-20 11:24:02.000000000 +0900
@@ -1977,17 +1977,26 @@
                        <key>Title</key>
                        <string>Bookmark Menu</string>
                        <key>UUID</key>
-                       <string>670BEE73-1A7F-11DA-9C9D-0030656346C8</string>
+                       <string>F8FF4D5A-0E56-4513-9AF7-7FFC0A485340</string>
                </dict>
                <dict>
                        <key>Children</key>
-                       <array/>
+                       <array>
+                               <dict>
+                                       <key>Title</key>
+                                       <string>Translate this Page</string>
+                                       <key>URL</key>
+                                       <string>javascript:void(location.href='http://translate.google.com/translate?u='+location.href)</string>
+                                       <key>UUID</key>
+                                       <string>82DC9330-1623-4EA7-8F3D-A1D54E2D3B41</string>
+                               </dict>
+                       </array>
                        <key>FolderType</key>
                        <integer>4</integer>
                        <key>Title</key>
                        <string>Bookmark Bar</string>
                        <key>UUID</key>
-                       <string>0FA3F935-1A80-11DA-9C9D-0030656346C8</string>
+                       <string>78E1EE04-1803-43A0-80B6-25E6B4A1591D</string>
                </dict>
        </array>
        <key>FolderType</key>
@@ -1995,6 +2004,6 @@
        <key>Title</key>
        <string>Bookmarks</string>
        <key>UUID</key>
-       <string>670BEB79-1A7F-11DA-9C9D-0030656346C8</string>
+       <string>73B1977C-8DAF-4E0E-86D1-977776D54C1B</string>
 </dict>
 </plist>
(In reply to comment #5)
> Apparently the "Oldest Target" has been set to 10.5 since we landed OpenSearch,
> with no ill effects.

I think I decided before that that setting just affects the compatibility warnings it shows in IB.

> Is it just coincidence that the bookmarks went corrupt after this patch (and
> why didn't our "corrupt bookmarks" code detect this corruption, or did the
> exception kill that code, too)?

The bookmark file isn't corrupt. I'm pretty sure the problem is that the bookmark bar tab chain code can't handle an empty bookmark bar, which is what the difference between the two files is. I'll update shortly.
(In reply to comment #7)
> The bookmark file isn't corrupt. I'm pretty sure the problem is that the
> bookmark bar tab chain code can't handle an empty bookmark bar, which is what
> the difference between the two files is. I'll update shortly.

That's seems to be correct.
I deleted Translate this Page in  Bookmaks Bar and has an empty bookmark bar, then
Camino loses the browser window and the bookmark manager window.
Hardware: PC → All
Attached patch fixSplinter Review
Make sure we handle zero bookmarks in the bar correctly.
Assignee: nobody → stuart.morgan+bugzilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
I just went ahead and landed this on cvs trunk, since it's a trivial fix for a very nasty regression.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Camino2.0
Thanks for a quick fix, Stuart.
I confirmed Camino works fine with empty bookmark bar.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: