⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Timeline



Jan 6, 2013:

11:28 PM Changeset in webkit [138927] by jonlee@apple.com
  • 4 edits in trunk/Source/WebCore

Show label automatically for plug-ins of significant size
​https://bugs.webkit.org/show_bug.cgi?id=106146
<rdar://problem/12783010>

Reviewed by Simon Fraser.

For significantly sized plug-ins, trigger a timer that displays the label automatically
without requiring the user to mouse over the element first. The trickiness of the logic
here is that there are two delays involved-- one for whether the user mouses over (shorter),
and one for when the label is shown automatically (longer). Mousing over a plug-in that is
marked to show it automatically should have the timer delay switched. And if the label
showed automatically, mousing in and out of the element should not change that label's
state.

  • html/HTMLPlugInImageElement.cpp:

(WebCore): Add constants that determine whether the plug-in is of a significant size.
(WebCore::shouldPlugInShowLabelAutomatically): Based on the size of the frame view and the
clipped plug-in size, determine whether the label should show automatically. If the plug-in is
not contained within the bounds of the frame view, or is not at least as large as the threshold
size, then do not show the label automatically.
(WebCore::HTMLPlugInImageElement::subframeLoaderWillCreatePlugIn): After we've determined that
the plug-in should not auto-start, make a check to see if the label should show automatically.
Also, update some of the logging.
(WebCore::HTMLPlugInImageElement::subframeLoaderDidCreatePlugIn): Update the logging.

  • platform/Timer.h:

(WebCore::DeferrableOneShotTimer::setDelay): Added to allow changing the delay of the timer. It
does not change any currently set timer, but should change the delay for the next one.

  • rendering/RenderSnapshottedPlugIn.h: Rename the timer to m_showLabelDelayTimer since

it can fire for two different reasons. Add some additional state variables, and an enum
to explain why the label appeared.

  • rendering/RenderSnapshottedPlugIn.cpp:

(WebCore): Change hoverDelay to showLabelAfterMouseOverDelay. Add a new, longer delay for
when the plug-in is supposed to auto-show the label.
(WebCore::RenderSnapshottedPlugIn::RenderSnapshottedPlugIn): Initialize the member variables.
(WebCore::RenderSnapshottedPlugIn::updateSnapshot): When the snapshot image is updated,
start the timer to auto-show the label.
(WebCore::RenderSnapshottedPlugIn::paintLabel): Avoid painting the label only if the element
is not hovered and the user was mousing over the plug-in. Otherwise, the plug-in is supposed
to show automatically, and we should paint. Mark the renderer as having showed the label at
least once.
(WebCore::RenderSnapshottedPlugIn::showLabelDelayTimerFired): Renamed to reflect the
purpose of the timer.
(WebCore::RenderSnapshottedPlugIn::setShouldShowLabelAutomatically): Set the variable that
determines whether, in general, this plug-in should show the label automatically even
without user input.
(WebCore::RenderSnapshottedPlugIn::handleEvent): If the user mouses over the plug-in,
only reset the show timer is the label has never appeared before, or if it has, that
it's not because the label was supposed to show automatically. That is, if the label is
supposed to show automatically, the label should remain visible. This is also true when
the user mouses out of the plug-in. If the user moused out before the time had a chance
to fire and show the label for the first time, then we check to see if the plug-in should
be displaying the label automatically, and if so, restart the timer using the longer delay.
(WebCore::RenderSnapshottedPlugIn::stopAndRestartDelayTimer): Convenience function to
update the m_showReason variable, and reset the timer with the appropriate delay.

11:15 PM Changeset in webkit [138926] by inferno@chromium.org
  • 4 edits
    2 adds in trunk

Heap-use-after-free in DocumentLoader::stopLoading
​https://bugs.webkit.org/show_bug.cgi?id=103656

Reviewed by Eric Seidel.

Source/WebCore:

Test: fast/dom/ready-state-change-crash.html

  • html/parser/HTMLDocumentParser.cpp:

(WebCore::HTMLDocumentParser::prepareToStopParsing): Bail out
if the parser is detached due to mutation event.

  • loader/DocumentLoader.cpp:

(WebCore::DocumentLoader::stopLoading): Move the protectors for
frame and document loader to the start of the function. Call to
m_frame->loader()->stopLoading() can change document ready state
and fire mutation event which might blow the document loader from
underneath.

LayoutTests:

  • fast/dom/ready-state-change-crash-expected.txt: Added.
  • fast/dom/ready-state-change-crash.html: Added.
10:45 PM Changeset in webkit [138925] by hayato@chromium.org
  • 6 edits in branches/chromium/1364

Merge 138165

Expose WebKitShadowRoot constructor to DOMWindow.
​https://bugs.webkit.org/show_bug.cgi?id=105385

Reviewed by Dimitri Glazkov.

Source/WebCore:

This is a follow-up patch for r137870. WebKitShadowRoot
constructor should be in DOMWindow, just like all of the other
not-callable-constructors like HTMLDivElement, etc. We need it
for instanceof tests and so on.

Test: fast/dom/shadow/shadow-root-js-api.html

fast/js/global-constructors-expected.html

  • page/DOMWindow.idl:

LayoutTests:

  • fast/dom/shadow/shadow-root-js-api-expected.txt:
  • fast/dom/shadow/shadow-root-js-api.html:
  • fast/js/global-constructors-expected.txt:
  • platform/efl/fast/js/global-constructors-expected.txt:
  • platform/gtk/fast/js/global-constructors-expected.txt:

TBR=​hayato@chromium.org
Review URL: ​https://codereview.chromium.org/11776020

10:34 PM Changeset in webkit [138924] by fpizlo@apple.com
  • 5 edits in trunk/Source/JavaScriptCore

Simplify slow case profiling
​https://bugs.webkit.org/show_bug.cgi?id=106208

Reviewed by Mark Rowe.

Removing the minimum execution ratio portion of slow case profiling, which allows
the removal of a field from CodeBlock. This appears to be performance neutral,
implying that the complexity incurred by the previous heuristic was purely
harmful: it made the code more complicated, and it made CodeBlock larger, without
resulting in any measurable benefits.

  • bytecode/CodeBlock.cpp:

(JSC::CodeBlock::CodeBlock):

  • bytecode/CodeBlock.h:

(JSC::CodeBlock::likelyToTakeSlowCase):
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::likelyToTakeSpecialFastCase):
(JSC::CodeBlock::couldTakeSpecialFastCase):
(JSC::CodeBlock::likelyToTakeDeepestSlowCase):
(JSC::CodeBlock::likelyToTakeAnySlowCase):

  • jit/JIT.cpp:

(JSC::JIT::privateCompile):

  • runtime/Options.h:
10:10 PM Changeset in webkit [138923] by tasak@google.com
  • 2 edits in trunk/Source/WebCore

[Shadow DOM]: crash in WebCore::ElementShadow::setValidityUndetermined
​https://bugs.webkit.org/show_bug.cgi?id=106203

Reviewed by Hajime Morita.

InsertionPoint should check whether ElementShadow is available or not
before invoking its methods.

No new tests. Webcomponents_fuzzer reported this bug. Would like to
use the fuzzer to check this issue.

  • html/shadow/InsertionPoint.cpp:

(WebCore::InsertionPoint::getDistributedNodes):
(WebCore::InsertionPoint::childrenChanged):
(WebCore::InsertionPoint::insertedInto):
Added ifs to check whether ElementShadow is available or not before
invoking ElementShadow's methods, i.e. setValidityUndetermined,
invalidateDistribution, and ensureDistributionDocument.

10:03 PM Changeset in webkit [138922] by shinyak@chromium.org
  • 2 edits in trunk/Source/WebCore

RenderImage should not use shadowAncestorNode
​https://bugs.webkit.org/show_bug.cgi?id=97871

Reviewed by Dimitri Glazkov.

Since shadowAncestorNode() does not return 0, this if-condition will never hold.
shadowHost() should be used instead.

No change in logic, refactoring.

  • rendering/RenderImage.cpp:

(WebCore::RenderImage::hostImageElement):

6:24 PM Changeset in webkit [138921] by fpizlo@apple.com
  • 18 edits in trunk/Source/JavaScriptCore

DFG should inline closure calls
​https://bugs.webkit.org/show_bug.cgi?id=106067

Reviewed by Gavin Barraclough.

This adds initial support for inlining closure calls to the DFG. A call is considered
to be a closure call when the JSFunction* varies, but always has the same executable.
We already have closure call inline caching in both JITs, which works by checking that
the callee has an expected structure (as a cheap way of detecting that it is in fact
a JSFunction) and an expected executable. Closure call inlining uses profiling data
aggregated by CallLinkStatus to decide when to specialize the call to the particular
structure/executable, and inline the call rather than emitting a call sequence. When
we choose to do a closure inline rather than an ordinary inline, a number of things
change about how inlining is performed:

  • The inline is guarded by a CheckStructure/CheckExecutable rather than a CheckFunction.


  • Instead of propagating a constant value for the scope, we emit GetMyScope every time that the scope is needed, which loads the scope from a local variable. We do similar things for the callee.


  • The prologue of the inlined code includes SetMyScope and SetCallee nodes to eagerly plant the scope and callee into the "true call frame", i.e. the place on the stack where the call frame would have been if the call had been actually performed. This allows GetMyScope/GetCallee to work as they would if the code wasn't inlined. It also allows for trivial handling of scope and callee for call frame reconstruction upon stack introspection and during OSR.


  • A new node called GetScope is introduced, which just gets the scope of a function. This node has the expected CSE support. This allows for the SetMyScope(GetScope(@function)) sequence to set up the scope in the true call frame.


  • GetMyScope/GetCallee CSE can match against SetMyScope/SetCallee, which means that the GetMyScope/GetCallee nodes emitted during parsing are often removed during CSE, if we can prove that it is safe to do so.


  • Inlining heuristics are adjusted to grok the cost of inlining a closure. We are less likely to inline a closure call than we are to inline a normal call, since we end up emitting more code for closures due to CheckStructure, CheckExecutable, GetScope, SetMyScope, and SetCallee.


Additionally, I've fixed the VariableEventStream to ensure that we don't attempt to
plant Undefined into the true call frames. This was previously a harmless oversight,
but it becomes quite bad if OSR is relying on the scope/callee already having been
set and not subsequently clobbered by the OSR itself.

This is a ~60% speed-up on programs that frequently make calls to closures. It's
neutral on V8v7 and other major benchmark suites.

The lack of a definite speed-up is likely due the fact that closure inlining currently
does not do any cardinality [1] optimizations. We don't observe when a closure was
constructed within its caller, and so used the scope from its caller; and furthermore
we have no facility to detect when the scope is single. All scoped variable accesses
are assumed to be multiple instead. A subsequent step will be to ensure that closure
call inlining will be single and loving it.

[1] Single and loving it: Must-alias analysis for higher-order languages. Suresh

Jagannathan, Peter Thiemann, Stephen Weeks, and Andrew Wright. In POPL '98.

  • bytecode/CallLinkStatus.cpp:

(JSC::CallLinkStatus::dump):

  • bytecode/CallLinkStatus.h:

(JSC::CallLinkStatus::isClosureCall):
(CallLinkStatus):

  • bytecode/CodeBlock.cpp:

(JSC::CodeBlock::globalObjectFor):
(JSC):

  • bytecode/CodeBlock.h:

(CodeBlock):

  • bytecode/CodeOrigin.cpp:

(JSC::InlineCallFrame::dump):

  • dfg/DFGAbstractState.cpp:

(JSC::DFG::AbstractState::execute):

  • dfg/DFGByteCodeParser.cpp:

(ByteCodeParser):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::emitFunctionChecks):
(JSC::DFG::ByteCodeParser::handleInlining):

  • dfg/DFGCSEPhase.cpp:

(JSC::DFG::CSEPhase::pureCSE):
(CSEPhase):
(JSC::DFG::CSEPhase::getCalleeLoadElimination):
(JSC::DFG::CSEPhase::checkExecutableElimination):
(JSC::DFG::CSEPhase::getMyScopeLoadElimination):
(JSC::DFG::CSEPhase::performNodeCSE):

  • dfg/DFGCapabilities.cpp:

(JSC::DFG::mightInlineFunctionForClosureCall):

  • dfg/DFGCapabilities.h:

(DFG):
(JSC::DFG::mightInlineFunctionForClosureCall):
(JSC::DFG::canInlineFunctionForClosureCall):
(JSC::DFG::canInlineFunctionFor):

  • dfg/DFGNode.h:

(Node):
(JSC::DFG::Node::hasExecutable):
(JSC::DFG::Node::executable):

  • dfg/DFGNodeType.h:

(DFG):

  • dfg/DFGPredictionPropagationPhase.cpp:

(JSC::DFG::PredictionPropagationPhase::propagate):

  • dfg/DFGSpeculativeJIT32_64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

  • dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

  • dfg/DFGVariableEventStream.cpp:

(JSC::DFG::VariableEventStream::reconstruct):

  • runtime/Options.h:

(JSC):

3:58 PM Changeset in webkit [138920] by kerz@chromium.org
  • 2 edits in branches/chromium/1364/Source/WebKit/chromium

Merge 138302

[chromium] Disable color profile support for WebImageSkia users
​https://bugs.webkit.org/show_bug.cgi?id=105493

Reviewed by Eric Seidel.

Disable color profiles to prevent null pointer dereference under some
conditions. Tested by unittests at src.chromium.org.

  • src/WebImageSkia.cpp:

(WebKit::WebImage::fromData):
(WebKit::WebImage::framesFromData):

TBR=​noel.gordon@gmail.com
Review URL: ​https://codereview.chromium.org/11785017

12:26 PM Changeset in webkit [138919] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

Bug 106177 - [GStreamer] Don't call gst_video_info_from_caps() with non-fixed caps
​https://bugs.webkit.org/show_bug.cgi?id=106177

Patch by Sebastian Dröge <​sebastian.droege@collabora.co.uk> on 2013-01-06
Reviewed by Martin Robinson.

  • platform/graphics/gstreamer/GStreamerVersioning.cpp:

(getVideoSizeAndFormatFromCaps):
Don't call gst_video_info_from_caps() with non-fixed caps as
it will cause assertions.

10:53 AM Changeset in webkit [138918] by inferno@chromium.org
  • 3 edits
    2 adds in trunk

Heap-use-after-free in WebCore::Document::implicitClose
​https://bugs.webkit.org/show_bug.cgi?id=105655

Reviewed by Eric Seidel.

Source/WebCore:

Test: fast/dom/window-load-crash.html

  • dom/Document.cpp:

(WebCore::Document::implicitClose): RefPtr protect |this| document since it
can be destroyed in the dispatchWindowLoadEvent call.

LayoutTests:

  • fast/dom/window-load-crash-expected.txt: Added.
  • fast/dom/window-load-crash.html: Added.
3:18 AM BuildingGtk edited by Christophe Dumez
(diff)
3:17 AM BuildingGtk edited by Christophe Dumez
(diff)
1:43 AM Changeset in webkit [138917] by mkwst@chromium.org
  • 4 edits in trunk

Seamless: IFrame's padding isn't taken into account when calculating its height.
​https://bugs.webkit.org/show_bug.cgi?id=106167

Reviewed by Eric Seidel.

Source/WebCore:

IFrames rendered seamlessly don't currently calculate their height
correctly when padding is applied to the frame itself. This patch adds
padding calculations to RenderIFrame::layoutSeamlessly to ensure that
the seamless frame is correctly sized.

  • rendering/RenderIFrame.cpp:

(WebCore::RenderIFrame::layoutSeamlessly):

LayoutTests:

  • fast/frames/seamless/seamless-border-padding-expected.txt:

Adjusts the previously failing expectations to the correct values.

Jan 5, 2013:

10:16 PM Changeset in webkit [138916] by rniwa@webkit.org
  • 2 edits in trunk/Source/WebCore

REGRESSION: [Mac] Intermittent crashes in AXObjectCache::notificationPostTimerFired
​https://bugs.webkit.org/show_bug.cgi?id=106106

Reviewed by Eric Seidel.

The crash was cause by notification post timer firing after the object destruction had taken place.
Clear the timer so that this won't happen. Also make sure the document doesn't go away while we're
going through m_notificationsToPost.

No new tests since crashes have been caught by various layout tests, and we can't easily
create a deterministic layout test for this particular crash.

  • accessibility/AXObjectCache.cpp:

(WebCore::AXObjectCache::~AXObjectCache):
(WebCore::AXObjectCache::notificationPostTimerFired):

6:59 PM Changeset in webkit [138915] by fpizlo@apple.com
  • 2 edits in trunk/Source/JavaScriptCore

Data flow paths that carry non-numbers, non-undefined, non-null values should not cause subtractions and arithmetic additions (i.e. ++) to speculate double
​https://bugs.webkit.org/show_bug.cgi?id=106190

Reviewed by Sam Weinig.

The problem is that the DFG logic for deciding when to speculate integer was
confusing the special case of ValueAdd (where non-numeric values should cause us
to not speculate integer, because we want to fall off into the generic case) with
the more normal case of ArithAdd and ArithSub (where we want to speculate integer
unless we have evidence that the operands are doubles, since the DFG doesn't have
generic handling of those operations). Prior to this change doing a - b where
either a or b were possibly non-numeric would always force the subtraction to be
done using doubles.

  • dfg/DFGGraph.h:

(JSC::DFG::Graph::addSpeculationMode):
(Graph):
(JSC::DFG::Graph::valueAddSpeculationMode):
(JSC::DFG::Graph::arithAddSpeculationMode):
(JSC::DFG::Graph::addImmediateShouldSpeculateInteger):

6:45 PM Changeset in webkit [138914] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

IndexedDB: Replace int64 with int64_t
​https://bugs.webkit.org/show_bug.cgi?id=106189

Patch by Michael Pruett <​michael@68k.org> on 2013-01-05
Reviewed by Sam Weinig.

Cleaning up coding inconsistencies, no change in behavior.

Tests: storage/indexeddb/*

  • Modules/indexeddb/IDBDatabaseBackendImpl.cpp:

(WebCore::GetOperation::create):

6:26 PM Changeset in webkit [138913] by weinig@apple.com
  • 20 edits
    4 deletes in trunk/Source/WebKit2

Remove WebProcessInitialization and NetworkProcessInitialization by putting the rest of initialization in ChildProcess derived classes
​https://bugs.webkit.org/show_bug.cgi?id=106163

Reviewed by Darin Adler.

Adds ChildProcess::initializeProcessName() and the catchall ChildProcess::initializeProcess()
as the last pieces to have all the initialization from WebProcessInitialization and NetworkProcessInitialization
captured in ChildProcess and derived classes.

  • NetworkProcess/NetworkProcess.cpp:

(WebKit::NetworkProcess::initializeProcessName):
(WebKit::NetworkProcess::initializeSandbox):

  • NetworkProcess/NetworkProcess.h:

(NetworkProcess):

  • NetworkProcess/mac/NetworkProcessInitialization.h: Removed.
  • NetworkProcess/mac/NetworkProcessInitialization.mm: Removed.
  • NetworkProcess/mac/NetworkProcessMac.mm:

(WebKit::NetworkProcess::initializeProcessName):
(WebKit::NetworkProcess::initializeSandbox):

  • NetworkProcess/mac/NetworkProcessMainMac.mm:

(WebKit::NetworkProcessMain):

  • PluginProcess/PluginProcess.cpp:

(WebKit::PluginProcess::initializeProcess):

  • PluginProcess/PluginProcess.h:

(PluginProcess):

  • PluginProcess/mac/PluginProcessMac.mm:

(WebKit::PluginProcess::platformInitializeProcess):

  • PluginProcess/mac/PluginProcessMainMac.mm:

(WebKit::PluginProcessMain):

  • PluginProcess/qt/PluginProcessQt.cpp:

(WebKit::PluginProcess::platformInitializeProcess):
(WebKit::PluginProcess::platformInitializePluginProcess):

  • PluginProcess/unix/PluginProcessUnix.cpp:

(WebKit::PluginProcess::platformInitializeProcess):

  • Shared/ChildProcess.cpp:

(WebKit::ChildProcess::initialize):
(WebKit::ChildProcess::initializeProcess):
(WebKit::ChildProcess::initializeProcessName):
(WebKit::ChildProcess::initializeSandbox):
(WebKit::ChildProcess::initializeConnection):

  • Shared/ChildProcess.h:

(ChildProcess):

  • SharedWorkerProcess/mac/SharedWorkerProcessMainMac.mm:

(WebKit::SharedWorkerProcessMain):

  • WebKit2.xcodeproj/project.pbxproj:
  • WebProcess/WebProcess.cpp:

(WebKit::WebProcess::initializeProcess):
(WebKit::WebProcess::initializeProcessName):
(WebKit::WebProcess::initializeSandbox):

  • WebProcess/WebProcess.h:

(WebProcess):

  • WebProcess/mac/WebProcessInitialization.h: Removed.
  • WebProcess/mac/WebProcessInitialization.mm: Removed.
  • WebProcess/mac/WebProcessMac.mm:

(WebKit::WebProcess::initializeSandbox):
(WebKit::WebProcess::initializeProcessName):
(WebKit::WebProcess::platformInitializeProcess):

  • WebProcess/mac/WebProcessMainMac.mm:

(WebKit::WebProcessMain):

  • WebProcess/mac/WebProcessServiceEntryPoints.mm:

(WebKit::WebProcessServiceEventHandler):
(initializeWebProcessForWebProcessServiceForWebKitDevelopment):

4:03 PM Changeset in webkit [138912] by rniwa@webkit.org
  • 2 edits in trunk/LayoutTests

Add failing test expectations to some tile drawing tests on Mac WebKit2.
The failures are tracked by the bug 106187.

  • platform/mac-wk2/TestExpectations:
3:55 PM Changeset in webkit [138911] by rniwa@webkit.org
  • 2 edits in trunk/LayoutTests

Revert an erroneous change from r138874.

http/tests/misc/link-rel-icon-beforeload.html had been skipped prior to r138874
and it should continued to be.

  • platform/mac-wk2/TestExpectations:
3:40 PM Changeset in webkit [138910] by rniwa@webkit.org
  • 2 edits in trunk/LayoutTests

Add a flaky test expectation for the bug 106185.

  • platform/mac/TestExpectations:
3:07 PM Changeset in webkit [138909] by esprehn@chromium.org
  • 10 edits in trunk/Source/WebCore

Remove RenderObjectChildList::beforePseudoElementRenderer and afterPseudoElementRenderer
​https://bugs.webkit.org/show_bug.cgi?id=106132

Reviewed by Abhishek Arya.

We no longer need the complicated traversals in beforePseudoElementRenderer
and afterPseudoElementRenderer since we can get the renderers of pseudo
elements through the node. This removes all that code and swaps it for
Element::pseudoElementRenderer.

This is possible now that r138850 removed all the now incorrect manual
management of pseudo element renderers from the render tree that was
left over from before the switch to DOM based pseudo elements.

No new tests, just refactoring.

  • css/CSSComputedStyleDeclaration.cpp:

(WebCore::CSSComputedStyleDeclaration::getPropertyCSSValue):

  • dom/Element.cpp:

(WebCore::Element::pseudoElementRenderer):

Added, gets the renderer of the pseudo element by PseudoId if it
exists.

  • dom/Element.h:

(Element):

  • dom/NodeRenderingTraversal.cpp:

(WebCore::NodeRenderingTraversal::nextSiblingSlow):
(WebCore::NodeRenderingTraversal::previousSiblingSlow):

  • rendering/RenderCounter.cpp:

(WebCore::previousInPreOrder):
(WebCore::previousSiblingOrParent):
(WebCore::nextInPreOrder):

  • rendering/RenderObject.h:

(WebCore::RenderObject::lastChild):

  • rendering/RenderObjectChildList.cpp:
  • rendering/RenderObjectChildList.h:

(RenderObjectChildList):

  • rendering/RenderTreeAsText.cpp:

(WebCore::counterValueForElement):

1:23 PM Changeset in webkit [138908] by robert@webkit.org
  • 3 edits
    2 adds in trunk

Heap-use-after-free in WebCore::RenderBlock::insertIntoTrackedRendererMaps
​https://bugs.webkit.org/show_bug.cgi?id=105654

Reviewed by Simon Fraser.

Source/WebCore:

As with position:relative, position:sticky does not apply to table sections.

Test: fast/block/sticky-position-containing-block-crash.html

  • css/StyleResolver.cpp:

(WebCore::StyleResolver::adjustRenderStyle):

LayoutTests:

  • fast/block/sticky-position-containing-block-crash-expected.txt: Added.
  • fast/block/sticky-position-containing-block-crash.html: Added.
1:20 PM Changeset in webkit [138907] by mkwst@chromium.org
  • 7 edits
    1 add in trunk/LayoutTests

Deflaking http/tests/security/contentSecurityPolicy/report-uri-from-javascript.html
​https://bugs.webkit.org/show_bug.cgi?id=106165

Reviewed by Adam Barth.

The original test chose its violation mechanism poorly. The existing injection file
injected two violations, which generated reports delivered in a random order. This
patch creates a new injection JavaScript file that injects a single image, generating
a single report. That should deflake the test.

  • http/tests/security/contentSecurityPolicy/report-uri-from-javascript-expected.txt:
  • http/tests/security/contentSecurityPolicy/report-uri-from-javascript.html:
  • http/tests/security/contentSecurityPolicy/resources/inject-image.js:

Adjusting the test to be deterministic.

  • platform/chromium/TestExpectations:
  • platform/efl/TestExpectations:
  • platform/mac/TestExpectations:
  • platform/qt/TestExpectations:

Unskipping test.

1:07 PM Changeset in webkit [138906] by mkwst@chromium.org
  • 4 edits in trunk/Source/WebCore

Cleanup: mayDisplaySeamlessWithParent -> mayDisplaySeamless_ly_WithParent
​https://bugs.webkit.org/show_bug.cgi?id=106169

Reviewed by Eric Seidel.

This patch renames SecurityContext's 'm_mayDisplaySeamlessWithParent' to
'm_mayDisplaySeamlesslyWithParent'. Because adverbs matter.

  • dom/Document.cpp:

(WebCore::Document::initSecurityContext):
(WebCore::Document::shouldDisplaySeamlesslyWithParent):

  • dom/SecurityContext.cpp:

(WebCore::SecurityContext::SecurityContext):

  • dom/SecurityContext.h:

(SecurityContext):

1:02 PM Changeset in webkit [138905] by commit-queue@webkit.org
  • 3 edits in trunk/Source/WebKit/blackberry

[BlackBerry] SelectionHandler::selectAtPoint should use last fat finger result when it is a link
​https://bugs.webkit.org/show_bug.cgi?id=106141

Patch by Andy Chen <​andchen@rim.com> on 2013-01-05
Reviewed by Rob Buis.

If last fat finger result is a link, select it directly when
SelectionHandler::selectAtPoint is called.
PR 263449
Internally reviewed by Mike Fenton and Yongxin Dai.

  • WebKitSupport/SelectionHandler.cpp:

(BlackBerry::WebKit::SelectionHandler::selectNodeIfFatFingersResultIsLink):
(WebKit):
(BlackBerry::WebKit::SelectionHandler::selectAtPoint):

  • WebKitSupport/SelectionHandler.h:

(WebKit):
(SelectionHandler):

12:50 PM Changeset in webkit [138904] by mkwst@chromium.org
  • 3 edits
    2 adds in trunk

seamless iframes don't take border into account properly and make the iframe too small.
​https://bugs.webkit.org/show_bug.cgi?id=90827

Reviewed by Ojan Vafai.

Source/WebCore:

Seamless IFrames were incorrectly calculating their width; borders and
padding of the child document were accidentally left out of the end
result. This tiny patch adds the border/padding width to the calculated
width for the seamless IFrame, bringing things back into line with
expectations.

Test: fast/frames/seamless/seamless-border-padding.html

  • rendering/RenderIFrame.cpp:

(WebCore::RenderIFrame::minPreferredLogicalWidth):
(WebCore::RenderIFrame::maxPreferredLogicalWidth):

Add borderAndPaddingLogicalWidth() to the result of both methods.

LayoutTests:

  • fast/frames/seamless/seamless-border-padding-expected.txt: Added.
  • fast/frames/seamless/seamless-border-padding.html: Added.

This test checks the IFrame's handling of borders and padding.
Things work correctly for width after this patch, but there are
still issues with padding and height, which will be fixed in
​http://wkbug.com/106167

12:50 PM Changeset in webkit [138903] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WTF

Only enable MinGW-w64 pow() workaround if needed
​https://bugs.webkit.org/show_bug.cgi?id=106099

Patch by Jonathan Liu <​net147@gmail.com> on 2013-01-05
Reviewed by Filip Pizlo.

The pow() workaround is no longer needed in the latest version
of MinGW-w64.

  • wtf/MathExtras.h:
12:49 PM Changeset in webkit [138902] by commit-queue@webkit.org
  • 3 edits
    2 adds in trunk

MediaControls::show() should make controls opaque
​https://bugs.webkit.org/show_bug.cgi?id=106034

Patch by Min Qin <​qinmin@chromium.org> on 2013-01-05
Reviewed by Eric Carlson.

Source/WebCore:

When a video enters fullscreen, webkit starts a timer to make the control transparent when the timer expires.
If the user exits fullscreen while the timer expires, webkit will call mediaControls::show().
However, show() actually displays nothing as the control is transparent.
The user had to move his mouse outside the video rect and move it back in order to show the controls.
Simply clicking/moving the mouse inside the video rect will not make the control opaque.
Test: media/video-controls-visible-exiting-fullscreen.html

  • html/shadow/MediaControls.cpp:

(WebCore::MediaControls::show):

LayoutTests:

Add tests to check that video controls are shown when exiting from fullscreen.

  • media/video-controls-visible-exiting-fullscreen-expected.txt: Added.
  • media/video-controls-visible-exiting-fullscreen.html: Added.
12:44 PM Changeset in webkit [138901] by commit-queue@webkit.org
  • 2 edits in trunk/LayoutTests

[WK2] Exclude IndexedDB tests which use eventSender.beginDragWithFiles()
​https://bugs.webkit.org/show_bug.cgi?id=106138

Patch by Michael Pruett <​michael@68k.org> on 2013-01-05
Reviewed by Alexey Proskuryakov.

  • platform/wk2/TestExpectations:
12:42 PM Changeset in webkit [138900] by alecflett@chromium.org
  • 24 edits in trunk

IndexedDB: Migrate backend ObjectStore calls to use transaction id
​https://bugs.webkit.org/show_bug.cgi?id=102741

Reviewed by Tony Chang.

Source/WebCore:

Fully migrate 8 core data calls (get, put, setIndexKeys, setIndexesReady,
openCursor, count, deleteRange, and clear) into IDBDatabaseBackendImpl,
combining common code from IDBObjectStoreBackendImpl and IDBIndexBackendImpl
in order to simplify the backend interface. These calls are now
implemented in terms of an int64_t-based transactionId rather than
an IDBTransactionBackendInterface, which simplifies the ownership model
between the frontend and the backend.

In addition, remove references to IDBObjectStoreBackend* from IDBIndex,
as it is no longer needed.

A few duplicate IDB_TRACE methods have been removed from wrapper methods
that call another method that already have IDB_TRACE's.

Finally, IDBCursorBackendImpl now no longer holds onto an
IDBObjectStoreBackendImpl*, so its destruction and member variables are
simplified, and reordered to match proper destruction order.

  • Modules/indexeddb/IDBCursorBackendImpl.cpp: Reordered to account for proper destruction.

(WebCore::IDBCursorBackendImpl::IDBCursorBackendImpl):
(WebCore::IDBCursorBackendImpl::~IDBCursorBackendImpl):
(WebCore::IDBCursorBackendImpl::deleteFunction):

  • Modules/indexeddb/IDBCursorBackendImpl.h:

(WebCore::IDBCursorBackendImpl::create):
(IDBCursorBackendImpl):

  • Modules/indexeddb/IDBDatabase.h:

(WebCore::IDBDatabase::backend):
(IDBDatabase):

  • Modules/indexeddb/IDBDatabaseBackendImpl.cpp:

(GetOperation): Combined from IDBObjectStoreBackendImpl/IDBIndexBackendImpl::*RetrievalOperation
(WebCore::GetOperation::create):
(WebCore::GetOperation::GetOperation):
(WebCore):
(PutOperation): Combined from IDBObjectStoreBackendImpl/IDBIndexBackendImpl::*StorageOperation.
(WebCore::PutOperation::create):
(WebCore::PutOperation::PutOperation):
(SetIndexesReadyOperation): Moved from IDBObjectStoreBackendImpl::IndexesReadyOperation
(WebCore::SetIndexesReadyOperation::create):
(WebCore::SetIndexesReadyOperation::SetIndexesReadyOperation):
(OpenCursorOperation): Combined from IDBObjectStoreBackendImpl/IDBIndexBackendImpl::Open*CursorOperation
(WebCore::OpenCursorOperation::create):
(WebCore::OpenCursorOperation::OpenCursorOperation):
(CountOperation): Combined from IDBObjectStoreBackendImpl/IDBIndexBackendImpl::CountOperation
(WebCore::CountOperation::create):
(WebCore::CountOperation::CountOperation):
(DeleteRangeOperation): Moved from IDBObjectStoreBackendImpl::DeleteOperation
(WebCore::DeleteRangeOperation::create):
(WebCore::DeleteRangeOperation::DeleteRangeOperation):
(ClearOperation): Moved from IDBObjectStoreBackendImpl::ClearOperation
(WebCore::ClearOperation::create):
(WebCore::ClearOperation::ClearOperation):
(WebCore::IDBDatabaseBackendImpl::get): Combined from IDBObjectStoreBackendImpl/IDBIndexBackendImpl::get*
(WebCore::GetOperation::perform):
(WebCore::IDBDatabaseBackendImpl::put): Moved from IDBObjectStoreBackendImpl::put
(WebCore::PutOperation::perform):
(WebCore::IDBDatabaseBackendImpl::setIndexKeys): Moved from IDBObjectStoreBackendImpl::setIndexKeys
(WebCore::IDBDatabaseBackendImpl::setIndexesReady):
(WebCore::SetIndexesReadyOperation::perform):
(WebCore::IDBDatabaseBackendImpl::openCursor):
(WebCore::IDBDatabaseBackendImpl::count):
(WebCore::CountOperation::perform):
(WebCore::IDBDatabaseBackendImpl::deleteRange):
(WebCore::DeleteRangeOperation::perform):
(WebCore::IDBDatabaseBackendImpl::clear):
(WebCore::ClearOperation::perform):
(WebCore::OpenCursorOperation::perform):

  • Modules/indexeddb/IDBIndex.cpp:

(WebCore::IDBIndex::IDBIndex):
(WebCore::IDBIndex::openCursor):
(WebCore::IDBIndex::count):
(WebCore::IDBIndex::openKeyCursor):
(WebCore::IDBIndex::get):
(WebCore::IDBIndex::getKey):
(WebCore::IDBIndex::backendDB):
(WebCore):

  • Modules/indexeddb/IDBIndex.h:

(WebCore::IDBIndex::create):
(IDBIndex):

  • Modules/indexeddb/IDBIndexBackendImpl.cpp:

(WebCore::IDBIndexBackendImpl::IDBIndexBackendImpl):

  • Modules/indexeddb/IDBIndexBackendImpl.h:

(WebCore::IDBIndexBackendImpl::create):
(WebCore::IDBIndexBackendImpl::openCursor):
(WebCore::IDBIndexBackendImpl::count):
(WebCore::IDBIndexBackendImpl::openKeyCursor):
(WebCore::IDBIndexBackendImpl::get):
(WebCore::IDBIndexBackendImpl::getKey):
(IDBIndexBackendImpl):

  • Modules/indexeddb/IDBObjectStore.cpp:

(WebCore::IDBObjectStore::get):
(WebCore::IDBObjectStore::put):
(WebCore::IDBObjectStore::deleteFunction):
(WebCore::IDBObjectStore::clear):
(WebCore):
(WebCore::IDBObjectStore::createIndex):
(WebCore::IDBObjectStore::index):
(WebCore::IDBObjectStore::openCursor):
(WebCore::IDBObjectStore::count):
(WebCore::IDBObjectStore::backendDB):

  • Modules/indexeddb/IDBObjectStore.h:

(WebCore::IDBObjectStore::id):
(IDBObjectStore):

  • Modules/indexeddb/IDBObjectStoreBackendImpl.cpp:

(WebCore::IDBObjectStoreBackendImpl::createIndex):
(WebCore::IDBObjectStoreBackendImpl::loadIndexes):
(WebCore::IDBObjectStoreBackendImpl::generateKey):
(WebCore::IDBObjectStoreBackendImpl::updateKeyGenerator):

  • Modules/indexeddb/IDBObjectStoreBackendImpl.h:

(WebCore::IDBObjectStoreBackendImpl::get):
(WebCore::IDBObjectStoreBackendImpl::put):
(WebCore::IDBObjectStoreBackendImpl::deleteFunction):
(WebCore::IDBObjectStoreBackendImpl::clear):
(WebCore::IDBObjectStoreBackendImpl::setIndexKeys):
(WebCore::IDBObjectStoreBackendImpl::setIndexesReady):
(WebCore::IDBObjectStoreBackendImpl::openCursor):
(WebCore::IDBObjectStoreBackendImpl::count):
(IDBObjectStoreBackendImpl):

  • Modules/indexeddb/IDBTransactionBackendImpl.h:

(WebCore::IDBTransactionBackendImpl::database):
(IDBTransactionBackendImpl):

Source/WebKit/chromium:

Fix a bug where an array was initialized with a large empty buffer,
clean up whitespace, and update to match signatures that changed
in WebCore.

  • public/WebIDBDatabase.h:

(WebKit::WebIDBDatabase::clear):

  • src/WebIDBDatabaseImpl.cpp:

(WebKit::WebIDBDatabaseImpl::put):

  • src/WebIDBIndexImpl.cpp:
  • tests/IDBDatabaseBackendTest.cpp:

LayoutTests:

Add additional count() tests for multi-entry indexes, not previously
covered.

  • storage/indexeddb/index-multientry-expected.txt:
  • storage/indexeddb/resources/index-multientry.js:

(.transaction.oncomplete):
(verifyCount.request.onsuccess.request.onsuccess):
(verifyCount.request.onsuccess):
(verifyCount):

12:26 PM Changeset in webkit [138899] by robert@webkit.org
  • 3 edits
    2 adds in trunk

Max width of a floated container with floated children calculated incorrectly
​https://bugs.webkit.org/show_bug.cgi?id=47975

Source/WebCore:

Accumulate the width of child floats in the correct counter so that it gets reset
as expected when a subsequent sibling decides to clear it.

Reviewed by Levi Weintraub.

Test: fast/block/float/max-width-clear-float-with-overflow-hidden.html

  • rendering/RenderBlock.cpp:

(WebCore::RenderBlock::computeBlockPreferredLogicalWidths):

LayoutTests:

Reviewed by Levi Weintraub.

  • fast/block/float/max-width-clear-float-with-overflow-hidden-expected.html: Added.
  • fast/block/float/max-width-clear-float-with-overflow-hidden.html: Added.
12:22 PM Changeset in webkit [138898] by alecflett@chromium.org
  • 10 edits in trunk/Source

IndexedDB: Stub out IDBDatabaseBackendInterface::createIndex/deleteIndex
​https://bugs.webkit.org/show_bug.cgi?id=106117

Reviewed by Adam Barth.

Source/WebCore:

No new tests, these are just stubs for refactoring.

  • Modules/indexeddb/IDBDatabaseBackendImpl.h:

(WebCore::IDBDatabaseBackendImpl::createIndex):
(WebCore::IDBDatabaseBackendImpl::deleteIndex):
(IDBDatabaseBackendImpl):

  • Modules/indexeddb/IDBDatabaseBackendInterface.h:

(IDBDatabaseBackendInterface):

Source/WebKit/chromium:

Stubs for migration from WebIDBObjectStore.

  • public/WebIDBDatabase.h:

(WebKit::WebIDBDatabase::createIndex):
(WebKit::WebIDBDatabase::deleteIndex):
(WebIDBDatabase):

  • src/IDBDatabaseBackendProxy.cpp:

(WebKit::IDBDatabaseBackendProxy::createIndex):
(WebKit):
(WebKit::IDBDatabaseBackendProxy::deleteIndex):

  • src/IDBDatabaseBackendProxy.h:

(IDBDatabaseBackendProxy):

  • src/WebIDBDatabaseImpl.cpp:

(WebKit::WebIDBDatabaseImpl::createIndex):
(WebKit):
(WebKit::WebIDBDatabaseImpl::deleteIndex):

  • src/WebIDBDatabaseImpl.h:

(WebIDBDatabaseImpl):

  • tests/IDBDatabaseBackendTest.cpp:
12:11 PM Changeset in webkit [138897] by tasak@google.com
  • 4 edits
    2 adds in trunk

[Shadow DOM]: Some named elements in ShadowTree visible on nesting document level
​https://bugs.webkit.org/show_bug.cgi?id=105617

Reviewed by Dimitri Glazkov.

Source/WebCore:

According to the shadow dom spec, the nodes and named elements are not
accessible using shadow host's document DOM tree accessors or with
Window object named properties. c.f.
​https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation

Test: fast/dom/shadow/element-name-in-shadow.html

  • dom/Element.h:

(WebCore::Element::updateName):
Check whether the given element is in a shadow dom tree or not. If in
a shadow dom tree, don't register the name.

  • html/HTMLIFrameElement.cpp:

(WebCore::HTMLIFrameElement::insertedInto):
(WebCore::HTMLIFrameElement::removedFrom):
(WebCore::HTMLIFrameElement::parseAttribute):
HTMLIFrameElement doesn't use updateName. Instead the element uses
addExtraNamedItem and removeExtraNameItem in HTMLIFrameElement.cpp.

LayoutTests:

  • fast/dom/shadow/element-name-in-shadow-expected.txt: Added.
  • fast/dom/shadow/element-name-in-shadow.html: Added.
12:05 PM Changeset in webkit [138896] by zandobersek@gmail.com
  • 2 edits in trunk/LayoutTests

Unreviewed GTK gardening

Skipping http/tests/multipart/multipart-wait-before-boundary.html for now,
the test is intermittently timing out on release builders despite being assigned
a SLOW expectation, thus unnecessarily painting bots red. A bug identifier is also
added for this test.

  • platform/gtk/TestExpectations:
12:04 PM Changeset in webkit [138895] by crogers@google.com
  • 9 edits in trunk

Implement MediaStreamSource::setAudioFormat()
​https://bugs.webkit.org/show_bug.cgi?id=106053

Reviewed by Kenneth Russell.

Source/Platform:

  • chromium/public/WebAudioDestinationConsumer.h:

(WebAudioDestinationConsumer):

Source/WebCore:

MediaStreamAudioDestinationNode needs to be able to tell its associated
MediaStreamSource about the audio format (number of channels and sample-rate).

  • Modules/webaudio/MediaStreamAudioDestinationNode.cpp:

(WebCore::MediaStreamAudioDestinationNode::MediaStreamAudioDestinationNode):

  • platform/audio/AudioDestinationConsumer.h:

(AudioDestinationConsumer):

  • platform/chromium/support/WebMediaStreamSource.cpp:

(ConsumerWrapper):
(WebKit::ConsumerWrapper::setFormat):
(WebKit):

  • platform/mediastream/MediaStreamSource.cpp:

(WebCore::MediaStreamSource::setAudioFormat):
(WebCore):

  • platform/mediastream/MediaStreamSource.h:

(MediaStreamSource):

12:02 PM Changeset in webkit [138894] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WTF

Fix compilation of MathExtras.h with MinGW-w64
​https://bugs.webkit.org/show_bug.cgi?id=106105

Patch by Jonathan Liu <​net147@gmail.com> on 2013-01-05
Reviewed by Simon Hausmann.

The isfinite and isinf functions are required by wtf_pow but
not defined until after wtf_pow. Move wtf_pow to after
"using std::isfinite" and "using std::isinf" to fix compilation.

  • wtf/MathExtras.h:

(wtf_pow):

12:01 PM Changeset in webkit [138893] by commit-queue@webkit.org
  • 4 edits in trunk/Source/WebKit/chromium

Add function to move caret selection towards a point
​https://bugs.webkit.org/show_bug.cgi?id=105189

Patch by Chris Hopman <​cjhopman@google.com> on 2013-01-05
Reviewed by Eric Seidel.

This function moves the selection to the corresponding point in the
rootEditableElement of the current selection. Used on Android for
the behavior of insertion handles (i.e. dragging the caret around).

  • public/WebFrame.h:

(WebFrame):

  • src/WebFrameImpl.cpp:

(WebKit::WebFrameImpl::moveCaretSelectionTowardsWindowPoint):
(WebKit):

  • src/WebFrameImpl.h:

(WebFrameImpl):

7:15 AM Changeset in webkit [138892] by Christophe Dumez
  • 7 edits in trunk/LayoutTests

Unreviewed EFL gardening.

Rebaseline several tests after r138838.

  • platform/efl/fast/ruby/base-shorter-than-text-expected.png:
  • platform/efl/fast/ruby/base-shorter-than-text-expected.txt:
  • platform/efl/fast/table/038-vertical-expected.png:
  • platform/efl/fast/table/038-vertical-expected.txt:
  • platform/efl/fast/table/border-collapsing/004-vertical-expected.png:
  • platform/efl/fast/table/border-collapsing/004-vertical-expected.txt:
5:52 AM Changeset in webkit [138891] by zeno.albisser@digia.com
  • 2 edits in trunk/Source/WebCore

[Texmap] TextureMapperGL should reset ARRAY_BUFFER after painting.
​https://bugs.webkit.org/show_bug.cgi?id=106098

This fixes the issue of the address bar disappearing in
Qt/MiniBrowser after r138555.

Reviewed by Jocelyn Turcotte.

  • platform/graphics/texmap/TextureMapperGL.cpp:

(WebCore::TextureMapperGL::drawEdgeTriangles):
(WebCore::TextureMapperGL::drawUnitRect):

1:24 AM AddingFeatures edited by zandobersek@gmail.com
Adjust the name of the file containing feature defines for the … (diff)
1:04 AM Changeset in webkit [138890] by fpizlo@apple.com
  • 2 edits in trunk/Source/JavaScriptCore

DFG should trust array profiling over value profiling
​https://bugs.webkit.org/show_bug.cgi?id=106155

Reviewed by Gavin Barraclough.

The real problem is that prediction propagation is not flow-sensitive. We had code
like:

var a = (some load from memory); returns either an array or false
if (a)

a[i] = v;


Because 'a' could be 'false', we were emitting a fully generic unoptimized PutByVal.
This patch changes ArrayMode to ignore the type of the base of an array access, if
array profiling tells us that the array access can be optimized.

In the future, we could probably make this work even better with some flow
sensitivity in the prediction propagator, but I also tend to think that this is a
more robust overall solution. If we ever did want to support array accesses on
array-or-false then we should change the array profiler to be able to tell us that
this is what is going on.

3.7% speed-up on V8/earley.

  • dfg/DFGArrayMode.cpp:

(JSC::DFG::ArrayMode::refine):

12:28 AM Changeset in webkit [138889] by rniwa@webkit.org
  • 1 edit
    1 delete in trunk/Tools

Add svn:executable to a bunch of scripts in BuildSlaveSupport.
Also removed the empty mac directory.

  • BuildSlaveSupport/built-product-archive: Added property svn:executable.
  • BuildSlaveSupport/download-built-product: Added property svn:executable.
  • BuildSlaveSupport/mac: Removed.
  • BuildSlaveSupport/test-result-archive: Added property svn:executable.
12:20 AM Changeset in webkit [138888] by rniwa@webkit.org
  • 2 edits
    1 add in trunk/Tools

Add a script to delete stale zero-byte build files
​https://bugs.webkit.org/show_bug.cgi?id=106131

Reviewed by Tony Chang.

Delete zero-byte build files on Mac port for now. It doesn't do anything on other ports.

  • BuildSlaveSupport/build.webkit.org-config/master.cfg:

(DeleteStaleBuildFiles): Added.
(Factory.init): Add DeleteStaleBuildFiles step.

  • BuildSlaveSupport/delete-stale-build-files: Added.

(main): Delete zero-byte files except ones intentionally generated by our build process.
(webkitBuildDirectory): Copied from build-product-archive.

Note: See TracTimeline for information about the timeline view.