10

  • Dragging a tab out of existing window causes a beachball hang with multiple screens

  • BugsDesktopDone

This appears to be consistent, at least for me and Vlad, although it doesn't happen in a completely clean Virtualbuddy VM running Orion RC, so there appears to be something stateful about the bug.

On a system that is affected (Mac Mini M4 running 15.1.1), the beachball hang is reproducible in a clean, new Orion Profile (i.e. not inheriting preferences, settings or extensions etc.)

Resetting Orion entirely on the system (Caches, Preferences, Application Support) doesn't change anything - the issue still occurs on an entirely clean install of Orion RC.

The issue doesn't occur on the same computer on a clean install of Orion 0.99.129-beta.

Mac OS 15.1.1, Orion RC version 0.99.129.2-rc

Sequoia (15)

    Just tested with the following configuration:

    Orion RC
Version 0.99.129.2-rc (WebKit 621.1.2.111.4)
Build date Nov 20 2024
MacBook Pro (Intel CPU, macOS Ventura 13.4 build 22F66)

    The following scenarios were just fine:

    • Move the tab in the new window with the mouse
    • Move the tab in the new window with the touchpad
    • Right-click the tab > Move Tab > New Window
    • Right-click the tab > Move Tab > Select existing window

    No crashes at all.

    Perhaps, the issue is related to ARM and Apple Silicon?

      Just to add some data, dragging tabs to other windows or creating new windows by dragging both work as expected on
      Orion Version 0.99.129.2-rc (WebKit 621.1.2.111.4)
      Build date Nov 20 2024
      MacBook Air M1 (macOS Sequoia 15.1.1 build 24B91)

        Also to add a data point, there's no beachball hang on a MBP M1 Pro 14, on the latest RC, running 15.2 dev beta.

        @Vlad out of interest, were you testing on an M4 device when you reproduced the beachball hang? Or was it on your Intel iMac Pro?

        • Vlad replied to this.

          gp It was on my iMac Pro.

          • gp likes this.
            5 days later

            Also curiously, this seems to only affect the "click-and-drag" method of moving a tab to a new window. Right-clicking a tab and selecting Move Tab > New Window doesn't cause a crash.

              And this appears to be resolved in Version 0.99.129.3-rc 🙂

              Afraid I spoke too soon - this is still present on 0.99.129.3.

              Some further investigation:

              If you have 2 open windows, then there is no hang if you drag a tab from one window into the other window (with the "+" icon showing on drop). I believe this is why I incorrectly thought this hang was fixed - for anyone trying to reproduce this, ensure you are dragging the tab outside of all existing Orion windows, so you should get a new window on dropping the tab.

              If you right click a tab, and pick "Move Tab > New Window", there is no hang, and it achieves the result you would expect, suggesting the issue is UI related rather than functionality-related.

              The UI hang appears to pertain specifically to dropping a tab on a blank area of screen (i.e. not on an existing Orion window), and happens after the 'preview' of dropping the tab is rendered. Putting the tab back in the source window (without releasing the mouse) is also fine.

                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)

                • gp likes this.

                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]

                    @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:

                    OrionRC-15.0-130.1.0.1-dev

                    Thanks!

                    • gp replied to this.