Issue #954: If a display is disconnected while KeeWeb is minimized,
when the window position is restored (either during the same session
or after quitting and restarting KeeWeb) it will typically be positioned
where the now disconnected display used to be, making it difficult
for the user to find the window and reposition it to a connected display.
This commit makes KeeWeb check whenever the window position is restored
to be sure there is enough of the title bar on some connected display
that the user can find and drag the window. If there is not, the window
is repositioned to the primary display.
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.
When sending a PUT XMLHttpRequest Chromium includes the header
"Origin: file://".
This confuses some WebDAV clients, notably OwnCloud.
The header is invalid, so removing it everywhere it occurs
should do no harm.
