date | project | content | link |
|---|
| 23:29 on Jan 25 | WebKit | Commit by kerz@chromium.org on chromium :: r105909 /963/LayoutTests/platform/ (830 files in 47 dirs): | # |
| 02:42 on Jan 25 | WebKit | Commit by kerz@chromium.org on chromium :: r105821 /963/LayoutTests/platform/chromium/test_expectations.txt: fix branch test expectations | # |
| 21:06 on Jan 19 | WebKit | Commit by kerz@chromium.org on chromium :: r105422 /963/LayoutTests/platform/chromium/test_expectations.txt: clean up branch expectations | # |
| 03:29 on Jan 18 | WebKit | Commit by kerz@chromium.org on chromium :: r105210 /963/ (5 files in 4 dirs): | # |
| 03:28 on Jan 18 | WebKit | Commit by kerz@chromium.org on chromium :: r105209 /963/Source/WebCore/ (2 files in 2 dirs): | # |
| 03:24 on Jan 18 | WebKit | Commit by kerz@chromium.org on chromium :: r105208 /963/ (6 files in 5 dirs): Merge 104140 - WebKit adds vertical paddings and borders to the fixed width of CSS tables
https://bugs.webkit.org/show_bug.cgi?id=74955
Patch by Max Vujovic <mvujovic at adobe dot com> on 2012-01-05
Reviewed by Julien Chaffraix.
Source/WebCore:
Test: fast/table/css-table-width.html
- rendering/RenderTable.cpp: (WebCore::RenderTable::computeLogicalWidth): Changed the width calculation for CSS tables to take into account horizontal paddings and borders instead of vertical paddings and borders. LayoutTests: Added tests to check that the fixed width style is applied correctly to CSS tables with respect to table paddings and borders.
- fast/table/css-table-width-expected.txt: Added.
- fast/table/css-table-width.html: Added.
- fast/table/script-tests/css-table-width.js: Added. (computeCSSTableOffsetWidth): (computeCSSTableOffsetHeight): (computeCSSTableProperty): TBR=commit-queue at webkit dot org Review URL: https://chromiumcodereview.appspot.com/9220007
| # |
| 02:32 on Jan 04 | WebKit | Commit by kerz@chromium.org on chromium :: r103976 /wpotest/: Branch at same point as M17 for WPO testing. | # |
| 01:26 on Dec 20, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r103269 /963/Source/WebCore/ (2 files in 2 dirs): Merge 102519 - WebPImageDecoder progressive decodes fail to decode valid images
https://bugs.webkit.org/show_bug.cgi?id=74062
Reviewed by Adam Barth.
The WEBP header is followed by a so-called P0 header, then some data to
decode. If a partial P0 header is received during progressive decodes,
WebPIDecGetRGB() returns false; that makes the decoder enter the failed
state, no image appears on the page.
James Zern (webp) recommended the following via e-mail:
WebPIUpdate() validates input data, and will return an error status for
malformed data (bit-stream error, invalid data). Otherwise, it returns
OK or SUSPENDED. OK means that decoding is done/complete/no-error, and
SUSPENDED means more input data is needed to complete decoding. A NULL
return from WebPIDecGetRGB() is valid at this time due to a partial P0,
and should not be interpreted as a decoding failure.
No new tests. Not something DumpRenderTree can easily test.
| # |
| 01:25 on Dec 20, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r103268 /963/Source/WebCore/ (2 files in 2 dirs): Merge 102310 - WebPImageDecoder should not do a full image decode if progressive decoding is active
https://bugs.webkit.org/show_bug.cgi?id=74041
Reviewed by Adam Barth.
If the decoder input data state reaches allDataReceived during a progressive image
decode, the decoder performs a full image decode.
On allDataReceived, check if we already have a decoder, and if so, continue to run
the progressive decoder.
No new tests. No change in behavior.
| # |
| 03:41 on Dec 08, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r102287 /963/codereview.settings: add codereview settings file | # |
| 03:38 on Dec 08, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r102286 /963/Source/WebCore/ (3 files in 2 dirs): Merge 102180 - [chromium] Don't crash if tile upload happens without painting first
https://bugs.webkit.org/show_bug.cgi?id=73939
Reviewed by James Robinson.
Remove at least one place (in ImageLayerChromium) where this could
happen.
Although this shouldn't happen, we should be robust to it in the
chance that other code causes it to.
- platform/graphics/chromium/ImageLayerChromium.cpp: (WebCore::ImageLayerChromium::paintContentsIfDirty):
- platform/graphics/chromium/TiledLayerChromium.cpp: (WebCore::TiledLayerChromium::updateCompositorResources): TBR=enne at google dot com
| # |
| 20:07 on Dec 06, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r102145 /963/: Branching webkit for Chromium | # |
| 18:41 on Oct 27, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r98586 /912/Source/WebCore/ (2 files in 2 dirs): Merge 98112 - Fix Windows build.
| # |
| 18:40 on Oct 27, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r98585 /912/ (5 files in 3 dirs): Merge 98060 - Hidden composited iframes cause infinite loop
https://bugs.webkit.org/show_bug.cgi?id=52655
Source/WebCore:
Reviewed by Darin Adler.
visibility:hidden is problematic for compositing, because it causes
RenderLayers to be removed from the z-order layer tree. This confuses
RenderLayerCompositor in several ways; it never sees these layers
when traversing the tree as it computes compositing requirements, or
rebuilds the layer tree.
This is a particular problem with composited iframes. When an iframe
becomes composited, scheduleSetNeedsStyleRecalc() is called on that
iframe's ownerElement in the parent document. If this happens inside
Document::updateStyleForAllDocuments(), we get into an infinite loop
because notifyIFramesOfCompositingChange() queues up style update as we
bounce in and out of compositing mode, so documentsThatNeedStyleRecalc
never empties out.
This is an initial, conservative fix that doesn't attempt to fix all
the issues with visibility. It changes RenderLayerCompositor to count
the number of compositing RenderLayers, and to not leave compositing
mode if there are any (even if they are hidden, so not hit while
traversing the z-order tree). This avoids the infinite loop.
Test: compositing/visibility/hidden-iframe.html
- rendering/RenderLayer.cpp: (WebCore::RenderLayer::ensureBacking): (WebCore::RenderLayer::clearBacking):
- rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::RenderLayerCompositor): (WebCore::RenderLayerCompositor::hasAnyAdditionalCompositedLayers): (WebCore::RenderLayerCompositor::updateCompositingLayers): (WebCore::RenderLayerCompositor::computeCompositingRequirements):
- rendering/RenderLayerCompositor.h: (WebCore::RenderLayerCompositor::layerBecameComposited): (WebCore::RenderLayerCompositor::layerBecameNonComposited): LayoutTests: Reviewed by Darin Adler. Test with a visibility:hidden iframe, whose subframe becomes composited.
- compositing/visibility/hidden-iframe-expected.txt: Added.
- compositing/visibility/hidden-iframe.html: Added. TBR=simon dot fraser at apple dot com Review URL: http://codereview.chromium.org/8399041
| # |
| 22:13 on Oct 21, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r98127 /912/Source/WebCore/html/HTMLKeygenElement.cpp: Hand merge of patch for bug 70617 from Gaurav Shah | # |
| 20:31 on Aug 23, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r93619 /835/Source/WebCore/ (ChangeLog WebCore.gyp/WebCore.gyp): Merge 92159 - Shard webcore_remaining for msvs official builds
https://bugs.webkit.org/show_bug.cgi?id=65475
Patch by Bradley Nelson <bradnelson at chromium dot org> on 2011-08-01
Reviewed by Darin Fisher.
webcore_remaining has consistently exceeded Visual Studio 2008's
capacity to link when link time code generation is turned on (full
release builds). This has been dealt with the past by carving off
larger and larger pieces of webcore_remaining (ie webcore_html,
webcore_renderer etc).
A new option has been added to gyp to automate this sharding:
'msvs_shard': SHARD_COUNT,
Targets marked in this way will be built in several pieces
(target_0, target_1...).
Since the resulting project is less comprehensible in the IDE (and
since the linking limitation only afflicts official builds), this
option is only needed for those builds.
This patch shards webcore_remaining into 10 parts for official builds.
| # |
| 02:51 on Aug 23, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r93569 /835/ (5 files in 4 dirs): Merge 92298 - Crash in DocumentWriter::endIfNotLoadingMainResource
https://bugs.webkit.org/show_bug.cgi?id=65581
Reviewed by Nate Chapin.
Source/WebCore:
This function is poorly designed because isLoadingMainResource is a
poor proxy for determing whether to flush/finish the parser. Really,
we should change how loads complete to match the model in HTML5, but
that's pretty tricky. In the meantime, this null check fixes the
crash.
I'm sure there's another bug on file about this crash, but we've never
been able to reproduce it. Thanks to Berend-Jan Wever for the test
case!
Test: fast/loader/reload-zero-byte-plugin.html
| # |
| 20:18 on Aug 22, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r93525 /835/Source/WebCore/ (4 files in 3 dirs): Merge 93042 - Web Inspector: [V8] crash upon stepIn while not on pause.
https://bugs.webkit.org/show_bug.cgi?id=66221
Reviewed by Yury Semikhatsky.
- inspector/InspectorDebuggerAgent.cpp: (WebCore::InspectorDebuggerAgent::resume): (WebCore::InspectorDebuggerAgent::stepOver): (WebCore::InspectorDebuggerAgent::stepInto): (WebCore::InspectorDebuggerAgent::stepOut): (WebCore::InspectorDebuggerAgent::assertPaused):
- inspector/InspectorDebuggerAgent.h:
- inspector/front-end/ScriptsPanel.js: (WebInspector.ScriptsPanel.prototype._stepOverClicked): (WebInspector.ScriptsPanel.prototype._stepIntoClicked): (WebInspector.ScriptsPanel.prototype._stepOutClicked): TBR=pfeldman at chromium dot org Review URL: http://codereview.chromium.org/7708013
| # |
| 20:16 on Aug 22, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r93524 /835/ (4 files in 4 dirs): Merge 92764 - Web Inspector: [REGRESSION] Editor lost after committing a CSS property value for inline style
https://bugs.webkit.org/show_bug.cgi?id=65918
Reviewed by Pavel Feldman.
Source/WebCore:
- inspector/front-end/StylesSidebarPane.js: (WebInspector.StylesSidebarPane.prototype._innerUpdate.stylesCallback): (WebInspector.StylesSidebarPane.prototype._innerUpdate.computedStyleCallback): (WebInspector.StylesSidebarPane.prototype._innerUpdate): (WebInspector.StylePropertyTreeElement.prototype): (WebInspector.StylePropertyTreeElement.prototype.event): (WebInspector.StylePropertyTreeElement.prototype.styleText.updateInterface.majorChange.isRevert.parentPane): (WebInspector.StylePropertyTreeElement.prototype.styleText.updateInterface.majorChange.isRevert): LayoutTests:
- inspector/styles/styles-commit-editing.html: TBR=apavlov at chromium dot org Review URL: http://codereview.chromium.org/7708012
| # |
| 03:20 on Aug 10, 2011 | WebKit | Commit by kerz@chromium.org on chromium :: r92740 /835/Source/WebCore/ (2 files in 2 dirs): | # |
RSS 2.0 Feed