To reproduce: open attached test case (index.html). The test case has some js in it that toggles a css class (which contains a box reflect rule) on a div. The div is positioned with absolute positioning and have a translate3d transform applied. There is a catch all rule applying preserve-3d style to all elements. In Safari 5.0.5 it causes the div to wander across the screen seemingly in the direction of the translate3d transform. In the most recent webkit nightly this causes the browser to crash: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x0000000101648bb9 WebCore::PlatformCALayer::replaceSublayer(WebCore::PlatformCALayer*, WebCore::PlatformCALayer*) + 9 1 com.apple.WebCore 0x00000001010148c4 WebCore::GraphicsLayerCA::ensureStructuralLayer(WebCore::GraphicsLayerCA::StructuralLayerPurpose) + 1236 2 com.apple.WebCore 0x0000000101014e15 WebCore::GraphicsLayerCA::commitLayerChangesBeforeSublayers() + 981 3 com.apple.WebCore 0x0000000101014e45 WebCore::GraphicsLayerCA::recursiveCommitChanges() + 21 4 com.apple.WebCore 0x0000000101014e81 WebCore::GraphicsLayerCA::recursiveCommitChanges() + 81 5 com.apple.WebCore 0x0000000101014e81 WebCore::GraphicsLayerCA::recursiveCommitChanges() + 81 6 com.apple.WebCore 0x0000000101014e81 WebCore::GraphicsLayerCA::recursiveCommitChanges() + 81 7 com.apple.WebCore 0x0000000101014e81 WebCore::GraphicsLayerCA::recursiveCommitChanges() + 81 8 com.apple.WebCore 0x00000001016f0b69 WebCore::RenderLayerCompositor::flushPendingLayerChanges() + 41 9 com.apple.WebCore 0x0000000100fd9127 WebCore::FrameView::syncCompositingStateForThisFrame() + 167 10 com.apple.WebCore 0x0000000100fda185 WebCore::FrameView::syncCompositingStateIncludingSubframes() + 21 11 com.apple.WebKit 0x0000000100ad6b86 -[WebView(WebViewInternal) _syncCompositingChanges] + 38 12 com.apple.WebKit 0x0000000100ac877f layerSyncRunLoopObserverCallBack(__CFRunLoopObserver*, unsigned long, void*) + 79 13 com.apple.CoreFoundation 0x00007fff86ee7b37 __CFRunLoopDoObservers + 519 14 com.apple.CoreFoundation 0x00007fff86ec363f __CFRunLoopRun + 943 15 com.apple.CoreFoundation 0x00007fff86ec2dbf CFRunLoopRunSpecific + 575 16 com.apple.HIToolbox 0x00007fff812fc7ee RunCurrentEventLoopInMode + 333 17 com.apple.HIToolbox 0x00007fff812fc5f3 ReceiveNextEventCommon + 310 18 com.apple.HIToolbox 0x00007fff812fc4ac BlockUntilNextEventMatchingListInMode + 59 19 com.apple.AppKit 0x00007fff834abe64 _DPSNextEvent + 718 20 com.apple.AppKit 0x00007fff834ab7a9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155 21 com.apple.Safari 0x0000000100015ff6 0x100000000 + 90102 22 com.apple.AppKit 0x00007fff8347148b -[NSApplication run] + 395 23 com.apple.AppKit 0x00007fff8346a1a8 NSApplicationMain + 364 24 com.apple.Safari 0x0000000100009f18 0x100000000 + 40728
Created attachment 91157 [details] Testcase
Safari 16.3 does not crash on the attached test case and also WebKit ToT build running via run-safari --release. Do we need to track anything here? Thanks!
Crashes this old are indeed unlikely to still reproduce, but technically, this was a WebKit1 bug, and this functionality works very differently in WebKit2. So it needs to be tested in MiniBrowser using a legacy WebKit window.
(In reply to Alexey Proskuryakov from comment #3) > Crashes this old are indeed unlikely to still reproduce, but technically, > this was a WebKit1 bug, and this functionality works very differently in > WebKit2. So it needs to be tested in MiniBrowser using a legacy WebKit > window. It does not crash in mini-browser WebKit1 window as well based on WebKit Trunk of 259744@main.
Yay!