Right click sub menus opening on the wrong screen
Categories
(Core :: Widget: Cocoa, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox80 | --- | verified |
People
(Reporter: haik, Assigned: haik)
References
Details
Attachments
(2 files)
On bug 1592416 comment 74, Tyler reported that right click sub-menus are appearing on the wrong screen. I have reproduced this and included a screen shot. It's likely that the fix for bug 1592416 didn't go far enough a similar change is needed here for the submenu.
Assignee | ||
Comment 1•5 years ago
|
||
This appears to be the same problem as in bug 1592416. We use the same code to create the nsCocoaWindow widget that we use for the popup menu as we do for the submenu. Like with 1592416, the first time the submenu displays, it displays on the correct display, but subsequent nsCocoaWindow::Show() calls do not. The stack where the widget is created is below. I'm testing using the same fix as bug 1592416 for the submenu code path.
Command #2 'c' continued the target.
(lldb) bt
* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0 XUL`nsCocoaWindow::Create() at nsCocoaWindow.mm:299
frame #1 XUL`nsCocoaWindow::Create() at nsCocoaWindow.mm:347
frame #2 XUL`nsBaseWidget::CreateChild() at nsBaseWidget.cpp:433
frame #3 XUL`nsView::CreateWidgetForPopup() at nsView.cpp:612
frame #4 XUL`nsMenuPopupFrame::CreateWidgetForView() at nsMenuPopupFrame.cpp:337
frame #5 XUL`nsMenuPopupFrame::EnsureWidget() at nsMenuPopupFrame.cpp:260
frame #6 XUL`nsMenuPopupFrame::InitializePopup() at nsMenuPopupFrame.cpp:722
frame #7 XUL`nsXULPopupManager::ShowMenu() at nsXULPopupManager.cpp:677
frame #8 XUL`nsMenuFrame::OpenMenu() at nsMenuFrame.cpp:622
frame #9 XUL`nsMenuFrame::Notify() at nsMenuFrame.cpp:737
frame #10 XUL`nsMenuTimerMediator::Notify() at nsMenuFrame.cpp:1138
frame #11 XUL`nsTimerImpl::Fire() at nsTimerImpl.cpp:565
frame #12 XUL`nsTimerEvent::Run() at TimerThread.cpp:251
frame #13 XUL`nsThread::ProcessNextEvent() at nsThread.cpp:1234
frame #14 XUL`NS_ProcessPendingEvents() at nsThreadUtils.cpp:452
frame #15 XUL`nsBaseAppShell::NativeEventCallback() at nsBaseAppShell.cpp:87
frame #16 XUL`nsAppShell::ProcessGeckoEvents() at nsAppShell.mm:429
frame #17 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__()
frame #18 CoreFoundation`__CFRunLoopDoSource0()
frame #19 CoreFoundation`__CFRunLoopDoSources0()
frame #20 CoreFoundation`__CFRunLoopRun()
frame #21 CoreFoundation`CFRunLoopRunSpecific()
frame #22 HIToolbox`RunCurrentEventLoopInMode()
frame #23 HIToolbox`ReceiveNextEventCommon()
frame #24 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter()
frame #25 AppKit`_DPSNextEvent()
frame #26 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]()
frame #27 XUL`-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]() at nsAppShell.mm:171
frame #28 AppKit`-[NSApplication run]()
frame #29 XUL`nsAppShell::Run() at nsAppShell.mm:692
frame #30 XUL`nsAppStartup::Run() at nsAppStartup.cpp:271
frame #31 XUL`XREMain::XRE_mainRun() at nsAppRunner.cpp:4711
frame #32 XUL`XREMain::XRE_main() at nsAppRunner.cpp:4860
frame #33 XUL`XRE_main() at nsAppRunner.cpp:4914
frame #34 XUL`mozilla::BootstrapImpl::XRE_main() at Bootstrap.cpp:45
frame #35 firefox`do_main() at nsBrowserApp.cpp:217
frame #36 firefox`main() at nsBrowserApp.cpp:331
frame #37 libdyld.dylib`start()
Assignee | ||
Comment 2•5 years ago
|
||
Apply the fix for bug 1592416 to submenus.
This adds the NSWindowCollectionBehaviorMoveToActiveSpace behavior to
submenu popups so that they override the "Assign To" space setting and display
on the active space. And, when mutiple displays are in use, recreates the
submenu widget each time it is displayed.
Comment 4•5 years ago
|
||
bugherder |
Comment 5•5 years ago
|
||
Hello,
Unfortunately, at this time with the Covid-19 situation QA does not have the hardware to verify this issue. Can you please confirm that the issue is fixed?
Assignee | ||
Comment 6•5 years ago
|
||
(In reply to Daniel Cicas [:dcicas], Release QA from comment #5)
Unfortunately, at this time with the Covid-19 situation QA does not have the hardware to verify this issue. Can you please confirm that the issue is fixed?
Verified. I tested on Beta80 and could not reproduce the problem.
Comment 7•5 years ago
|
||
Marked verified as per assignee confirmation in comment 6.
Description
•