159655 - Previously selected bookmark/folder name still appears in Bookmark dialog

Status: VERIFIED FIXED

(Camino Graveyard :: Bookmarks, defect)

Description

[Chris Petersen]

Build: 2002-07-26-05
Platform: OS X 10.1.5
Expected  Results: Bookmark dialog should only show currently selected
bookmarks/folders
What I got: Previously selected bookmark/folder name appears in Bookmark dialog
(which you can edit !)

Steps to reproduce:

1) Select a folder in sidebar and click on Pencil icon to should bookmark
dialog. Verify information is correct. Close dialog.

2) Now, unselect this folder by clicking in blank area of sidebar.

3) Click on Pencil icon. Notice folder's name is appearing and can be edited.

Comment 1

[Chris Petersen]

With slightly modified steps I can reproduce a crash:

1) Open side bar and select bookmark. 
2) Click Pencil icon to display Bookmark info. Close this dialog.
3) Delete this bookmark.
4) After bookmark is deleted, unselect any folder or bookmark in side.
5) Now, press the pencil icon again. A crash should occur.

Comment 2

[Chris Petersen]

Attachment: Stack trace from crash

Comment 3

[David Haas (gone, not reading mail)]

Attachment: proposed fix

This isn't going to fix the window which doesn't disappear when the bookmark is
unselected.  I believe this will get rid of your crash.

Everytime I put anything that updated bookmark info in
"controlTextDidEndEditing" I'd stumble across a crash.	That's why all the
update code had been moved into windowDidResignKey.  Some managed to sneak back
in to DidEndEditing, so this patch gets rid of it.

Comment 4

[David Haas (gone, not reading mail)]

Attachment: fix

When nothing's selected, there's no info window anymore.

It also cleans up the crash mentioned in this bug, and possibly (maybe)
(hopefully) deals with some of the random, tough-to-repeat crashes that
happen when editing bookmarks.	We'll see.

Comment 5

[Mike Pinkerton (not reading bugmail)]

+-(void)windowDidBecomeKey:(NSNotification*) aNotification
+{
+  [[self window] makeFirstResponder:mNameField];
+}
 
why set this explicitly? what if i focus the url bar then click into one of the
other text fields in the info panel? will it preempt me and focus the name field?

Comment 6

[David Haas (gone, not reading mail)]

Notice in windowDidResignKey it's setting the firstResponder to the window. 
This frees up the field editor (which might fix some of the hard-to-reproduce
crashes) and prevents a crash if the panel is open on delete.  

If we don't reset the firstResponder to a textfield, and click on a random part
of the window (not a field) i don't think any text fields are editable, so then
you have to click again, which is annoying.  at least i'm pretty sure that's
what happened when it wasn't set explicitly.

if you click on a different text field to wake the window back up that field
becomes active - so it doesn't preempt you.  at least it didn't when i just
tried it a second ago.

Comment 7

[Mike Pinkerton (not reading bugmail)]

patch needs some tweaking. when there's no selection, i can still open the info
window, and not only that, it will still have the last deleted item in it.
However, it doesn't crash. I'm on it.

to answer my previous question, clicking back into the info window focuses the
field i clicked in, which is good ;)

Comment 8

[Mike Pinkerton (not reading bugmail)]

wow, we somehow lost some outlets in the bookmarks data source. i'm hooking them
up again to disable the buttons when there's no selection.

Comment 9

[David Haas (gone, not reading mail)]

I think smfr was hooking up the edit/delete buttons so that they'd be disabled
when nothing was selected.  i guess it hasn't been check in yet.  it's another
bug, somewhere.  

Comment 10

[Mike Pinkerton (not reading bugmail)]

landed with some extra changes, fixed the nib, ensure the info/edit buttons are
disabled when the window awakes from nib.

Comment 11

[Chris Petersen]

Marking verified in the 2002-07-30-05 NB.