| Bug ID |
12485
|
| Summary |
Qt: After changing Coloring Rules, the selected packet’s frame tree's coloring rules details are not immediately updated
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86
|
| OS |
Mac OS X 10.10
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Qt UI
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14609 [details]
Before and after snapshots after temporarily selecting a different packet.
Build Information:
Version 2.1.0-3223-g281691f (v2.1.0rc0-3223-g281691f from unknown)
Copyright 1998-2016 Gerald Combs <[email protected]> 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.3.2, with libpcap, without POSIX capabilities, with
GLib 2.36.0, with zlib 1.2.5, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2,
with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with
QtMultimedia, without AirPcap.
Running on Mac OS X 10.10.5, build 14F1808 (Darwin 14.5.0), with locale C, with
libpcap version 1.5.3 - Apple version 47, with GnuTLS 2.12.19, with Gcrypt
1.5.0, with zlib 1.2.5.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.9.00).
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Note: The following behavior is similar --- but not identical --- to symptom
reported in Bug 12475.
If a coloring rule changes the rule assigned to the currently selected packet,
the packet's frame tree will not be immediately updated to reflect the new
coloring rules (if any) in effect for the selected packet.
Steps to reproduce.
1 - Open a capture with some ICMP packets.
If the default ICMP coloring rule is enabled (and coloring rules are globally
enabled) then any ICMP packets should be colored pink.
2 - Select one of the ICMP packets (but not the first displayed packet: see Bug
12475 for why).
3 - Confirm that the selected packet's packet list frame tree displays the
[Coloring Rule Name: ICMP] and [Coloring Rule String: icmp || icmpv8] entries.
4 - Open the Coloring Rules dialog and disable the ICMP coloring rule.
5 - Click [OK] to close the Coloring Rules dialog and apply the updated
coloring rules.
6 - Confirm that the selected packet's packet list frame tree still displays
the now obsolete [Coloring Rule Name: ICMP] and [Coloring Rule String: icmp ||
icmpv8] entries.
7 - Move focus to another packet.
8 - Move focus back to the originally selected packet.
9 - Confirm that the selected packet's packet list frame tree no longer
displays any [Coloring Rule Name:] nor [Coloring Rule String:] entries.
10 - Reopen the Coloring Rules dialog and re-enable the ICMP coloring rule.
11 - Again click [Ok] to close the Coloring Rules dialog and apply the updated
coloring rules.
12 - Confirm that the selected packet's packet list frame tree does NOT display
the expected [Coloring Rule Name: ICMP] and [Coloring Rule String: icmp ||
icmpv8] entries.
13 - Move focus to another frame and back to the original frame.
14 - Confirm that the selected packet's packet list frame tree now displays the
expected [Coloring Rule Name: ICMP] and [Coloring Rule String: icmp || icmpv8]
entries.
Workaround: After changing Coloring Rules move focus to another packet and
back to the original packet to get the original packet's frame tree [Coloring
Rule Name:] and [Coloring Rule String:] entries to display the current rule (if
any).
You are receiving this mail because:
- You are watching all bug changes.
