[webkit-dev] Webkit (Mobile Safari) issues in the iPhone
David Kilzer
ddkilzer at webkit.org
Wed Oct 15 21:09:39 PDT 2008
Hi Diego,
The WebKit framework is not public API on iPhone OS at this time, so any direct calls you make to WebKit are not supported and may have unintended consequences (like crashes or hangs).
Having said that, if you're seeing an issue with -[UIWebView stringByEvaluatingJavaScriptFromString:], please file a bug on <http://developer.apple.com/bugreporter/>. A reproducible test case (or attaching your entire project as a zip archive) with steps to reproduce is greatly appreciated. Thanks!
Dave
On Wed, 10/15/08, Diego Taylor <diego.taylor at gmail.com> wrote:
> Hi,
>
> I am aware that this mailing list is not specifically
> oriented to the
> Apple's iphone mobile safari implementation, but I am
> confident that some
> people on this list can give me some hints on how to solve
> this issue.
>
> In a nutshell I have issues updating the DOM. I have a rich
> text edit and to
> simulate the text selection I have enclosed the text in a
> tag with a
> background colour.
> All this is done in javascript but if i do not send (after
> it in
> Objective-C) a setSelectionToStart message to the text view
> It comes back
> with something like this (the same issue can occur in some
> few places but
> always ends in the same place):
>
>
> #0 0x3272e30f in
> std::__push_heap<WebCore::TimerHeapIterator, int,
> WebCore::TimerHeapElement> ()
> #1 0x327389d6 in
> std::__adjust_heap<WebCore::TimerHeapIterator, int,
> WebCore::TimerHeapElement> ()
> #2 0x32738978 in WebCore::TimerBase::heapPopMin ()
> #3 0x326b5acc in WebCore::TimerBase::setNextFireTime ()
> #4 0x326b58c1 in WebCore::TimerBase::stop ()
> #5 0x32739fde in WebCore::FrameView::layout ()
> #6 0x3275cea7 in WebCore::Frame::forceLayout ()
> #7 0x3275ce4c in -[WebCoreFrameBridge
> forceLayoutAdjustingViewSize:] ()
> #8 0x32de6cbd in -[WebHTMLView
> layoutToMinimumPageWidth:maximumPageWidth:adjustingViewSize:]
> ()
> #9 0x32de6b34 in -[WebHTMLView layout] ()
> #10 0x32a7caae in WKViewLayout ()
> #11 0x30bc16d0 in -[UIWebDocumentView layoutBeforeDraw] ()
> #12 0x30ae23e9 in -[UITiledView layoutSubviews] ()
> #13 0x30bbb66c in -[UIWebDocumentView layoutSubviews] ()
> #14 0x31e87278 in -[CALayer layoutSublayers] ()
> #15 0x31e871a8 in CALayerLayoutIfNeeded ()
> #16 0x31e9f639 in -[CALayer layoutIfNeeded] ()
> #17 0x31e9e92d in -[CALayer renderInContext:] ()
> #18 0x30b6ff5c in -[UITextLoupe drawRect:] ()
> #19 0x30a82df1 in -[UIView(CALayerDelegate)
> drawLayer:inContext:] ()
> #20 0x31e951fe in -[CALayer drawInContext:] ()
> #21 0x31e951a7 in backing_callback ()
> #22 0x31e94db7 in CABackingStoreUpdate ()
> #23 0x31e9442e in -[CALayer _display] ()
> #24 0x31e887d1 in CALayerDisplayIfNeeded ()
> #25 0x31e86b3f in CAContextCommitTransaction ()
> #26 0x31e86853 in CATransactionCommit ()
> #27 0x95aea9c2 in __CFRunLoopDoObservers ()
> #28 0x95aec424 in CFRunLoopRunSpecific ()
> #29 0x95aeccf8 in CFRunLoopRunInMode ()
> #30 0x31699d38 in GSEventRunModal ()
> #31 0x31699dfd in GSEventRun ()
> #32 0x30a5dadb in -[UIApplication _run] ()
> #33 0x30a68ce4 in UIApplicationMain ()
>
>
> Since I am using DOMRange's and selection(s), the issue
> seems to be related
> to this, but I thought the issue was solved, and with more
> "complex" DOM
> manipulations it is happening again. It's worth adding
> that I am doing these
> changes while some UI events are happenning (e.g: touches),
> but if I
> simulate the same process steps in another way (pressing a
> button for each
> DOM manipulation) it doesn't happen. IMHO it may be
> related with some
> sync/event/layout issue but don't know yet the WebKit
> internals.
>
> If somebody can shed me some light on it, I would be very
> grateful.
>
> Thank you,
> Diego
More information about the webkit-dev
mailing list