After a context menu was shown the first time, the item under the cursor of subsequent context menus usually only remained highlighted for about a second
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: matt.fagnani, Unassigned)
Details
(Keywords: regression)
Attachments
(4 files)
Steps to reproduce:
I ran Thunderbird 131.0a1 (2024-08-14) on Wayland in Plasma 6.1.4 in a Fedora 40 KDE installation. I right-clicked on emails in lists to show the context menu many times. I moved the cursor over the items in those context menus without selecting anything. I opened emails and right-clicked on various parts of them such as links, the background of the main part, the From and To fields etc. many times to show the context menus. I moved the cursor over the items in those context menus without selecting anything. I did the steps above on many Thunderbird runs.
Actual results:
After a context menu was shown the first time, the item under the cursor of subsequent context menus usually only remained highlighted in grey for about a second even though the cursor was still over the item. This problem happened both for context menus of emails in lists and when reading emails when right-clicking on links, the background of the body, the From and To fields etc. When the highlight disappeared from the context menus for emails in lists, other parts of the interface were often incorrectly highlighted such as folders in the folder lists, the Get Messages and New Message widgets above the folder lists, and the Spaces Menu widget at the top left of the window one at a time in a seemingly random way. The problem happened 70-90% of the Thunderbird 131.0a1 (2024-08-14) runs.
I didn't see this problem with Thunderbird 131.0a1 (2024-08-13) and earlier. Bisecting is complicated by a previous problem with Thunderbird 131.0a1 (2024-08-13) in which context menus after the first one shown were usually unresponsive so the highlight wasn't shown Bug 1913037 That problem didn't happen with 131.0a1 (2024-08-14). I'll try to bisect again with mozregression, but the problem might be with a change in mozilla-central and so might not have Thunderbird builds.
Expected results:
The context menu items under the cursor should've remained highlighted in grey as long as the cursor was over them. Other parts of the interface shouldn't have been highlighted incorrectly when the highlight in the context menu disappeared for emails in lists.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 1•2 years ago
|
||
The context menu items affected by this problem for emails in message lists are: the top five icons Mark As unread, Reply, Archive, Mark as Junk, Delete Message, and items below those without popup submenus Edit as New Message, Move to ... Again, Save As, and Print. Those items with submenus like Open, Reply, etc. don't seem to show this issue. This problem also affects 131.0a1 (2024-08-15). I bisected between 2024-08-13 and 2024-08-14. I marked the one bisection build showing Bug 1913037 as good because it didn't show the current problem, but Bug 1913037 could've masked this one. The final pushlog showed 9 changes which looked to be mostly Windows specific. The problem might have been introduced to mozilla-central before those ones on 2024-08-13.
4:37.92 INFO: Narrowed integration regression window from [1be42fa6, 1d6240cf] (3 builds) to [81bc2da7, 1d6240cf] (2 builds) (~1 steps left)
4:37.92 INFO: No more integration revisions, bisection finished.
4:37.92 INFO: Last good revision: 81bc2da7dc17b1c47f9a983acbf92a01994b8b88
4:37.92 INFO: First bad revision: 1d6240cf1717defb42e30cfe4d06b36b6084dccf
4:37.92 INFO: Pushlog:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=81bc2da7dc17b1c47f9a983acbf92a01994b8b88&tochange=1d6240cf1717defb42e30cfe4d06b36b6084dccf
| Reporter | ||
Comment 2•2 years ago
|
||
I'm reassigning this report to Core: Widget: Gtk because that might be more appropriate. This problem still happens with Thunderbird 131.0a1 (2024-08-19).
Comment 3•2 years ago
|
||
Can you create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Create_screenshot/screencast_for_a_bug_report
Thanks.
| Reporter | ||
Comment 4•2 years ago
|
||
I'm attaching a recording of the problem with Thunderbird 131.0a1 (2024-08-21) on Wayland in Plasma 6.1.4 in a Fedora 41 KDE installation. I had already opened a context menu before I started the recording. The highlighting disappeared after about 1 second for the context menu's top five icons Mark As Unread, Reply, Archive, Mark as Junk, Delete Message, and items below those without popup submenus Edit as New Message, Move to "Inbox" Again, Save As, and Print. When the highlight disappeared for Mark As Unread, the Spaces Menu button at the top left of the window was incorrectly highlighted. When the highlight disappeared for Mark As Unread, the Spaces Menu button at the top left of the window was incorrectly highlighted. When the highlight disappeared for Move to "Inbox" Again, the Sent folder for the top account's folder list was incorrectly highlighted. When the highlight disappeared for Save As, the Fedora folder in the Local folders list was incorrectly highlighted. The same problem happened for context menus when reading emails which I could record if you want. Thanks.
Comment 5•2 years ago
|
||
Please run on terminal with MOZ_LOG="WidgetPopup:5" env variable, reproduce the issue and attach the log here.
Thanks.
Comment 6•2 years ago
|
||
Also please try to run with MOZ_ENABLE_WAYLAND=0 (i.e. as X11 app).
| Reporter | ||
Comment 7•2 years ago
|
||
Output of Thunderbird 131.0a1 (2024-08-27) with MOZ_LOG="WidgetPopup:5" when I reproduced the problem. I opened a context menu for an email in a message list by right-clicking on it, closed it, opened another context menu on the email, moved the cursor over each of the top five icons in the menu until their highlights disappeared, then moved the cursor over the four context menu items without submenus in a similar way. The problem didn't happen with Thunderbird 131.0a1 (2024-08-27) on XWayland using MOZ_ENABLE_WAYLAND=0 in a few runs. Thanks.
| Reporter | ||
Comment 8•2 years ago
|
||
When I ran Thunderbird 131.0a1 (2024-08-27) with MOZ_LOG="WidgetPopup:5" and the highlight disappeared on context menu items which weren't the five icons at the top, lines like the following were output though they also were shown when the highlight didn't disappear.
[Parent 9515: Main Thread]: D/WidgetPopup [7fb7d4c07c00]: nsWindow::SetInputRegion(1, 0)
When I ran Thunderbird 131.0a1 (2024-08-27) with MOZ_LOG="WidgetPopup:5" and the highlight disappeared on context menu items which were the five icons at the top, lines like the following were output
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00] NativeMoveResizeCallback flipped_x 0 flipped_y 0
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00] new position [196, 167] -> [237 x 121]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: orig mBounds [724, 388] -> [237 x 121]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::WaylandGetParentPosition() [528, 221]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: new mBounds [724, 388] -> [237 x 121]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::WaylandPopupPropagateChangesToLayout()
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::OnExposeEvent GdkWindow [7f1e482cb4a0] XID [0x0]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: quit, !moz_container_wayland_can_draw()
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::SetInputRegion(0, 4)
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: moz_container_wayland_add_or_fire_initial_draw_callback ConfigureCompositor
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::ResumeCompositorImpl()
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: GtkCompositorWidget::SetRenderingSurface() [7f1e4a76db00]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: configure widget 7f1e4a76db00
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::OnExposeEvent GdkWindow [7f1e482cb4a0] XID [0x0]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::RequestRepaint()
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: needs composite, ScheduleComposite() call
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: redirect painting to OMTC rendering...
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: CaptureRollupEvents(0)
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a768600]: CaptureRollupEvents(1)
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::Show state 0 frame Frame(7f1e47769270) menupopup
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::NativeShow hide
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::WaylandPopupMarkAsClosed: [7f1e4a76db00]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::UpdateWaylandPopupHierarchy
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Widget Popup Hierarchy:
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Frame(7f1e4f90fb18) menupopup Menu nsWindow [7f1e4a768600] Menu 1 Permanent 0 ContextMenu 1 Anchored 0 Visible 1 MovedByRect 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Frame(7f1e47769270) menupopup Menu nsWindow [7f1e4a76db00] Menu 1 Permanent 0 ContextMenu 1 Anchored 1 Visible 1 MovedByRect 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Layout Popup Hierarchy:
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Frame(7f1e4f90fb18) menupopup Menu nsWindow [7f1e4a768600] Menu 1 Permanent 0 ContextMenu 1 Anchored 0 Visible 1 MovedByRect 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: first changed popup [7f1e4a76db00]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::WaylandPopupHierarchyHideTemporary()
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::WaylandPopupRemoveClosedPopups()
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::HideWaylandPopupWindow: remove from list 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: gtk_widget_is_visible() = 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::OnUnmap
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: GtkCompositorWidget::CleanupResources [7f1e4a76db00]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::SetCompositorWidgetDelegate 0 mIsMapped 0 mCompositorWidgetDelegate 7f1e4c7629a0
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: GtkCompositorWidget::~GtkCompositorWidget [7f1e4a76db00]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: GtkCompositorWidget::CleanupResources [7f1e4a76db00]
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Clearing mMoveToRectPopupSize
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: last popup was removed, quit.
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Widget Popup Hierarchy:
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Frame(7f1e4f90fb18) menupopup Menu nsWindow [7f1e4a768600] Menu 1 Permanent 0 ContextMenu 1 Anchored 0 Visible 1 MovedByRect 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Layout Popup Hierarchy:
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: Frame(7f1e4f90fb18) menupopup Menu nsWindow [7f1e4a768600] Menu 1 Permanent 0 ContextMenu 1 Anchored 0 Visible 1 MovedByRect 1
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::OnWindowStateEvent for 7f1e4798d760 changed 0x1 new_window_state 0x81
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: early return because no interesting bits changed
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::OnWindowStateEvent for 7f1e4a9dd4f0 changed 0x1 new_window_state 0x81
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: nsWindow::SetHasMappedToplevel(0)
[Parent 10804: Main Thread]: D/WidgetPopup [7f1e4a76db00]: quick return because IS_MOZ_CONTAINER(aWidget) is true
| Reporter | ||
Comment 9•2 years ago
|
||
I saw this problem with Firefox 131.0a1 (2024-8-30) on Wayland. When I right-clicked on links on bugs.kde.org to show context menus a second time, the highlights disappeared after about a second even though the cursor was still over the menu items, and for some of the items, the tab in the tab bar was incorrectly highlighted and the tab preview was shown, the button to the left of the tabs in the tab bar in a new profile was highlighted, or the reload button was highlighted incorrectly. I'm attaching a recording of this problem in which the second context menu over Search at the top of bugs.kde.org had the highlights of the top four menu items disappear while the cursor was still over them. When the cursor was over Open Link in New Private Window, the tab in the tab bar was incorrectly highlighted and the tab preview was shown.
| Reporter | ||
Comment 10•2 years ago
|
||
I'm attaching the output of Firefox 131.0a1 (2024-8-30) with MOZ_LOG="WidgetPopup:5" corresponding to the run of the recording. When the highlight disappeared over the context menu items while the cursor was still over them, the output was the following lines repeated each time like nsWindow::SetInputRegion(1, 0) like with Thunderbird. Above those lines were repeated lines like quick return because IS_MOZ_CONTAINER(aWidget) is true and Widget Popup Hierarchy and Layout Popup Hierarchy were Empty which I saw with Thunderbird for the top five icons in the context menus. Could those Popup Hierarchies being empty be involved in the problem?
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: Widget Popup Hierarchy:
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: Empty
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: Layout Popup Hierarchy:
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: Empty
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: nsWindow::Show state 0 frame Frame(7f0b451d8748) menupopup
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: nsWindow::NativeShow hide
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: nsWindow::HideWaylandPopupWindow: remove from list 1
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: gtk_widget_is_visible() = 0
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: Clearing mMoveToRectPopupSize
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: nsWindow::Show state 0 frame Frame(7f0b52adfa40) menupopup
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: nsWindow::NativeShow hide
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: nsWindow::HideWaylandPopupWindow: remove from list 1
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: gtk_widget_is_visible() = 0
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: Clearing mMoveToRectPopupSize
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: nsWindow::Show state 0 frame Frame(7f0b54e64e40) menupopup
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: nsWindow::NativeShow hide
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: nsWindow::HideWaylandPopupWindow: remove from list 1
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: gtk_widget_is_visible() = 0
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: Clearing mMoveToRectPopupSize
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: nsWindow::OnWindowStateEvent for 7f0b4b3d0760 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: early return because no interesting bits changed
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: nsWindow::OnWindowStateEvent for 7f0b4a093130 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: nsWindow::SetHasMappedToplevel(0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4a144900]: quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: nsWindow::OnWindowStateEvent for 7f0b4a017c60 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: early return because no interesting bits changed
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: nsWindow::OnWindowStateEvent for 7f0b52a7ff30 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: nsWindow::SetHasMappedToplevel(0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b4c649b00]: quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: nsWindow::OnWindowStateEvent for 7f0b529eb660 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: early return because no interesting bits changed
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: nsWindow::OnWindowStateEvent for 7f0b52a7ee50 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: nsWindow::SetHasMappedToplevel(0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9eb00]: quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: nsWindow::OnWindowStateEvent for 7f0b4a017f60 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: early return because no interesting bits changed
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: nsWindow::OnWindowStateEvent for 7f0b545815d0 changed 0x1 new_window_state 0x81
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: nsWindow::SetHasMappedToplevel(0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b51e9d200]: quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: mBounds: x:0 y:0 w:0 h:0
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow::Create() Popup
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: set parent window [7f0b7832d100] browser
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow type 2
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: mShell 7f0b45153c60 (window 7f0b4b32e7e0) mContainer 7f0b4a093e50 mGdkWindow 0 XID 0x0
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow::SetInputRegion(1, 0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow::SetInputRegion(1, 0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow::SetInputRegion(1, 0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow::SetInputRegion(1, 0)
[Parent 42568: Main Thread]: D/WidgetPopup [7f0b50fb8900]: nsWindow::SetInputRegion(1, 0)
The problem seems less frequent with Firefox than Thunderbird. I tried to bisect but the first bad revision I got was for a test on 2024-08-19 and I don't think it is correct. I retried at each step of the bisection up to 5 times because the problem didn't happen on some Firefox runs. I'll try to bisect again.
Updated•2 years ago
|
Comment 11•2 years ago
|
||
I don't see that on my end but it may be cause by tooltips.
Please flip with browser.chrome.toolbar_tips to false at about:config and try again.
Thanks.
Comment 12•2 years ago
|
||
looking at the recording I wonder why we see the tab popup during the menu selection - looks like another mouse cursor selects the tab which causes the pointer out event on selected menu.
Comment 13•2 years ago
|
||
See the 0:05 time of the recording...why the tab preview popup is opened?
| Reporter | ||
Comment 14•2 years ago
|
||
I reproduced the problem with Firefox 132.0a1 20240905095820 with my normal profile. I set browser.chrome.toolbar_tips to false, and I didn't see the problem with that setting changed.
In the recording with Firefox 131.0a1 (2024-8-30), when the cursor was over Open Link in New Private Window in the context menu, the tab in the tab bar was incorrectly highlighted, so I think that resulted in the tab preview being shown. All I did was keep the cursor over Open Link in New Private Window until its highlight disappeared after about a second, and there wasn't another cursor or other input from me. Some other buttons like the Reload page, Previous page, and Firefox View sometimes became incorrectly highlighted when the highlight disappeared over other context menu items, but their tooltips didn't appear. I've seen the problem in Firefox almost always after right-clicking on links two or more times. Right-clicking on the background or on text boxes didn't show this with their context menus. I saw this problem once after right-clicking on the empty part of the tab bar to the right of the tabs twice, and parts of the page became incorrectly highlighted. The context menus needed to be shown twice for the same type of thing being right-clicked like links or in Thunderbird emails in message lists or From/To email addresses in emails.
I didn't see the problem with Firefox 131.0a1 (2024-8-14) with mozregression even though I first saw the problem with Thunderbird 131.0a1 (2024-08-14). The problem doesn't always happen, so I sometimes needed to right-click on various links or run Firefox or Thunderbird a few times before it happened. Thanks.
Comment 15•2 years ago
|
||
I tested Fedora 40 KDE bare metal and I don't see it. I wonder what causes such weird behavior. Do you test that in virtual machine? Can you try higher resolution? May be related to low-res screen I see on the recording. But the cursor definitely behaves strange there.
Updated•2 years ago
|
| Reporter | ||
Comment 16•2 years ago
|
||
I'm using Fedora 41 on bare metal. I haven't tested this in a VM, but I could if it would help. The screen has a resolution of 1366 x 768 which is its maximum. I don't have the hardware to try a higher resolution now. The problem might be something to do with the tooltips which do show up after hovering for about a second, and that's how long it took for the context menu items' highlights to disappear. When the top five icons' highlights disappeared in context menus for emails in message lists in Thunderbird, their tooltips didn't appear as shown in the recording in comment 4.
Comment 17•2 years ago
|
||
I see, okay, will try such resolution then.
Updated•2 years ago
|
Comment 18•2 years ago
|
||
Tested Fedora 40 with such low resolution and I still don't see it. Will look at it after Fedora 41 update.
| Reporter | ||
Comment 20•1 year ago
|
||
I haven't seen this problem with Firefox or Thunderbird 140.0a1 (2025-05-22) on Wayland or in recent Nightly or Daily builds in Plasma 6.3.5 in a Fedora 42 KDE installation. I reproduced this problem in Fedora's build of Thunderbird 128.10.2 on Wayland when opening context menus by right-clicking on links in emails. The problem might have been fixed, but I don't know when. Thanks.
Description
•