The fix for alt-tab behavior when KeeWeb is minimized to the tray
in 3dae878 left a problem when auto-type raises a selection list: the
taskbar button shows, and after a selection is made KeeWeb minimizes
to the taskbar but leaves a tray icon present. The same thing happens
if auto-type is canceled by clicking either the minimize button or the
close button at the top right of the selection window. From this state,
various scenarios lead to having duplicate tray icons.
This commit restores the behavior of 1.6.3 when auto-type raises
a selection list while KeeWeb is minimized to the tray: the selection
window shows, the tray icon stays, and no taskbar button shows.
We used to minimize the window after selection regardless of its
previous state; this worked because we hid the taskbar button and
minimized the window when minimizing to the tray, but that's what caused
the alt-tab problem. Since we now hide when minimizing to the tray,
we have to know whether to minimize or hide after selection.
The simplest way to do that is to keep the old behavior of leaving the
tray icon present when auto-type raises a selection window while KeeWeb
is minimized to the tray. Instead of calling minimize on the main
window, launcher-electron.js now calls app.minimizeThenHideIfInTray
which is defined in desktop/app.js. That routine minimizes KeeWeb (which
returns focus to the previously active window) and then hides the main
window if and only if a tray icon is present. Because we don't want a
tray icon and a taskbar button present at the same time, app.minimizeApp
is also changed to restore the call to mainWindow.setSkipTaskbar(true)
in the non-Darwin path; thus, when auto-type raises a selection window,
there won't be a taskbar button if KeeWeb was minimized to the tray.
If auto-type is canceled by clicking the top right close button while a
selection list is displayed and there is a tray icon, the KeeWeb window
is hidden and the tray icon stays, just as one would expect. This is
the most likely way someone using "Minimize app instead of close" would
choose to dismiss the auto-type selection list.
If auto-type is canceled when a selection list is displayed while there
is a tray icon by clicking the top right minimize button, by using
alt-tab, or by clicking outside the selection window, the KeeWeb window
reverts to its normal display and shows in the alt-tab list, but the
tray icon remains and no taskbar button is shown. This is not ideal;
it could be addressed in another commit if it seems worth doing. This
commit mitigates these scenarios by adding a check to app.minimizeApp
to assure that we never create a second tray icon if one is already
present. This can do no harm and might catch other "corner cases" that
are difficult to foresee. The next time the tray icon is clicked or
the app is minimized to the tray by clicking the top right close button
normal behavior is fully restored.
If I've made no mistakes, the only change to the Darwin path is that it,
too, is subject to the check that a new tray icon is not created if one
already exists. I'm guessing that's OK, but I have no way to test
Darwin.
Adding max-width, white-space, overflow and text-overflow to "a" children
of .details_field-value elements corrects an anomaly with long Website
values. Previously they displayed wider than other values, and the space
in which one could click to edit the field without triggering the link
was very thin. This establishes what was presumably the intended behavior.
Removing white-space from .details__attachment-preview-download-text
allows the text to wrap when the details pane is too narrow to show it all
on one line.
Replacing margin-right with max-width in .details__history fixes
issue #945 and makes fields in the history wrap as they do
in the ordinary details pane.
Adding flex to .details_history-top prevents the history details from
overlapping the navigation controls when the window height is too small
to show everything without scrolling.
Adding padding-right and margin-right to .details__history-top and
.details__history-buttons keeps those elements from overlapping
the scroll bar and aligns their right edges with the right edges
of the widest .details_field-value elements.
These changes make it possible to drag the value of a field in the
details view by dragging its label. The value dragged is the same
as would be copied by clicking on the label.
While app-view already prevented the default action for files and urls
in a browser window (navigation), the drag indicator showed that any
drop was possible. These changes cause the drag indicator to show that
nothing can be dropped on areas of the interface that don't contain
a drop target. The addition of dragenter avoids some flickering which
otherwise can occur when dragging a file rapidly across the group
or entry lists.
Accompanying changes to details-view, menu-item-view and open-view are
needed because those views relied on "inheriting" from app-view
the indication that dropping anything was allowed.
In testing, making labels draggable resulted in a lot of annoying,
flashing indications of drop targets in places where text cannot
be dropped. This change causes the details view to show the message
panel indicating that a file can be dropped only when the drag contains
a file.
