Erratic note behaviour together with search

This happens everytime: When creating a child note (cursor on a main entry) after having used the search field (i.e. the string still visible in the search-box) my new note unfailingly disappears after I type a couple of characters into the right hand panel's note-section. What seems to happen is the closing-up of the main-entry, followed by a redraw of the (contexutal) right-hand panel. When I open the note again and continue typing, the same thing happens after a few seconds of typing.

When I use the standalone-option for typing in the note I can actually see how the unfolded main entry suddenly clams up; in this case the note stays open. – This seems to be related to a similar issue around working with notes when the searchfield is in action I posted a couple of days ago:

Am unsure, whether this issue might need another ticket or could be handled under the one Dan created here
  • Just to be sure, you're saying this only happens when you're using quick search? And this still happens in 2.0b7.4?

    I don't lose focus simply editing a note with a quick search entered. I can only reproduce this (or something similar) if I delete the word in the note that's causing the quick search to match—Zotero automatically clears the quick search so that it can continue to display the note item, but something weird happens to the note field's focus. (The cursor remains in the field, but typing doesn't work.) I've created a ticket for this.
  • Dan, cannot repeat this behaviour in 2.0b7.4 anymore. Using quick search and creating a child note does take a strangely longtime (4-5 secs) but the note does get created, gets the focus and a blinking cursor in the righthand pane; it does neither lose focus after I enter text nor disappear as in the previous version. So all seems well!

    Sorry for not having tested this with the latest version of Zotero before adding my comment in the other thread. (And thanks for pointing out what I got wrong with the trac ticket)
    I'm on OS 10.5.8, FF 3.5.5
  • The note problem is back in 2.0b7.6. I'm sure this was working fine in 2.0b4/5 after I had written about it here and in this thread – and everything seemed fixed with 2.0b7.4

    I experience two different issues:
    When I find a main entry in the midddle pane by using quick search and then create a child note (focus on main entry)
    (a) the new note gets created
    (b) the quicksearch field is cleared
    (c) I'm back in my unsorted library
    I would expect instead:
    (a) the main entry to show the new childnote
    (b) the quicksearch field to retain my search string
    (c) The focus to move to the right panel, cursor in newly created note.

    Issue two:
    As long as I have a search string visible in the quick search while typing a note in the right pane, the note unfailingly disappears after a few keystrokes. If I re-open it and continue typing (i.e. with the quick search box still showing a search string) the note disappears again. This does not happen if I open the note in a separate window (although I can see after typing a few keystrokes into the note window that in the middle pane the previously opened-up main entry collapses.)

    I'm using FF 3.5.6 on OS X (10.5.8) and 2.0b7.6. Thanks for looking into this.
  • Any news on these two issues? After it looked as if one was fixed in 2.0b74 both are definitely unresolved now and invariably occur under the conditions described above – (Zotero 2.03 / FF 3.6.6 OSX 10.6.4):
    (i) Loss of focus when creating a new childnote after finding an entry with quick search and
    (ii) disappearance of a childnote while typing in righthand pane when quick search string is still visible.

    The snag seems to be about the use of quick search, since otherwise, the notes behave as would be expected. – The points seem minor but are a regular annoyance in the otherwise smooth workflow of finding an existing entry with search, adding a childnote, typing some text into it. Grateful for attention to this.
    Thanks, kithairon
Sign In or Register to comment.