Bug 14152 – REGRESSION: closing a tab with a modified form, then hitting undo causes a crash

• Component: Forms
• Status: RESOLVED FIXED

[Rachael Worthington (cheers)]

steps to reproduce:
1 . launch Safari 3.0 beta or a recent webkit nightly (reproduced with r23527) - make sure tabs are enabled. I was unable to reproduce this with separate windows instead of tabs.
2. open 2 tabs. in one (order is irrelevant) open a page with a text area (this page would work fine!)
3. type stuff in the text area, then close the tab.
4. hit command z to undo, or select "Undo Typing" in the edit menu
5. crash!

here's the backtrace:
Date/Time:      2007-06-14 16:06:07.085 -0700
OS Version:     10.4.9 (Build 8P2137)
Report Version: 4

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [64]

Version:        3.0 (522.11)
Build Version:  2
Project Name:   WebBrowser
Source Version: 45221100

PID:    6991
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xac3e8495

Thread 0 Crashed:
0   libobjc.A.dylib          	0x90a574c7 objc_msgSend + 23
1   com.apple.Foundation     	0x928a20cb -[_NSUndoStack popAndInvoke] + 278
2   com.apple.Foundation     	0x928a1f5d -[NSUndoManager undoNestedGroup] + 347
3   com.apple.AppKit         	0x935d2a14 -[NSCellUndoManager undo] + 107
4   com.apple.AppKit         	0x9337ad88 -[NSApplication sendAction:to:from:] + 107
5   com.apple.Safari         	0x000184db 0x1000 + 95451
6   com.apple.AppKit         	0x93428ce7 -[NSMenu performActionForItemAtIndex:] + 455
7   com.apple.AppKit         	0x93428a29 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 103
8   com.apple.AppKit         	0x93428680 -[NSMenu performKeyEquivalent:] + 766
9   com.apple.AppKit         	0x934280a2 -[NSApplication _handleKeyEquivalent:] + 254
10  com.apple.AppKit         	0x9335bd87 -[NSApplication sendEvent:] + 3542
11  com.apple.Safari         	0x00014c98 0x1000 + 81048
12  com.apple.AppKit         	0x93286dfe -[NSApplication run] + 547
13  com.apple.AppKit         	0x9327ad2f NSApplicationMain + 573
14  com.apple.Safari         	0x00002302 0x1000 + 4866
15  com.apple.Safari         	0x00048ef5 0x1000 + 294645


Reproduced with: Safari 3.0, Safari 2.0 with nightly revision 23527, internal omniweb alphas on Webkit rev 22076
Not reproduced with : Safari 2.0 without modification, OmniWeb 5.5.4 which is on rev 13302.

[Rachael Worthington (cheers)]

for what it's worth, also reproed in XP SP 2

[Sanjay Madhav (chmmravatar)]

To understand the two window behavior, try this. Open a form in two separate windows. Type in the form one one window, notice that in Edit, "Undo Typing" is available. Now go to your other window. "Undo" is grayed out and unavailable. So when you have two separate windows, each window is maintaining a separate undo stack, and when you change windows the current window's undo stack is correctly referenced.

However, if you do this same experiment with tabs, when you click on the next tab, the "Undo Typing" option is still available from the previous tab you typed on. And if you hit undo, sure enough it will undo the typing in the previous tab.

So, this means that either the tabs aren't maintaining separate undo stacks, or they are but for some reason they aren't being correctly swapped when you switch tabs. Alternatively, if separate undo stacks is undesirable for tabs, then some additional validation would be needed (but that seems like a very roundabout way of fixing the bug).

I'll try to look into this further tonight to see if I can produce a patch for it.

[Mark Rowe (bdash)]

<rdar://problem/5276266>

[Adele Peterson]

Should be fixed in r22065.