Timeline
Apr 8, 2012:
- 10:25 PM Changeset in webkit [113556] by
-
- 2 edits in trunk/Source/WebKit/mac
[mac] REGRESSION (r113467): Some canvas tests are failing in WebKit1 when run after compositing/tiled-layers-hidpi.html
https://bugs.webkit.org/show_bug.cgi?id=83453
Reviewed by Sam Weinig.
- WebView/WebView.mm:
(-[WebView _setCustomBackingScaleFactor:]): When the scale factor parameter was 0, meaning
no custom scale factor, this method was setting the Page scale factor to 0, and that value
was used by canvas. Changed it to correctly set the Page scale factor back to the device
scale factor.
- 9:59 PM Changeset in webkit [113555] by
-
- 4 edits in trunk
<content> in <meter> is not rendered correctly.
https://bugs.webkit.org/show_bug.cgi?id=81311
This code changes a code location where MeterValueElement's value
attribute is initialized. In the old code, HTMLMeterElement's attach
did. It is better to initialize the attribute just after creating
meter's shadow subtree.
Patch by Takashi Sakamoto <tasak@google.com> on 2012-04-08
Reviewed by Hajime Morita.
No new tests, because an existing test,
content-element-in-meter-element.html covers.
However test_expectations.txt is changed. Now the test passes.
- html/HTMLMeterElement.cpp:
- html/HTMLMeterElement.h:
(HTMLMeterElement):
(HTMLMeterElement::attach):
Removed attach method, because attach method is just calling
LabelableElement::attach after removing didElementStateChange.
(HTMLMeterElement::createShadowSubTree):
Added setWidthPercentage to initialize MeterValueElement's value
attribute.
- LayoutTests/platform/chromium/test_expectations.txt:
Removed BUGWK81311 fast/dom/shadow/content-element-in-meter.html,
because now contentElementInMeterElement passes.
- 9:04 PM Changeset in webkit [113554] by
-
- 2 edits in trunk/Tools
The port object is missing unit_tests_results_path
https://bugs.webkit.org/show_bug.cgi?id=83448
Unreviewed.
This is causing the cr-linux-ews to throw an exception.
- Scripts/webkitpy/common/config/ports.py:
(DeprecatedPort.unit_tests_results_path):
- 1:50 PM Changeset in webkit [113553] by
-
- 2 edits in trunk/Source/JavaScriptCore
Command-line jsc's exception handling should be rationalized
https://bugs.webkit.org/show_bug.cgi?id=83437
Reviewed by Dan Bernstein.
- If an exception is thrown during run() execution, it is now propagated, so that it will terminate program execution unless it is caught.
- If program execution terminates with an exception, the exception is now always printed.
- When printing the exception, the backtrace is now also printed if one is available. It will only not be available if you use something akin to my favorite line of code, 'throw "error"', since primitives don't have properties and hence we cannot attach a "stack" property to them.
- jsc.cpp:
(functionRun):
(runWithScripts):
- 1:46 PM Changeset in webkit [113552] by
-
- 14 edits in trunk/Source/JavaScriptCore
Forced OSR exits should lead to recompilation based on count, not rate
https://bugs.webkit.org/show_bug.cgi?id=83247
<rdar://problem/10720925>
Reviewed by Geoff Garen.
Track which OSR exits happen because of inadequate coverage. Count them
separately. If the count reaches a threshold, immediately trigger
reoptimization.
This is in contrast to the recompilation trigger for all other OSR exits.
Normally recomp is triggered when the exit rate exceeds a certain ratio.
Looks like a slight V8 speedup (sub 1%).
- bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
- bytecode/CodeBlock.h:
(JSC::CodeBlock::forcedOSRExitCounter):
(JSC::CodeBlock::addressOfForcedOSRExitCounter):
(JSC::CodeBlock::offsetOfForcedOSRExitCounter):
(JSC::CodeBlock::shouldReoptimizeNow):
(JSC::CodeBlock::shouldReoptimizeFromLoopNow):
(CodeBlock):
- bytecode/DFGExitProfile.h:
(JSC::DFG::exitKindToString):
- dfg/DFGOSRExitCompiler.cpp:
(JSC::DFG::OSRExitCompiler::handleExitCounts):
(DFG):
- dfg/DFGOSRExitCompiler.h:
(OSRExitCompiler):
- dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
- dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
- dfg/DFGOperations.cpp:
- dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
- dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- runtime/Options.cpp:
(Options):
(JSC::Options::initializeOptions):
- runtime/Options.h:
(Options):
- 1:38 PM PrefixedAPIs edited by
- (diff)
- 11:35 AM Changeset in webkit [113551] by
-
- 2 edits in trunk/Source/WebCore
Build fix for !ENABLE(CSS_FILTERS) && ASSERT_DISABLED after r109953.
- platform/graphics/ca/GraphicsLayerCA.cpp:
Apr 7, 2012:
- 8:45 PM Changeset in webkit [113550] by
-
- 2 edits19 adds in trunk/LayoutTests
2012-04-07 Andrew Scherkus <scherkus@chromium.org>
[Chromium] Unreviewed, checking in baselines for video-frame-size-change.html.
- platform/chromium-linux/platform/chromium/compositing/video-frame-size-change-expected.png: Added.
- platform/chromium-linux/platform/chromium/media/video-frame-size-change-expected.png: Added.
- platform/chromium-mac-leopard/platform/chromium/compositing/video-frame-size-change-expected.png: Added.
- platform/chromium-mac-leopard/platform/chromium/media/video-frame-size-change-expected.png: Added.
- platform/chromium-mac-snowleopard/platform/chromium/compositing/video-frame-size-change-expected.png: Added.
- platform/chromium-mac-snowleopard/platform/chromium/media/video-frame-size-change-expected.png: Added.
- platform/chromium-mac/platform/chromium/compositing/video-frame-size-change-expected.png: Added.
- platform/chromium-mac/platform/chromium/compositing/video-frame-size-change-expected.txt: Added.
- platform/chromium-mac/platform/chromium/media/video-frame-size-change-expected.png: Added.
- platform/chromium-mac/platform/chromium/media/video-frame-size-change-expected.txt: Added.
- platform/chromium-win/platform/chromium/compositing/video-frame-size-change-expected.png: Added.
- platform/chromium-win/platform/chromium/compositing/video-frame-size-change-expected.txt: Added.
- platform/chromium-win/platform/chromium/media/video-frame-size-change-expected.png: Added.
- platform/chromium-win/platform/chromium/media/video-frame-size-change-expected.txt: Added.
- platform/chromium/test_expectations.txt:
- 11:47 AM Changeset in webkit [113549] by
-
- 2 edits in trunk/LayoutTests
Added fast/canvas/webgl/array-message-passing.html to skipped tests on mac.
Tracked by https://bugs.webkit.org/show_bug.cgi?id=83427
- platform/mac/Skipped:
- 10:14 AM Changeset in webkit [113548] by
-
- 9 edits in trunk
[CMake] Cleanup WTF include directories
https://bugs.webkit.org/show_bug.cgi?id=82716
Reviewed by Eric Seidel.
Source/WebCore:
- CMakeLists.txt:
Source/WebKit:
- CMakeLists.txt:
Source/WebKit2:
- CMakeLists.txt:
Tools:
- DumpRenderTree/efl/CMakeLists.txt:
- WinCELauncher/CMakeLists.txt:
- 8:48 AM PrefixedAPIs edited by
- (diff)
- 8:48 AM PrefixedAPIs edited by
- (diff)
- 8:30 AM Changeset in webkit [113547] by
-
- 8 edits2 adds in trunk
[BlackBerry] Add Battery Status API support
https://bugs.webkit.org/show_bug.cgi?id=82615
Reviewed by George Staikos.
.:
Enable BATTERY_STATUS.
- Source/cmake/OptionsBlackBerry.cmake:
Source/WebKit:
Add BatteryClientBlackBerry.cpp to the build.
- PlatformBlackBerry.cmake:
Source/WebKit/blackberry:
Add client implementation for Battery API.
- Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::init): initialize BatteryClient.
- WebCoreSupport/BatteryClientBlackBerry.cpp: Added.
(WebCore):
(WebCore::BatteryClientBlackBerry::BatteryClientBlackBerry):
(WebCore::BatteryClientBlackBerry::setController):
(WebCore::BatteryClientBlackBerry::startUpdating):
(WebCore::BatteryClientBlackBerry::stopUpdating):
(WebCore::BatteryClientBlackBerry::batteryControllerDestroyed):
(WebCore::BatteryClientBlackBerry::onLevelChange):
(WebCore::BatteryClientBlackBerry::onChargingChange):
(WebCore::BatteryClientBlackBerry::onChargingTimeChange):
(WebCore::BatteryClientBlackBerry::onDischargingTimeChange):
- WebCoreSupport/BatteryClientBlackBerry.h: Added.
(WebCore):
(BatteryClientBlackBerry):
(WebCore::BatteryClientBlackBerry::~BatteryClientBlackBerry):
Tools:
Enable BATTERY_STATUS.
- Scripts/build-webkit:
- 7:31 AM Changeset in webkit [113546] by
-
- 3 edits3 adds in trunk
Remove dead code in SVGCSSParser
https://bugs.webkit.org/show_bug.cgi?id=83404
Reviewed by Nikolas Zimmermann.
Source/WebCore:
Remove code that was there to create a SVGColor representation for color, but was never reached. Since
SVGColor is deprecated now (also see bug 15012), this code has lost any potential. Should SVGColor come
back in SVG2 we can revisit this.
Add a test to confirm for SVG we follow the CSS3 handling of color="currentColor". This is something the
removed code never dealt with, but the existing code in CSSParser.cpp handles, make sure we stick to this
behaviour in the future using this test.
Test: svg/custom/currentColor-on-color.html
- css/SVGCSSParser.cpp:
(WebCore::CSSParser::parseSVGValue):
LayoutTests:
Test that we support color="currentColor" in SVG. This follows from the CSS3 spec, see
http://www.w3.org/TR/css3-color/#currentcolor. This matches FF behaviour.
- svg/custom/currentColor-on-color-expected.txt: Added.
- svg/custom/currentColor-on-color.html: Added.
- svg/custom/script-tests/currentColor-on-color.js: Added.
- 6:13 AM Changeset in webkit [113545] by
-
- 2 edits in trunk/LayoutTests
[Qt] Unreviewed Easter gardening, skip new failing tests to paint the bots green.
- platform/qt/Skipped:
- 1:21 AM Changeset in webkit [113544] by
-
- 4 edits in trunk/LayoutTests
2012-04-07 Nikolas Zimmermann <nzimmermann@rim.com>
Not reviewed. Rebaseline three results on Lion, so my baseline passes with tolerance 0 again.
- platform/mac/svg/W3C-SVG-1.1/animate-elem-30-t-expected.png: Images have wrong colorspace in those results.
- platform/mac/svg/W3C-SVG-1.1/animate-elem-36-t-expected.png: Ditto.
- platform/mac/svg/carto.net/selectionlist-expected.png: Ditto.
- 1:09 AM Changeset in webkit [113543] by
-
- 2 edits in trunk/Source/WebCore
2012-04-07 Nikolas Zimmermann <nzimmermann@rim.com>
FrameData constructor zeroes all fields, causing ImageOrientation to be 0
https://bugs.webkit.org/show_bug.cgi?id=83416
Inofficially rubber-stamped by Tim Horton.
Lots of svg/as-image/ crash on debug builds. FrameData is used in a Vector and currently
special VectorTraits force it to be initialized with memset(), nulling all members, instead
of properly initializing them causing the ImageOrientation bug. To be able to remove the
SimpleClassVectorTraits specialization, we have to allow FrameData to be copied.
- platform/graphics/BitmapImage.h:
- 12:38 AM Changeset in webkit [113542] by
-
- 19 edits in trunk
2012-04-07 Nikolas Zimmermann <nzimmermann@rim.com>
Work around an entity parsing bug in libxml2 2.7.3 (supplied with Lion) and unskip tests
https://bugs.webkit.org/show_bug.cgi?id=82577
Reviewed by Filip Pizlo.
Unskip several tests on Lion, now that the libxml2 bug doesn't affect us anymore.
- platform/mac-lion/Skipped:
- platform/mac/svg/W3C-SVG-1.1-SE/types-dom-01-b-expected.png:
- platform/mac/svg/W3C-SVG-1.1-SE/types-dom-01-b-expected.txt:
- platform/mac/svg/W3C-SVG-1.1/coords-viewattr-01-b-expected.png:
- platform/mac/svg/W3C-SVG-1.1/coords-viewattr-01-b-expected.txt:
- platform/mac/svg/W3C-SVG-1.1/coords-viewattr-02-b-expected.png:
- platform/mac/svg/W3C-SVG-1.1/coords-viewattr-02-b-expected.txt:
- platform/mac/svg/custom/preserve-aspect-ratio-syntax-expected.png:
- platform/mac/svg/custom/preserve-aspect-ratio-syntax-expected.txt:
- platform/mac/svg/custom/viewbox-syntax-expected.png:
- platform/mac/svg/custom/viewbox-syntax-expected.txt:
- platform/mac/svg/zoom/page/zoom-coords-viewattr-01-b-expected.png:
- platform/mac/svg/zoom/page/zoom-coords-viewattr-01-b-expected.txt:
- platform/mac/svg/zoom/text/zoom-coords-viewattr-01-b-expected.png:
- platform/mac/svg/zoom/text/zoom-coords-viewattr-01-b-expected.txt:
2012-04-07 Nikolas Zimmermann <nzimmermann@rim.com>
Work around an entity parsing bug in libxml2 2.7.3 (supplied with Lion) and unskip tests
https://bugs.webkit.org/show_bug.cgi?id=82577
Reviewed by Filip Pizlo.
Work-around entity expansion bug that affects several SVG tests on Lion.
Sample test document which is currently broken:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-W3CDTD SVG 1.1 BasicEN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-basic.dtd" [
<!ENTITY Smile "<rect x='.5' y='.5' width='29' height='39' fill='black' stroke='red'/>">
]>
<svg xmlns="http://www.w3.org/2000/svg">&Smile;</svg>
The expanded rect carries no namespace, thus an Element will be created for it, instead of a SVGRectElement.
libxml2 2.7.4 fixed this bug (https://bugzilla.gnome.org/show_bug.cgi?id=502960) in 2009 already, but Lion
still ships with 2.7.3, so we need to find a work-around for the problem. It works like this:
- When an entity is requested (getEntityHandler) determine whether the entity is being declared (while the <!ENTITY.. parses) or wheter its references (when the &Smile; is parsed). If its referenced, record the current depth of the libxml2 parser.
- When startElementNs is called while we're expanding entities, be sure to transfer the namespace of the parent node to the new node, but only do this if the current depth() is greater than the depth() at the time where entity expansion started. This way we only apply our workaround for elements inside entities, that get expanded at the insertion point.
- When endElementNs is called, and our current depth() is less than our equal to the depth() where entity expansion started, clear the recorded detph(), and stop executing the workaround.
It requires storing an extra integer & boolean in XMLDocumentParser, which is only used for this work-around.
- xml/parser/XMLDocumentParser.h: (XMLDocumentParser): (WebCore::XMLDocumentParser::isParsingEntityDeclaration): (WebCore::XMLDocumentParser::setIsParsingEntityDeclaration): (WebCore::XMLDocumentParser::depthTriggeringEntityExpansion): (WebCore::XMLDocumentParser::setDepthTriggeringEntityExpansion):
- xml/parser/XMLDocumentParserLibxml2.cpp: (WebCore::XMLDocumentParser::XMLDocumentParser): (WebCore::hackAroundLibXMLEntityParsingBug): (WebCore::XMLDocumentParser::startElementNs): (WebCore::XMLDocumentParser::endElementNs): (WebCore::entityDeclarationHandler): (WebCore::getEntityHandler): (WebCore::XMLDocumentParser::initializeParserContext):