[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	12989
Summary	Check for Updates requires manually exiting Wireshark and asks redundant questions.
Product	Wireshark
Version	2.2.1
Hardware	All
OS	Windows 8.1
Status	UNCONFIRMED
Severity	Enhancement
Priority	Low
Component	Build process
Assignee	bugzilla-admin@wireshark.org
Reporter	alan.adams@novell.com

Build Information:
Version 2.2.1 (v2.2.1-0-ga6fbd27 from master-2.2)

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.6.1, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.8, with SMI 0.4.8, with c-ares 1.12.0, with Lua 5.2.4, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.

Running on 64-bit Windows 8.1, build 9600, with locale English_United
States.1252, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based
on libpcap version 1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with
Gcrypt 1.6.2, without AirPcap.
      Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz (with SSE4.2), with 8149MB of
physical memory.


Built using Microsoft Visual C++ 12.0 build 40629

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
This enhancement is not specific to any one Wireshark version or Windows
platform, although I am speaking from a Windows platform perspective.

When Wireshark's automatic check for updates finds an updated version is
available, or if you manually invoke "Check for Updates" and a newer version is
found to be available, after Wireshark successfully downloads the new
installation package, when you press the "Install Update" button to proceed
with installation, 100% of the time Wireshark's installer just turns around and
says "you need to exit Wireshark in order to perform installation."

The user initiated the update from /within/ Wireshark, so Wireshark should have
already known that there are existing instances that needed to be closed, and
should have proceeded with closing them.  (At the very least, for the instance
within which the user is selecting "Install Update".)  Its fine if we have to
halt & bring foreground an instance where live capture is still running, where
an unsaved capture is still loaded, etc., but the basic case "should simply
proceed and do the upgrade."

And if you try to be smart about it, by closing Wireshark /before/ hitting the
"Install Update" button to initiate the installation, that doesn't work either.
 The "Install Update" button is being presented by the Wireshark process, and
disappears as soon as you close the running Wireshark instance without having
hit "Install Update" first.

Both behaviors seem non-intuitive and contrary to helping the user easily
update.  What I think of as an "ideal" model is the behavior I see when
updating the Filezilla client on Windows.  If you approve to "Install" the
updated version that is available, the application immediately closes, the
setup runs, and the application re-opens in the newer version.

Same with the "Do you want to uninstall the existing version?" prompt that
appears once the installer is finally running.  The user already answered that
question by saying they /do/ want to upgrade from their current version to the
new version.  Wireshark doesn't have the option to /not/ uninstall the current
version when performing the upgrade (at least not in the Windows version), so
we're simply prompting them again for the same consent they already gave.

I don't know if there is already Windows Restart Manager behavior supported in
Wireshark builds on Windows, but that would be something to leverage here too. 
Meaning if there is already a way for open Wireshark sessions to save state
(which file(s) were open, which packet was selected, what was expanded and what
wasn't, etc.) so that the session can be re-opened after Windows reboots, that
kind of processing should be trying to happen when upgrade has to shut down
your running instances of Wireshark, too.  So that those running instances can
be re-opened them to where you left off, even though Windows doesn't have to
reboot usually when performing a Wireshark upgrade.


The minimum proposed behavior for this enhancement:

When pressing the "Install Update" button after a successful download, at least
exit the instance of Wireshark that the update process is initiated from. 
Meaning the existing "please exit Wireshark" prompt might still happen if there
are /multiple/ instances running, or if for any reason I have an unsaved LAN
trace or active capture in the current instance.  (e.g. Maybe the download is
over a slow link and took time, so I continued working and have unsaved work by
the time the update is ready to install.)

But the basic experience of "I opened my first/only/empty instance of
Wireshark, was offered a new version, downloaded that version and agreed to
proceed" should be simply proceeding without ever asking "exit your running
Wireshark" or "Do you want to uninstall the current version" questions.


The maximum behavior for this enhancement:

Same as above, but we would also be shutting down the other running instances
of Wireshark automatically, saving their state so they can be automatically
re-opened to the same state once the upgrade is finished.  The only "stop and
prompt" will be bringing instances to the foreground that still have live
captures running or unsaved captures still loaded, same as if you had tried to
close those same instances interactively.

---

      You are receiving this mail because:

• You are watching all bug changes.