Bug 10873 - Crash when window resigns key and content is not yet loaded
Summary: Crash when window resigns key and content is not yet loaded
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 419.x
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-15 11:23 PDT by Robert Burns
Modified: 2009-01-04 07:13 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Burns 2006-09-15 11:23:31 PDT
I'm getting a repeated crash with WebKit. It seems to be related to a delay in loading XHTML into the main WebFrame: especially on the initial launch. The small XHTML loads quicker on subsequent new windows.  If the window resigns key while the data is loading the crash occurs. Usually this load happens very quickly and so there's no time for the window to resign key while loading, but with my delay its happening more frequently.

So I guess what's happening here is the WebCore FontFallback is trying to respond to a notification about a window resigning key and then query the WebView for information that's just not there (since the data's not finished loading).

The crash log:

#0	0x093145cc in WebCore::FontFallbackList::fontDataAt at FontFallbackList.cpp:60
#1	0x0926f830 in WebCore::Font::lineSpacing at Font.cpp:391
#2	0x091cf154 in WebCore::RenderObject::lineHeight at RenderObject.cpp:2541
#3	0x091bb60c in WebCore::RenderFlow::lineHeight at RenderFlow.cpp:298
#4	0x091984e8 in WebCore::RenderBlock::lineHeight at RenderBlock.cpp:3248
#5	0x09194a10 in WebCore::RenderBlock::layoutInlineChildren at bidi.cpp:1751
#6	0x091a5394 in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:487
#7	0x091a4cc8 in WebCore::RenderBlock::layoutBlockChildren at RenderObject.h:465
#8	0x091a53cc in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:489
#9	0x091b0ab8 in WebCore::RenderView::layout at RenderView.cpp:117
#10	0x09104428 in WebCore::FrameView::layout at FrameView.cpp:473
#11	0x090e9408 in WebCore::Frame::setIsActive at Frame.cpp:3343
#12	0x9293fad8 in _nsnote_callback
#13	0x90803010 in __CFXNotificationPost
#14	0x907fb0ec in _CFXNotificationPostNotification
#15	0x92929ee0 in -[NSNotificationCenter postNotificationName:object:userInfo:]
#16	0x9374c95c in -[NSWindow becomeKeyWindow]
#17	0x9374c138 in -[NSWindow _changeKeyAndMainLimitedOK:]
#18	0x9374b288 in -[NSWindow makeKeyAndOrderFront:]
#19	0x93827708 in -[NSApplication _cycleWindowsReversed:]
#20	0x93789988 in _NSKeyboardUIHandleSymbolicHotKey
#21	0x937e49a8 in -[NSApplication _handleKeyEquivalent:]
#22	0x936ee408 in -[NSApplication sendEvent:]
#23	0x936e5d10 in -[NSApplication run]
#24	0x937d687c in NSApplicationMain
#25	0x005d9fac in main at main.m:13
Comment 1 Robert Burns 2006-09-15 12:21:04 PDT
Let me add that this is a Blot like application except the content is loaded as application/xhtml+xml instead of text/html. This crash occurs on the first new window before any other custom code is executed (except for the mainmenu related code).

So while waiting for the relatively small default.xhtml file to load, a click on onaother apps window brings about the crash.
Comment 2 Robert Burns 2006-09-19 18:42:58 PDT
as a workaround I just changed my app so that the WebView is added to the window only after tthe content is loaded (come to think of it this must be what Safari does too).
Comment 3 Alexey Proskuryakov 2007-07-02 05:28:04 PDT
Could you please attach a test application showing this behavior?
Comment 4 Robert Blaut 2009-01-04 07:13:01 PST
(In reply to comment #3)
> Could you please attach a test application showing this behavior?
> 

Robert, as Alexey said, without test case demonstrating the reported issue we are unable to proceed with this report. I have to close this report. Feel free to reopen it if you provide further details.