2 listeners handle shortcuts and hotkeys: bubbling ZoteroPane.handleKeyDown
and capturing Zoteropane.captureKeyDown.
We generally want shortcuts to be handled by the non-capturing listener
to avoid a conflict with lower level component that may want to handle the event
(e.g. we want to handle Escape keypress only if nothing else took care of it).
Tab navigation is an exception, since we want it to happen all the time.
For example, Ctrl+PageUp can be handled by itemTree but we want to override
it to make sure that it selects the tab regardless of other listeners.
This fixes regression after 5f0e3d5
where the tab selection logic was never reached because the event was handled
by itemTree.
- Bring back un-highlighting of collections on keydown if any other
control key besides Ctrl/Options is pressed (with better comments).
It fixes regression after 527fa5b12f
where if one presses, for example, Ctrl-Shift-A to copy an item,
collection highlighting would scroll the collection tree for no reason.
- To decrease the chance of collection highlighting being activated when
it is not intended, only highlight collections when the itemTree is focused
- handle additional focusElementID options value in Zotero_Tabs.select to
focus a node with the specified ID, instead of what was recorded
as last focused element
- use that parameter in ZoteroPane.selectItems to make sure that
itemTree is focused after the tab is switched to zotero-pane
- removed redundant calls to Zotero_Tabs.select('zotero-pane') after
Zotero_Pane.selectItems
Use <checkbox> instead of <html:input type="checkbox"> for the
suppress author checkbox. <html:input> on mousedown on the actual box
looses focus, so the popover is immediately closed by focusout listener.
Fixes: #3830
- Remove directories that should no longer be present in the build.
- Add watching for new files.
- Add debounce and batching to reduce verbosity and avoid needless cleanup and "add to omni" steps
when entire directories are affected.
We can await /usr/bin/open on macOS because it returns as soon as the
application has begun launching, but we can't await when we exec a
program directly on other platforms.
Fixes#3799
When contextmenu closes, it clears visibility style from all components.
It is added temporarily so that the options buttons do not
disappear if the mouse leaves the row. The visibility setting for
the grippy for items with only one author should be in
a separate class so that grippy is not displayed by accident.
Fixes: zotero#3732
_setState() doesn't await setAttachmentLastPageIndex(), so the setting
sometimes won't be updated in the cache by the time we call
getAttachmentLastPageIndex() below. Notifier event should work every
time (and is a lot simpler).
Hardcode transparent background and black text color for inputs.
Otherwise, the inputs end up with dark background and white text
which does not work with the rest of the dialog that always has white
background.
This is temporary until the rest of the dialog works with the dark mode.
Fixes: #3768
- Backspace from the very beginning of the input will delete the previous
bubble, as opposed to removing the input itself. If it makes it so that
two inputs are next to each other, they are merged.
- When a new input is created via a mouse click, and the current input
is empty, manually delete it right away. Waiting for the blur handler
to remove it makes it so that the bubbles shift back and forth for a moment
when a new input is added and the old input is not removed.
- Minor tweak to make sure that even if there's a 'br' before an input,
clicking before it will not make a new input and just refocus it.
Fixes: zotero#3749
- Run label update logic once instead of repeating on every item
- Show plural attachment type when multiple attachments of same type
are selected (instead of "Attachments")
- Fix incorrect icon and label showing when openReaderInNewWindow = true
- ZoteroPane.handleKeyDown does not capture events. It is not strictly
necessary now but it helps to avoid future issues such as one solved in
b15fb36f1b. One benefit from this now is
if one tabs onto a toolbarbutton that opens a menu in contextPane (e.g.
an options button in itemBox), clicks space to open the menu and then
escape to close it, this will keep focus where it was, while the capturing
listener would immediately shift the focus to the reader.
- Removed shift-tab specific case from the handler. It looks like it
was handling the shift-tab in the following scenarios:
from notes search bar (can just be handled by Tab),
from "Return to notes list button" in note editor toolbar (it's no longer there),
from a child of zotero-view-item e.g. itembox. (does not apply,
since zotero-view-item itself is a focusable scrollable area)
- use reader.focus() instead of reader.focusFirst() in tab handler,
since focusFirst() focuses the <body> of the browser and it's not interactable.
