Firefox focus query

fbennett

This is more a Firefox/Javascript query than a Zotero question. Please forgive.

In the multilingual version of Zotero, I'm seeing odd behavior with tabbing. The UI is set up to click on the next element when the Tab key is pressed, and that's working to open the field for editing -- except that the focus jumps to the address bar.

http://img844.imageshack.us/f/schizophrenicfocus.png/

This is under Linux. I've tried changing keyboard layouts, and have looked at the system preferences; nothing seems relevant, and I haven't found any settings that have any effect on the behavior. The code to open the next field runs without error. But the focus ends up in the address bar even when I purposely crash Javascript and a much earlier stage.

I'm completely flummoxed by this one. Is there an obvious reason why this might be happening? Any tips on how to debug an issue like this would also be welcome -- I don't know when or how it's happening, so I have no idea where to tie in a stack trace to try to see what's going on. It's all just very odd.

dstillman

I could look into it in more detail later, but a quick comment: tabbing in the metadata pane is not what it seems. Since each editable field is created on-demand when a label is clicked on, we can't rely on the normal Firefox tabbing behavior. So we fake it, and you should be able to find various references to focusing and tabbing in itembox.xml (e.g., _focusNextField). I haven't worked with that code in a while, but, off the top of my head, if you're creating new fields and, say, not making the usual _focusNextField() call in hideEditor(), Firefox could easily take over and do its own thing, and since it doesn't know anything about what we're doing, it'll just start at the beginning of the tab order (i.e., the address bar).

fbennett

It's useful to know that a misstep will end up in the address bar. The last thing in my trace was _focusNextField(), but maybe a notifier or something had been kicking off an additional event. If I'm able to sort it out, I'll post here again (or if I really and honestly decide to throw in the towel).

fbennett

Dan,

Yay! Cracked it. Just as you said, the solution involved catching a keypress event with _focusNextField(). The specific context didn't have one previously, but I found that (mysteriously), an elem.blur() event had become unnecessary (broke things, actually), so it was removed, that that was when things started going awry. I didn't realize that another call needed to be substituted for it.

All smiles now, and it looks like the multilingual branch has cleared its last speed bump on the way to the look and feel of 2.1.