10
Dragging a tab out of existing window causes a beachball hang with multiple screens
6 days later
So far so good in Version 0.99.129.5-rc 
Same issue when I connect my MacBook to the external display. (MacBook Pro M2 Pro, MacOS 15.2, orion 0.99.130-beta)
- Edited
This is happening again on Version 0.99.130-rc on Sequoia 15.2 (24C101).
Also happens on a brand new Macbook Pro, clean out the box.
6 days later
I too have this repeatable hang on 0.99.130.1-beta
The main thread seems to deadlock with an NSOperationQueue:
Call graph:
2485 Thread_1098356 DispatchQueue_1: com.apple.main-thread (serial)
+ 2485 start (in dyld) + 2840 [0x19c230274]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x7aa908 [0x10307e908]
+ 2485 NSApplicationMain (in AppKit) + 888 [0x1a01ca854]
+ 2485 -[NSApplication run] (in AppKit) + 480 [0x1a01f4060]
+ 2485 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 688 [0x1a0b652d4]
+ 2485 _DPSNextEvent (in AppKit) + 660 [0x1a0201034]
+ 2485 _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox) + 76 [0x1a7bf4508]
+ 2485 ReceiveNextEventCommon (in HIToolbox) + 676 [0x1a7bf4348]
+ 2485 RunCurrentEventLoopInMode (in HIToolbox) + 292 [0x1a7bee530]
+ 2485 CFRunLoopRunSpecific (in CoreFoundation) + 588 [0x19c696724]
+ 2485 __CFRunLoopRun (in CoreFoundation) + 1996 [0x19c6975ac]
+ 2485 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE (in CoreFoundation) + 16 [0x19c6d79c0]
+ 2485 _dispatch_main_queue_callback_4CF (in libdispatch.dylib) + 44 [0x19c40bc58]
+ 2485 _dispatch_main_queue_drain (in libdispatch.dylib) + 748 [0x19c40bf54]
+ 2485 _dispatch_source_invoke (in libdispatch.dylib) + 836 [0x19c413a4c]
+ 2485 _dispatch_source_latch_and_call (in libdispatch.dylib) + 420 [0x19c414e84]
+ 2485 _dispatch_continuation_pop (in libdispatch.dylib) + 596 [0x19c400a68]
+ 2485 _dispatch_client_callout (in libdispatch.dylib) + 20 [0x19c3fd5b4]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x4b90c4 [0x102d8d0c4]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x795e54 [0x103069e54]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x2d8670 [0x102bac670]
+ 2485 _dispatch_group_wait_slow (in libdispatch.dylib) + 56 [0x19c3fe374]
+ 2485 _dlock_wait (in libdispatch.dylib) + 56 [0x19c3fdfa4]
+ 2485 __ulock_wait (in libsystem_kernel.dylib) + 8 [0x19c570cac]
2485 Thread_1700269 DispatchQueue_32920: NSOperationQueue 0x414ba64b0 (QOS: BACKGROUND) (concurrent)
+ 2485 start_wqthread (in libsystem_pthread.dylib) + 8 [0x19c5ab0f0]
+ 2485 _pthread_wqthread (in libsystem_pthread.dylib) + 228 [0x19c5ac39c]
+ 2485 _dispatch_worker_thread2 (in libdispatch.dylib) + 156 [0x19c40fcd8]
+ 2485 _dispatch_root_queue_drain (in libdispatch.dylib) + 392 [0x19c40f4cc]
+ 2485 _dispatch_async_redirect_invoke (in libdispatch.dylib) + 580 [0x19c400098]
+ 2485 _dispatch_continuation_pop (in libdispatch.dylib) + 596 [0x19c400a68]
+ 2485 _dispatch_client_callout (in libdispatch.dylib) + 20 [0x19c3fd5b4]
+ 2485 _dispatch_call_block_and_release (in libdispatch.dylib) + 32 [0x19c3fb854]
+ 2485 __NSOQSchedule_f (in Foundation) + 172 [0x19d849fb0]
+ 2485 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ (in Foundation) + 16 [0x19d84a0c0]
+ 2485 -[NSOperation start] (in Foundation) + 648 [0x19d84a350]
+ 2485 __NSOPERATION_IS_INVOKING_MAIN__ (in Foundation) + 16 [0x19d84aff0]
+ 2485 -[NSBlockOperation main] (in Foundation) + 104 [0x19d84b060]
+ 2485 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ (in Foundation) + 24 [0x19d84b1a0]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x4b90c4 [0x102d8d0c4]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x735b18 [0x103009b18]
+ 2485 ??? (in Orion) load address 0x1028d4000 + 0x735eac [0x103009eac]
+ 2485 OS_dispatch_queue.sync<A>(execute:) (in libswiftDispatch.dylib) + 64 [0x1b32f159c]
+ 2485 OS_dispatch_queue.asyncAndWait<A>(execute:) (in libswiftDispatch.dylib) + 144 [0x1b32f1634]
+ 2485 OS_dispatch_queue._syncHelper<A>(fn:execute:rescue:) (in libswiftDispatch.dylib) + 404 [0x1b32f0b20]
+ 2485 partial apply for implicit closure #2 in implicit closure #1 in OS_dispatch_queue.sync<A>(execute:) (in libswiftDispatch.dylib) + 76 [0x1b32f2c50]
+ 2485 implicit closure #2 in implicit closure #1 in OS_dispatch_queue.asyncAndWait<A>(execute:) (in libswiftDispatch.dylib) + 192 [0x1b32f1a84]
+ 2485 _dispatch_sync_f_slow (in libdispatch.dylib) + 148 [0x19c40cca0]
+ 2485 __DISPATCH_WAIT_FOR_QUEUE__ (in libdispatch.dylib) + 368 [0x19c40d0f4]
+ 2485 _dispatch_thread_event_wait_slow (in libdispatch.dylib) + 56 [0x19c3fdd58]
+ 2485 _dlock_wait (in libdispatch.dylib) + 56 [0x19c3fdfa4]
+ 2485 __ulock_wait (in libsystem_kernel.dylib) + 8 [0x19c570cac]- Edited
@jeromectm, thanks for providing the stack trace. There's some helpful information there.
Also would you guys, @gp and @jeromectm, be able to try the following dev build and let us know whether it helps with hand freezes during tab dragging:
Thanks!
Yeah - the issue is happening on an M4 Mini running Mac OS 15.2 (upgraded from 15.1.1). I also have a MBP M4 Pro that isn't now showing the issue (on regular Orion RC).
I have tried to create a clean reproduction scenario in a VM, but it isn't occurring now. I'll look a bit more at if I can replicate the environment causing this crash (extensions etc), although in the past I was able to reproduce this crash with a clean profile.
Nonetheless, I will try fully resetting Orion RC on the M4 Mini and see if it still happens.
- Edited
Using the regular RC release (not your dev build) on an M4 Mini (regular M4 CPU, 16 GB RAM, 512 GB SSD), on Mac OS 15.2 public release.
I backed up my Orion profile data via zipping it. I deleted the main profile folders myself.
I used the built-in Orion RC > Reset Orion" menu item to attempt to totally erase everything - all browsing data boxes ticked; "Older than" set to "All time", and all "Resources" boxes ticked. I then closed Orion RC after this reset/wipe.
On a clean start of Orion RC, I set the following settings:
a) File Download Location -> Ask for each download.
b) Open external links in -> Default profile
c) Enabled auto updates
d) Open new tab next to current tab -> On
e) Open external links in Preview -> Off
f) Check spelling while typing -> On
g) Orion iCloud Sync -> Off
h) Passwords (Use Orion's Keychain) -> Off
i) Remove trackers from URLs -> For all browsing
j) Remove history items -> After one year
k) In addition to default blockers, enabled Hagezi Pro Plus Mini, added a custom filter ofaccounts.google.com/gsi/*to the existing 3 default ones.
l) Set search engine to Kagi for regular, ticked for also use in private. Pasted in an account token URL to the box.
m) Enabled installation of both Firefox and Chrome extensions.
n) Hit get plus, to enable "Orion Plus" from Kagi account.Open a tab to kagi.com, and another to orionfeedback.org. Drag one tab out of the window - beachball freeze occurs.
I can't think of any more basic a set of reproduction steps given effectively everything was reset to defaults. I even turned off all login items and background items in System Settings, then logged out and back in again.
The next step would probably be to create a new Mac OS user to see if I can reproduce the issue on a totally new profile on the same system.
Orion 0.99.129-beta doesn't beachball on the same system. 0.99.130.1-beta does beachball. Downgrading back to Orion 0.99.129-beta then fixes the beachballing, suggesting this isn't a profile-related kind of issue.
- Edited
OK @nrudnyk, think I have a revelation, thanks to @Irix 's comment earlier.
This issue APPEARS to happen only when there are >=2 screens connected.
The M4 Mini has 2 screens (2x 2560x1440 27" 144 Hz displays; one by HDMI, and one by Thunderbolt to Displayport).
I unplugged the HDMI display out of the M4 Mini, and can now successfully drag/drop tabs without beachball on the Mini. That is a change from before, showing that with only 1 screen, there's no beachball freeze on the M4 Mini.
I then plugged that HDMI cable into my M4 MBP, and immediately could get the beachball freeze to happen on RC on the laptop. That shows the issue doesn't happen until there's > 1 screen, then it will.
The moment I unplugged the second screen (no need to restart Orion), I can then drag a window without issue.
Thoughts - I wonder if display scaling is relevant here? These are not HiDPI screens. They are also high refresh rate (144 Hz). But I think this is the missing reproduction step!
gp changed the title to Dragging a tab out of existing window causes a beachball hang with multiple screens .
Can confirm it was happening to me when two screens were active.
@nrudnyk - Repro steps without a second screen.
Install Deskpad (https://github.com/Stengo/DeskPad) - free and open source. Run it, approve the permissions for accessibility/screen capture. Restart the app when prompted.
Now it's running drag a window out of an Orion RC window, and it will crash. This is a simulated second screen, and is enough to trigger the beachball crash without a hardware second monitor
When I drag a tab from the current Orion window that I am working in to create a new window, Orion freezes and the pinwheel of death spins for ever. This has occurred when I am dragging the tab within the same screen, and across my multi-screen setup.
I replicated multiple times by opening two websites in the same window and then dragging one of them out of the current Orion window to create a new Orion window with that tab. It froze every time.
I expected that tab to create a new window with that website being the starting point.
Version 0.99.130-beta
Sequoia (15)
5 days later
- Edited
@pauld Thank you for reporting this issue. Although we cannot reproduce it on our end, could you please test the following dev build and let us know if you can still reproduce the issue?
Here is the build: OrionRC-15.0-130.1.0.1-dev
Updated build: Orion-15.0-130.1.0.12-dev
Thank you!
I too am getting this issue. Every time I try to drag a tab to an external monitor I get the pinwheel of death and have to force close the program. This doesn't happen using other browsers like Edge.
Version 0.99.130.1-beta (WebKit 621.1.2.111.4)
Build date Dec 19 2024
MacBook Pro (macOS Sequoia 15.1.1 build 24B91)