Summary: | Snapshotted plug-in should use shadow root | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dean Jackson <dino> | ||||||||||||||||
Component: | Plug-ins | Assignee: | Dean Jackson <dino> | ||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||
Severity: | Normal | CC: | buildbot, cmarcelo, dglazkov, eric, esprehn, gyuyoung.kim, jonlee, macpherson, menard, mifenton, ojan.autocc, peter+ews, philn, rakuco, rego+ews, rniwa, rwlbuis, tkent, tonikitoo, webcomponents-bugzilla, webkit-bug-importer, webkit-ews, webkit.review.bot, xan.lopez, yong.li.webkit | ||||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||
Bug Depends on: | |||||||||||||||||||
Bug Blocks: | 108273 | ||||||||||||||||||
Attachments: |
|
Description
Dean Jackson
2013-01-29 18:56:09 PST
Created attachment 185545 [details]
Patch
Comment on attachment 185545 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185545&action=review Unofficial r=me with adjustments to style calc calls > Source/WebCore/html/HTMLPlugInImageElement.cpp:146 > + if (displayState() == DisplayingSnapshot && document()->page() && document()->page()->settings()->plugInSnapshottingEnabled()) { Is the setting check required? The displayState should only ever not be Playing if the setting is enabled. > Source/WebCore/html/HTMLPlugInImageElement.cpp:355 > + recalcStyle(Force); Is this second recalcStyle necessary? (In reply to comment #3) > (From update of attachment 185545 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=185545&action=review > > Unofficial r=me with adjustments to style calc calls > > > Source/WebCore/html/HTMLPlugInImageElement.cpp:146 > > + if (displayState() == DisplayingSnapshot && document()->page() && document()->page()->settings()->plugInSnapshottingEnabled()) { > > Is the setting check required? The displayState should only ever not be Playing if the setting is enabled. > > > Source/WebCore/html/HTMLPlugInImageElement.cpp:355 > > + recalcStyle(Force); > > Is this second recalcStyle necessary? Fixed both of these. Created attachment 185659 [details]
Patch
Updated patch after r141066, which changed the way you attach shadow roots and their subtrees. Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16257054 Comment on attachment 185659 [details]
Patch
Need to appropriately remove of startLabelImage() and references to LabelSize from other ports.
(In reply to comment #8) > (From update of attachment 185659 [details]) > Need to appropriately remove of startLabelImage() and references to LabelSize from other ports. ... which means removing ChromeClient::plugInStartLabelImage(). Or alternatively, don't remove LabelSize. Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16218894 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16250104 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/16265001 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16267005 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/16269023 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16268051 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/16278112 Comment on attachment 185659 [details] Patch Attachment 185659 [details] did not pass cr-linux-debug-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16269119 Comment on attachment 185659 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185659&action=review > Source/WebCore/html/HTMLPlugInImageElement.cpp:291 > +void HTMLPlugInImageElement::didAddUserAgentShadowRoot(ShadowRoot* root) Elliott's been refactoring around this. Need to cc him so that he don't stomp over ya here. Comment on attachment 185659 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185659&action=review > Source/WebCore/html/HTMLPlugInImageElement.cpp:337 > + recalcStyle(Force); Why do you need to manually cause the style recalc or set all these needs properties? This seems really wrong. Just like doing appendChild() in JS, we handle all of that automatically here. > Source/WebCore/html/HTMLPlugInImageElement.cpp:351 > + attach(); Adding a shadow root will already cause a reattach. You don't need to do it manually. See: ElementShadow::addShadowRoot > Source/WebCore/html/HTMLPlugInImageElement.cpp:362 > + attach(); reattach(). What's the reason for wanting to destroy and recreate the render tree here? > Source/WebCore/rendering/RenderSnapshottedPlugIn.cpp:171 > + firstChild()->style()->setWidth(Length(newSize.width(), Fixed)); I think you should be able to do this with just CSS? It doesn't seem you should need to layout the child twice here. Created attachment 185810 [details]
Patch
Comment on attachment 185810 [details] Patch Attachment 185810 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16270281 Comment on attachment 185810 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185810&action=review Looks great, two small things. > Source/WebCore/html/HTMLPlugInImageElement.cpp:295 > + RefPtr<Element> shadowContainer = doc->createElement(divTag, ASSERT_NO_EXCEPTION); It would be nicer to use HTMLDivElement::create(doc) instead here since you wouldn't need that ASSERT_NO_EXCEPTION. > Source/WebCore/html/HTMLPlugInImageElement.cpp:357 > + attach(); Lets use reattach() Comment on attachment 185810 [details] Patch Attachment 185810 [details] did not pass cr-linux-debug-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16292035 Comment on attachment 185810 [details] Patch Attachment 185810 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16266339 (In reply to comment #18) > (From update of attachment 185659 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=185659&action=review > > > Source/WebCore/html/HTMLPlugInImageElement.cpp:291 > > +void HTMLPlugInImageElement::didAddUserAgentShadowRoot(ShadowRoot* root) > > Elliott's been refactoring around this. Need to cc him so that he don't stomp over ya here. Oh, I thought that was the result of the refactoring :) Comment on attachment 185810 [details] Patch Attachment 185810 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16264360 (In reply to comment #9) > (In reply to comment #8) > > (From update of attachment 185659 [details] [details]) > > Need to appropriately remove of startLabelImage() and references to LabelSize from other ports. > > ... which means removing ChromeClient::plugInStartLabelImage(). Or alternatively, don't remove LabelSize. This is just a side effect of this patch depending on https://bugs.webkit.org/show_bug.cgi?id=108273 I'll run against EWS before landing, once that other one has committed. Created attachment 185828 [details]
Patch
New patch with fixed for comments from Dimitri and Elliot. Sorry, this is going to fail the bots once more and cause bugzilla email :( Like I said, it's expecting https://bugs.webkit.org/show_bug.cgi?id=108273 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass cr-linux-debug-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16270314 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16251495 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16273347 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16269363 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/16270324 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16266378 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16303061 Comment on attachment 185828 [details]
Patch
Unofficial r=me.
Comment on attachment 185828 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185828&action=review Unofficial r=me on this. Two nits. > Source/WebCore/html/HTMLPlugInImageElement.cpp:337 > + return (childContext.isOnUpperEncapsulationBoundary() && HTMLElement::childShouldCreateRenderer(childContext)); nit: extra parens are not needed. > Source/WebCore/html/HTMLPlugInImageElement.cpp:343 > + if (displayState() == DisplayingSnapshot && !userAgentShadowRoot()) { Why do you both assert about it and check here? Early return is usually considered better as well. Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/16297473 Comment on attachment 185828 [details] Patch Attachment 185828 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/16301707 (In reply to comment #38) > (From update of attachment 185828 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=185828&action=review > > Unofficial r=me on this. Two nits. > > > Source/WebCore/html/HTMLPlugInImageElement.cpp:337 > > + return (childContext.isOnUpperEncapsulationBoundary() && HTMLElement::childShouldCreateRenderer(childContext)); > > nit: extra parens are not needed. Removed. > > > Source/WebCore/html/HTMLPlugInImageElement.cpp:343 > > + if (displayState() == DisplayingSnapshot && !userAgentShadowRoot()) { > > Why do you both assert about it and check here? Early return is usually considered better as well. Good point. I've removed the test in the conditional, and swapped it around to an early return. I won't upload a new patch to avoid the EWS build fail emails :) Comment on attachment 185828 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185828&action=review > Source/WebCore/css/plugIns.css:42 > +/* > + * This is the UA StyleSheet for <object> and <embed> elements. > + * > + * Such elements, when snapshotted (paused), will contain a ShadowRoot > + * with the following structure: > + * > + * <object> > + * #ShadowRoot > + * <div class="snapshot-container"> > + * <div class="snapshot-overlay"></div> <!-- e.g. for dimming content --> > + * <div class="snapshot-label"> > + * <span class="snapshot-title">Snapshotted Plug-In</span> > + * <span class="snapshot-subtitle">Click to restart</span> > + * </div> > + * </div> > + * </div> > + * > + */ It's a shame to bog down UA stylesheet parsing with big comments. Or is this stripped out before we convert to const char[] ? > Source/WebCore/css/plugIns.css:55 > +object::-webkit-snapshotted-plugin-content * { > + cursor: hand; > + pointer-events: none; > + -webkit-user-select: none; > +} Is this necessary on all child nodes or just some container? > Source/WebCore/css/plugIns.css:91 > + color: #444; You have used every one of rgba(), keyword and hex values for colors! > Source/WebCore/html/HTMLPlugInImageElement.cpp:74 > + , m_snapshotImage(0) No need to init a RefPtr. > Source/WebCore/html/HTMLPlugInImageElement.cpp:311 > + String clientTitleText = document()->page()->chrome()->client()->plugInStartLabelTitle(); Do you need to null-check chrome()->client()? Comment on attachment 185828 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185828&action=review >> Source/WebCore/css/plugIns.css:42 >> + */ > > It's a shame to bog down UA stylesheet parsing with big comments. Or is this stripped out before we convert to const char[] ? Yes, it's stripped out. >> Source/WebCore/css/plugIns.css:55 >> +} > > Is this necessary on all child nodes or just some container? Removed >> Source/WebCore/css/plugIns.css:91 >> + color: #444; > > You have used every one of rgba(), keyword and hex values for colors! Thank you!! :) All rgb or rgba now. >> Source/WebCore/html/HTMLPlugInImageElement.cpp:74 >> + , m_snapshotImage(0) > > No need to init a RefPtr. Fixed. >> Source/WebCore/html/HTMLPlugInImageElement.cpp:311 >> + String clientTitleText = document()->page()->chrome()->client()->plugInStartLabelTitle(); > > Do you need to null-check chrome()->client()? No. No other use of this does. Created attachment 187360 [details]
Landing EWS test
Landing Patch for EWS Test
Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16428824 Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass cr-linux-debug-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16445893 Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16429840 Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/16432857 Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16435830 Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16445954 Comment on attachment 187360 [details] Landing EWS test Attachment 187360 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16432937 Created attachment 187381 [details]
Another build test
chromium, qt and gtk are failing to link looking for snapshottedPlugInLabelTitle() and snapshottedPlugInLabelSubtitle() both of which landed in http://trac.webkit.org/changeset/142311 I'm not sure why it can't find those methods. mac & mac-wk2 build error seems unrelated. Comment on attachment 187381 [details] Another build test Attachment 187381 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16465014 Created attachment 187384 [details]
Patch
Duh! I forgot to update platform localized strings. The gtk failure is the same unrelated one that mac was hitting in InlineBox. Committed r142333: <http://trac.webkit.org/changeset/142333> Rolled out and landed again in http://trac.webkit.org/changeset/142343 (In reply to comment #59) > Rolled out and landed again in http://trac.webkit.org/changeset/142343 Let me roll it out. This change is very suspicious about a test crash. http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&showExpectations=true&tests=inspector%2Fprofiler%2Fselector-profiler-url.html If the roll out won't resolve the crash, I'll re-land it. Reverted r142343 for reason: It might make inspector/profiler/selector-profiler-url.html crashy. Committed r142400: <http://trac.webkit.org/changeset/142400> (In reply to comment #61) > Reverted r142343 for reason: > > It might make inspector/profiler/selector-profiler-url.html crashy. > > Committed r142400: <http://trac.webkit.org/changeset/142400> Has it made a difference? I can never understand those flakiness pages. (In reply to comment #62) > > Reverted r142343 for reason: > > > > It might make inspector/profiler/selector-profiler-url.html crashy. > > > > Committed r142400: <http://trac.webkit.org/changeset/142400> > > Has it made a difference? I can never understand those flakiness pages. Yes, the revert fixed the crash. Stack trace on Apple MountainLion Debug WK1 follows. Other ports had similar stack. Process: DumpRenderTree [11741] Path: /Volumes/VOLUME/*/DumpRenderTree Identifier: DumpRenderTree Version: 0 Code Type: X86-64 (Native) Parent Process: Python [11327] User ID: 501 Date/Time: 2013-02-10 07:48:29.816 -0800 OS Version: Mac OS X 10.8.2 (12C54) Report Version: 10 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000000f VM Regions Near 0xf: --> __TEXT 000000010ed93000-000000010ee2f000 [ 624K] r-x/rwx SM=COW /Volumes/VOLUME/* Application Specific Information: CRASHING TEST: inspector/profiler/selector-profiler-url.html Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x0000000110bc1cdc WebCore::CSSRule::hasCachedSelectorText() const + 12 (CSSRule.h:107) 1 com.apple.WebCore 0x0000000110bc16fd WebCore::CSSStyleRule::selectorText() const + 45 (CSSStyleRule.cpp:82) 2 com.apple.WebCore 0x00000001112ebd39 WebCore::SelectorProfile::startSelector(WebCore::CSSStyleRule const*) + 57 (InspectorCSSAgent.cpp:172) 3 com.apple.WebCore 0x00000001112e7c12 WebCore::InspectorCSSAgent::willMatchRule(WebCore::StyleRule*, WebCore::StyleResolver*) + 146 (InspectorCSSAgent.cpp:964) 4 com.apple.WebCore 0x000000011135f27e WebCore::InspectorInstrumentation::willMatchRuleImpl(WebCore::InstrumentingAgents*, WebCore::StyleRule*, WebCore::StyleResolver*) + 78 (InspectorInstrumentation.cpp:607) 5 com.apple.WebCore 0x00000001120c501a WebCore::InspectorInstrumentation::willMatchRule(WebCore::Document*, WebCore::StyleRule*, WebCore::StyleResolver*) + 106 (InspectorInstrumentation.h:1205) 6 com.apple.WebCore 0x00000001120af70d WebCore::StyleResolver::collectMatchingRulesForList(WTF::Vector<WebCore::RuleData, 0ul> const*, WebCore::StyleResolver::MatchRequest const&, WebCore::StyleResolver::RuleRange&) + 253 (StyleResolver.cpp:696) 7 com.apple.WebCore 0x00000001120af5fc WebCore::StyleResolver::collectMatchingRules(WebCore::StyleResolver::MatchRequest const&, WebCore::StyleResolver::RuleRange&) + 1052 (StyleResolver.cpp:518) 8 com.apple.WebCore 0x00000001120b01b2 WebCore::StyleResolver::matchUARules(WebCore::StyleResolver::MatchResult&, WebCore::RuleSet*) + 162 (StyleResolver.cpp:675) 9 com.apple.WebCore 0x00000001120b05eb WebCore::StyleResolver::matchUARules(WebCore::StyleResolver::MatchResult&) + 171 (StyleResolver.cpp:1193) 10 com.apple.WebCore 0x00000001120b0289 WebCore::StyleResolver::matchAllRules(WebCore::StyleResolver::MatchResult&, bool) + 57 (StyleResolver.cpp:750) 11 com.apple.WebCore 0x00000001120ae46b WebCore::StyleResolver::styleForElement(WebCore::Element*, WebCore::RenderStyle*, WebCore::StyleSharingBehavior, WebCore::RuleMatchingBehavior, WebCore::RenderRegion*) + 1179 (StyleResolver.cpp:1445) 12 com.apple.WebCore 0x0000000110e8591b WebCore::Element::styleForRenderer() + 283 (Element.cpp:1330) 13 com.apple.WebCore 0x0000000110e85abd WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 397 (Element.cpp:1350) 14 com.apple.WebCore 0x0000000110e85fdd WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1709 (Element.cpp:1419) 15 com.apple.WebCore 0x0000000110e85fdd WebCore::Element::recalcStyle(WebCore::Node::StyleChange) + 1709 (Element.cpp:1419) 16 com.apple.WebCore 0x0000000110c71cde WebCore::Document::recalcStyle(WebCore::Node::StyleChange) + 1166 (Document.cpp:1804) 17 com.apple.WebCore 0x0000000110c6dedc WebCore::Document::updateStyleIfNeeded() + 396 (Document.cpp:1852) 18 com.apple.WebCore 0x0000000111e934ed WebCore::RenderView::repaintSelection() const + 45 (RenderView.cpp:563) 19 com.apple.WebCore 0x0000000110fc053e WebCore::FrameSelection::focusedOrActiveStateChanged() + 78 (FrameSelection.cpp:1691) 20 com.apple.WebCore 0x0000000110fc0a6a WebCore::FrameSelection::setFocused(bool) + 106 (FrameSelection.cpp:1739) 21 com.apple.WebCore 0x0000000110f40c0d WebCore::FocusController::setFocused(bool) + 269 (FocusController.cpp:227) 22 com.apple.WebKit 0x000000011021d8f1 -[WebHTMLView becomeFirstResponder] + 609 (WebHTMLView.mm:3844) 23 com.apple.AppKit 0x00007fff956758e8 -[NSWindow makeFirstResponder:] + 702 24 com.apple.WebKit 0x00000001101aa98e -[WebDefaultUIDelegate webView:makeFirstResponder:] + 62 (WebDefaultUIDelegate.m:99) 25 com.apple.CoreFoundation 0x00007fff8f6e863c __invoking___ + 140 26 com.apple.CoreFoundation 0x00007fff8f6e84d7 -[NSInvocation invoke] + 263 27 com.apple.CoreFoundation 0x00007fff8f6e86a9 -[NSInvocation invokeWithTarget:] + 57 28 com.apple.WebKit 0x00000001102b7e09 -[_WebSafeForwarder forwardInvocation:] + 361 (WebView.mm:3128) 29 com.apple.CoreFoundation 0x00007fff8f6e3737 ___forwarding___ + 775 30 com.apple.CoreFoundation 0x00007fff8f6e33b8 _CF_forwarding_prep_0 + 232 31 com.apple.WebKit 0x000000011019c3d1 WebChromeClient::makeFirstResponder(NSResponder*) + 129 (WebChromeClient.mm:778) 32 com.apple.WebCore 0x00000001109dfa81 WebCore::Chrome::focusNSView(NSView*) + 369 (ChromeMac.mm:46) 33 com.apple.WebCore 0x000000011237f209 WebCore::Widget::setFocus(bool) + 201 (WidgetMac.mm:113) 34 com.apple.WebCore 0x0000000110c77d37 WebCore::Document::setFocusedNode(WTF::PassRefPtr<WebCore::Node>, WebCore::FocusDirection) + 2071 (Document.cpp:3414) 35 com.apple.WebCore 0x0000000110f42c1d WebCore::FocusController::setFocusedNode(WebCore::Node*, WTF::PassRefPtr<WebCore::Frame>, WebCore::FocusDirection) + 973 (FocusController.cpp:620) 36 com.apple.WebCore 0x0000000110e880f2 WebCore::Element::focus(bool, WebCore::FocusDirection) + 306 (Element.cpp:1894) 37 com.apple.WebCore 0x000000011116ef9f WebCore::HTMLInputElement::focus(bool, WebCore::FocusDirection) + 111 (HTMLInputElement.cpp:377) 38 com.apple.WebCore 0x0000000111556bac WebCore::jsElementPrototypeFunctionFocus(JSC::ExecState*) + 444 (JSElement.cpp:1991) 39 ??? 0x00002ae2a6801045 0 + 47152944386117 40 com.apple.JavaScriptCore 0x000000010f197fe4 JSC::JITCode::execute(JSC::JSStack*, JSC::ExecState*, JSC::JSGlobalData*) + 84 (JITCode.h:135) 41 com.apple.JavaScriptCore 0x000000010f190719 JSC::Interpreter::execute(JSC::EvalExecutable*, JSC::ExecState*, JSC::JSValue, JSC::JSScope*) + 2169 (Interpreter.cpp:1321) 42 com.apple.JavaScriptCore 0x000000010f230565 JSC::globalFuncEval(JSC::ExecState*) + 997 (JSGlobalObjectFunctions.cpp:523) 43 com.apple.JavaScriptCore 0x000000010f195289 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 1561 (Interpreter.cpp:1058) 44 com.apple.JavaScriptCore 0x000000010efa4a52 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 306 (CallData.cpp:40) 45 com.apple.WebCore 0x000000011168ee52 WebCore::JSInjectedScriptHost::evaluate(JSC::ExecState*) + 482 (JSInjectedScriptHostCustom.cpp:304) 46 com.apple.WebCore 0x000000011168b82a WebCore::jsInjectedScriptHostPrototypeFunctionEvaluate(JSC::ExecState*) + 410 (JSInjectedScriptHost.cpp:310) 47 ??? 0x00002ae2a6801045 0 + 47152944386117 48 com.apple.JavaScriptCore 0x000000010f197fe4 JSC::JITCode::execute(JSC::JSStack*, JSC::ExecState*, JSC::JSGlobalData*) + 84 (JITCode.h:135) 49 com.apple.JavaScriptCore 0x000000010f19525f JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 1519 (Interpreter.cpp:1055) 50 com.apple.JavaScriptCore 0x000000010efa4a52 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 306 (CallData.cpp:40) 51 com.apple.WebCore 0x0000000111425572 WebCore::JSMainThreadExecState::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 146 (JSMainThreadExecState.h:56) 52 com.apple.WebCore 0x0000000111f3b329 WebCore::ScriptFunctionCall::call(bool&, bool) + 537 (ScriptFunctionCall.cpp:140) 53 com.apple.WebCore 0x000000011125bae5 WebCore::InjectedScriptBase::callFunctionWithEvalEnabled(WebCore::ScriptFunctionCall&, bool&) const + 213 (InjectedScriptBase.cpp:91) 54 com.apple.WebCore 0x000000011125bbc9 WebCore::InjectedScriptBase::makeCall(WebCore::ScriptFunctionCall&, WTF::RefPtr<WebCore::InspectorValue>*) + 137 (InjectedScriptBase.cpp:108) 55 com.apple.WebCore 0x000000011125bd7a WebCore::InjectedScriptBase::makeEvalCall(WTF::String*, WebCore::ScriptFunctionCall&, WTF::RefPtr<WebCore::TypeBuilder::Runtime::RemoteObject>*, WebCore::TypeBuilder::OptOutput<bool>*) + 74 (InjectedScriptBase.cpp:120) 56 com.apple.WebCore 0x0000000111256e6c WebCore::InjectedScript::evaluate(WTF::String*, WTF::String const&, WTF::String const&, bool, bool, bool, WTF::RefPtr<WebCore::TypeBuilder::Runtime::RemoteObject>*, WebCore::TypeBuilder::OptOutput<bool>*) + 316 (InjectedScript.cpp:72) 57 com.apple.WebCore 0x00000001113aadf8 WebCore::InspectorRuntimeAgent::evaluate(WTF::String*, WTF::String const&, WTF::String const*, bool const*, bool const*, int const*, bool const*, bool const*, WTF::RefPtr<WebCore::TypeBuilder::Runtime::RemoteObject>&, WebCore::TypeBuilder::OptOutput<bool>*) + 600 (InspectorRuntimeAgent.cpp:92) 58 com.apple.WebCore 0x00000001113ab043 non-virtual thunk to WebCore::InspectorRuntimeAgent::evaluate(WTF::String*, WTF::String const&, WTF::String const*, bool const*, bool const*, int const*, bool const*, bool const*, WTF::RefPtr<WebCore::TypeBuilder::Runtime::RemoteObject>&, WebCore::TypeBuilder::OptOutput<bool>*) + 179 59 com.apple.WebCore 0x00000001112a6bd1 WebCore::InspectorBackendDispatcherImpl::Runtime_evaluate(long, WebCore::InspectorObject*) + 1553 (InspectorBackendDispatcher.cpp:1662) 60 com.apple.WebCore 0x00000001112c4789 WebCore::InspectorBackendDispatcherImpl::dispatch(WTF::String const&) + 1833 (InspectorBackendDispatcher.cpp:6335) 61 com.apple.WebCore 0x00000001112d8390 WebCore::InspectorController::dispatchMessageFromFrontend(WTF::String const&) + 96 (InspectorController.cpp:357) 62 com.apple.WebCore 0x000000011135862e WebCore::InspectorBackendDispatchTask::onTimer(WebCore::Timer<WebCore::InspectorBackendDispatchTask>*) + 110 (InspectorFrontendClientLocal.cpp:94) 63 com.apple.WebCore 0x0000000111358a43 WebCore::Timer<WebCore::InspectorBackendDispatchTask>::fired() + 115 (Timer.h:106) 64 com.apple.WebCore 0x000000011229b356 WebCore::ThreadTimers::sharedTimerFiredInternal() + 294 (ThreadTimers.cpp:119) 65 com.apple.WebCore 0x000000011229b0e9 WebCore::ThreadTimers::sharedTimerFired() + 25 (ThreadTimers.cpp:94) 66 com.apple.WebCore 0x0000000111fcb513 WebCore::timerFired(__CFRunLoopTimer*, void*) + 67 (SharedTimerMac.mm:167) 67 com.apple.CoreFoundation 0x00007fff8f6b1da4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 68 com.apple.CoreFoundation 0x00007fff8f6b18bd __CFRunLoopDoTimer + 557 69 com.apple.CoreFoundation 0x00007fff8f697099 __CFRunLoopRun + 1513 70 com.apple.CoreFoundation 0x00007fff8f6966b2 CFRunLoopRunSpecific + 290 71 com.apple.Foundation 0x00007fff8c68489e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 268 72 DumpRenderTree 0x000000010edac009 runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 5017 (DumpRenderTree.mm:1375) 73 DumpRenderTree 0x000000010edaabfa runTestingServerLoop() + 282 (DumpRenderTree.mm:832) 74 DumpRenderTree 0x000000010edaa5f5 dumpRenderTree(int, char const**) + 405 (DumpRenderTree.mm:887) 75 DumpRenderTree 0x000000010edac7f9 main + 105 (DumpRenderTree.mm:925) 76 libdyld.dylib 0x00007fff8f51f7e1 start + 1 Removed the offending style rule that was causing the crash. It's not really related to this commit, so I'll file another bug. Committed r142507: <http://trac.webkit.org/changeset/142507> |