Avi Drissman wrote:
> #10 0x94759306 in -[WebView initWithFrame:] ()
That's not one of our addresses. OK...
To be sure, I looked for Obj-C in our libwebcore and didn't find very much.
000007d4 t +[WebCoreControlTintObserver controlTintDidChange]
00000000 A .objc_class_name_WebCoreControlTintObserver
00001a6a t +[ScrollbarPrefsObserver appearancePrefsChanged:]
00001a54 t +[ScrollbarPrefsObserver behaviorPrefsChanged:]
00001662 t +[ScrollbarPrefsObserver registerAsObserver]
00000000 A .objc_class_name_ScrollbarPrefsObserver
00000236 t +[WebFontCache fontWithFamily:traits:weight:size:]
00000866 t +[WebFontCache getTraits:inFamily:]
0000033e t +[WebFontCache internalFontWithFamily:traits:weight:size:]
00000000 A .objc_class_name_WebFontCache
00006f8e t -[WebCoreRenderThemeNotificationObserver initWithTheme:]
00001278 t -[WebCoreRenderThemeNotificationObserver systemColorsDidChange:]
00000000 A .objc_class_name_WebCoreRenderThemeNotificationObserver
Of these, WebFontCache sounds like the most likely one to run
interference for us. It's possible that something not shown in the
stack is calling into WebFontCache and storing something that it can't
cope properly with later.
You can validate this theory by setting a breakpoint on -[NSHTMLReader
_loadUsingWebKit]. When that fires, set some more breakpoints to
watch for calls into our version of WebFontCache (or the other Obj-C
bits we expose).
Mark
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
