[webkit-changes] [WebKit/WebKit] 63f468: Branch WebKitGTK+ for 2.8
Carlos Garcia Campos
noreply at github.com
Thu Dec 1 13:45:22 PST 2022
Branch: refs/heads/webkitgtk/2.8
Home: https://github.com/WebKit/WebKit
Commit: 63f468f08bca04be548990ed90efee180b4d6094
https://github.com/WebKit/WebKit/commit/63f468f08bca04be548990ed90efee180b4d6094
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-02-17 (Tue, 17 Feb 2015)
Changed paths:
Log Message:
-----------
Branch WebKitGTK+ for 2.8
Commit: 9ee0cd2b5527c83f99361b5dd9584c805b0e9fad
https://github.com/WebKit/WebKit/commit/9ee0cd2b5527c83f99361b5dd9584c805b0e9fad
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-02-17 (Tue, 17 Feb 2015)
Changed paths:
M Tools/ChangeLog
M Tools/gtk/manifest.txt.in
Log Message:
-----------
Merge r180221 - Unreviewed. Fix GTK+ make distcheck.
Do not exclude bmalloc directory from the tarball.
* gtk/manifest.txt.in:
Commit: 5a6365e7dff73bd03ef75e36a97878952d829f30
https://github.com/WebKit/WebKit/commit/5a6365e7dff73bd03ef75e36a97878952d829f30
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-02-17 (Tue, 17 Feb 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.7.90 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.7.90.
Commit: ba9cd3bdd856006861e8fd16398711bd3c98378d
https://github.com/WebKit/WebKit/commit/ba9cd3bdd856006861e8fd16398711bd3c98378d
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/heap/MachineStackMarker.cpp
M Tools/ChangeLog
M Tools/asan/webkit-asan-ignore.txt
Log Message:
-----------
Merge r180649 - ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
<https://webkit.org/b/141672>
Reviewed by Alexey Proskuryakov.
ASan does not like the fact that we memcpy the stack for GC scans. So,
we're working around this by using our own memcpy (asanUnsafeMemcpy)
implementation that we can tell ASan to ignore.
Source/JavaScriptCore:
* heap/MachineStackMarker.cpp:
(JSC::asanUnsafeMemcpy):
Tools:
Also removed the previous added directive to ignore *tryCopyOtherThreadStack*
which isn't effective for working around this issue.
* asan/webkit-asan-ignore.txt:
Commit: 0abd929a67601f76976003ed768ea9b69f5c4f62
https://github.com/WebKit/WebKit/commit/0abd929a67601f76976003ed768ea9b69f5c4f62
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/CCallHelpers.h
Log Message:
-----------
Merge r180232 - [ARM] Add the necessary setupArgumentsWithExecState after bug141332
https://bugs.webkit.org/show_bug.cgi?id=141714
Reviewed by Michael Saboff.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
Commit: f1035eced338aefb4c879bae1a85a7af087f1e55
https://github.com/WebKit/WebKit/commit/f1035eced338aefb4c879bae1a85a7af087f1e55
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/JITOpcodes.cpp
M Source/JavaScriptCore/llint/LowLevelInterpreter.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
A Source/JavaScriptCore/tests/stress/throw-from-ftl-call-ic-slow-path-cells.js
A Source/JavaScriptCore/tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js
A Source/JavaScriptCore/tests/stress/throw-from-ftl-call-ic-slow-path.js
Log Message:
-----------
Merge r180234 - Throwing from an FTL call IC slow path may result in tag registers being clobbered on 64-bit CPUs
https://bugs.webkit.org/show_bug.cgi?id=141717
rdar://problem/19863382
Reviewed by Geoffrey Garen.
The best solution is to ensure that the engine catching an exception restores tag registers.
Each of these new test cases reliably crashed prior to this patch and they don't crash at all now.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: Added.
* tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: Added.
* tests/stress/throw-from-ftl-call-ic-slow-path.js: Added.
Commit: 999978e4998b5726fb8b23275b2958b794815254
https://github.com/WebKit/WebKit/commit/999978e4998b5726fb8b23275b2958b794815254
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGGraph.h
M Source/JavaScriptCore/dfg/DFGStackLayoutPhase.cpp
Log Message:
-----------
Merge r180237 - StackLayoutPhase should use CodeBlock::usesArguments rather than FunctionExecutable::usesArguments
https://bugs.webkit.org/show_bug.cgi?id=141721
rdar://problem/17198633
Reviewed by Michael Saboff.
I've seen cases where the two are out of sync. We know we can trust the CodeBlock::usesArguments because
we use it everywhere else.
No test because I could never reproduce the crash.
* dfg/DFGGraph.h:
(JSC::DFG::Graph::usesArguments):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
Commit: fdeacdfc8669e266503950b42d7ee1d9a002ec7f
https://github.com/WebKit/WebKit/commit/fdeacdfc8669e266503950b42d7ee1d9a002ec7f
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/history/CachedPage.cpp
M Source/WebCore/history/CachedPage.h
Log Message:
-----------
Merge r180244 - Slight CachedPage class clean up
https://bugs.webkit.org/show_bug.cgi?id=141693
Reviewed by Andreas Kling.
Slight CachedPage class clean up:
- Drop unnecessary m_timeStamp data member
- Protect m_needsCaptionPreferencesChanged data member with
#if ENABLE(VIDEO_TRACK)
- Merge destroy() method into the destructor as this is the
only caller
- Update clear() to reset 2 data members that were missing
Commit: efdaec7246b7ee8075e86e767db6e85f6c3964c4
https://github.com/WebKit/WebKit/commit/efdaec7246b7ee8075e86e767db6e85f6c3964c4
Author: Commit Queue <commit-queue at webkit.org>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
Log Message:
-----------
Merge r180248 - Unreviewed, rolling out r180184.
https://bugs.webkit.org/show_bug.cgi?id=141733
Caused infinite recursion on js/function-apply-aliased.html
(Requested by ap_ on #webkit).
Reverted changeset:
"REGRESSION(r180060): C Loop crashes"
https://bugs.webkit.org/show_bug.cgi?id=141671
http://trac.webkit.org/changeset/180184
Unreviewed, Restoring the C LOOP insta-crash fix in r180184.
Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
* llint/LowLevelInterpreter.asm: Fixed a typo.
Commit: ba94a96533cb301b6f1cbc01c8dbea02de0464b9
https://github.com/WebKit/WebKit/commit/ba94a96533cb301b6f1cbc01c8dbea02de0464b9
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/dfg/DFGOSRExit.h
M Source/JavaScriptCore/dfg/DFGOSRExitBase.cpp
M Source/JavaScriptCore/dfg/DFGOSRExitBase.h
M Source/JavaScriptCore/ftl/FTLOSRExit.h
Log Message:
-----------
Merge r180257 - Clean up OSRExit's considerAddingAsFrequentExitSite()
https://bugs.webkit.org/show_bug.cgi?id=141690
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-02-17
Reviewed by Anders Carlsson.
Looks like some code was removed from CodeBlock::tallyFrequentExitSites()
and the OSRExit were left untouched.
This patch cleans up the two loops and remove the boolean return
on considerAddingAsFrequentExitSite().
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::tallyFrequentExitSites):
* dfg/DFGOSRExit.h:
(JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
* dfg/DFGOSRExitBase.cpp:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
* ftl/FTLOSRExit.h:
(JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
Commit: 56be359c1295036ca8a4157dbdd5468b87bf9553
https://github.com/WebKit/WebKit/commit/56be359c1295036ca8a4157dbdd5468b87bf9553
Author: Benjamin Poulain <benjamin at webkit.org>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/CMakeLists.txt
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCore.vcxproj
M Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/jit/JITOperations.cpp
M Source/JavaScriptCore/jit/JITOperations.h
A Source/JavaScriptCore/runtime/MathCommon.cpp
A Source/JavaScriptCore/runtime/MathCommon.h
M Source/JavaScriptCore/runtime/MathObject.cpp
Log Message:
-----------
Merge r180258 - Fix the C-Loop LLInt build
https://bugs.webkit.org/show_bug.cgi?id=141618
Reviewed by Filip Pizlo.
I broke C-Loop when moving the common code of pow()
to JITOperations because that file is #ifdefed out
when the JITs are disabled.
It would be weird to move it back to MathObject since
the function needs to know about the calling conventions.
To avoid making a mess, I just gave the function its own file
that is used by both the runtime and the JIT.
* CMakeLists.txt:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/MathCommon.cpp: Added.
(JSC::fdlibmScalbn):
(JSC::fdlibmPow):
(JSC::isDenormal):
(JSC::isEdgeCase):
(JSC::mathPowInternal):
(JSC::operationMathPow):
* runtime/MathCommon.h: Added.
* runtime/MathObject.cpp:
Commit: a78c1192905bb7248460a5be2751705002bc3d5e
https://github.com/WebKit/WebKit/commit/a78c1192905bb7248460a5be2751705002bc3d5e
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/bmalloc/CMakeLists.txt
M Source/bmalloc/ChangeLog
Log Message:
-----------
Merge r180264 - Build bmalloc through CMake as a static library. It's then linked either
into the WTF library (if built as a shared library) or into the JSC and
WebKit2 libraries. There's no need to build it as a standalone shared library.
Rubber-stamped by Carlos Garcia Campos.
* CMakeLists.txt:
Commit: f24400b5a22c855f003d6ce882ea91184453d802
https://github.com/WebKit/WebKit/commit/f24400b5a22c855f003d6ce882ea91184453d802
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc.xcodeproj/project.pbxproj
A Source/bmalloc/bmalloc/SuperChunk.h
M Source/bmalloc/bmalloc/VMHeap.cpp
M Source/bmalloc/bmalloc/VMHeap.h
Log Message:
-----------
Merge r180272 - bmalloc: VMHeap should keep a record of all of its VM ranges (for malloc introspection)
https://bugs.webkit.org/show_bug.cgi?id=141759
Reviewed by Andreas Kling.
* bmalloc.xcodeproj/project.pbxproj:
* bmalloc/SuperChunk.h: Added.
(bmalloc::SuperChunk::create):
(bmalloc::SuperChunk::SuperChunk):
(bmalloc::SuperChunk::smallChunk):
(bmalloc::SuperChunk::mediumChunk):
(bmalloc::SuperChunk::largeChunk): Factored out super chunk creation
into a separate class, for clarity and type safety.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
(bmalloc::VMHeap::allocateSuperChunk): Renamed "allocateSuperChunk" to
"grow" because Andreas found "allocateSuperChunk" to be unclear.
* bmalloc/VMHeap.h: Track all our VM ranges. We will use this information
for malloc introspection.
(bmalloc::VMHeap::allocateSmallPage):
(bmalloc::VMHeap::allocateMediumPage):
(bmalloc::VMHeap::allocateLargeRange): Updated for renames.
Commit: ad9b946c9eae69a146693edeb3e5118885fc2ed1
https://github.com/WebKit/WebKit/commit/ad9b946c9eae69a146693edeb3e5118885fc2ed1
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/ruby-justification-flush-expected.html
A LayoutTests/fast/text/ruby-justification-flush.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBlockFlow.h
M Source/WebCore/rendering/RenderBlockLineLayout.cpp
Log Message:
-----------
Merge r180278 - Justified ruby can cause lines to grow beyond their container
https://bugs.webkit.org/show_bug.cgi?id=141732
Reviewed by David Hyatt.
Source/WebCore:
After we re-layout RenderRubyRuns, this can change the environment upon which
ruby's overhang calculation is sensitive to. Before this patch, we would recalculate
the overhang after the RenderRubyRun gets relaid out. However, doing such causes the
effective width of the RenderRubyRun to change, which causes out subsequent
justification calculations to be off.
Therefore, we have a cycle; the amount of ruby overhang can change the justification
in a line, and the layout of the line affects the ruby overhang calculation. Instead
of performing a layout in a loop until it converges, this patch simply observes that
having a flush right edge is more valuable than having a perfectly correct overhang.
It therefore simply removes the secondary overhang calculation.
Test: fast/text/ruby-justification-flush.html
* rendering/RenderBlockFlow.h:
* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlockFlow::updateRubyForJustifiedText):
(WebCore::RenderBlockFlow::computeExpansionForJustifiedText):
(WebCore::RenderBlockFlow::computeInlineDirectionPositionsForSegment):
LayoutTests:
Make sure that the right edge of a justified ruby line matches up with
the same line without ruby.
* fast/text/ruby-justification-flush-expected.html: Added.
* fast/text/ruby-justification-flush.html: Added.
Commit: 5e0c2bdca0f9f5e26208850691779f7f0cb5641b
https://github.com/WebKit/WebKit/commit/5e0c2bdca0f9f5e26208850691779f7f0cb5641b
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/indexeddb/IDBDatabase.cpp
Log Message:
-----------
Merge r180280 - Crashes under IDBDatabase::closeConnection.
https://bugs.webkit.org/show_bug.cgi?id=141745
rdar://problem/19816412
Reviewed by David Kilzer.
* Modules/indexeddb/IDBDatabase.cpp: (WebCore::IDBDatabase::closeConnection):
Add a missing protector.
Commit: 70b60f297d0c1f55df4af1c7461c5be02d4b01a1
https://github.com/WebKit/WebKit/commit/70b60f297d0c1f55df4af1c7461c5be02d4b01a1
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/multicol/crash-when-spanner-gets-moved-around-expected.txt
A LayoutTests/fast/multicol/crash-when-spanner-gets-moved-around.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderMultiColumnFlowThread.cpp
M Source/WebCore/rendering/RenderMultiColumnFlowThread.h
Log Message:
-----------
Merge r180328 - REGRESSION(r174761) Dangling spanner pointer in RenderMultiColumnSpannerPlaceholder.
https://bugs.webkit.org/show_bug.cgi?id=138224
Reviewed by Dave Hyatt.
It's wrong to call flowThreadRelativeWillBeRemoved(child).
RenderMultiColumnFlowThread::removeFlowChildInfo() does not mean that the child is actually about to be removed.
Should this introduce any regressions, we need to deal with those separately.
Source/WebCore:
Test: fast/multicol/crash-when-spanner-gets-moved-around.html
* rendering/RenderMultiColumnFlowThread.cpp:
(WebCore::RenderMultiColumnFlowThread::removeFlowChildInfo): Deleted.
* rendering/RenderMultiColumnFlowThread.h:
LayoutTests:
* fast/multicol/crash-when-spanner-gets-moved-around-expected.txt: Added.
* fast/multicol/crash-when-spanner-gets-moved-around.html: Added.
Commit: 05d4b00bf92d4594a089379b164ed41cfdcf4444
https://github.com/WebKit/WebKit/commit/05d4b00bf92d4594a089379b164ed41cfdcf4444
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/indexeddb/IDBDatabase.cpp
Log Message:
-----------
Merge r180336 - Roll out r180280.
Crashes under IDBDatabase::closeConnection.
https://bugs.webkit.org/show_bug.cgi?id=141745
rdar://problem/19816412
* Modules/indexeddb/IDBDatabase.cpp: (WebCore::IDBDatabase::closeConnection):
Commit: 5eb5cef449c58218051c4c42c89ca468dd1d5693
https://github.com/WebKit/WebKit/commit/5eb5cef449c58218051c4c42c89ca468dd1d5693
Author: Andreas Kling <akling at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/history/page-cache-clearing-expected.txt
A LayoutTests/fast/history/page-cache-clearing.html
M Source/WebCore/ChangeLog
M Source/WebCore/history/PageCache.cpp
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
Log Message:
-----------
Merge r180337 - REGRESSION(r179347): Clearing the PageCache no longer clears the PageCache.
<https://webkit.org/b/141788>
Reviewed by Anders Carlsson.
Source/WebCore:
Once again we've fallen into the TemporaryChange trap:
TemporaryChange<unsigned>(m_member, temporaryValue);
The code above doesn't actually do anything. Since the TemporaryChange local is not named,
it immediately goes out of scope and restores the original value of m_member.
Unless someone knows a C++ trick to prevent these, we'll need to add a style checker pass
to catch bugs like this. Whatever we do will be done separately from this bug.
Test: fast/history/page-cache-clearing.html
* history/PageCache.cpp:
(WebCore::PageCache::pruneToSizeNow): Name the local so it lives longer.
* testing/Internals.cpp:
(WebCore::Internals::clearPageCache):
(WebCore::Internals::pageCacheSize):
* testing/Internals.h:
* testing/Internals.idl: Add a way to clear the page cache and query its size from
window.internals to facilitate writing a simple test for this bug.
LayoutTests:
Add a simple test that navigates to a temporary page which immediately does a history.back
navigation. Upon returning to the first page, check that the page cache now has 1 entry,
and that clearing the page cache makes that entry go away.
* fast/history/page-cache-clearing-expected.txt: Added.
* fast/history/page-cache-clearing.html: Added.
Commit: 650a2d08af1e2631d422c0f7d0f13c76c5ba5289
https://github.com/WebKit/WebKit/commit/650a2d08af1e2631d422c0f7d0f13c76c5ba5289
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc.xcodeproj/project.pbxproj
M Source/bmalloc/bmalloc/Algorithm.h
M Source/bmalloc/bmalloc/VMHeap.cpp
M Source/bmalloc/bmalloc/VMHeap.h
A Source/bmalloc/bmalloc/Zone.cpp
A Source/bmalloc/bmalloc/Zone.h
Log Message:
-----------
Merge r180359 - bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
https://bugs.webkit.org/show_bug.cgi?id=141802
Reviewed by Andreas Kling.
This patch does the bare minimum to stop false positive leaks from
being reported by the Darwin leaks tool. We register each super chunk
as a single object, and then request that the leaks tool scan it.
* bmalloc.xcodeproj/project.pbxproj: Added an abstraction for the malloc
zone introspection API.
* bmalloc/Algorithm.h: Missing #include.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
* bmalloc/VMHeap.h: Adopt the new abstraction.
* bmalloc/Zone.cpp: Added.
(bmalloc::remoteRead): Helper for reading an object out of another process.
(bmalloc::Zone::enumerator):
(bmalloc::Zone::Zone): Register a malloc zone so that we will participate
in introspection.
* bmalloc/Zone.h: Added.
(bmalloc::Zone::superChunks):
(bmalloc::Zone::addSuperChunk): Use a non-dynamically-allocated vector
since our dynamic allocations will not be scanned by leaks since they
will have the malloc VM tag.
Commit: 7380486045abe9e2bde8fc517667609b95378174
https://github.com/WebKit/WebKit/commit/7380486045abe9e2bde8fc517667609b95378174
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/VMHeap.cpp
M Source/bmalloc/bmalloc/VMHeap.h
Log Message:
-----------
Merge r180363 - bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
https://bugs.webkit.org/show_bug.cgi?id=141802
Reviewed by Andreas Kling.
Fixed a last-minute type.
The macro is OS, not PLATFORM.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
* bmalloc/VMHeap.h:
* bmalloc/Zone.h:
Commit: 7576502f41d2cbc8e4bf26363fe69c670662da1f
https://github.com/WebKit/WebKit/commit/7576502f41d2cbc8e4bf26363fe69c670662da1f
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Zone.cpp
M Source/bmalloc/bmalloc/Zone.h
Log Message:
-----------
Merge r180430 - bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
https://bugs.webkit.org/show_bug.cgi?id=141802
Reviewed by Andreas Kling.
Rolling back in with a fix for a crash seen while using GuardMalloc.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
* bmalloc/VMHeap.h:
* bmalloc/Zone.cpp: Re-land the old patch.
(bmalloc::Zone::size): Be sure to implement the size() function since
it's accessible indirectly via the malloc_zone_from_ptr public API --
and GuardMalloc calls it all the time.
(bmalloc::Zone::Zone):
* bmalloc/Zone.h: Re-land the old patch.
Commit: 1cef7eb07b38b1b15596de71011eb17b34d8c0b4
https://github.com/WebKit/WebKit/commit/1cef7eb07b38b1b15596de71011eb17b34d8c0b4
Author: Dhi Aurrahman <diorahman at rockybars.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/fast/css/css-selector-text-expected.txt
M LayoutTests/fast/css/css-selector-text.html
M LayoutTests/fast/css/parsing-css-lang-expected.txt
M LayoutTests/fast/css/parsing-css-lang.html
M LayoutTests/fast/selectors/lang-extended-filtering-expected.txt
M LayoutTests/fast/selectors/lang-extended-filtering.html
M LayoutTests/fast/selectors/lang-valid-extended-filtering-expected.txt
M LayoutTests/fast/selectors/lang-valid-extended-filtering.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSGrammar.y.in
M Source/WebCore/css/CSSParser.cpp
Log Message:
-----------
Merge r180413 - Language ranges containing asterisks must be quoted as strings
https://bugs.webkit.org/show_bug.cgi?id=141659
Reviewed by Benjamin Poulain.
Source/WebCore:
As specified in [1], the language ranges containing asterisks must be quoted as strings.
[1] http://dev.w3.org/csswg/selectors-4/#the-lang-pseudo.
* css/CSSGrammar.y.in:
* css/CSSParser.cpp:
(WebCore::CSSParser::realLex):
LayoutTests:
Ensure language ranges containing asterisks are quoted as strings.
* fast/css/css-selector-text-expected.txt:
* fast/css/css-selector-text.html:
* fast/css/parsing-css-lang-expected.txt:
* fast/css/parsing-css-lang.html:
* fast/selectors/lang-extended-filtering-expected.txt:
* fast/selectors/lang-extended-filtering.html:
* fast/selectors/lang-valid-extended-filtering-expected.txt:
* fast/selectors/lang-valid-extended-filtering.html:
Commit: b5e1b67262ba9859221bf45e2079b46c41879683
https://github.com/WebKit/WebKit/commit/b5e1b67262ba9859221bf45e2079b46c41879683
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/js/regress-141098-expected.txt
M LayoutTests/js/script-tests/regress-141098.js
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/EvalCodeCache.h
M Source/JavaScriptCore/dfg/DFGJITCompiler.cpp
M Source/JavaScriptCore/runtime/Options.h
M Tools/ChangeLog
M Tools/Scripts/run-jsc-stress-tests
Log Message:
-----------
Merge r180423 - DFG JIT needs to check for stack overflow at the start of Program and Eval execution
https://bugs.webkit.org/show_bug.cgi?id=141676
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes.
To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const
a options in runtime/Options.h. The test script, run-jsc-stress-tests, sets that option
to a huge value when running with the "Eager" options. This allows the updated test to
reliably exercise the code in questions.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
Added stack check.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::getSlow):
* runtime/Options.h:
Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength
so that it can be configured when running the related test.
Tools:
Set the newly added --maximumEvalCacheableSourceLength option for eager test runs. This is needed
to allow the eval out of stack tests to tier up. Without this option, we don't cache the likely
large string expression that we want to eval.
* Scripts/run-jsc-stress-tests:
LayoutTests:
Updated the check for out of stack at eval entry test from using a fixed number of frame to
back track to now adjust the amount of back tracking up the stack based on where we can run a
simple eval(). At that point in the stack we try to cause an out of stack exception.
Also added a second pass of the test that takes the originally failing eval and tiers that
eval expression up to the DFG when used with the agreessive options of run-jsc-stress-tests.
This was done to reduce the amount of time the test takes to run in debug builds.
* js/regress-141098-expected.txt:
* js/script-tests/regress-141098.js:
(testEval):
(probeAndRecurse):
Commit: 8870181d8a906eb4b5bcf0faf7ecadebc7cd8fa7
https://github.com/WebKit/WebKit/commit/8870181d8a906eb4b5bcf0faf7ecadebc7cd8fa7
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/RunLoop.cpp
Log Message:
-----------
Merge r180434 - RunLoop::dispatch() should drop the mutex before calling wakeUp().
https://bugs.webkit.org/show_bug.cgi?id=141820
Reviewed by Alexey Proskuryakov.
RunLoop::wakeUp() calls into CoreFoundation which could take time,
so scope the mutex just to protect m_functionQueue.
* wtf/RunLoop.cpp:
(WTF::RunLoop::dispatch):
Commit: 941d0f9859363ada7e48bc74de9c727aa8ce40ce
https://github.com/WebKit/WebKit/commit/941d0f9859363ada7e48bc74de9c727aa8ce40ce
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/editing/inserting/insert-as-body-sibling-expected.txt
A LayoutTests/editing/inserting/insert-as-body-sibling.html
M Source/WebCore/ChangeLog
M Source/WebCore/editing/CompositeEditCommand.cpp
Log Message:
-----------
Merge r180464 - Invalid assert in CompositeEditCommand::insertNodeAfter/insertNodeBefore
https://bugs.webkit.org/show_bug.cgi?id=141854
Reviewed by Ryosuke Niwa.
Inserting content before/after the body as the result of editing is a valid operation.
This assert was originally introduced to cover cases where edited content would get moved
out of body. However, asserting such operation properly is not possible atm.
Source/WebCore:
Test: editing/inserting/insert-as-body-sibling.html
* editing/CompositeEditCommand.cpp:
(WebCore::CompositeEditCommand::insertNodeBefore):
(WebCore::CompositeEditCommand::insertNodeAfter):
LayoutTests:
* editing/inserting/insert-as-body-sibling-expected.txt: Added.
* editing/inserting/insert-as-body-sibling.html: Added.
Commit: 00b379f42f8c829554e8f5beab46437761555c86
https://github.com/WebKit/WebKit/commit/00b379f42f8c829554e8f5beab46437761555c86
Author: Dean Jackson <dino at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/fast/canvas/canvas-toDataURL-crash-expected.txt
M LayoutTests/fast/canvas/pattern-too-large-to-create-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLCanvasElement.cpp
Log Message:
-----------
Merge r180492 - Print a console warning when HTMLCanvasElement exceeds the maximum size
https://bugs.webkit.org/show_bug.cgi?id=141861
<rdar://problem/19729145>
Reviewed by Simon Fraser.
Source/WebCore:
Add a warning if we ever try to create a canvas that is
too big.
No test because:
1. We can't ref-test against console messages.
2. The output is platform specific.
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::createImageBuffer):
LayoutTests:
Add error message to expected results.
* fast/canvas/canvas-toDataURL-crash-expected.txt:
* fast/canvas/pattern-too-large-to-create-expected.txt:
Commit: c0235b35935e285be4f32f2c40e1a8ed16e40b56
https://github.com/WebKit/WebKit/commit/c0235b35935e285be4f32f2c40e1a8ed16e40b56
Author: Tomáš Popela <tpopela at redhat.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M ChangeLog
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r180502 - [GTK] Fails to compile with cmake 3.2.x
https://bugs.webkit.org/show_bug.cgi?id=141796
With cmake 3.2.x we have to explicitly ask for X11 otherwise the
X11_X11_LIB variable won't be set thus the X11 linker flags won't be
added and the build will fail.
Patch by Tomas Popela <tpopela at redhat.com> on 2015-02-23
Reviewed by Martin Robinson.
* Source/cmake/OptionsGTK.cmake:
Commit: 66c2a758915a3c7c77b45231ed291eaf5b07fae9
https://github.com/WebKit/WebKit/commit/66c2a758915a3c7c77b45231ed291eaf5b07fae9
Author: Philippe Normand <pnormand at igalia.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp
Log Message:
-----------
Merge r180503 - [GStreamer] Redundant track language notifications
https://bugs.webkit.org/show_bug.cgi?id=141908
Reviewed by Žan Doberšek.
Invoke languageChanged only if the language code actually
changed.
* platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp:
(WebCore::TrackPrivateBaseGStreamer::notifyTrackOfTagsChanged):
Commit: 387ab708dfc0dc0c7e1e9f3075a0b19f203b8362
https://github.com/WebKit/WebKit/commit/387ab708dfc0dc0c7e1e9f3075a0b19f203b8362
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
A Source/JavaScriptCore/tests/stress/regress-141883.js
Log Message:
-----------
Merge r180505 - Crash in DFGFrozenValue
https://bugs.webkit.org/show_bug.cgi?id=141883
Reviewed by Benjamin Poulain.
If a value might be a cell, then we have to have Graph freeze it rather than trying to
create the FrozenValue directly. Creating it directly is just an optimization for when you
know for sure that it cannot be a cell.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* tests/stress/regress-141883.js: Added. Hacked the original test to be faster while still crashing before this fix.
Commit: c956d4370026c20a69dd86e5c650e971a5a425e2
https://github.com/WebKit/WebKit/commit/c956d4370026c20a69dd86e5c650e971a5a425e2
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/canvas/canvas-global-alpha-svg-expected.html
A LayoutTests/svg/canvas/canvas-global-alpha-svg.html
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/GraphicsContext.cpp
M Source/WebCore/platform/graphics/GraphicsContext.h
M Source/WebCore/platform/graphics/cairo/GraphicsContextCairo.cpp
M Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp
M Source/WebCore/svg/graphics/SVGImage.cpp
Log Message:
-----------
Merge r180511 - Drawing an SVG image into a canvas using drawImage() ignores globalAlpha.
https://bugs.webkit.org/show_bug.cgi?id=141729.
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-02-23
Reviewed by Simon Fraser.
Source/WebCore:
When drawing an SVG image and the drawing context is set to be transparent,
make sure this transparency is applied to the compositing layer.
Test: svg/canvas/canvas-global-alpha-svg.html
* platform/graphics/GraphicsContext.cpp:
(WebCore::GraphicsContext::setAlpha): Make setAlpha() calls the platform
function and sets 'm_state.alpha' to the input value.
(WebCore::GraphicsContext::alpha): Add a new function 'alpha()' which
returns the value of the global alpha.
* platform/graphics/GraphicsContext.h:
(WebCore::GraphicsContextState::GraphicsContextState): Add a new member
'alpha' to the context state since the getter function CGContextGetAlpha
is defined only in a private header file. Also move single line functions
from the source file to the header file.
* platform/graphics/cairo/GraphicsContextCairo.cpp:
(WebCore::GraphicsContext::setPlatformAlpha):
(WebCore::GraphicsContext::setAlpha): Deleted.
* platform/graphics/cg/GraphicsContextCG.cpp:
(WebCore::GraphicsContext::setPlatformAlpha):
(WebCore::GraphicsContext::setAlpha): Deleted.
Rename setAlpha() to setPlatformAlpha() in the platform files. Add setAlpha()
to the core file. setAlpha() will set the value of 'm_state.alpha' and call
setPlatformAlpha().
* svg/graphics/SVGImage.cpp:
(WebCore::SVGImage::draw): If the drawing context is transparent, apply its
global alpha value to the compositing layer.
LayoutTests:
Add a new test which draws an SVG image on a canvas after setting its
globalAlpha to a value less than 1.
* svg/canvas/canvas-global-alpha-svg-expected.html: Added.
* svg/canvas/canvas-global-alpha-svg.html: Added.
Commit: e1fbb97830594d159c192739d912b1bc1c4ddfb1
https://github.com/WebKit/WebKit/commit/e1fbb97830594d159c192739d912b1bc1c4ddfb1
Author: Matthew Mirman <mmirman at apple.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/RegisterSet.cpp
A Source/JavaScriptCore/tests/stress/regress-141489.js
Log Message:
-----------
Merge r180516 - r9 is volatile on ARMv7 for iOS 3 and up.
https://bugs.webkit.org/show_bug.cgi?id=141489
rdar://problem/19432916
Reviewed by Michael Saboff.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers.
* tests/stress/regress-141489.js: Added.
(foo):
Commit: 530e7415b9197887a7e738158e845f3139b44afc
https://github.com/WebKit/WebKit/commit/530e7415b9197887a7e738158e845f3139b44afc
Author: Shivakumar J M <shiva.jm at samsung.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/select-size-expected.txt
A LayoutTests/fast/dom/select-size.html
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLSelectElement.cpp
Log Message:
-----------
Merge r180530 - Default value of HTMLSelectElement size IDL attribute should be 0.
https://bugs.webkit.org/show_bug.cgi?id=141795
Reviewed by Andreas Kling.
Source/WebCore:
Default value of HTMLSelectElement size IDL attribute should be 0.
As in spec: http://www.w3.org/html/wg/drafts/html/master/forms.html#the-select-element, also this matches the behavior of Chrome, IE and
Gecko.
Test: fast/dom/select-size.html
* html/HTMLSelectElement.cpp:
(WebCore::HTMLSelectElement::parseAttribute):
LayoutTests:
* fast/dom/select-size-expected.txt: Added.
* fast/dom/select-size.html: Added.
Commit: 7f9172069b48ba10243d095a73b0bffc22355775
https://github.com/WebKit/WebKit/commit/7f9172069b48ba10243d095a73b0bffc22355775
Author: Brent Fulgham <bfulgham at webkit.org>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/WeakPtr.h
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp
Log Message:
-----------
Merge r180528 - Source/WTF:
WTF::WeakPtr should have a 'forget' method
https://bugs.webkit.org/show_bug.cgi?id=141923
Reviewed by Myles C. Maxfield.
* wtf/WeakPtr.h:
(WTF::WeakPtr::forget): Added.
Tools:
WTF::WeakPtr should have a 'forget' method.
https://bugs.webkit.org/show_bug.cgi?id=141923
Reviewed by Myles C. Maxfield.
* TestWebKitAPI/Tests/WTF/WeakPtr.cpp:
(TestWebKitAPI::TEST): Added 'Forget' tests case.
Commit: 7c1199bfaff9924593eece70e3bc533803ac7e06
https://github.com/WebKit/WebKit/commit/7c1199bfaff9924593eece70e3bc533803ac7e06
Author: Brent Fulgham <bfulgham at webkit.org>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/WeakPtr.h
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp
Log Message:
-----------
Merge r180535 - WTF::WeakPtr should rename 'forgot' to 'clear' and support nullptr assignment
https://bugs.webkit.org/show_bug.cgi?id=141935
Reviewed by Myles C. Maxfield.
Source/WTF:
* wtf/WeakPtr.h:
(WTF::WeakPtr::operator=): Added 'nullptr_t' overload.
(WTF::WeakPtr::clear): Renamed from 'forget'
(WTF::WeakPtr::forget): Deleted.
Tools:
* TestWebKitAPI/Tests/WTF/WeakPtr.cpp:
(TestWebKitAPI::TEST): Updated for 'clear' method rename, and added a few
tests for assigning from nullptr.
Commit: a552645cc0328befa16503988cfa5e829bd2a410
https://github.com/WebKit/WebKit/commit/a552645cc0328befa16503988cfa5e829bd2a410
Author: Brent Fulgham <bfulgham at webkit.org>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/page/EventHandler.h
M Source/WebCore/platform/Scrollbar.cpp
M Source/WebCore/platform/Scrollbar.h
Log Message:
-----------
Merge r180548 - EventHandler references deleted Scrollbar
https://bugs.webkit.org/show_bug.cgi?id=141931
<rdar://problem/19915210>
Reviewed by Tim Horton.
Tested by scrollbars/overflow-custom-scrollbar-crash.html
Update the EventHandler class to use a WeakPtr to reference the
last used Scrollbar, rather than retaining the Scrollbar and
artificially extending its life. This keeps the EventHandler
state in proper sync with the state of the render tree, and
avoids cases where we have destroyed a ScrollableArea (and
Scrollbar) but are still sending messages to a fake zombie
version of the element.
* page/EventHandler.cpp:
(WebCore::EventHandler::clear):
(WebCore::EventHandler::handleMousePressEvent):
(WebCore::EventHandler::updateMouseEventTargetNode):
(WebCore::EventHandler::updateLastScrollbarUnderMouse):
* page/EventHandler.h:
* platform/Scrollbar.cpp:
(WebCore::Scrollbar::Scrollbar): Initialize WeakPtrFactory.
* platform/Scrollbar.h:
(WebCore::Scrollbar::createWeakPtr): Added,
Commit: 1f88fe06e80b3b19ff278629949222f4cd79500e
https://github.com/WebKit/WebKit/commit/1f88fe06e80b3b19ff278629949222f4cd79500e
Author: Antti Koivisto <koivisto at iki.fi>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/css/StyleResolver.cpp
Log Message:
-----------
Merge r180554 - Give TemporaryChange for m_inLoadPendingImages assertion a name so it actually does something.
* css/StyleResolver.cpp:
(WebCore::StyleResolver::loadPendingImages):
Commit: 0e5951bd86e6ab7066b9e1d6636fd4d56865fd25
https://github.com/WebKit/WebKit/commit/0e5951bd86e6ab7066b9e1d6636fd4d56865fd25
Author: Dhi Aurrahman <diorahman at rockybars.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/fast/css/css-lang-selector-with-string-arguments-text-expected.txt
M LayoutTests/fast/css/css-lang-selector-with-string-arguments-text.html
M LayoutTests/fast/css/css-selector-text-expected.txt
M LayoutTests/fast/css/css-selector-text.html
M LayoutTests/fast/css/css-set-selector-text-expected.txt
M LayoutTests/fast/css/css-set-selector-text.html
M LayoutTests/fast/css/parsing-css-lang-expected.txt
M LayoutTests/fast/css/parsing-css-lang.html
M LayoutTests/fast/dom/css-selectorText-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSGrammar.y.in
M Source/WebCore/css/CSSParserValues.cpp
M Source/WebCore/css/CSSParserValues.h
M Source/WebCore/css/CSSSelector.cpp
M Source/WebCore/css/CSSSelector.h
M Source/WebCore/css/SelectorCheckerTestFunctions.h
M Source/WebCore/cssjit/SelectorCompiler.cpp
Log Message:
-----------
Merge r180558 - Always serialize :lang()'s arguments to strings
https://bugs.webkit.org/show_bug.cgi?id=141944
Reviewed by Benjamin Poulain.
Source/WebCore:
As specified in [1] :lang()'s arguments are always serialized to strings.
[1] http://dev.w3.org/csswg/cssom/#serializing-selectors
Related tests are updated.
* css/CSSGrammar.y.in:
* css/CSSParserValues.cpp:
(WebCore::CSSParserSelector::setLangArgumentList):
* css/CSSParserValues.h:
(WebCore::CSSParserString::init):
(WebCore::CSSParserString::clear):
(WebCore::CSSParserString::tokenType): Deleted.
(WebCore::CSSParserString::setTokenType): Deleted.
* css/CSSSelector.cpp:
(WebCore::appendLangArgumentList):
(WebCore::CSSSelector::setLangArgumentList):
* css/CSSSelector.h:
(WebCore::CSSSelector::langArgumentList):
* css/SelectorCheckerTestFunctions.h:
(WebCore::matchesLangPseudoClass):
* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::addPseudoClassType):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementIsInLanguage):
LayoutTests:
Some tests results are updated to reflect the always serialize
:lang()'s arguments to strings.
* fast/css/css-lang-selector-with-string-arguments-text-expected.txt:
* fast/css/css-lang-selector-with-string-arguments-text.html:
* fast/css/parsing-css-lang-expected.txt:
* fast/css/parsing-css-lang.html:
* fast/css/css-selector-text-expected.txt:
* fast/css/css-selector-text.html:
* fast/css/css-set-selector-text-expected.txt:
* fast/css/css-set-selector-text.html:
* fast/dom/css-selectorText-expected.txt:
Commit: 95ba7182d3a807d928f9338d878bc46bc2b42a5d
https://github.com/WebKit/WebKit/commit/95ba7182d3a807d928f9338d878bc46bc2b42a5d
Author: Michael Catanzaro <mcatanzaro at igalia.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp
M Source/WebCore/platform/graphics/freetype/FontPlatformDataFreeType.cpp
Log Message:
-----------
Merge r180563 - [GTK] Fonts loaded via @font-face look bad
https://bugs.webkit.org/show_bug.cgi?id=140994
Patch by Michael Catanzaro <mcatanzaro at igalia.com> on 2015-02-24
Reviewed by Martin Robinson.
We've had several complaints that woff fonts look bad on some websites. This seems to be a
combination of multiple issues. For one, we don't look at Fontconfig settings at all when
creating a web font. This commit changes FontPlatformData::initializeWithFontFace to instead
use sane default settings from Fontconfig when loading a web font, rather than accepting the
default settings from GTK+, which are normally overridden by Fontconfig when loading system
fonts. However, we will hardcode the hinting setting for web fonts to always force use of
the light autohinter, so that we do not use a font's native hints. This avoids compatibility
issues when fonts with poor native hinting are only tested in browsers that do not use the
native hints. It also allows us to sidestep future security vulnerabilities in FreeType's
bytecode interpreter.
The net result of this is that there should be little noticable difference if you have GTK+
set to use slight hinting (which forces use of the autohinter) unless you have customized
Fontconfig configuration, but a dramatic improvement with particular fonts if you use medium
or full hinting. This should reduce complaints about our font rendering on "fancy sites."
No new tests, since the affected fonts we've found are not freely redistributable.
* platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp:
(WebCore::FontCustomPlatformData::FontCustomPlatformData): Force web fonts to be autohinted.
* platform/graphics/freetype/FontPlatformDataFreeType.cpp:
(WebCore::getDefaultCairoFontOptions): Renamed to disambiguate.
(WebCore::getDefaultFontconfigOptions): Added.
(WebCore::FontPlatformData::initializeWithFontFace): Always call
FontPlatformData::setCairoOptionsFromFontConfigPattern. If the FontPlatformData was not
created with an FcPattern (e.g. because this is a web font), call
getDefaultFontconfigOptions to get a sane default FcPattern.
(WebCore::FontPlatformData::setOrientation): Renamed call to getDefaultCairoFontOptions.
(WebCore::getDefaultFontOptions): Deleted.
Commit: d4b30102f4f74d448c9e390119080d98180504a1
https://github.com/WebKit/WebKit/commit/d4b30102f4f74d448c9e390119080d98180504a1
Author: Michael Catanzaro <mcatanzaro at igalia.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebPageProxy.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2/LoadAlternateHTMLStringWithNonDirectoryURL.cpp
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestLoaderClient.cpp
Log Message:
-----------
Merge r180565 - Crash loading local file with WebPageProxy::loadAlternateHTMLString
https://bugs.webkit.org/show_bug.cgi?id=141867
Patch by Michael Catanzaro <mcatanzaro at igalia.com> on 2015-02-24
Reviewed by Anders Carlsson.
Source/WebKit2:
WebPageProxy::loadAlternateHTMLString needs to assume read access to unreachableURL as well
as baseURL, because unreachableURL will get added to the back/forward list, causing us to
crash later on when we notice the unexpected URL received in checkURLReceivedFromWebProcess.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::loadAlternateHTMLString):
Tools:
* TestWebKitAPI/Tests/WebKit2/LoadAlternateHTMLStringWithNonDirectoryURL.cpp:
(TestWebKitAPI::loadAlternateHTMLString): Split most of this test into a function so it can
be shared with the new test.
(TestWebKitAPI::TEST): Add a cross-platform test for this crash.
* TestWebKitAPI/Tests/WebKit2Gtk/TestLoaderClient.cpp: Add a GTK+ test for this crash.
(testLoadAlternateHTMLForLocalPage):
(beforeAll):
Commit: 5df0434575890ce2b29a3b301bd30333df7925b5
https://github.com/WebKit/WebKit/commit/5df0434575890ce2b29a3b301bd30333df7925b5
Author: Joanmarie Diggs <jdiggs at igalia.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/platform/gtk/accessibility/roles-exposed-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp
Log Message:
-----------
Merge r180566 - [GTK] Layout Test accessibility/roles-exposed.html is failing
https://bugs.webkit.org/show_bug.cgi?id=141960
Reviewed by Martin Robinson.
Source/WebCore:
The test was failing because Gtk now uses GtkColorChooserDialog for the
color input, making the input field a button which results in the color
chooser dialog appearing. As a side effect of this change, the input now
has an accessible role of ColorWell, which is currently mapped to
ATK_ROLE_COLOR_CHOOSER (which is by definition the dialog which results
upon activating the button input field). Changed the Gtk platform mapping
to ATK_ROLE_BUTTON, leaving the Efl mapping as-is.
No new tests. Instead, updated and unskipped failing test.
* accessibility/atk/WebKitAccessibleWrapperAtk.cpp:
(atkRole):
LayoutTests:
* platform/gtk/TestExpectations: Unskip the failing test.
* platform/gtk/accessibility/roles-exposed-expected.txt: Update the expectations.
Commit: b6d121b37483aed2a535bb0628fcef20a56ebf1c
https://github.com/WebKit/WebKit/commit/b6d121b37483aed2a535bb0628fcef20a56ebf1c
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/JavaScriptCore.order
M Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCore.vcxproj
M Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/JavaScriptCore/jsc.cpp
M Source/JavaScriptCore/runtime/JSGlobalObject.cpp
M Source/JavaScriptCore/runtime/JSGlobalObject.h
A Source/JavaScriptCore/runtime/RuntimeFlags.h
M Source/WebCore/ChangeLog
A Source/WebCore/ForwardingHeaders/runtime/RuntimeFlags.h
M Source/WebCore/WebCore.order
M Source/WebCore/WebCore.vcxproj/WebCore.vcxproj
M Source/WebCore/WebCore.vcxproj/WebCore.vcxproj.filters
M Source/WebCore/bindings/js/JSDOMWindowBase.cpp
M Source/WebCore/bindings/js/JSDOMWindowBase.h
M Source/WebCore/bindings/js/JSWorkerGlobalScopeBase.cpp
M Source/WebCore/bindings/js/JSWorkerGlobalScopeBase.h
M Source/WebCore/inspector/InspectorFrontendClientLocal.cpp
M Source/WebCore/page/Settings.h
M Source/WebCore/page/Settings.in
M Source/WebKit/mac/ChangeLog
M Source/WebKit/mac/Misc/WebNSDictionaryExtras.h
M Source/WebKit/mac/Misc/WebNSDictionaryExtras.m
M Source/WebKit/mac/WebKit.order
M Source/WebKit/mac/WebView/WebPreferenceKeysPrivate.h
M Source/WebKit/mac/WebView/WebPreferences.mm
M Source/WebKit/mac/WebView/WebPreferencesPrivate.h
M Source/WebKit/mac/WebView/WebView.mm
M Source/WebKit/win/ChangeLog
M Source/WebKit/win/Interfaces/IWebPreferences.idl
M Source/WebKit/win/Interfaces/IWebPreferencesPrivate.idl
M Source/WebKit/win/WebPreferenceKeysPrivate.h
M Source/WebKit/win/WebPreferences.cpp
M Source/WebKit/win/WebPreferences.h
M Source/WebKit/win/WebView.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/WebPreferencesDefinitions.h
M Source/WebKit2/UIProcess/API/C/WKPreferences.cpp
M Source/WebKit2/UIProcess/API/C/WKPreferencesRef.h
M Source/WebKit2/UIProcess/API/C/WKPreferencesRefPrivate.h
M Source/WebKit2/UIProcess/API/Cocoa/WKPreferences.mm
M Source/WebKit2/UIProcess/API/Cocoa/WKPreferencesPrivate.h
M Source/WebKit2/UIProcess/efl/WebInspectorProxyEfl.cpp
M Source/WebKit2/UIProcess/gtk/WebInspectorProxyGtk.cpp
M Source/WebKit2/UIProcess/mac/WebInspectorProxyMac.mm
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
M Source/WebKit2/mac/WebKit2.order
M Tools/ChangeLog
M Tools/DumpRenderTree/mac/DumpRenderTree.mm
M Tools/DumpRenderTree/win/DumpRenderTree.cpp
M Tools/WebKitTestRunner/TestController.cpp
Log Message:
-----------
Merge r180570 - REGRESSION(r179429): Can't type comments in Facebook
https://bugs.webkit.org/show_bug.cgi?id=141859
Reviewed by Brent Fulgham.
Source/JavaScriptCore:
When window.Symbol is exposed to user-space pages,
Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
However, to work with Symbols completely, it also requires
1) Object.getOwnPropertySymbols (for mixin including Symbols)
2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
Since they are not landed yet, comments in Facebook don't work.
This patch introduces RuntimeFlags for JavaScriptCore.
Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
And drop JavaScriptExperimentsEnabled flag
because it is no longer used and use case of this is duplicated to runtime flags.
* JavaScriptCore.order:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::javaScriptRuntimeFlags):
(GlobalObject::javaScriptExperimentsEnabled): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::finishCreation):
(JSC::JSGlobalObject::javaScriptRuntimeFlags):
(JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
* runtime/RuntimeFlags.h: Added.
(JSC::RuntimeFlags::RuntimeFlags):
(JSC::RuntimeFlags::createAllEnabled):
Source/WebCore:
Enable SymbolEnabled runtime flag in inspector context.
* ForwardingHeaders/runtime/RuntimeFlags.h: Added.
* WebCore.order:
* WebCore.vcxproj/WebCore.vcxproj:
* WebCore.vcxproj/WebCore.vcxproj.filters:
* bindings/js/JSDOMWindowBase.cpp:
(WebCore::JSDOMWindowBase::javaScriptRuntimeFlags):
(WebCore::JSDOMWindowBase::javaScriptExperimentsEnabled): Deleted.
* bindings/js/JSDOMWindowBase.h:
* bindings/js/JSWorkerGlobalScopeBase.cpp:
(WebCore::JSWorkerGlobalScopeBase::javaScriptRuntimeFlags):
(WebCore::JSWorkerGlobalScopeBase::javaScriptExperimentsEnabled): Deleted.
* bindings/js/JSWorkerGlobalScopeBase.h:
* inspector/InspectorFrontendClientLocal.cpp:
(WebCore::InspectorFrontendClientLocal::InspectorFrontendClientLocal):
* page/Settings.h:
* page/Settings.in:
Source/WebKit/mac:
Introduce SymbolEnabled and drop javaScriptExperimentsEnabled.
Private API, javaScriptExperimentsEnabled is dropped.
* Misc/WebNSDictionaryExtras.h:
* Misc/WebNSDictionaryExtras.m:
(-[NSMutableDictionary _webkit_setUnsignedInt:forKey:]):
* WebKit.order:
* WebView/WebPreferenceKeysPrivate.h:
* WebView/WebPreferences.mm:
(+[WebPreferences initialize]):
(-[WebPreferences _setUnsignedIntValue:forKey:]):
(-[WebPreferences javaScriptRuntimeFlags]):
(-[WebPreferences setJavaScriptRuntimeFlags:]):
(-[WebPreferences setJavaScriptExperimentsEnabled:]): Deleted.
(-[WebPreferences javaScriptExperimentsEnabled]): Deleted.
* WebView/WebPreferencesPrivate.h:
* WebView/WebView.mm:
(-[WebView _preferencesChanged:]):
Source/WebKit/win:
Added Windows support.
* Interfaces/IWebPreferences.idl:
* Interfaces/IWebPreferencesPrivate.idl:
* WebPreferenceKeysPrivate.h:
* WebPreferences.cpp:
(WebPreferences::initializeDefaultSettings):
(WebPreferences::javaScriptRuntimeFlags):
(WebPreferences::setJavaScriptRuntimeFlags):
(WebPreferences::isWebSecurityEnabled):
* WebPreferences.h:
* WebView.cpp:
(WebView::notifyPreferencesChanged):
Source/WebKit2:
Enable SymbolEnabled in inspector context.
* Shared/WebPreferencesDefinitions.h:
* UIProcess/API/C/WKPreferences.cpp:
(WKPreferencesSetJavaScriptRuntimeFlags):
(WKPreferencesGetJavaScriptRuntimeFlags):
(WKPreferencesSetJavaScriptExperimentsEnabled): Deleted.
(WKPreferencesGetJavaScriptExperimentsEnabled): Deleted.
* UIProcess/API/C/WKPreferencesRef.h:
* UIProcess/API/C/WKPreferencesRefPrivate.h:
* UIProcess/API/Cocoa/WKPreferences.mm:
(-[WKPreferences _javaScriptRuntimeFlags]):
(-[WKPreferences _setJavaScriptRuntimeFlags:]):
* UIProcess/API/Cocoa/WKPreferencesPrivate.h:
* UIProcess/efl/WebInspectorProxyEfl.cpp:
(WebKit::WebInspectorProxy::platformCreateInspectorPage):
* UIProcess/gtk/WebInspectorProxyGtk.cpp:
(WebKit::WebInspectorProxy::platformCreateInspectorPage):
* UIProcess/mac/WebInspectorProxyMac.mm:
(WebKit::WebInspectorProxy::platformCreateInspectorPage):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::updatePreferences):
* mac/WebKit2.order:
Tools:
Drop javaScriptExperimentsEnabled and specify JavaScriptRuntimeFlagsAllEnabled as KJavaScriptRuntimeFlags.
* DumpRenderTree/mac/DumpRenderTree.mm:
(resetWebPreferencesToConsistentValues):
* DumpRenderTree/win/DumpRenderTree.cpp:
(resetWebPreferencesToConsistentValues):
* WebKitTestRunner/TestController.cpp:
(WTR::TestController::resetPreferencesToConsistentValues):
Commit: 57d529897f23d453f729a39730ab184832f0e7d6
https://github.com/WebKit/WebKit/commit/57d529897f23d453f729a39730ab184832f0e7d6
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc.xcodeproj/project.pbxproj
M Source/bmalloc/bmalloc/Allocator.cpp
M Source/bmalloc/bmalloc/BeginTag.h
M Source/bmalloc/bmalloc/BoundaryTag.h
M Source/bmalloc/bmalloc/BoundaryTagInlines.h
M Source/bmalloc/bmalloc/EndTag.h
M Source/bmalloc/bmalloc/Heap.cpp
M Source/bmalloc/bmalloc/Heap.h
A Source/bmalloc/bmalloc/LargeObject.h
M Source/bmalloc/bmalloc/SegregatedFreeList.cpp
M Source/bmalloc/bmalloc/SegregatedFreeList.h
M Source/bmalloc/bmalloc/VMHeap.cpp
M Source/bmalloc/bmalloc/VMHeap.h
Log Message:
-----------
Merge r180576 - bmalloc: Added a little more abstraction for large objects
https://bugs.webkit.org/show_bug.cgi?id=141978
Reviewed by Sam Weinig.
Previously, each client needed to manage the boundary tags of
a large object using free functions. This patch introduces a LargeObject
class that does things a little more automatically.
* bmalloc.xcodeproj/project.pbxproj:
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::reallocate): Use the new LargeObject class.
* bmalloc/BeginTag.h:
(bmalloc::BeginTag::isInFreeList): Deleted. Moved this logic into the
LargeObject class.
* bmalloc/BoundaryTag.h:
(bmalloc::BoundaryTag::isSentinel):
(bmalloc::BoundaryTag::compactBegin):
(bmalloc::BoundaryTag::setRange):
(bmalloc::BoundaryTag::initSentinel): Added an explicit API for sentinels,
which we used to create and test for implicitly.
* bmalloc/BoundaryTagInlines.h:
(bmalloc::BoundaryTag::init):
(bmalloc::validate): Deleted.
(bmalloc::validatePrev): Deleted.
(bmalloc::validateNext): Deleted.
(bmalloc::BoundaryTag::mergeLeft): Deleted.
(bmalloc::BoundaryTag::mergeRight): Deleted.
(bmalloc::BoundaryTag::merge): Deleted.
(bmalloc::BoundaryTag::deallocate): Deleted.
(bmalloc::BoundaryTag::split): Deleted.
(bmalloc::BoundaryTag::allocate): Deleted. Moved this logic into the
LargeObject class.
* bmalloc/EndTag.h:
(bmalloc::EndTag::init):
(bmalloc::EndTag::operator=): Deleted. Re-reading this code, I found
special behavior in the assignment operator to be a surprising API.
So, I replaced the assignment operation with an explicit initializing
function.
* bmalloc/Heap.cpp:
(bmalloc::Heap::scavengeLargeRanges):
(bmalloc::Heap::allocateXLarge):
(bmalloc::Heap::findXLarge):
(bmalloc::Heap::deallocateXLarge):
(bmalloc::Heap::allocateLarge):
(bmalloc::Heap::deallocateLarge):
* bmalloc/Heap.h: No behavior changes here -- just adopting the
LargeObject interface.
* bmalloc/LargeObject.h: Added.
(bmalloc::LargeObject::operator!):
(bmalloc::LargeObject::begin):
(bmalloc::LargeObject::size):
(bmalloc::LargeObject::range):
(bmalloc::LargeObject::LargeObject):
(bmalloc::LargeObject::setFree):
(bmalloc::LargeObject::isFree):
(bmalloc::LargeObject::hasPhysicalPages):
(bmalloc::LargeObject::setHasPhysicalPages):
(bmalloc::LargeObject::isValidAndFree):
(bmalloc::LargeObject::merge):
(bmalloc::LargeObject::split):
(bmalloc::LargeObject::validateSelf):
(bmalloc::LargeObject::validate): Moved this code into a class, out of
BoundaryTag free functions.
New to the class are these features:
(1) Every reference to an object is validated upon creation and use.
(2) There's an explicit API for "This is a reference to an object
that might be stale (the DoNotValidate API)".
(3) The begin and end tags are kept in sync automatically.
* bmalloc/SegregatedFreeList.cpp:
(bmalloc::SegregatedFreeList::insert):
(bmalloc::SegregatedFreeList::takeGreedy):
(bmalloc::SegregatedFreeList::take):
* bmalloc/SegregatedFreeList.h: Adopt the LargeObject interface.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
* bmalloc/VMHeap.h:
(bmalloc::VMHeap::allocateLargeRange):
(bmalloc::VMHeap::deallocateLargeRange): Adopt the LargeObject interface.
Commit: 8a28f08f512fe64287a3c51299b214503796c1ec
https://github.com/WebKit/WebKit/commit/8a28f08f512fe64287a3c51299b214503796c1ec
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/JavaScriptCore/API/tests/testapi.mm
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/heap/Heap.cpp
M Source/JavaScriptCore/heap/Heap.h
M Source/JavaScriptCore/heap/MachineStackMarker.cpp
M Source/JavaScriptCore/heap/MachineStackMarker.h
Log Message:
-----------
Merge r180591 - Rolling out r179753. The fix was invalid.
<https://webkit.org/b/141990>
Not reviewed.
* API/tests/testapi.mm:
(threadMain):
(useVMFromOtherThread): Deleted.
(useVMFromOtherThreadAndOutliveVM): Deleted.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::gatherStackRoots):
* heap/Heap.h:
(JSC::Heap::machineThreads):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::addCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::removeCurrentThread):
* heap/MachineStackMarker.h:
Commit: b8dddb789a3c75d8502062c56a56ec87f9fdf98a
https://github.com/WebKit/WebKit/commit/b8dddb789a3c75d8502062c56a56ec87f9fdf98a
Author: Joanmarie Diggs <jdiggs at igalia.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/accessibility/aria-switch-checked-expected.txt
A LayoutTests/accessibility/aria-switch-checked.html
A LayoutTests/accessibility/aria-switch-sends-notification-expected.txt
A LayoutTests/accessibility/aria-switch-sends-notification.html
A LayoutTests/accessibility/aria-switch-text.html
M LayoutTests/accessibility/roles-exposed.html
A LayoutTests/platform/efl/accessibility/aria-fallback-roles-expected.txt
A LayoutTests/platform/efl/accessibility/aria-switch-text-expected.txt
M LayoutTests/platform/efl/accessibility/roles-exposed-expected.txt
A LayoutTests/platform/gtk/accessibility/aria-fallback-roles-expected.txt
A LayoutTests/platform/gtk/accessibility/aria-switch-text-expected.txt
M LayoutTests/platform/gtk/accessibility/roles-exposed-expected.txt
M LayoutTests/platform/mac-mavericks/accessibility/roles-exposed-expected.txt
M LayoutTests/platform/mac/TestExpectations
A LayoutTests/platform/mac/accessibility/aria-switch-text-expected.txt
M LayoutTests/platform/mac/accessibility/roles-exposed-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.h
M Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp
M Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp
M Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
Log Message:
-----------
Merge r180600 - AX: Implement support for ARIA 1.1 'switch' role
https://bugs.webkit.org/show_bug.cgi?id=141986
Reviewed by Chris Fleizach.
Source/WebCore:
Map the role to ATK_ROLE_TOGGLE_BUTTON for Gtk and Efl; on the Mac, to
AXCheckBox with a subrole of AXSwitch. Ensure it looks and acts like a
widget to accessibility APIs (supports and emits notifications when
toggled, doesn't have children, exposes a name and description when
provided).
Tests: accessibility/aria-switch-checked.html
accessibility/aria-switch-sends-notification.html
accessibility/aria-switch-text.html
* accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::canHaveChildren):
(WebCore::AccessibilityNodeObject::isChecked):
(WebCore::AccessibilityNodeObject::visibleText):
(WebCore::AccessibilityNodeObject::title):
* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::isARIAInput):
(WebCore::AccessibilityObject::actionVerb):
(WebCore::initializeRoleMap):
(WebCore::AccessibilityObject::supportsChecked):
(WebCore::AccessibilityObject::checkboxOrRadioValue):
* accessibility/AccessibilityObject.h:
(WebCore::AccessibilityObject::isSwitch):
* accessibility/atk/AXObjectCacheAtk.cpp:
(WebCore::AXObjectCache::postPlatformNotification):
* accessibility/atk/WebKitAccessibleWrapperAtk.cpp:
(atkRole):
* accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:
(-[WebAccessibilityObjectWrapper accessibilityCanFuzzyHitTest]):
(-[WebAccessibilityObjectWrapper accessibilityTraits]):
(-[WebAccessibilityObjectWrapper determineIsAccessibilityElement]):
* accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(createAccessibilityRoleMap):
(-[WebAccessibilityObjectWrapper subrole]):
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]):
LayoutTests:
* accessibility/aria-switch-checked-expected.txt: Added.
* accessibility/aria-switch-checked.html: Added.
* accessibility/aria-switch-sends-notification-expected.txt: Added.
* accessibility/aria-switch-sends-notification.html: Added.
* accessibility/aria-switch-text.html: Added.
* accessibility/roles-exposed.html: Added a test case for the new role.
* platform/efl/accessibility/aria-fallback-roles-expected.txt: Added.
* platform/efl/accessibility/aria-switch-text-expected.txt: Added.
* platform/efl/accessibility/roles-exposed-expected.txt: Updated for the new role.
* platform/gtk/accessibility/aria-fallback-roles-expected.txt: Added.
* platform/gtk/accessibility/aria-switch-text-expected.txt: Added.
* platform/gtk/accessibility/roles-exposed-expected.txt: Updated for the new role.
* platform/mac-mavericks/accessibility/roles-exposed-expected.txt: Updated for the new role.
* platform/mac/TestExpectations: Skip the 'checked' notifcation as the Mac doesn't have it.
* platform/mac/accessibility/aria-switch-text-expected.txt: Added.
* platform/mac/accessibility/roles-exposed-expected.txt: Updated for the new role.
Commit: a1f31d62b9a1696f76e1568232b22cd1ef643867
https://github.com/WebKit/WebKit/commit/a1f31d62b9a1696f76e1568232b22cd1ef643867
Author: Stephanie Lewis <slewis at apple.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/VMHeap.cpp
M Source/bmalloc/bmalloc/VMHeap.h
M Source/bmalloc/bmalloc/Zone.cpp
M Source/bmalloc/bmalloc/Zone.h
Log Message:
-----------
Merge r180604 - Rolling out http://trac.webkit.org/changeset/180430 as it causes the PLT to crash.
<rdar://problem/19948015>
Unreviewed.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
* bmalloc/VMHeap.h:
* bmalloc/Zone.cpp:
(bmalloc::Zone::Zone):
(bmalloc::Zone::size): Deleted.
* bmalloc/Zone.h:
Commit: 0f79485bb389b9ffb629a60ce4454b8d44281cdb
https://github.com/WebKit/WebKit/commit/0f79485bb389b9ffb629a60ce4454b8d44281cdb
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/JavaScriptCore/CMakeLists.txt
M Source/JavaScriptCore/ChangeLog
A Source/JavaScriptCore/llvm/library/libllvmForJSC.version
Log Message:
-----------
CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
https://bugs.webkit.org/show_bug.cgi?id=141989
Reviewed by Gyuyoung Kim.
* CMakeLists.txt:
* llvm/library/libllvmForJSC.version: Added.
Commit: 0cb32b954c08bbcbf6bff4b79af329696c5eb144
https://github.com/WebKit/WebKit/commit/0cb32b954c08bbcbf6bff4b79af329696c5eb144
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-02-28 (Sat, 28 Feb 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/Platform.h
Log Message:
-----------
Merge r180620 - Enable concurrent JIT on GTK
https://bugs.webkit.org/show_bug.cgi?id=142007
Reviewed by Benjamin Poulain.
Seems weird that GTK keeps it off. No good reason for that as far as I can tell.
* wtf/Platform.h:
Commit: ff58dcfeb8ad504cb1c5bb836833d36bd3a26a0a
https://github.com/WebKit/WebKit/commit/ff58dcfeb8ad504cb1c5bb836833d36bd3a26a0a
Author: Joanmarie Diggs <jdiggs at igalia.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/accessibility/roles-computedRoleString-expected.txt
M LayoutTests/accessibility/roles-computedRoleString.html
M LayoutTests/accessibility/roles-exposed.html
M LayoutTests/platform/efl/accessibility/roles-exposed-expected.txt
M LayoutTests/platform/gtk/accessibility/roles-exposed-expected.txt
M LayoutTests/platform/mac-mavericks/accessibility/roles-exposed-expected.txt
M LayoutTests/platform/mac/accessibility/roles-exposed-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.h
M Source/WebCore/accessibility/AccessibilityRenderObject.cpp
M Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp
M Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
Log Message:
-----------
Merge r180621 - AX: Implement support for ARIA 1.1 'searchbox' role
https://bugs.webkit.org/show_bug.cgi?id=142004
Reviewed by Chris Fleizach.
Source/WebCore:
Add a new accessible SearchFieldRole to handle both the ARIA role
and the "search" input type.
No new tests. Instead, added a new test case to roles-exposed.html
for the mapping, and updated roles-computedRoleString.html because
there is now a one-to-one mapping between the "search" input type
and an ARIA role.
* accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::determineAccessibilityRole):
(WebCore::AccessibilityNodeObject::isSearchField):
* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::isARIATextControl):
(WebCore::AccessibilityObject::isARIAInput):
(WebCore::initializeRoleMap):
* accessibility/AccessibilityObject.h:
* accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::determineAccessibilityRole):
* accessibility/atk/WebKitAccessibleWrapperAtk.cpp:
(atkRole):
* accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:
(-[WebAccessibilityObjectWrapper accessibilityCanFuzzyHitTest]):
(-[WebAccessibilityObjectWrapper accessibilityTraits]):
(-[WebAccessibilityObjectWrapper determineIsAccessibilityElement]):
* accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(createAccessibilityRoleMap):
LayoutTests:
* accessibility/roles-computedRoleString-expected.txt: Updated for new role.
* accessibility/roles-computedRoleString.html: Updated for new role.
* accessibility/roles-exposed.html: New test case added.
* platform/efl/accessibility/roles-exposed-expected.txt: Updated for new test case.
* platform/gtk/accessibility/roles-exposed-expected.txt: Updated for new test case.
* platform/mac-mavericks/accessibility/roles-exposed-expected.txt: Updated for new test case.
* platform/mac/accessibility/roles-exposed-expected.txt: Updated for new test case.
Commit: 0692afb4254617d4632b09c78f164fd1e910053c
https://github.com/WebKit/WebKit/commit/0692afb4254617d4632b09c78f164fd1e910053c
Author: Beth Dakin <bdakin at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Merge r180634 - REGRESSION (r180018 ): Holding a rubber-band in place can get stuck
https://bugs.webkit.org/show_bug.cgi?id=142020
-and corresponding-
rdar://problem/19945216
Reviewed by Tom Horton.
It was a mistaken assumption that it was necessary to return false in the zero-
delta case. That is clearly conceptually wrong since false represents the DOM
doing something special with the event, which is clearly not the case if we never
even send the event to the DOM. Returning true will allow the rest of the
scrolling machinery the ability to handle the event.
* dom/Element.cpp:
(WebCore::Element::dispatchWheelEvent):
Commit: 8f6278a5add0becaaea5e1286ae4a572405eb7dd
https://github.com/WebKit/WebKit/commit/8f6278a5add0becaaea5e1286ae4a572405eb7dd
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M PerformanceTests/SunSpider/ChangeLog
M PerformanceTests/SunSpider/profiler-test.yaml
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
A Source/JavaScriptCore/tests/stress/op-push-name-scope-crashes-profiler.js
M Tools/ChangeLog
M Tools/Scripts/run-jsc-stress-tests
Log Message:
-----------
Merge r180639 - CodeBlock crashes when dumping op_push_name_scope
https://bugs.webkit.org/show_bug.cgi?id=141953
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-02-25
PerformanceTests/SunSpider:
Reviewed by Filip Pizlo.
* profiler-test.yaml:
Source/JavaScriptCore:
Reviewed by Filip Pizlo and Csaba Osztrogonác.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* tests/stress/op-push-name-scope-crashes-profiler.js: Added.
Tools:
Reviewed by Filip Pizlo.
* Scripts/run-jsc-stress-tests:
Commit: cb51fa63aceecc8ebdc3163d5c208e50819f97c8
https://github.com/WebKit/WebKit/commit/cb51fa63aceecc8ebdc3163d5c208e50819f97c8
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/clip-path/clip-path-line-use-before-defined-expected.svg
A LayoutTests/svg/clip-path/clip-path-line-use-before-defined.svg
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp
M Source/WebCore/rendering/svg/RenderSVGResourceClipper.h
M Source/WebCore/rendering/svg/RenderSVGResourceContainer.cpp
M Source/WebCore/rendering/svg/RenderSVGResourceContainer.h
M Source/WebCore/svg/SVGElement.cpp
Log Message:
-----------
Merge r180643 - Horizontal and vertical lines are clipped completely if clip-path is included in the tag but the referenced element is defined later.
https://bugs.webkit.org/show_bug.cgi?id=141776.
Reviewed by Dean Jackson.
Source/WebCore:
Tests: svg/clip-path/clip-path-line-use-before-defined-expected.svg
svg/clip-path/clip-path-line-use-before-defined.svg
* rendering/svg/RenderSVGResourceClipper.cpp:
(WebCore::RenderSVGResourceClipper::applyClippingToContext): Ensure the renderer
is added to m_clipper if it does not exist. The same renderer might have been
added to m_clipper in resourceBoundingBox().
(WebCore::RenderSVGResourceClipper::addRendererToClipper): Add the renderer to
m_clipper if it does not exist. Return the associated ClipperData.
(WebCore::RenderSVGResourceClipper::resourceBoundingBox): If the clipper is
referenced before it is defined, add the renderer to m_clipper. While doing the
layout() for the clipper, we can check if m_clipper has values or not. If it does
have, we are going to mark the clipper for client invalidation which is done by
the SVG root.
* rendering/svg/RenderSVGResourceClipper.h:
* rendering/svg/RenderSVGResourceContainer.h:
(WebCore::RenderSVGResourceContainer::selfNeedsClientInvalidation): Define a
new function selfNeedsClientInvalidation() which controls marking the clipper
for client invalidation. In RenderSVGResourceClipper, override it so it checks
m_clipper to force clients validation even if it the first time we do layout
for this clipper.
* rendering/svg/RenderSVGResourceContainer.cpp:
(WebCore::RenderSVGResourceContainer::layout): Call the virtual function
selfNeedsClientInvalidation() to check whether we need to mark the clipper for
client invalidation.
* svg/SVGElement.cpp: Delete unneeded header file.
LayoutTests:
New test cases for SVG lines which are clipped to a <clipPath>. The <clipPath>
is referenced before it is defined.
* svg/clip-path/clip-path-line-use-before-defined-expected.svg: Added.
* svg/clip-path/clip-path-line-use-before-defined.svg: Added.
Commit: 855abb823ea0a282a058e8123b666f69658ac1d5
https://github.com/WebKit/WebKit/commit/855abb823ea0a282a058e8123b666f69658ac1d5
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/RegisterSet.cpp
Log Message:
-----------
Merge r180667 - Add calleeSaveRegisters() implementation for ARM Traditional
https://bugs.webkit.org/show_bug.cgi?id=141903
Reviewed by Darin Adler.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters):
Commit: 09c837da6b679010ab80e5cac548fc7497f033a8
https://github.com/WebKit/WebKit/commit/09c837da6b679010ab80e5cac548fc7497f033a8
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/as-object/resources/lime100x100.html
A LayoutTests/svg/as-object/resources/lime100x100.png
A LayoutTests/svg/as-object/resources/lime100x100.svg
A LayoutTests/svg/as-object/resources/red100x100.svg
A LayoutTests/svg/as-object/svg-in-object-dynamic-attribute-change-expected.html
A LayoutTests/svg/as-object/svg-in-object-dynamic-attribute-change.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Element.h
M Source/WebCore/html/HTMLObjectElement.cpp
M Source/WebCore/html/HTMLObjectElement.h
M Source/WebCore/html/HTMLPlugInImageElement.cpp
Log Message:
-----------
Merge r180683 - Setting any of the <object> element plugin controlling attributes does not have any affect.
https://bugs.webkit.org/show_bug.cgi?id=141936.
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-02-26
Reviewed by Zalan Bujtas.
Source/WebCore:
When setting any of the <object> element plugin controlling attributes
dynamically we need to mark the the element to be dirty by calling
setNeedsStyleRecalc(), so it has to recreate its renderer when needed.
Test: svg/as-object/svg-in-object-dynamic-attribute-change.html
* dom/Element.h: Delete unimplemented function.
* html/HTMLObjectElement.cpp:
(WebCore::HTMLObjectElement::parseAttribute): Dirty the element by calling
setNeedsStyleRecalc() when one of the plugin controlling attributes gets
changed. We have to clear the m_useFallbackContent because the attribute's
new value might fix the object rendering.
* html/HTMLObjectElement.h: Add a function to clear m_useFallbackContent.
* html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::willRecalcStyle): We might need to
reconstruct the object renderer in the image case. This can happen if the
image was rendering fallback content and the attribute's new value fixes
the object rendering.
LayoutTests:
* svg/as-object/resources/lime100x100.html: Added.
* svg/as-object/resources/lime100x100.png: Added.
* svg/as-object/resources/lime100x100.svg: Added.
* svg/as-object/resources/red100x100.svg: Added.
* svg/as-object/svg-in-object-dynamic-attribute-change-expected.html: Added.
* svg/as-object/svg-in-object-dynamic-attribute-change.html: Added.
Ensure that changing the 'type' and the 'data' attributes of the <object>
element will have the expected outcome. Also make sure that the <object>
element renderer falls back correctly when setting any of the attributes
to some unexpected value.
Commit: 5a606141e075938fe116d3f5a15cc8523d2c2d28
https://github.com/WebKit/WebKit/commit/5a606141e075938fe116d3f5a15cc8523d2c2d28
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Algorithm.h
M Source/bmalloc/bmalloc/BoundaryTag.h
M Source/bmalloc/bmalloc/Sizes.h
Log Message:
-----------
Merge r180688 - bmalloc: free up a bit in BoundaryTag
https://bugs.webkit.org/show_bug.cgi?id=142048
Reviewed by Brady Eidson.
We were wasting a bit by accident, and I need one now.
* bmalloc/Algorithm.h:
(bmalloc::rightShift): Deleted. Not needed, now that I've simplified
the math.
* bmalloc/BoundaryTag.h: Since each boundary tag bucket is 1024 bytes
long, the maximum offset into a bucket is 1023.
You need 5 bits to count up to 1024, but only 4 to count up to 1023.
Math is hard.
(bmalloc::BoundaryTag::compactBegin): Switched to division because it
is simpler, and easier to match up with our ASSERT. The compiler will
turn division by constant power of two into a shift for us.
(bmalloc::BoundaryTag::setRange): Added an ASSERT for compactBegin
because we do encode it, so we should ASSERT that encoding did not
lose information.
* bmalloc/Sizes.h: Shifting is no longer used since we use division
instead.
Commit: a7aaa72661a3a624eec626023aa49b02b9345898
https://github.com/WebKit/WebKit/commit/a7aaa72661a3a624eec626023aa49b02b9345898
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/bmalloc/CMakeLists.txt
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc.xcodeproj/project.pbxproj
R Source/bmalloc/bmalloc/BoundaryTagInlines.h
A Source/bmalloc/bmalloc/FreeList.cpp
A Source/bmalloc/bmalloc/FreeList.h
M Source/bmalloc/bmalloc/LargeObject.h
M Source/bmalloc/bmalloc/SegregatedFreeList.cpp
M Source/bmalloc/bmalloc/SegregatedFreeList.h
M Source/bmalloc/bmalloc/Sizes.h
M Source/bmalloc/bmalloc/VMHeap.cpp
Log Message:
-----------
Merge r180693 - bmalloc: Refactored SegregatedFreeList and BoundaryTag::init
https://bugs.webkit.org/show_bug.cgi?id=142049
Reviewed by Anders Carlsson.
Split out a FreeList class from SegregatedFreeList. This will make it
easier to add behaviors on free list insertion and removal -- and it's
probably how I should have designed things at the start.
Moved BoundaryTag::init into LargeObject, since all the related logic
lives in LargeObject now too, and this allows us to remove BoundaryTagInlines.h.
* bmalloc.xcodeproj/project.pbxproj:
* bmalloc/BoundaryTagInlines.h: Removed.
* bmalloc/FreeList.cpp: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.cpp.
(bmalloc::FreeList::takeGreedy):
(bmalloc::FreeList::take):
(bmalloc::SegregatedFreeList::SegregatedFreeList): Deleted.
(bmalloc::SegregatedFreeList::insert): Deleted.
(bmalloc::SegregatedFreeList::takeGreedy): Deleted.
(bmalloc::SegregatedFreeList::take): Deleted.
* bmalloc/FreeList.h: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.h.
(bmalloc::FreeList::push):
* bmalloc/LargeObject.h:
(bmalloc::LargeObject::init):
* bmalloc/SegregatedFreeList.cpp:
(bmalloc::SegregatedFreeList::SegregatedFreeList):
(bmalloc::SegregatedFreeList::insert):
(bmalloc::SegregatedFreeList::takeGreedy):
(bmalloc::SegregatedFreeList::take):
* bmalloc/SegregatedFreeList.h:
* bmalloc/Sizes.h:
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::grow):
Commit: 6b985c824d6e6c1360a79819528e900109b8fecc
https://github.com/WebKit/WebKit/commit/6b985c824d6e6c1360a79819528e900109b8fecc
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/BoundaryTag.h
M Source/bmalloc/bmalloc/FreeList.cpp
M Source/bmalloc/bmalloc/FreeList.h
M Source/bmalloc/bmalloc/LargeObject.h
M Source/bmalloc/bmalloc/Sizes.h
Log Message:
-----------
Merge r180701 - bmalloc: Large object free list can grow infinitely
https://bugs.webkit.org/show_bug.cgi?id=142055
Reviewed by Andreas Kling.
By design, we don't eagerly remove large objects from the free list.
This creates two simple pathologies:
(1) If you free and then allocate the same object repeatedly, it will
duplicate itself in the free list repeatedly. Since it is never
invalid at the time of allocation, it will never be removed.
(2) If you split and then merge the same object repeatedly, it will
duplicate its split sibling in the free list repeatedly. If its
sibling is in a separate free list size class, it will never be
consulted at the time of allocation, so it will never be removed.
So, a simple "while (1) { free(malloc(x)); }" causes infinite memory
use in the free list.
The solution in this patch is a simple helper to remove garbage from the
free list if it grows too large. This pathology is not common, so the
cost is OK.
Long-term, perhaps we should rethink the laziness of these free lists.
* bmalloc/BoundaryTag.h:
(bmalloc::BoundaryTag::isMarked):
(bmalloc::BoundaryTag::setMarked): New bit, used by free list GC.
* bmalloc/FreeList.cpp:
(bmalloc::FreeList::removeInvalidAndDuplicateEntries): The GC algorithm.
* bmalloc/FreeList.h:
(bmalloc::FreeList::FreeList):
(bmalloc::FreeList::push): Invoke the GC if we're getting huge.
* bmalloc/LargeObject.h:
(bmalloc::LargeObject::isMarked):
(bmalloc::LargeObject::setMarked):
(bmalloc::LargeObject::validateSelf): Expose the new bit.
* bmalloc/Sizes.h: New constant to control GC frequency.
Commit: 46cbf415b28355a298decb000e8aea5507bdc550
https://github.com/WebKit/WebKit/commit/46cbf415b28355a298decb000e8aea5507bdc550
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/heap/MachineStackMarker.cpp
M Source/JavaScriptCore/heap/MachineStackMarker.h
Log Message:
-----------
Merge r180716 - MachineThreads::Thread clean up has a use after free race condition.
<https://webkit.org/b/141990>
Reviewed by Filip Pizlo.
MachineThreads::Thread clean up relies on the clean up mechanism
implemented in _pthread_tsd_cleanup_key(), which looks like this:
void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
{
void (*destructor)(void *);
if (_pthread_key_get_destructor(key, &destructor)) {
void **ptr = &self->tsd[key];
void *value = *ptr;
// === Start of window for the bug to manifest =================
// At this point, this thread has cached "destructor" and "value"
// (which is a MachineThreads*). If the VM gets destructed (along
// with its MachineThreads registry) by another thread, then this
// thread will have no way of knowing that the MachineThreads* is
// now pointing to freed memory. Calling the destructor below will
// therefore result in a use after free scenario when it tries to
// access the MachineThreads' data members.
if (value) {
*ptr = NULL;
if (destructor) {
// === End of window for the bug to manifest ==================
destructor(value);
}
}
}
}
The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
and always check if the manager still contains that MachineThreads object
before we call removeCurrentThread() on it. When MachineThreads is destructed,
it will remove itself from the manager. The add, remove, and checking
operations are all synchronized on the manager's lock, thereby ensuring that
the MachineThreads object, if found in the manager, will remain alive for the
duration of time we call removeCurrentThread() on it.
There's also possible for the MachineThreads object to already be destructed
and another one happened to have been instantiated at the same address.
Hence, we should only remove the exiting thread if it is found in the
MachineThreads object.
There is no test for this issue because this bug requires a race condition
between 2 threads where:
1. Thread B, which had previously used the VM, exiting and
getting to the bug window shown in _pthread_tsd_cleanup_key() above.
2. Thread A destructing the VM (and its MachineThreads object)
within that window of time before Thread B calls the destructor.
It is not possible to get a reliable test case without invasively
instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
to significantly increase that window of opportunity.
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::Locker::Locker):
(JSC::ActiveMachineThreadsManager::add):
(JSC::ActiveMachineThreadsManager::remove):
(JSC::ActiveMachineThreadsManager::contains):
(JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
(JSC::activeMachineThreadsManager):
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::removeThreadIfFound):
(JSC::MachineThreads::removeCurrentThread): Deleted.
* heap/MachineStackMarker.h:
Commit: df8180881a56514b98d24202a00dd3dd52f7ce2a
https://github.com/WebKit/WebKit/commit/df8180881a56514b98d24202a00dd3dd52f7ce2a
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/regions/region-with-multicolumn-embedded-crash-expected.txt
A LayoutTests/fast/regions/region-with-multicolumn-embedded-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderObject.cpp
Log Message:
-----------
Merge r180767 - Use after free in WebCore::RenderNamedFlowFragment::restoreRegionObjectsOriginalStyle
https://bugs.webkit.org/show_bug.cgi?id=138366
Reviewed by Dave Hyatt.
This patch ensures that we clean up RenderNamedFlowFragment::m_renderObjectRegionStyle when embedded flow content is getting destroyed.
In m_renderObjectRegionStyle hash map, we store style information about the named flow's descendant children.
When a child is being detached from the tree, it removes itself from this hashmap.
We do it by traversing up on the ancestor chain and call removeFlowChildInfo() on the parent flow.
However in case of embedded flows (for example multicolumn content inside a region), we need to check whether the parent flow
is inside a flow too and continue the cleanup accordingly.
Source/WebCore:
Test: fast/regions/region-with-multicolumn-embedded-crash.html
* rendering/RenderObject.cpp:
(WebCore::RenderObject::removeFromRenderFlowThreadIncludingDescendants):
LayoutTests:
* fast/regions/region-with-multicolumn-embedded-crash-expected.txt: Added.
* fast/regions/region-with-multicolumn-embedded-crash.html: Added.
Commit: 8fdb76704a873b6c48efab53f4849d2d5661c6fa
https://github.com/WebKit/WebKit/commit/8fdb76704a873b6c48efab53f4849d2d5661c6fa
Author: Andreas Kling <akling at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
M Source/WebCore/bindings/scripts/test/JS/JSTestActiveDOMObject.h
M Source/WebCore/bindings/scripts/test/JS/JSTestCustomNamedGetter.h
M Source/WebCore/bindings/scripts/test/JS/JSTestEventConstructor.h
M Source/WebCore/bindings/scripts/test/JS/JSTestEventTarget.h
M Source/WebCore/bindings/scripts/test/JS/JSTestException.h
M Source/WebCore/bindings/scripts/test/JS/JSTestGenerateIsReachable.h
M Source/WebCore/bindings/scripts/test/JS/JSTestInterface.h
M Source/WebCore/bindings/scripts/test/JS/JSTestMediaQueryListListener.h
M Source/WebCore/bindings/scripts/test/JS/JSTestNamedConstructor.h
M Source/WebCore/bindings/scripts/test/JS/JSTestNondeterministic.h
M Source/WebCore/bindings/scripts/test/JS/JSTestObj.h
M Source/WebCore/bindings/scripts/test/JS/JSTestOverloadedConstructors.h
M Source/WebCore/bindings/scripts/test/JS/JSTestSerializedScriptValueInterface.h
M Source/WebCore/bindings/scripts/test/JS/JSTestTypedefs.h
M Source/WebCore/bindings/scripts/test/JS/JSattribute.h
M Source/WebCore/bindings/scripts/test/JS/JSreadonly.h
Log Message:
-----------
Merge r180772 - Use NeverDestroyed for JS wrapper owners.
<https://webkit.org/b/142090>
Reviewed by Chris Dumez.
Using NeverDestroyed puts these objects in BSS which is preferable
since that prevents them from pinning down entire malloc pages forever.
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateHeader): Use NeverDestroyed instead of DEPRECATED_DEFINE_STATIC_LOCAL.
* bindings/scripts/test/JS/*: Rebaseline bindings tests for this change.
Commit: 76aab4ba43620cd37fc1215840bfc53713456bfe
https://github.com/WebKit/WebKit/commit/76aab4ba43620cd37fc1215840bfc53713456bfe
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc.xcodeproj/project.pbxproj
M Source/bmalloc/bmalloc/BoundaryTag.h
M Source/bmalloc/bmalloc/Deallocator.cpp
M Source/bmalloc/bmalloc/FreeList.cpp
M Source/bmalloc/bmalloc/FreeList.h
M Source/bmalloc/bmalloc/Heap.cpp
M Source/bmalloc/bmalloc/Heap.h
M Source/bmalloc/bmalloc/LargeObject.h
A Source/bmalloc/bmalloc/Owner.h
M Source/bmalloc/bmalloc/SegregatedFreeList.cpp
M Source/bmalloc/bmalloc/SegregatedFreeList.h
M Source/bmalloc/bmalloc/VMAllocate.h
M Source/bmalloc/bmalloc/VMHeap.cpp
M Source/bmalloc/bmalloc/VMHeap.h
Log Message:
-----------
Merge r180797 - bmalloc: Pathological madvise churn on the free(malloc(x)) benchmark
https://bugs.webkit.org/show_bug.cgi?id=142058
Reviewed by Andreas Kling.
The churn was caused by repeatedly splitting an object with physical
pages from an object without, and then merging them back together again.
The merge would conservatively forget that we had physical pages, forcing
a new call to madvise on the next allocation.
This patch more strictly segregates objects in the heap from objects in
the VM heap, with these changes:
(1) Objects in the heap are not allowed to merge with objects in the VM
heap, and vice versa -- since that would erase our precise knowledge of
which physical pages had been allocated.
(2) The VM heap is exclusively responsible for allocating and deallocating
physical pages.
(3) The heap free list must consider entries for objects that are in the
VM heap to be invalid, and vice versa. (This condition can arise
because the free list does not eagerly remove items.)
With these changes, we can know that any valid object in the heap's free
list already has physical pages, and does not need to call madvise.
Note that the VM heap -- as before -- might sometimes contain ranges
or pieces of ranges that have physical pages, since we allow splitting
of ranges at granularities smaller than the VM page size. These ranges
can eventually merge with ranges in the heap during scavenging.
* bmalloc.xcodeproj/project.pbxproj:
* bmalloc/BoundaryTag.h:
(bmalloc::BoundaryTag::owner):
(bmalloc::BoundaryTag::setOwner):
(bmalloc::BoundaryTag::initSentinel):
(bmalloc::BoundaryTag::hasPhysicalPages): Deleted.
(bmalloc::BoundaryTag::setHasPhysicalPages): Deleted. Replaced the concept
of "has physical pages" with a bit indicating which heap owns the large
object. This is a more precise concept, since the old bit was really a
Yes / Maybe bit.
* bmalloc/Deallocator.cpp:
* bmalloc/FreeList.cpp: Adopt
(bmalloc::FreeList::takeGreedy):
(bmalloc::FreeList::take):
(bmalloc::FreeList::removeInvalidAndDuplicateEntries):
* bmalloc/FreeList.h:
(bmalloc::FreeList::push): Added API for considering the owner when
deciding if a free list entry is valid.
* bmalloc/Heap.cpp:
(bmalloc::Heap::Heap): Adopt new API.
(bmalloc::Heap::scavengeLargeRanges): Scavenge all ranges with no minimum,
since some ranges might be able to merge with ranges in the VM heap, and
they won't be allowed to until we scavenge them.
(bmalloc::Heap::allocateSmallPage):
(bmalloc::Heap::allocateMediumPage):
(bmalloc::Heap::allocateLarge): New VM heap API makes this function
simpler, since we always get back physical pages now.
* bmalloc/Heap.h:
* bmalloc/LargeObject.h:
(bmalloc::LargeObject::end):
(bmalloc::LargeObject::owner):
(bmalloc::LargeObject::setOwner):
(bmalloc::LargeObject::isValidAndFree):
(bmalloc::LargeObject::merge): Do not merge objects across heaps since
that causes madvise churn.
(bmalloc::LargeObject::validateSelf):
(bmalloc::LargeObject::init):
(bmalloc::LargeObject::hasPhysicalPages): Deleted.
(bmalloc::LargeObject::setHasPhysicalPages): Deleted. Propogate the Owner API.
* bmalloc/Owner.h: Added.
* bmalloc/SegregatedFreeList.cpp:
(bmalloc::SegregatedFreeList::SegregatedFreeList):
(bmalloc::SegregatedFreeList::insert):
(bmalloc::SegregatedFreeList::takeGreedy):
(bmalloc::SegregatedFreeList::take):
* bmalloc/SegregatedFreeList.h: Propogate the owner API.
* bmalloc/VMAllocate.h:
(bmalloc::vmDeallocatePhysicalPagesSloppy):
(bmalloc::vmAllocatePhysicalPagesSloppy): Clarified these functions and
removed an edge case.
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::VMHeap):
* bmalloc/VMHeap.h:
(bmalloc::VMHeap::allocateSmallPage):
(bmalloc::VMHeap::allocateMediumPage):
(bmalloc::VMHeap::allocateLargeObject):
(bmalloc::VMHeap::deallocateLargeObject): Be sure to give each object
a new chance to merge, since it might have been prohibited from merging
before by virtue of not being in the VM heap.
(bmalloc::VMHeap::allocateLargeRange): Deleted.
(bmalloc::VMHeap::deallocateLargeRange): Deleted.
Commit: 1944558f0469c7b50f4051d926f2574ac67045bb
https://github.com/WebKit/WebKit/commit/1944558f0469c7b50f4051d926f2574ac67045bb
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-03-01 (Sun, 01 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
Log Message:
-----------
Merge r180846 - FrameView::layoutTimerFired() should update style if needed before doing layout
https://bugs.webkit.org/show_bug.cgi?id=141688
Reviewed by Andreas Kling.
If the style recalc timer has been scheduled to fire after the layout timer,
when the layout timer fires, we might as well just do the style recalc
too. The call to updateStyleIfNeeded() will cancel the pending style
recalc timer.
This doesn't have much impact on the number of layouts (measured via PLT)
but seems like a reasonable thing to do.
* page/FrameView.cpp:
(WebCore::FrameView::layoutTimerFired):
Commit: 7d5b9130a586d3a26a93119262c3798857de13f9
https://github.com/WebKit/WebKit/commit/7d5b9130a586d3a26a93119262c3798857de13f9
Author: Debarshi Ray <debarshir at gnome.org>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M ChangeLog
M Source/cmake/gtksymbols.filter
Log Message:
-----------
Merge r180884 - REGRESSION(r179409): [GTK] Undefined symbol prevents web extensions from being loaded
https://bugs.webkit.org/show_bug.cgi?id=142165
Patch by Debarshi Ray <debarshir at gnome.org> on 2015-03-02
Reviewed by Carlos Garcia Campos.
* Source/cmake/gtksymbols.filter:
Commit: 86d653eacc819f7c4d5ddfc9c55faa020986cf07
https://github.com/WebKit/WebKit/commit/86d653eacc819f7c4d5ddfc9c55faa020986cf07
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/FreeList.cpp
Log Message:
-----------
Merge r180908 - bmalloc: Eagerly remove allocated objects from the free list
https://bugs.webkit.org/show_bug.cgi?id=142194
Reviewed by Andreas Kling.
This reduces the pressure to garbage collect the free list.
Might be a 1% speedup on MallocBench.
* bmalloc/FreeList.cpp: Put this comment at the top of the file instead
of repeating it inside of each function. Tried to clarify the details.
(bmalloc::FreeList::takeGreedy): Matched the other iteration code in this
file for consistency -- even though either direction works fine in this
function.
(bmalloc::FreeList::take): Change to iterate from low to high so that we
can maintain an index into the vector that is not disturbed even if we
pop from the middle (which invalidates the last index in the vector).
Decrement i when popping from the middle to make sure that we don't
skip the next item after popping.
(bmalloc::FreeList::removeInvalidAndDuplicateEntries): Ditto.
Commit: 9fbeeb066efa530e16aa1188d173ce88a069a0b6
https://github.com/WebKit/WebKit/commit/9fbeeb066efa530e16aa1188d173ce88a069a0b6
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/DrawingArea.h
M Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp
M Source/WebKit2/WebProcess/WebPage/LayerTreeHost.h
M Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp
M Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.h
Log Message:
-----------
Merge r180924 - REGRESSION(r177075): WebProcess crashes when entering accelerating compositing mode before the WebView is realized
https://bugs.webkit.org/show_bug.cgi?id=142079
Reviewed by Žan Doberšek.
The problem is that the texture mapper and native window handler
are initialized when the LayerTreeHost is initialized, assuming
the UI process has already sent the native window handler to the
web process, but that doesn't always happen since we moved the
redirected window creation to realize in r177075.
* WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::nativeSurfaceHandleForCompositing): Deleted.
* WebProcess/WebPage/DrawingAreaImpl.cpp:
(WebKit::DrawingAreaImpl::enterAcceleratedCompositingMode): Call
LayerTreeHost::setNativeSurfaceHandleForCompositing if we
already have a native window handle at this point.
(WebKit::DrawingAreaImpl::setNativeSurfaceHandleForCompositing):
Call LayerTreeHost::setNativeSurfaceHandleForCompositing also when
not using threaded compositing.
* WebProcess/WebPage/LayerTreeHost.h:
* WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:
(WebKit::LayerTreeHostGtk::makeContextCurrent): Helper function to
ensure a context and making it current.
(WebKit::LayerTreeHostGtk::ensureTextureMapper): Ensure a texture
is created for the current context.
(WebKit::LayerTreeHostGtk::initialize): Use makeContextCurrent()
and ensureTextureMapper(), and remove the LayerTreeContext
initialization since that's is now always initialized in
setNativeSurfaceHandleForCompositing().
(WebKit::LayerTreeHostGtk::compositeLayersToContext): Use
makeContextCurrent() helper function and also call
ensureTextureMapper() just in case the texture could not be
created during initialization because the native window handle was
not yet available.
(WebKit::LayerTreeHostGtk::flushAndRenderLayers): Use makeContextCurrent().
(WebKit::LayerTreeHostGtk::setNativeSurfaceHandleForCompositing):
Initialize the LayerTreeContext.
(WebKit::LayerTreeHostGtk::glContext): Deleted.
* WebProcess/WebPage/gtk/LayerTreeHostGtk.h:
Commit: 67e6ac015fe5b70770f563d4f082f84c7e280234
https://github.com/WebKit/WebKit/commit/67e6ac015fe5b70770f563d4f082f84c7e280234
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestResources.cpp
M Tools/gtk/jhbuild.modules
Log Message:
-----------
Merge r180927 - [SOUP] Synchronous XMLHttpRequests can time out when we reach the max connections limit
https://bugs.webkit.org/show_bug.cgi?id=141508
Reviewed by Sergio Villar Senin.
Source/WebCore:
Use SOUP_MESSAGE_IGNORE_CONNECTION_LIMITS flag when loading a
synchronous message instead of increasing the maximum number of
connections allowed if the soup version is recent enough.
The current solution of increasing/decreasing the limits doesn't
always work, because connections are not marked as IDLE in libsoup
until the message is unqueued, but we don't wait for the message
to be unqueued to finish our loads in WebKit, we finish them as
soon as we have finished reading the stream. This causes that
synchronous loads keep blocked in the nested main loop until the
timeout of 10 seconds is fired and the load fails.
Also marked WebCoreSynchronousLoader class as final, the virtual
methods as override and removed the unsused method isSynchronousClient.
* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::createSoupMessageForHandleAndRequest):
(WebCore::WebCoreSynchronousLoader::WebCoreSynchronousLoader):
(WebCore::WebCoreSynchronousLoader::isSynchronousClient): Deleted.
(WebCore::WebCoreSynchronousLoader::didReceiveResponse):
(WebCore::WebCoreSynchronousLoader::didReceiveData):
(WebCore::WebCoreSynchronousLoader::didReceiveBuffer):
(WebCore::WebCoreSynchronousLoader::didFinishLoading):
(WebCore::WebCoreSynchronousLoader::didFail):
(WebCore::WebCoreSynchronousLoader::didReceiveAuthenticationChallenge):
(WebCore::WebCoreSynchronousLoader::shouldUseCredentialStorage):
Tools:
Add a unit test to check that synchronous XHRs load even if the
maximum connection limits are reached.
* TestWebKitAPI/Tests/WebKit2Gtk/TestResources.cpp:
(testWebViewSyncRequestOnMaxConns):
(serverCallback):
(beforeAll):
* gtk/jhbuild.modules: Bump libsoup version to 2.49.91.
Commit: 941f8d9fbb37cd80660be2d510fefdb372c3bca4
https://github.com/WebKit/WebKit/commit/941f8d9fbb37cd80660be2d510fefdb372c3bca4
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp
M Source/WebCore/platform/network/soup/SoupNetworkSession.cpp
Log Message:
-----------
Merge r180928 - [SOUP] Use SoupMessage::starting instead of SoupSession::request-started
https://bugs.webkit.org/show_bug.cgi?id=142164
Reviewed by Sergio Villar Senin.
SoupSession::request-started is deprecated in libsoup 2.50. Both
signals are equivalent, but SoupMessage::starting is also emitted
for resources loaded from the disk cache. This fixes web timing
calculations for cached resources, since we were not initializing
m_requestStart.
* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::startingCallback):
(WebCore::createSoupMessageForHandleAndRequest):
* platform/network/soup/SoupNetworkSession.cpp:
(WebCore::SoupNetworkSession::SoupNetworkSession):
Commit: 3f23cbafb73c55656b05ca2c62e8da5dde8f58df
https://github.com/WebKit/WebKit/commit/3f23cbafb73c55656b05ca2c62e8da5dde8f58df
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.7.91 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.7.91.
Commit: 48c8dfd15df7ba44920e047e4f3644dcf95be459
https://github.com/WebKit/WebKit/commit/48c8dfd15df7ba44920e047e4f3644dcf95be459
Author: Per Arne Vollan <peavo at outlook.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/CCallHelpers.h
Log Message:
-----------
Merge r180938 - [Win64] JSC compile error.
https://bugs.webkit.org/show_bug.cgi?id=142216
Patch by peavo at outlook.com <peavo at outlook.com> on 2015-03-03
Reviewed by Mark Lam.
There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
Commit: e354a55404099b064c8ef98d22ac2539be9bc6fb
https://github.com/WebKit/WebKit/commit/e354a55404099b064c8ef98d22ac2539be9bc6fb
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Heap.cpp
M Source/bmalloc/bmalloc/Heap.h
M Source/bmalloc/bmalloc/LargeObject.h
M Source/bmalloc/bmalloc/StaticMutex.h
M Source/bmalloc/bmalloc/Vector.h
Log Message:
-----------
Merge r180953 - bmalloc: Miscellaneous cleanup
https://bugs.webkit.org/show_bug.cgi?id=142231
Reviewed by Andreas Kling.
No performance change -- maybe a tiny reduction in memory use.
* bmalloc/Heap.cpp: Moved the sleep function into StaticMutex, since
it's a helper for working with mutexes.
(bmalloc::Heap::scavenge): Make sure to wait before we start any
scavenging, since individual scavenging functions now always scavenge
at least one page before waiting themselves.
(bmalloc::Heap::scavengeSmallPages):
(bmalloc::Heap::scavengeMediumPages):
(bmalloc::Heap::scavengeLargeObjects): Use the new wait helper to
simplify this code. Also, we now require our caller to wait until at
least one deallocation is desirable. This simplifies our loop.
(bmalloc::Heap::allocateSmallPage):
(bmalloc::Heap::allocateMediumPage):
(bmalloc::Heap::allocateXLarge):
(bmalloc::Heap::allocateLarge): Don't freak out any time the heap does
an allocation. Only consider the heap to be growing if it actually needs
to allocate new VM. This allows us to shrink the heap back down from a
high water mark more reliably even if heap activity continues.
(bmalloc::sleep): Deleted.
(bmalloc::Heap::scavengeLargeRanges): Renamed to match our use of
"LargeObject".
* bmalloc/Heap.h:
* bmalloc/LargeObject.h:
(bmalloc::LargeObject::operator bool): Added to simplify a while loop.
* bmalloc/StaticMutex.h:
(bmalloc::sleep):
(bmalloc::waitUntilFalse): New helper for waiting until a condition
becomes reliably false.
* bmalloc/Vector.h:
(bmalloc::Vector<T>::~Vector): Oops! Don't deallocate the null pointer.
We don't actually run any Vector destructors, but an iteration of this
patch did, and then crashed. So, let's fix that.
Commit: 84f84cde6e7f54d74d92a1ff85d194df3f6ded66
https://github.com/WebKit/WebKit/commit/84f84cde6e7f54d74d92a1ff85d194df3f6ded66
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/BoundaryTag.h
Log Message:
-----------
Merge r180964 - bmalloc: Don't branch when setting the owner of a large object
https://bugs.webkit.org/show_bug.cgi?id=142241
Reviewed by Andreas Kling.
* bmalloc/BoundaryTag.h:
(bmalloc::BoundaryTag::owner):
(bmalloc::BoundaryTag::setOwner):
Commit: a7f6203d06deabd6af55b81028dc33b040fb40d3
https://github.com/WebKit/WebKit/commit/a7f6203d06deabd6af55b81028dc33b040fb40d3
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/css/image-object-hover-inherit-expected.html
A LayoutTests/fast/css/image-object-hover-inherit.html
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLObjectElement.cpp
M Source/WebCore/html/HTMLPlugInImageElement.cpp
Log Message:
-----------
Merge r181168 - Setting any of the <object> element plugin controlling attributes does not have any affect.
https://bugs.webkit.org/show_bug.cgi?id=141936.
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-03-06
Reviewed by Simon Fraser.
Source/WebCore:
When setting any of the <object> element plugin controlling attributes
dynamically we need to mark the the element to be dirty by calling
setNeedsStyleRecalc(), so it has to recreate its renderer when needed.
Tests: fast/css/image-object-hover-inherit.html
svg/as-object/svg-in-object-dynamic-attribute-change.html
* dom/Element.h: Delete unimplemented function.
* html/HTMLObjectElement.cpp:
(WebCore::HTMLObjectElement::parseAttribute): Mark the element dirty by
calling setNeedsStyleRecalc() when one of the plugin controlling attributes
gets changed. We have to clear m_useFallbackContent because the attribute's
new value might fix the object rendering.
* html/HTMLObjectElement.h: Add a function to clear m_useFallbackContent.
LayoutTests:
* fast/css/image-object-hover-inherit-expected.html: Added.
* fast/css/image-object-hover-inherit.html: Added.
A guarding test to catch the case of reconstructing the image <object>
renderer while performing a synchronous resolveTree() followed by page
rendering or dump render tree.
* svg/as-object/resources/lime100x100.html: Added.
* svg/as-object/resources/lime100x100.png: Added.
* svg/as-object/resources/lime100x100.svg: Added.
* svg/as-object/resources/red100x100.svg: Added.
* svg/as-object/svg-in-object-dynamic-attribute-change-expected.html: Added.
* svg/as-object/svg-in-object-dynamic-attribute-change.html: Added.
Ensure that changing the 'type' and the 'data' attributes of the <object>
element will have the expected outcome. Also make sure that the <object>
element renderer falls back correctly when setting any of the attributes
to some unexpected value.
Commit: cf6ae29bab986435d108d3c47fc6ed5fa328e22c
https://github.com/WebKit/WebKit/commit/cf6ae29bab986435d108d3c47fc6ed5fa328e22c
Author: Philippe Normand <pnormand at igalia.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp
Log Message:
-----------
Merge r180997 - [GStreamer] the GST_SCHEDULING_FLAG_BANDWIDTH_LIMITED should be wrapped by a ifdef
https://bugs.webkit.org/show_bug.cgi?id=142274
Patch by Philippe Normand <pnormand at igalia.com> on 2015-03-04
Reviewed by Carlos Garcia Campos.
Don't handle scheduling queries if building against versions of
GStreamer older than 1.2.0.
* platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(webKitWebSrcQueryWithParent):
Commit: e115e24b2262458e0e60a882618a52cf49bcbbe6
https://github.com/WebKit/WebKit/commit/e115e24b2262458e0e60a882618a52cf49bcbbe6
Author: Debarshi Ray <debarshir at gnome.org>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitWebView.cpp
Log Message:
-----------
Merge r180998 - [GTK] WebView should hold a reference on WebContext because non-default contexts are a reality
https://bugs.webkit.org/show_bug.cgi?id=142225
Patch by Debarshi Ray <debarshir at gnome.org> on 2015-03-04
Reviewed by Carlos Garcia Campos.
Source/WebKit2:
* UIProcess/API/gtk/WebKitWebView.cpp:
(webkitWebViewRequestFavicon):
(webkitWebViewWatchForChangesInFavicon):
(webkitWebViewDisconnectFaviconDatabaseSignalHandlers):
(webkitWebViewConstructed):
(webkitWebViewGetProperty):
(webkitWebViewDispose):
(webkitWebViewLoadChanged):
(webkitWebViewLoadFailedWithTLSErrors):
(webkit_web_view_get_context):
(webkit_web_view_download_uri):
Tools:
* TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitWebView.cpp:
(testWebViewWebContextLifetime):
(beforeAll):
Commit: cdc82bd4db19ce175489477785eb1afeefd95515
https://github.com/WebKit/WebKit/commit/cdc82bd4db19ce175489477785eb1afeefd95515
Author: Dean Jackson <dino at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLPlugInImageElement.cpp
Log Message:
-----------
Merge r181038 - REGRESSION (r179597): Can't see power saver banner for plugins
https://bugs.webkit.org/show_bug.cgi?id=142312
<rdar://problem/20040517>
Reviewed by Brent Fulgham.
We were being a bit too restrictive when deciding a child
should not create a renderer. All shadow root children
of the snapshotted plugin need one.
* html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::childShouldCreateRenderer):
Test if we're part of the shadow tree.
Commit: ee1127f0852ad79db7fac812005323e1c0b77eea
https://github.com/WebKit/WebKit/commit/ee1127f0852ad79db7fac812005323e1c0b77eea
Author: Debarshi Ray <debarshir at gnome.org>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/JavaScriptCore/API/JSContextRef.h
M Source/JavaScriptCore/ChangeLog
Log Message:
-----------
Merge r181059 - Silence GCC's -Wstrict-prototypes
https://bugs.webkit.org/show_bug.cgi?id=142278
Patch by Debarshi Ray <debarshir at gnome.org> on 2015-03-04
Reviewed by Alexey Proskuryakov.
* API/JSContextRef.h:
Commit: 40d76e94fcec37552817613d72b7115533f9f882
https://github.com/WebKit/WebKit/commit/40d76e94fcec37552817613d72b7115533f9f882
Author: Andreas Kling <akling at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/heap/Heap.cpp
M Source/JavaScriptCore/heap/Heap.h
M Source/JavaScriptCore/heap/MachineStackMarker.cpp
M Source/JavaScriptCore/heap/MachineStackMarker.h
Log Message:
-----------
Merge r181060 - GC should compute stack bounds and dump registers at the earliest opportunity.
<https://webkit.org/b/142310>
<rdar://problem/20045624>
Reviewed by Geoffrey Garen.
Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
The wrapper function that grabs a snapshot of the current stack boundaries and register values
on entry, and sanitizes the stack on exit.
This is a speculative fix for what appears to be overly conservative behavior in the garbage
collector following r178364 which caused a measurable regression in memory usage on Membuster.
The theory being that we were putting pointers to dead things on the stack before scanning it,
and by doing that ended up marking things that we'd otherwise discover to be garbage.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::collect):
(JSC::Heap::collectImpl):
* heap/Heap.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
Commit: 73911753a0a24b435df61a24f9ae3d5a1302c4a3
https://github.com/WebKit/WebKit/commit/73911753a0a24b435df61a24f9ae3d5a1302c4a3
Author: Grzegorz Czajkowski <g.czajkowski at samsung.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/editing/Editor.cpp
M Source/WebCore/editing/TextCheckingHelper.cpp
M Source/WebCore/editing/TextCheckingHelper.h
Log Message:
-----------
Merge r181072 - TextCheckingParagraph::isEmpty() is sufficient to check whether paragraph is empty
https://bugs.webkit.org/show_bug.cgi?id=142276
Reviewed by Darin Adler.
TextCheckingParagraph::isEmpty() already calls TextCheckingParagraph::isRangeEmpty().
There is no need to call them both at the caller site.
No new tests. No behavior change.
* editing/Editor.cpp:
(WebCore::Editor::markAllMisspellingsAndBadGrammarInRanges):
Update caller site.
* editing/TextCheckingHelper.cpp:
(WebCore::TextCheckingParagraph::isEmpty):
Avoid using helepers here to get rid of them as they are
no longer needed outside TextCheckingParagraph.
* editing/TextCheckingHelper.h:
(WebCore::TextCheckingParagraph::isTextEmpty): Deleted.
(WebCore::TextCheckingParagraph::isRangeEmpty): Deleted.
Do not expose isTextEmpty() and isRangeEmpty().
Commit: 3f0c0c157612768a778cfc7eb3f5cfb9bf40ae94
https://github.com/WebKit/WebKit/commit/3f0c0c157612768a778cfc7eb3f5cfb9bf40ae94
Author: Michael Catanzaro <mcatanzaro at igalia.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/NetworkProcess/EntryPoint/unix/NetworkProcessMain.cpp
M Source/WebKit2/WebProcess/EntryPoint/unix/WebProcessMain.cpp
Log Message:
-----------
Merge r181073 - [SOUP] Disable RC4
https://bugs.webkit.org/show_bug.cgi?id=140014
Patch by Michael Catanzaro <mcatanzaro at igalia.com> on 2015-03-05
Reviewed by Carlos Garcia Campos.
Disallow RC4-based ciphersuites when performing TLS negotiation,
because it is no longer considered secure.
* NetworkProcess/EntryPoint/unix/NetworkProcessMain.cpp:
(main):
* WebProcess/EntryPoint/unix/WebProcessMain.cpp:
(main):
Commit: 6994ab8ddd6d26c04baa1aafab5d358294c836ad
https://github.com/WebKit/WebKit/commit/6994ab8ddd6d26c04baa1aafab5d358294c836ad
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestSSL.cpp
Log Message:
-----------
Merge r181074 - [SOUP] Check TLS errors as soon as they are set in the SoupMessage
https://bugs.webkit.org/show_bug.cgi?id=142244
Reviewed by Sergio Villar Senin.
Source/WebCore:
Connect to the notify::tls-errors signal of SoupMessage to cancel
the load earlier in case of TLS failure, preventing any private
data from being sent to the server before the TLS errors are checked.
* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::tlsErrorsChangedCallback):
(WebCore::gotHeadersCallback):
(WebCore::createSoupMessageForHandleAndRequest):
Tools:
Check that the SSL server doesn't process any request in case of
TLS errors when the policy is set to FAIL.
* TestWebKitAPI/Tests/WebKit2Gtk/TestSSL.cpp:
(testTLSErrorsPolicy):
(testTLSErrorsRedirect):
(testTLSErrorsHTTPAuth):
(testLoadFailedWithTLSErrors):
(testSubresourceLoadFailedWithTLSErrors):
(httpsServerCallback):
Commit: b366b244710dc886e3462f9217a0f2ae4bb74d47
https://github.com/WebKit/WebKit/commit/b366b244710dc886e3462f9217a0f2ae4bb74d47
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestResources.cpp
Log Message:
-----------
Merge r181075 - Unreviewed. Fix /webkit2/WebKitWebResource/mime-type after r180927.
In r180927 we updated the libsoup version used by the jhbuild. In
this new version the sniffer uses image/x-icon instead of
image/vnd.microsoft.icon for blank.ico resource.
* TestWebKitAPI/Tests/WebKit2Gtk/TestResources.cpp:
(testWebResourceMimeType):
Commit: b1d434e8ed09cced36c8e4efa406efaca4675516
https://github.com/WebKit/WebKit/commit/b1d434e8ed09cced36c8e4efa406efaca4675516
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/js/script-tests/string-includes.js
M LayoutTests/js/string-includes-expected.txt
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/StringPrototype.cpp
M Source/WTF/ChangeLog
M Source/WTF/wtf/text/StringImpl.cpp
M Source/WTF/wtf/text/StringImpl.h
M Source/WTF/wtf/text/WTFString.h
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WTF/WTFString.cpp
Log Message:
-----------
Merge r181105 - Regression(r173761): ASSERTION FAILED: !is8Bit() in StringImpl::characters16()
https://bugs.webkit.org/show_bug.cgi?id=142350
Patch by Chris Dumez <cdumez at apple.com> on 2015-03-05
Reviewed by Michael Saboff and Benjamin Poulain.
Source/JavaScriptCore:
Call WTFString::hasInfixStartingAt() / hasInfixEndingAt() now that these
methods have been renamed for clarity.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
Source/WTF:
Fix ASSERTION FAILED: !is8Bit() in StringImpl::characters16() from
WTF::equalInner() after r173761. The code was incorrectly assuming that
if stringImpl is 16-bit, then matchString is 16-bit too, which is not
correct.
Also rename WTFString::startsWith() / endsWith() taking an offset to
hasInfixStartingAt() / hasInfixEndingAt() for clarity. It seems odd
to call it startsWith even though it won't technically *start* with
the pattern if the input offset is greater than zero.
Also drop the caseSensitive argument as it is never used (always true
at call sites.
* wtf/text/StringImpl.cpp:
(WTF::equalInner):
(WTF::StringImpl::hasInfixStartingAt):
(WTF::StringImpl::hasInfixEndingAt):
(WTF::StringImpl::startsWith): Deleted.
(WTF::StringImpl::endsWith): Deleted.
* wtf/text/StringImpl.h:
* wtf/text/WTFString.h:
(WTF::String::hasInfixStartingAt):
(WTF::String::hasInfixEndingAt):
(WTF::String::startsWith): Deleted.
(WTF::String::endsWith): Deleted.
Tools:
Add API test for WTFString::hasInfixStartingAt() to make sure it doesn't
crash if the string is 8-bit but the pattern is 16-bit (and vice-versa).
* TestWebKitAPI/Tests/WTF/WTFString.cpp:
(TestWebKitAPI::TEST):
LayoutTests:
Update String.startsWith() / endsWith() test to cover cases where the
input string is 8-bit and the pattern is 16-bit, and vice-versa.
* js/script-tests/string-includes.js:
* js/string-includes-expected.txt:
Commit: 12b7fad2273f180d1a89a00d33f8eae632002a6b
https://github.com/WebKit/WebKit/commit/12b7fad2273f180d1a89a00d33f8eae632002a6b
Author: Sandy Perez <sperez at indaba.es>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/cpu/arm/filters/FEBlendNEON.h
M Source/WebCore/platform/graphics/filters/FEGaussianBlur.cpp
Log Message:
-----------
Merge r181110 - Fix the build when NEON_INTRINSICS is enabled
https://bugs.webkit.org/show_bug.cgi?id=142361
Patch by Sandy Perez <sperez at indaba.es> on 2015-03-05
Reviewed by Csaba Osztrogonác.
* platform/graphics/cpu/arm/filters/FEBlendNEON.h:
(WebCore::FEBlend::platformApplySoftware):
* platform/graphics/filters/FEGaussianBlur.cpp:
(WebCore::standardBoxBlur):
Commit: 158c6e941058be995a20af091c3586a194682288
https://github.com/WebKit/WebKit/commit/158c6e941058be995a20af091c3586a194682288
Author: Commit Queue <commit-queue at webkit.org>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
Log Message:
-----------
Merge r181111 - Unreviewed, rolling out r180846.
https://bugs.webkit.org/show_bug.cgi?id=142368
Caused missing image banners in iTunes store pages (Requested
by smfr on #webkit).
Reverted changeset:
"FrameView::layoutTimerFired() should update style if needed
before doing layout"
https://bugs.webkit.org/show_bug.cgi?id=141688
http://trac.webkit.org/changeset/180846
Commit: 1c3d46704b2ba3032c701f574e536d16d95f679c
https://github.com/WebKit/WebKit/commit/1c3d46704b2ba3032c701f574e536d16d95f679c
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Merge r181133 - Document::recalcStyle() shouldn't call viewportContentsChanged() if there is a pending layout
https://bugs.webkit.org/show_bug.cgi?id=142140
Reviewed by Darin Adler.
Stop calling FrameView::viewportContentsChanged() in Document::recalcStyle()
if there is a layout pending to avoid doing unncessary work. If there is a
layout pending, we don't need to do anything because viewportContentsChanged()
will be called after layout.
We only need to call FrameView::viewportContentsChanged() in
Document::recalcStyle() if a style recalc does not cause a layout. For e.g.
a '-webkit-transform' could make an animated GIF visible without causing a
layout, in which case we need to resume the animated GIF after style recalc.
No new tests, already covered by:
fast/images/animated-gif-webkit-transform.html
* dom/Document.cpp:
(WebCore::Document::recalcStyle):
Commit: 258f85b143d927b8f701fc17a6728ebe6bd6ffef
https://github.com/WebKit/WebKit/commit/258f85b143d927b8f701fc17a6728ebe6bd6ffef
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp
M Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.h
Log Message:
-----------
Merge r181138 - REGRESSION(r180924): ASSERTION FAILED: !from.isEmpty() in WebCore::TransformationMatrix::rectToRect
https://bugs.webkit.org/show_bug.cgi?id=142345
Reviewed by Martin Robinson.
This was caused by r180924 that postpones the creation of the
TextureMapper, which could cause that a layer has not yet a size
when TextureMapper::paint() is called. This patch moves the
creation of the TextureMapper to
LayerTreeHostGtk::setNativeSurfaceHandleForCompositing(), so that
it's created as soon as it's possible to create. This method is
called by the drawing area right after creating the
LayerTreeHostGtk if it already have a handler, or when the handle
is received from the UI process.
* WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:
(WebKit::LayerTreeHostGtk::initialize): Remove the
nsureTextureMapper call because at this point the layer context ID
is always 0, so it's impossible to create the TextureMapper.
(WebKit::LayerTreeHostGtk::compositeLayersToContext): Remove the
ensureTextureMapper call from here too, since at this point, if we
have a context, we should also have a TextureMapper. Add an ASSERT
right before using the TextureMapper.
(WebKit::LayerTreeHostGtk::setNativeSurfaceHandleForCompositing):
Create the TextureMapper here.
(WebKit::LayerTreeHostGtk::ensureTextureMapper): Deleted.
* WebProcess/WebPage/gtk/LayerTreeHostGtk.h:
Commit: 9179d94b4737ca0ab2c9d6f05bd5f5ce65dc41bc
https://github.com/WebKit/WebKit/commit/9179d94b4737ca0ab2c9d6f05bd5f5ce65dc41bc
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestResources.cpp
Log Message:
-----------
Merge r181159 - [GTK] Test /webkit2/WebKitWebView/sync-request-on-max-conns might fail after finished
https://bugs.webkit.org/show_bug.cgi?id=142385
Reviewed by Sergio Villar Senin.
Use stack allocated GMainLoopSources to make sure they are
cancelled automatically if the test finishes before they have
been processed.
* TestWebKitAPI/Tests/WebKit2Gtk/TestResources.cpp:
(testWebViewSyncRequestOnMaxConns):
Commit: f531ec1d043d7615cb81eec53d98791bc4aadb10
https://github.com/WebKit/WebKit/commit/f531ec1d043d7615cb81eec53d98791bc4aadb10
Author: Brent Fulgham <bfulgham at webkit.org>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/css3/scroll-snap/scroll-snap-desination-lock-up-expected.txt
A LayoutTests/css3/scroll-snap/scroll-snap-desination-lock-up.html
M Source/WebCore/ChangeLog
M Source/WebCore/page/scrolling/AxisScrollSnapOffsets.cpp
Log Message:
-----------
Merge r181194 - Setting scroll-snap-desination to (100% 100%) locks up WebKit
https://bugs.webkit.org/show_bug.cgi?id=142414
<rdar://problem/20077275>
Reviewed by Dean Jackson.
Source/WebCore:
Tested by css3/scroll-snap/scroll-snap-desination-lock-up.html.
Correct an infinite loop that is triggered when you combine a repeating (100%)
scroll-snap-point-{x,y} along with a 100% scroll-snap-destination value.
* page/scrolling/AxisScrollSnapOffsets.cpp:
(WebCore::updateFromStyle): Make sure we break out of the loop properly when
the scroll-snap-point-{x,y} step is the same as the scroll-snap-destination.
LayoutTests:
* css3/scroll-snap/scroll-snap-desination-lock-up.html: Added.
* css3/scroll-snap/scroll-snap-desination-lock-up-expected.txt: Added.
Commit: 52355701b89150483a72a115b4cabc5bbc64e10c
https://github.com/WebKit/WebKit/commit/52355701b89150483a72a115b4cabc5bbc64e10c
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-03-08 (Sun, 08 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/notifications/NotificationCenter.cpp
Log Message:
-----------
Merge r181219 - Crash in WebCore::NotificationCenter::stop()
https://bugs.webkit.org/show_bug.cgi?id=142444
<rdar://problem/20082520>
Reviewed by Andreas Kling.
A use-after-free would sometimes cause us to crash in NotificationCenter::stop().
After investigation, it turns out that NotificationCenter::stop() calls
NotificationClient::clearNotifications() which will destroy the Notification
objects, all of which hold a strong reference to the NotificationCenter. If at
this point, only Notifications are ref'ing the NotificationCenter, this means
that the NotificationCenter will get destroyed right after the call to
NotificationClient::clearNotifications(). However, we reset m_client to null
after calling clearNotifications() and it causes us to crash in this case.
The issue is addressed by adding a Ref<NotificationCenter> protector in
NotificationCenter::stop() so that we make sure the NotificationCenter lives
at least until the end of the method execution.
I was able to consistently reproduce the crash by doing:
Tools/Scripts/run-webkit-tests -1 --debug --repeat-each=30 -g http/tests/notifications/event-listener-crash.html
No new tests, already covered by:
http/tests/notifications/event-listener-crash.html
* Modules/notifications/NotificationCenter.cpp:
(WebCore::NotificationCenter::stop):
Commit: a45d6feff78c9046965bce6300f6298650034053
https://github.com/WebKit/WebKit/commit/a45d6feff78c9046965bce6300f6298650034053
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-03-09 (Mon, 09 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/notifications/NotificationCenter.cpp
Log Message:
-----------
Merge r181256 - Crash in WebCore::NotificationCenter::stop()
https://bugs.webkit.org/show_bug.cgi?id=142444
<rdar://problem/20082520>
Reviewed by Darin Adler.
Rework the patch in r181219 so that we do not need a Ref<NotificationCenter> protector
in NotificationCenter::stop(). Instead, we put the client in a local variable and null
out m_client *before* calling NotificationClient::clearNotifications().
No new tests, already covered by:
http/tests/notifications/event-listener-crash.html
* Modules/notifications/NotificationCenter.cpp:
(WebCore::NotificationCenter::stop):
Commit: b9b0f60dddc628441ba800eaf8c2cdf6cb67bc30
https://github.com/WebKit/WebKit/commit/b9b0f60dddc628441ba800eaf8c2cdf6cb67bc30
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/ShareableBitmap.cpp
M Source/WebKit2/Shared/ShareableBitmap.h
M Source/WebKit2/WebProcess/Plugins/PluginProxy.cpp
Log Message:
-----------
Merge r181272 - bmalloc: tryFastMalloc shouldn't crash
https://bugs.webkit.org/show_bug.cgi?id=142443
Reviewed by Anders Carlsson.
Part 1: Stop using tryFastRealloc.
* Shared/ShareableBitmap.cpp:
(WebKit::ShareableBitmap::resize): Deleted.
* Shared/ShareableBitmap.h: Removed the resize function because it has
no clients.
* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::updateBackingStore): Changed to allocate a new
backing store instead of resizing the old one. This has three advantages:
(1) Might be more memory-efficient, since you don't have to keep the old
one around while allocating the new one.
(2) Avoids the overhead of realloc() copying the contents of the old
backing store even though we only want uninitialized memory.
(3) Makes resize failure consistent with initial allocation failure.
Previously, while initial allocation failure would set the backing store
to null, resize failure would keep the old wrong backing store and then
tell it not to paint. Now, resize failure also sets the backing store to
null.
Commit: e65b484178d479178191df4f8ba479a7ae55361a
https://github.com/WebKit/WebKit/commit/e65b484178d479178191df4f8ba479a7ae55361a
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/css3/flexbox/child-overflow-expected.html
M LayoutTests/css3/flexbox/child-overflow.html
A LayoutTests/fast/css/inline-block-tricky-baselines-expected.html
A LayoutTests/fast/css/inline-block-tricky-baselines.html
M LayoutTests/fast/forms/textfield-overflow-by-value-update-expected.txt
A LayoutTests/fast/text/baseline-inline-block-expected.html
A LayoutTests/fast/text/baseline-inline-block.html
M LayoutTests/platform/mac-mavericks/fast/forms/search-vertical-alignment-expected.txt
M LayoutTests/platform/mac/fast/forms/search-vertical-alignment-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Merge r181292 - REGRESSION(r176978): Inline-blocks with overflowing contents have ascents that are too large
https://bugs.webkit.org/show_bug.cgi?id=141783
Reviewed by David Hyatt.
Source/WebCore:
When we have an inline-block element, and we want to find its baseline (to lay out other
elements on the same line) we loop through the element's children and ask them what their
baselines are. The children use the location of the top of their last line to compute this
value. However, if the child has overflow-y, this might not be the correct calculation.
This behavior is in the spec: "The baseline of an 'inline-block' is the baseline of its last
line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow'
property has a computed value other than 'visible', in which case the baseline is the bottom
margin edge."
-- http://www.w3.org/TR/CSS21/visudet.html#leading
However, we believe that a better policy is, when overflow is not "visible," to place the
baseline at the bottom of the block if the contents overflowed in the Y direction, and to place
it at the bottom of the last line if the contents did not overflow in the Y direction. This is
partially consistent with previous behavior, and isn't too far from the spec to cause too many
breakages.
Test: fast/css/inline-block-tricky-baselines.html
fast/text/baseline-inline-block.html
* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::inlineBlockBaseline):
LayoutTests:
Update expected results.
* css3/flexbox/child-overflow-expected.html:
* css3/flexbox/child-overflow.html:
* fast/css/inline-block-tricky-baselines-expected.html: Added.
* fast/css/inline-block-tricky-baselines.html: Added.
* fast/forms/textfield-overflow-by-value-update-expected.txt:
* fast/text/baseline-inline-block-expected.html: Added.
* fast/text/baseline-inline-block.html: Added.
* platform/mac/fast/forms/search-vertical-alignment-expected.txt:
Commit: 58e8f232c81def1ed9b22b401febe3c22128995f
https://github.com/WebKit/WebKit/commit/58e8f232c81def1ed9b22b401febe3c22128995f
Author: Andreas Kling <akling at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/JavaScriptCore/API/JSWeakObjectMapRefInternal.h
M Source/JavaScriptCore/API/JSWeakObjectMapRefPrivate.cpp
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/JavaScriptCore/heap/Heap.cpp
M Source/JavaScriptCore/heap/Heap.h
M Source/JavaScriptCore/heap/HeapInlines.h
M Source/JavaScriptCore/runtime/JSCInlines.h
M Source/JavaScriptCore/runtime/JSGlobalObject.cpp
M Source/JavaScriptCore/runtime/JSString.cpp
M Source/JavaScriptCore/runtime/PrototypeMap.cpp
M Source/JavaScriptCore/runtime/PrototypeMap.h
M Source/JavaScriptCore/runtime/Structure.cpp
M Source/JavaScriptCore/runtime/VM.cpp
M Source/JavaScriptCore/runtime/WeakGCMap.h
A Source/JavaScriptCore/runtime/WeakGCMapInlines.h
A Source/WebCore/ForwardingHeaders/runtime/WeakGCMapInlines.h
M Source/WebCore/bindings/js/ScriptCachedFrameData.cpp
Log Message:
-----------
Merge r181297 - Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
<https://webkit.org/b/142115>
<rdar://problem/19992268>
Reviewed by Geoffrey Garen.
Prune stale entries from WeakGCMaps as part of every full garbage collection.
This frees up tons of previously-stuck WeakBlocks that were only sitting around
with finalized handles waiting to die.
Note that WeakGCMaps register/unregister themselves with the GC heap in their
ctor/dtor, so creating one now requires passing the VM.
Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
It seems somewhat excessive to do this on every Eden collection, so it's only
doing work in full collections for now.
Because the GC may now mutate WeakGCMap below object allocation, I've made it
so that the classic HashMap::add() optimization can't be used with WeakGCMap.
This caused intermittent test failures when originally landed due to having
an invalid iterator on the stack after add() inserted a new entry and we
proceeded to allocate the new object, triggering GC.
* API/JSWeakObjectMapRefInternal.h:
(OpaqueJSWeakObjectMap::create):
(OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
* API/JSWeakObjectMapRefPrivate.cpp:
* API/JSWrapperMap.mm:
(-[JSWrapperMap initWithContext:]):
(-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
* JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
it project-private so WebCore clients can access it.
* heap/Heap.cpp:
(JSC::Heap::collect):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
stale entries from WeakGCMaps. This is only executed during full collections.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::registerWeakGCMap):
(JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
themselves with the Heap and provide a pruning callback.
* runtime/PrototypeMap.h:
(JSC::PrototypeMap::PrototypeMap):
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
* runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
* runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
* runtime/JSString.cpp:
(JSC::jsStringWithCacheSlowCase):
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::addPrototype):
(JSC::PrototypeMap::emptyObjectStructureForPrototype): Remove HashMap add()
optimization since it's not safe in the GC-managed WeakGCMap world.
* runtime/VM.cpp:
(JSC::VM::VM): Pass VM to WeakGCMap constructor.
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::set):
(JSC::WeakGCMap::add):
(JSC::WeakGCMap::WeakGCMap): Deleted.
(JSC::WeakGCMap::gcMap): Deleted.
(JSC::WeakGCMap::gcMapIfNeeded): Deleted.
* runtime/WeakGCMapInlines.h: Added.
(JSC::WeakGCMap::WeakGCMap):
(JSC::WeakGCMap::~WeakGCMap):
(JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
prunes WeakGCMap at certain growth milestones and instead rely on the GC
callback for housekeeping.
Commit: f1eda77f5a423466ad2c68c3a4dd3bd8124d5f94
https://github.com/WebKit/WebKit/commit/f1eda77f5a423466ad2c68c3a4dd3bd8124d5f94
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
A Source/JavaScriptCore/API/tests/CompareAndSwapTest.cpp
M Source/JavaScriptCore/API/tests/testapi.c
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/JavaScriptCore.vcxproj/testapi/testapi.vcxproj
M Source/JavaScriptCore/JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/WTF/ChangeLog
M Source/WTF/wtf/Atomics.h
Log Message:
-----------
Merge r181305 - 8-bit version of weakCompareAndSwap() can cause an infinite loop.
https://webkit.org/b/142513>
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Added a test that exercises the 8-bit CAS from multiple threads. The threads
will contend to set bits in a large array of bytes using the CAS function.
* API/tests/CompareAndSwapTest.cpp: Added.
(Bitmap::Bitmap):
(Bitmap::numBits):
(Bitmap::clearAll):
(Bitmap::concurrentTestAndSet):
(setBitThreadFunc):
(testCompareAndSwap):
* API/tests/testapi.c:
(main):
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
Source/WTF:
Presently, Bitmap::concurrentTestAndSet() uses the 8-bit version of
weakCompareAndSwap() (which compares and swaps an uint8_t value).
Bitmap::concurrentTestAndSet() has a loop that checks if a bit in the
byte of interest has been set. If not, it will call the 8-bit CAS
function to set the bit.
Under the covers, for ARM, the 8-bit CAS function actually works with a
32-bit CAS. The 8-bit CAS will first fetch the 32-bit value in memory
that should contain the 8-bit value, and check if it contains the
expected byte. If the value in memory doesn't have the expected byte,
it will return early to its caller. The expectation is that the caller
will reload the byte from memory and call the 8-bit CAS again.
Unfortunately, this code path that returns early does not have a
compiler fence. Without a compiler fence, the C++ compiler can
optimize away the reloading of the expected byte value, leaving it
unchanged. As a result, we'll have a infinite loop here that checks a
value that will never change, and the loop will not terminate until the
value changes.
The fix is to eliminate the early return check in the 8-bit CAS, and
have it always call down to the 32-bit CAS. The 32-bit CAS has a
compiler fence which will prevent this issue.
* wtf/Atomics.h:
(WTF::weakCompareAndSwap):
Commit: 30c1c6b36458ff660000a333cf0498792bb4f2ef
https://github.com/WebKit/WebKit/commit/30c1c6b36458ff660000a333cf0498792bb4f2ef
Author: Darin Adler <darin at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/WTF.vcxproj/WTF.vcxproj
M Source/WTF/WTF.vcxproj/WTF.vcxproj.filters
M Source/WTF/WTF.xcodeproj/project.pbxproj
M Source/WTF/wtf/CMakeLists.txt
M Source/WTF/wtf/FastMalloc.h
R Source/WTF/wtf/PossiblyNull.h
Log Message:
-----------
Merge r180814 - Remove unused PossiblyNull
https://bugs.webkit.org/show_bug.cgi?id=142124
Reviewed by Andreas Kling.
* WTF.vcxproj/WTF.vcxproj: Removed the file.
* WTF.vcxproj/WTF.vcxproj.filters: Ditto.
* WTF.xcodeproj/project.pbxproj: Ditto.
* wtf/CMakeLists.txt: Ditto.
* wtf/PossiblyNull.h: Removed.
* wtf/FastMalloc.h: Moved everything to the left.
Moved member functions out of the TryMallocReturnValue class definition.
(WTF::TryMallocReturnValue::operator PossiblyNull<T>): Deleted.
(WTF::TryMallocReturnValue::getValue): Marked inline, changed to work
only with pointer types, not arbitrary non-pointer types.
Commit: 1c0687a9f50b3b8f379e0aebff36c2c0776ba57f
https://github.com/WebKit/WebKit/commit/1c0687a9f50b3b8f379e0aebff36c2c0776ba57f
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/FastMalloc.cpp
M Source/WTF/wtf/FastMalloc.h
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Allocator.cpp
M Source/bmalloc/bmalloc/Allocator.h
M Source/bmalloc/bmalloc/Cache.cpp
M Source/bmalloc/bmalloc/Cache.h
M Source/bmalloc/bmalloc/Heap.cpp
M Source/bmalloc/bmalloc/Heap.h
M Source/bmalloc/bmalloc/VMAllocate.h
M Source/bmalloc/bmalloc/bmalloc.h
Log Message:
-----------
Merge r181329 - bmalloc: tryFastMalloc shouldn't crash
https://bugs.webkit.org/show_bug.cgi?id=142443
Reviewed by Darin Adler.
Source/bmalloc:
Added support for tryMalloc.
We assume that non-x-large allocations always succeed, and we crash
otherwise, since normal allocation failure will just cause the next
non-try allocation or internal metadata allocation to fail, and it's
hard and not really useful to keep limping along after that. But
extra-large allocations can meaningfully fail, and we can recover.
* bmalloc/Heap.cpp:
(bmalloc::Heap::allocateXLarge):
(bmalloc::Heap::tryAllocateXLarge):
* bmalloc/Heap.h: Added support for non-crashy x-large allocation.
* bmalloc/VMAllocate.h:
(bmalloc::tryVMAllocate):
(bmalloc::vmAllocate): Added support for non-crashy VM allocation.
* bmalloc/bmalloc.h:
(bmalloc::api::tryMalloc):
(bmalloc::api::realloc):
(bmalloc::api::free): Tried to clarify our behavior with some comments.
Unfortunately, calling what we do "malloc" is still not quite right, since
malloc returns null on failure and we don't.
Source/WTF:
* wtf/FastMalloc.cpp:
(WTF::fastMalloc):
(WTF::fastRealloc):
(WTF::fastAlignedMalloc): Don't check for null. bmalloc automatically
crashes on allocation failure, and we'd rather not pay for an extra check.
(WTF::tryFastMalloc): Added an opt-out API to return null rather than
crashing, since some clients need this.
(WTF::tryFastRealloc): Deleted. Unused.
* wtf/FastMalloc.h:
Commit: c7edf1ec10c58f3bd64c5cd925d73deef29d9424
https://github.com/WebKit/WebKit/commit/c7edf1ec10c58f3bd64c5cd925d73deef29d9424
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSPrimitiveValue.cpp
M Source/WebCore/css/makeprop.pl
Log Message:
-----------
Merge r181320 - Shrink the CSSPropertyID enum type
https://bugs.webkit.org/show_bug.cgi?id=142456
Reviewed by Sam Weinig.
Specify uint16_t as the base type for the CSSPropertyID enum.
This is enough to cover all of the CSS properties (429 at this moment,
with static_assert covering future changes). It halves the enum type size,
from 4 bytes to 2, reducing the size of various CSSPropertyID containers.
No new tests -- no change in behavior.
* css/CSSPrimitiveValue.cpp:
(WebCore::propertyName): Remove the unnecessary propertyID < 0 check.
* css/makeprop.pl:
Commit: 76b48c7fc229c864d16cff50651bfd95997824fe
https://github.com/WebKit/WebKit/commit/76b48c7fc229c864d16cff50651bfd95997824fe
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M ChangeLog
M Source/WebCore/ChangeLog
M Source/WebCore/PlatformGTK.cmake
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r181321 - [GTK] Add a configure option to build with OpenGL ES 2
https://bugs.webkit.org/show_bug.cgi?id=142498
Patch by Carlos Garcia Campos <cgarcia at igalia.com> and José Dapena Paz <jdapena at igalia.com> on 2015-03-10
Reviewed by Martin Robinson.
.:
Add ENABLE_GLES2 option. It's disabled by default, but if passed
GLES2 is required and OpenGL is not even searched. Otherwise we
search for OpenGL as usual, using it only if present.
* Source/cmake/OptionsGTK.cmake:
Source/WebCore:
Build GLES or GL specific files depending on the build options.
* PlatformGTK.cmake:
Commit: 540c5af12becbcca9bc9541a6deb8fa8986d5dcd
https://github.com/WebKit/WebKit/commit/540c5af12becbcca9bc9541a6deb8fa8986d5dcd
Author: José Dapena Paz <jdapena at igalia.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/GLContext.cpp
Log Message:
-----------
Merge r181322 - Unreviewed. Fix GTK+ build with OpenGL ES 2 enabled.
Remove USE(OPENGL) ifdef from GLContext.cpp, since there's nothing
specific to OpenGL in that file, and everything depending on
configure options is already protected by USE(GLX) and USE(EGL)
ifdefs. This is causing linking issues when building with OpenGL
ES 2, because the header doesn't have the ifdef, and the cpp file
is not compiled leaving all the interface undefined.
Patch by José Dapena Paz <jdapena at igalia.com> on 2015-03-10
Rubber-stamped by Carlos Garcia Campos.
* platform/graphics/GLContext.cpp:
Commit: 85860584bc42ed4c741aaecdcf5be5462d494921
https://github.com/WebKit/WebKit/commit/85860584bc42ed4c741aaecdcf5be5462d494921
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp
Log Message:
-----------
Merge r181323 - [GTK] GL_MAX_VARYING_FLOATS is not defined in OpenGL ES 2
https://bugs.webkit.org/show_bug.cgi?id=142529
Reviewed by Žan Doberšek.
Do not use GL_MAX_VARYING_FLOATS when platform is GTK+ and using
OpenGL ES 2.
* platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp:
(WebCore::GraphicsContext3D::checkVaryingsPacking):
Commit: 4540a277456504e8ce49575c8b9670aab5edfaed
https://github.com/WebKit/WebKit/commit/4540a277456504e8ce49575c8b9670aab5edfaed
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
M Source/WebKit2/UIProcess/DrawingAreaProxyImpl.h
Log Message:
-----------
Merge r181324 - [GTK] Contents not shown when entering AC mode unless the window is resized
https://bugs.webkit.org/show_bug.cgi?id=142347
Reviewed by Žan Doberšek.
The problem is once again that we are now creating the redirected
X window in realize method. When entering AC mode we resize the
redirected window to the drawing area size. Since the size hasn't
changed from the drawing area point of view, the web process is
not notified. The WebProcess always uses the window size, instead
of the root layer size, to make sure it's in sync, see the comment
in LayerTreeHostGtk::compositeLayersToContext(). So, we need to
enforce a resize when we change the size of the redirected window
when entering AC mode.
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseEnterAcceleratedCompositingMode):
* UIProcess/DrawingAreaProxyImpl.h:
(WebKit::DrawingAreaProxyImpl::forceResize):
Commit: fe7f84d9708b56fff34e1084cfe89c205da890cc
https://github.com/WebKit/WebKit/commit/fe7f84d9708b56fff34e1084cfe89c205da890cc
Author: Michael Catanzaro <mcatanzaro at igalia.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jsc.cpp
M Source/WTF/ChangeLog
M Source/WTF/wtf/Assertions.cpp
M Source/WTF/wtf/Assertions.h
Log Message:
-----------
Merge r181326 - GCC: CRASH() should be annotated with NORETURN
https://bugs.webkit.org/show_bug.cgi?id=142524
Patch by Michael Catanzaro <mcatanzaro at igalia.com> on 2015-03-10
Reviewed by Anders Carlsson.
Source/JavaScriptCore:
Don't return from a NORETURN function. This used to avoid a warning from GCC, but now it
causes one.
* jsc.cpp:
Source/WTF:
Add COMPILER(GCC) to #ifdefs that already exist for Clang.
* wtf/Assertions.cpp:
* wtf/Assertions.h:
Commit: ca2cc1c20fcdbae458187fe60719910adb80cc63
https://github.com/WebKit/WebKit/commit/ca2cc1c20fcdbae458187fe60719910adb80cc63
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-11 (Wed, 11 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/JIT.cpp
M Source/JavaScriptCore/jit/JITInlines.h
M Source/JavaScriptCore/jit/SlowPathCall.h
M Source/JavaScriptCore/yarr/Yarr.h
Log Message:
-----------
Merge r181343 - Use std::numeric_limits<unsigned>::max() instead of (unsigned)-1.
<https://webkit.org/b/142539>
Reviewed by Benjamin Poulain.
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::privateCompile):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JITInlines.h:
(JSC::JIT::emitNakedCall):
(JSC::JIT::addSlowCase):
(JSC::JIT::addJump):
(JSC::JIT::emitJumpSlowToHot):
(JSC::JIT::emitGetVirtualRegister):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
* yarr/Yarr.h:
Commit: 6a218c16dbf9312cdd72d2d420c904d8eb90a7de
https://github.com/WebKit/WebKit/commit/6a218c16dbf9312cdd72d2d420c904d8eb90a7de
Author: Carlos Alberto Lopez Perez <clopez at igalia.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/PlatformEfl.cmake
M Source/WebCore/PlatformGTK.cmake
Log Message:
-----------
Merge r181385 - [CMake][GStreamer] Building EFL or GTK with ENABLE_VIDEO and without ENABLE_WEB_AUDIO is broken.
https://bugs.webkit.org/show_bug.cgi?id=142577
Reviewed by Carlos Garcia Campos.
No new tests, this is a build fix.
* PlatformEfl.cmake: Include GSTREAMER_AUDIO_LIBRARIES on the link step both for ENABLE_VIDEO and ENABLE_WEB_AUDIO.
* PlatformGTK.cmake: Idem.
Commit: 1d714426122b01be0dab735ae3080c376f81e625
https://github.com/WebKit/WebKit/commit/1d714426122b01be0dab735ae3080c376f81e625
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/baseline-inline-block-block-children-expected.html
A LayoutTests/fast/text/baseline-inline-block-block-children.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Merge r181387 - Inline block children do not have correct baselines if their children are also block elements
https://bugs.webkit.org/show_bug.cgi?id=142559
Patch by Myles C. Maxfield <mmaxfield at apple.com> on 2015-03-11
Reviewed by Darin Adler.
Source/WebCore:
Perform the same computation on child block elements as child inline elements.
Test: fast/text/baseline-inline-block-block-children.html
* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::inlineBlockBaseline):
LayoutTests:
* fast/text/baseline-inline-block-block-children-expected.html: Added.
* fast/text/baseline-inline-block-block-children.html: Added.
Commit: ed6d2efa91508cbc57bdf704d0d13c4607735a3f
https://github.com/WebKit/WebKit/commit/ed6d2efa91508cbc57bdf704d0d13c4607735a3f
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/gtk/ProcessExecutablePathGtk.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r181392 - [GTK] Do not look for child processes in the UI process binary path
https://bugs.webkit.org/show_bug.cgi?id=135752
Reviewed by Gustavo Noronha Silva.
.:
* Source/cmake/OptionsGTK.cmake: Add -DDEVELOPMENT_BUILD=1 to the
build for development builds.
Source/WebKit2:
It's only useful for internal tools and tests, but never when
installed, since we don't install the processes in the bin dir but
in the libexec dir.
* Shared/gtk/ProcessExecutablePathGtk.cpp:
(WebKit::findWebKitProcess): Only look or the executables in the
UI process binary path or WEBKIT_EXEC_PATH for development builds.
* UIProcess/API/gtk/WebKitWebContext.cpp:
(injectedBundleDirectory): Only check
WEBKIT_INJECTED_BUNDLE_PATH env var for development builds.
Commit: b045cae5a8d3705e164e727813b8c683b93a1430
https://github.com/WebKit/WebKit/commit/b045cae5a8d3705e164e727813b8c683b93a1430
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M ChangeLog
M Source/cmake/OptionsGTK.cmake
M Tools/CMakeLists.txt
M Tools/ChangeLog
M Tools/MiniBrowser/gtk/CMakeLists.txt
M Tools/MiniBrowser/gtk/main.c
Log Message:
-----------
Merge r181395 - [GTK] Add an option to enable MiniBrowser for non developer builds and always install it
https://bugs.webkit.org/show_bug.cgi?id=126688
Reviewed by Gustavo Noronha Silva.
.:
Add ENABLE_MINIBROWSER option, enabled by default for development
builds and disabled for production builds unless explicilty enabled.
* Source/cmake/OptionsGTK.cmake:
Tools:
* CMakeLists.txt: Build testing tools only for developer builds,
but MiniBrowser when ENABLE_MINIBROWSER option is ON.
* MiniBrowser/gtk/CMakeLists.txt: Only add
-DWEBKIT_INJECTED_BUNDLE_PATH to the build for developer builds,
and add a rule to install the MiniBrowser.
* MiniBrowser/gtk/main.c:
(main): Only set WEBKIT_INJECTED_BUNDLE_PATH env var for developer
builds.
Commit: e9c54db65c26f23b3868a23b6ed1ff0b334a23c6
https://github.com/WebKit/WebKit/commit/e9c54db65c26f23b3868a23b6ed1ff0b334a23c6
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Tools/ChangeLog
M Tools/MiniBrowser/gtk/BrowserWindow.c
Log Message:
-----------
Merge r181399 - [GTK] Add support for handling TLS errors to MiniBrowser
https://bugs.webkit.org/show_bug.cgi?id=142576
Reviewed by Sergio Villar Senin.
It's useful for testing TLS errors handling itself, but also to
allow ignoring TLS errors when testing.
* MiniBrowser/gtk/BrowserWindow.c:
(webViewLoadFailedWithTLSerrors):
(browserWindowConstructed):
Commit: 9376a876117f5c430ce8ed64c6ddf63ebe8efcc3
https://github.com/WebKit/WebKit/commit/9376a876117f5c430ce8ed64c6ddf63ebe8efcc3
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/API/JSBase.cpp
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/bytecode/CodeBlock.h
M Source/JavaScriptCore/heap/Heap.cpp
M Source/JavaScriptCore/heap/Heap.h
M Source/JavaScriptCore/heap/HeapInlines.h
M Source/JavaScriptCore/heap/SlotVisitor.h
M Source/JavaScriptCore/heap/SlotVisitorInlines.h
M Source/JavaScriptCore/runtime/JSArrayBufferView.cpp
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h
M Source/JavaScriptCore/runtime/JSString.cpp
M Source/JavaScriptCore/runtime/JSString.h
M Source/JavaScriptCore/runtime/SparseArrayValueMap.cpp
M Source/JavaScriptCore/runtime/WeakMapData.cpp
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/Modules/mediasource/SourceBuffer.h
M Source/WebCore/bindings/js/JSDocumentCustom.cpp
M Source/WebCore/bindings/js/JSImageDataCustom.cpp
M Source/WebCore/bindings/js/JSNodeListCustom.cpp
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
M Source/WebCore/dom/CollectionIndexCache.cpp
M Source/WebCore/dom/CollectionIndexCache.h
M Source/WebCore/html/HTMLCanvasElement.cpp
M Source/WebCore/html/HTMLCollection.h
M Source/WebCore/html/HTMLImageLoader.cpp
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/xml/XMLHttpRequest.cpp
Log Message:
-----------
Merge r181407 - Refactored the JSC::Heap extra cost API for clarity and to make some known bugs more obvious
https://bugs.webkit.org/show_bug.cgi?id=142589
Reviewed by Andreas Kling.
Source/JavaScriptCore:
* API/JSBase.cpp:
(JSReportExtraMemoryCost): Added a FIXME to annotate a known bug.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitAggregate):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode): Updated for rename.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::reportExtraMemoryAllocatedSlowCase):
(JSC::Heap::deprecatedReportExtraMemorySlowCase): Renamed our reporting
APIs to clarify their relationship to each other: One must report extra
memory at the time of allocation, and at the time the GC visits it.
(JSC::Heap::extraMemorySize):
(JSC::Heap::size):
(JSC::Heap::capacity):
(JSC::Heap::sizeAfterCollect):
(JSC::Heap::willStartCollection): Updated for renames. Added explicit
API for deprecated users who can't use our best API.
(JSC::Heap::reportExtraMemoryCostSlowCase): Deleted.
(JSC::Heap::extraSize): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::reportExtraMemoryAllocated):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::deprecatedReportExtraMemory):
(JSC::Heap::reportExtraMemoryCost): Deleted. Ditto.
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExtraMemoryUsage): Deleted. Moved this
functionality into the Heap since it's pretty detailed in its access
to the heap.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Updated for
renames.
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
(JSC::JSRopeString::resolveRopeToAtomicString):
(JSC::JSRopeString::resolveRope):
* runtime/JSString.h:
(JSC::JSString::finishCreation): Updated for renames.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add): Added FIXME.
* runtime/WeakMapData.cpp:
(JSC::WeakMapData::visitChildren): Updated for rename.
Source/WebCore:
Updated for renames to JSC extra cost APIs.
Added FIXMEs to our 10 use cases that are currently wrong, including
canvas, which is the cause of https://bugs.webkit.org/show_bug.cgi?id=142457.
* Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::appendBufferInternal):
(WebCore::SourceBuffer::sourceBufferPrivateAppendComplete):
(WebCore::SourceBuffer::reportExtraMemoryAllocated):
(WebCore::SourceBuffer::reportExtraMemoryCost): Deleted.
* Modules/mediasource/SourceBuffer.h:
* bindings/js/JSDocumentCustom.cpp:
(WebCore::toJS):
* bindings/js/JSImageDataCustom.cpp:
(WebCore::toJS):
* bindings/js/JSNodeListCustom.cpp:
(WebCore::createWrapper):
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateImplementation):
* dom/CollectionIndexCache.cpp:
(WebCore::reportExtraMemoryAllocatedForCollectionIndexCache):
(WebCore::reportExtraMemoryCostForCollectionIndexCache): Deleted.
* dom/CollectionIndexCache.h:
(WebCore::Iterator>::computeNodeCountUpdatingListCache):
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::createImageBuffer):
* html/HTMLCollection.h:
(WebCore::CollectionNamedElementCache::didPopulate):
* html/HTMLImageLoader.cpp:
(WebCore::HTMLImageLoader::imageChanged):
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::parseAttribute):
* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::dropProtection):
Commit: 5fef34cd3e6addcb3e7a53832f24432f1216b965
https://github.com/WebKit/WebKit/commit/5fef34cd3e6addcb3e7a53832f24432f1216b965
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/API/JSBase.cpp
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/SparseArrayValueMap.cpp
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/bindings/js/JSDocumentCustom.cpp
M Source/WebCore/bindings/js/JSImageDataCustom.cpp
M Source/WebCore/bindings/js/JSNodeListCustom.cpp
M Source/WebCore/dom/CollectionIndexCache.cpp
M Source/WebCore/html/HTMLCanvasElement.cpp
M Source/WebCore/html/HTMLImageLoader.cpp
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/xml/XMLHttpRequest.cpp
Log Message:
-----------
Merge r181411 - Many users of Heap::reportExtraMemory* are wrong, causing lots of memory growth
https://bugs.webkit.org/show_bug.cgi?id=142593
Reviewed by Andreas Kling.
Adopt deprecatedReportExtraMemory as a short-term fix for runaway
memory growth in these cases where we have not adopted
reportExtraMemoryVisited.
Long-term, we should use reportExtraMemoryAllocated+reportExtraMemoryVisited.
That's tracked by https://bugs.webkit.org/show_bug.cgi?id=142595.
Source/JavaScriptCore:
* API/JSBase.cpp:
(JSReportExtraMemoryCost):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::add):
Source/WebCore:
Using IOSDebug, I can see that the canvas stress test @ http://jsfiddle.net/fvyw4ba0/,
which used to keep > 1000 1MB NonVolatile GPU allocations live, now keeps about 10 live.
* Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::reportExtraMemoryAllocated):
* bindings/js/JSDocumentCustom.cpp:
(WebCore::toJS):
* bindings/js/JSImageDataCustom.cpp:
(WebCore::toJS):
* bindings/js/JSNodeListCustom.cpp:
(WebCore::createWrapper):
* dom/CollectionIndexCache.cpp:
(WebCore::reportExtraMemoryAllocatedForCollectionIndexCache):
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::createImageBuffer):
* html/HTMLImageLoader.cpp:
(WebCore::HTMLImageLoader::imageChanged):
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::parseAttribute):
* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::dropProtection):
Commit: f904decc0143d9e8b50afcc531b92b3178ef6d8b
https://github.com/WebKit/WebKit/commit/f904decc0143d9e8b50afcc531b92b3178ef6d8b
Author: Commit Queue <commit-queue at webkit.org>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLImageLoader.cpp
M Source/WebCore/html/HTMLImageLoader.h
M Source/WebCore/loader/ImageLoader.cpp
M Source/WebCore/loader/ImageLoader.h
M Source/WebCore/loader/cache/CachedImage.cpp
M Source/WebCore/loader/cache/CachedImageClient.h
M Source/WebCore/rendering/RenderImage.cpp
M Source/WebCore/rendering/RenderImage.h
M Source/WebCore/svg/SVGFEImageElement.cpp
M Source/WebCore/svg/SVGFEImageElement.h
Log Message:
-----------
Merge r181412 - Unreviewed, rolling out r179340 and r179344.
https://bugs.webkit.org/show_bug.cgi?id=142598
Caused images to stay alive forever when navigating away from
the page before they finish loading. (Requested by kling on
Reverted changesets:
"CachedImage: ensure clients overrides imageChanged instead of
notifyFinished"
https://bugs.webkit.org/show_bug.cgi?id=140722
http://trac.webkit.org/changeset/179340
"HTMLImageLoader: fix build failure on assert condition after
r179340"
https://bugs.webkit.org/show_bug.cgi?id=140722
http://trac.webkit.org/changeset/179344
Commit: 8c41d9edf51ffbff697ebd68feb9574803a02e13
https://github.com/WebKit/WebKit/commit/8c41d9edf51ffbff697ebd68feb9574803a02e13
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLCanvasElement.cpp
M Source/WebCore/html/HTMLCanvasElement.h
M Source/WebCore/html/HTMLCanvasElement.idl
Log Message:
-----------
Users of Heap::deprecatedReportExtraMemory should switch to reportExtraMemoryAllocated+reportExtraMemoryVisited
https://bugs.webkit.org/show_bug.cgi?id=142595
Reviewed by Andreas Kling.
Fixed this bug for canvas.
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::memoryCost): Factored out the helper function
required by our IDL generator.
(WebCore::HTMLCanvasElement::createImageBuffer): Use
reportExtraMemoryAllocated.
* html/HTMLCanvasElement.h:
* html/HTMLCanvasElement.idl: Adopt the IDL for reporting cost in the
right way during GC. This will match our reportExtraMemoryAllocated
with a reportExtraMemoryVisited during GC.
Commit: 845056421c25cfc973880b5672e92b1659119a62
https://github.com/WebKit/WebKit/commit/845056421c25cfc973880b5672e92b1659119a62
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/CMakeLists.txt
M Source/JavaScriptCore/ChangeLog
Log Message:
-----------
Merge r181435 - [cmake] Fix the incremental build issue revealed by r181419
https://bugs.webkit.org/show_bug.cgi?id=142613
Reviewed by Carlos Garcia Campos.
* CMakeLists.txt:
Commit: 6e9ec6b7e19c09255fc63fe8b5447057f75c1505
https://github.com/WebKit/WebKit/commit/6e9ec6b7e19c09255fc63fe8b5447057f75c1505
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/Platform.h
Log Message:
-----------
Merge r181436 - [ARM][Linux] GC sometimes stuck in an infinite loop if parallel GC is enabled
https://bugs.webkit.org/show_bug.cgi?id=141290
Reviewed by Carlos Garcia Campos.
* wtf/Platform.h: Enable parallel GC after r181319.
Commit: 3a6a763c4d4a270e5ed17dfbf7e700f71a030888
https://github.com/WebKit/WebKit/commit/3a6a763c4d4a270e5ed17dfbf7e700f71a030888
Author: Sebastian Dröge <sebastian at centricular.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/audio/gstreamer/AudioDestinationGStreamer.cpp
M Source/WebCore/platform/audio/gstreamer/AudioFileReaderGStreamer.cpp
M Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp
M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/GStreamerUtilities.cpp
M Source/WebCore/platform/graphics/gstreamer/GStreamerUtilities.h
M Source/WebCore/platform/graphics/gstreamer/ImageGStreamer.h
Log Message:
-----------
Merge r181449 - Stop using single-include headers that are only available since GStreamer >= 1.2.
https://bugs.webkit.org/show_bug.cgi?id=142537
Patch by Sebastian Dröge <sebastian at centricular.com> on 2015-03-12
Reviewed by Philippe Normand.
* platform/audio/gstreamer/AudioDestinationGStreamer.cpp:
* platform/audio/gstreamer/AudioFileReaderGStreamer.cpp:
* platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp:
* platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp:
* platform/graphics/gstreamer/GStreamerUtilities.cpp:
* platform/graphics/gstreamer/GStreamerUtilities.h:
* platform/graphics/gstreamer/ImageGStreamer.h:
Instead of using single-include headers for the GStreamer libraries,
directly include the headers we need. The single-include headers were
only added in 1.2, and this would be the only reason why we would
depend on 1.2.
Commit: ec8d32612c703c164f9d5b6c06c04860b132245b
https://github.com/WebKit/WebKit/commit/ec8d32612c703c164f9d5b6c06c04860b132245b
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/bytecode/CodeBlock.h
M Source/JavaScriptCore/heap/CodeBlockSet.cpp
Log Message:
-----------
Merge r181456 - Use std::atomic for CodeBlock::m_visitAggregateHasBeenCalled.
<https://webkit.org/b/142640>
Reviewed by Mark Hahnenberg.
We used to spin our own compare and swap on a uint8_t. Now that we can
use C++11, let's use std::atomic instead.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitAggregate):
- The CAS here needs std::memory_order_acquire ordering because it
requires lock acquisition semantics to visit the CodeBlock.
* bytecode/CodeBlock.h:
(JSC::CodeBlockSet::mark):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::clearMarksForEdenCollection):
- These can go with relaxed ordering because they are all done before
the GC starts parallel marking.
Commit: 30f7ca1d5d48496a59043534694b996d03a2635b
https://github.com/WebKit/WebKit/commit/30f7ca1d5d48496a59043534694b996d03a2635b
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Allocator.cpp
Log Message:
-----------
Merge r181457 - Assertion failure in bmalloc::LargeObject::validateSelf on Mavericks Debug layout test bot
https://bugs.webkit.org/show_bug.cgi?id=142642
Reviewed by Michael Saboff.
The typical backtrace to this crash shows the main thread trying to
realloc a large string while a DFG compiler thread tries to
free a large vector buffer.
I believe that this is a race condition -- at least in debug builds --
since the main thread will try to validate its object's neighbors
without holding a lock, even though those neighbors might be in the
midst of changing.
In general, there may be sneaky times when it is valid to look at an
object's metadata without holding the heap lock, but it is best not to
do so unless we have a really really good reason to.
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::reallocate): Take a lock before reading the metadata
for this object, since we generally require any access to shared heap
metadata to take a lock.
Commit: 669f2005fd8098d1119026c4077b9401be34443a
https://github.com/WebKit/WebKit/commit/669f2005fd8098d1119026c4077b9401be34443a
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/ByteSpinLock.h
Log Message:
-----------
Merge r181461 - Change WTF::ByteSpinLock to use std::atomic.
<https://webkit.org/b/142644>
Reviewed by Filip Pizlo.
* wtf/ByteSpinLock.h:
(WTF::ByteSpinLock::ByteSpinLock):
(WTF::ByteSpinLock::lock):
(WTF::ByteSpinLock::unlock):
(WTF::ByteSpinLock::isHeld):
Commit: d53554e3382e4ee972ec6fa072f5b0c189d26a75
https://github.com/WebKit/WebKit/commit/d53554e3382e4ee972ec6fa072f5b0c189d26a75
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/Platform.h
Log Message:
-----------
Merge r181462 - Disable Yarr JIT for ARMv7k
https://bugs.webkit.org/show_bug.cgi?id=142645
Reviewed by Oliver Hunt.
Make the setting of ENABLE_YARR_JIT match ENABLE_JIT for ARMv7k.
* wtf/Platform.h:
Commit: 896fde2aaa1ab7a4e81f491854532a34c3e7d459
https://github.com/WebKit/WebKit/commit/896fde2aaa1ab7a4e81f491854532a34c3e7d459
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGCommon.cpp
Log Message:
-----------
Merge r181469 - Change the DFG crashLock to use std::atomic.
<https://webkit.org/b/142649>
Reviewed by Filip Pizlo.
* dfg/DFGCommon.cpp:
(JSC::DFG::startCrashing):
(JSC::DFG::isCrashing):
Commit: 4842c61f44fb1aefdcff1f21f930f624f1b4a18a
https://github.com/WebKit/WebKit/commit/4842c61f44fb1aefdcff1f21f930f624f1b4a18a
Author: Joonghun Park <jh718.park at samsung.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSPrimitiveValue.cpp
M Source/WebCore/css/makeprop.pl
Log Message:
-----------
Merge r181475 - Fix Debug build error 'comparison is always true due to limited range of data type [-Werror=type-limits]'
https://bugs.webkit.org/show_bug.cgi?id=142652
Patch by Joonghun Park <jh718.park at samsung.com> on 2015-03-13
Reviewed by Csaba Osztrogonác.
No new tests, no behavior changes.
Now CSSPropertyID type is uint16_t, so propertyID >= 0 check is needed no more.
* css/CSSPrimitiveValue.cpp:
(WebCore::propertyName):
* css/makeprop.pl:
Commit: 5db62d1c64cbda49f72dc1d8d77a0fb1173cdc20
https://github.com/WebKit/WebKit/commit/5db62d1c64cbda49f72dc1d8d77a0fb1173cdc20
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/bytecode/CodeBlock.h
M Source/JavaScriptCore/dfg/DFGCommon.cpp
M Source/WTF/ChangeLog
M Source/WTF/wtf/Atomics.h
M Source/WTF/wtf/ByteSpinLock.h
Log Message:
-----------
Merge r181481 - Introduce WTF::Atomic to wrap std::atomic for a friendlier CAS.
<https://webkit.org/b/142661>
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Changed CodeBlock, and the DFG's crashLock to use WTF::Atomic instead of
std::atomic.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitAggregate):
* bytecode/CodeBlock.h:
* dfg/DFGCommon.cpp:
(JSC::DFG::startCrashing):
Source/WTF:
The CAS functions provided by std::atomic takes a reference to the expected
value and modifies it if the CAS fails. However, in a lot of our CAS usage,
we don't want the expected value to change. The solution to this is to
provide a WTF::Atomic struct that wraps std::atomic, and provide CAS
methods that won't alter the expected value if the CAS fails.
The method names in WTF::Atomic are chosen to be identical to those
in std::atomic so that WTF::Atomic can be a simple drop in replacement
for std::atomic.
Also changed ByteSpinLock to use WTF::Atomic instead of std::atomic.
* wtf/Atomics.h:
(WTF::Atomic::load):
(WTF::Atomic::store):
(WTF::Atomic::compare_exchange_weak):
(WTF::Atomic::compare_exchange_strong):
* wtf/ByteSpinLock.h:
(WTF::ByteSpinLock::ByteSpinLock):
(WTF::ByteSpinLock::lock):
Commit: 180f86e589092adcdcf1379873b2e6d5b3232039
https://github.com/WebKit/WebKit/commit/180f86e589092adcdcf1379873b2e6d5b3232039
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/heap/Heap.cpp
M Source/JavaScriptCore/heap/IncrementalSweeper.cpp
Log Message:
-----------
Merge r181486 - Prohibit GC while sweeping
https://bugs.webkit.org/show_bug.cgi?id=142638
Reviewed by Andreas Kling.
I noticed in https://bugs.webkit.org/show_bug.cgi?id=142636 that a GC
could trigger a sweep which could trigger another GC. Yo Dawg.
I tried to figure out whether this could cause problems or not and it
made me cross-eyed.
(Some clients like to report extra memory cost during deallocation as a
way to indicate that the GC now owns something exclusively. It's
arguably a bug to communicate with the GC in this way, but we shouldn't
do crazy when this happens.)
This patch makes explicit the fact that we don't allow GC while sweeping.
Usually, sweeping implicitly defers GC by virtue of happening during
allocation. But not always.
* heap/Heap.cpp:
(JSC::Heap::collectAllGarbage): Defer GC while sweeping due to an
explicit GC request.
(JSC::Heap::didFinishCollection): Make sure that zombifying sweep
defers GC by not returning to the non-GC state until we're all done.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::sweepNextBlock): Defer GC while sweeping due
to a timer.
Commit: a86398358c076dbdaa9907510c92eeb5a493c827
https://github.com/WebKit/WebKit/commit/a86398358c076dbdaa9907510c92eeb5a493c827
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
Log Message:
-----------
Merge r181495 - Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
https://bugs.webkit.org/show_bug.cgi?id=142686
Reviewed by Oliver Hunt.
Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
mean that we should handle it as if it was for one of our sinking candidates. Instead we should
prune based on m_sinkCandidates.
This fixes a benign bug where we would generate a lot of repeated IR for some pathological
tests.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
Commit: f24de76862cde45163bd9ec5c68cf9153f7a45f6
https://github.com/WebKit/WebKit/commit/f24de76862cde45163bd9ec5c68cf9153f7a45f6
Author: Adenilson Cavalcanti <cavalcantii at gmail.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/RenderBlock.h
Log Message:
-----------
Merge r181500 - RenderBlock::imageChange() calling const methods on exit
https://bugs.webkit.org/show_bug.cgi?id=142648
Reviewed by Brent Fulgham.
No new tests, no change on behavior.
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::imageChanged): Deleted.
* rendering/RenderBlock.h:
Commit: 1e42fca14f1a053524ecd20f508528bf5b09e92a
https://github.com/WebKit/WebKit/commit/1e42fca14f1a053524ecd20f508528bf5b09e92a
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Merge r181513 - Remove a redundant repaint when a layer becomes composited
https://bugs.webkit.org/show_bug.cgi?id=142711
Reviewed by Anders Carlsson.
RenderLayerCompositor::computeCompositingRequirements() doesn't need to call
repaintOnCompositingChange() when a layer is going to become composited,
because updateBacking() does exactly the same thing. I used an assertion
and ran the tests to ensure this wasn't a behavior change.
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeCompositingRequirements):
Commit: 7aaa2f2f07f0325d616c638de68a0675faf6d025
https://github.com/WebKit/WebKit/commit/7aaa2f2f07f0325d616c638de68a0675faf6d025
Author: Max Stepin <maxstepin at gmail.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/images/animated-png-expected.html
A LayoutTests/fast/images/animated-png.html
A LayoutTests/fast/images/resources/apng00-ref.png
A LayoutTests/fast/images/resources/apng00.png
A LayoutTests/fast/images/resources/apng01-ref.png
A LayoutTests/fast/images/resources/apng01.png
A LayoutTests/fast/images/resources/apng02-ref.png
A LayoutTests/fast/images/resources/apng02.png
A LayoutTests/fast/images/resources/apng04-ref.png
A LayoutTests/fast/images/resources/apng04.png
A LayoutTests/fast/images/resources/apng08-ref.png
A LayoutTests/fast/images/resources/apng08.png
A LayoutTests/fast/images/resources/apng10-ref.png
A LayoutTests/fast/images/resources/apng10.png
A LayoutTests/fast/images/resources/apng11-ref.png
A LayoutTests/fast/images/resources/apng11.png
A LayoutTests/fast/images/resources/apng12-ref.png
A LayoutTests/fast/images/resources/apng12.png
A LayoutTests/fast/images/resources/apng14-ref.png
A LayoutTests/fast/images/resources/apng14.png
A LayoutTests/fast/images/resources/apng18-ref.png
A LayoutTests/fast/images/resources/apng18.png
A LayoutTests/fast/images/resources/apng24-ref.png
A LayoutTests/fast/images/resources/apng24.png
A LayoutTests/fast/images/resources/apng26-ref.png
A LayoutTests/fast/images/resources/apng26.png
M Source/WTF/ChangeLog
M Source/WTF/wtf/FeatureDefines.h
M Source/WebCore/ChangeLog
M Source/WebCore/platform/image-decoders/ImageDecoder.h
M Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp
M Source/WebCore/platform/image-decoders/png/PNGImageDecoder.h
Log Message:
-----------
Merge r181553 - Add APNG support
https://bugs.webkit.org/show_bug.cgi?id=17022
Patch by Max Stepin <maxstepin at gmail.com> on 2015-03-16
Reviewed by Carlos Garcia Campos.
Source/WebCore:
Test: fast/images/animated-png.html
* platform/image-decoders/ImageDecoder.h:
(WebCore::ImageFrame::divide255):
(WebCore::ImageFrame::overRGBA):
* platform/image-decoders/png/PNGImageDecoder.cpp:
(WebCore::frameHeader):
(WebCore::readChunks):
(WebCore::PNGImageReader::PNGImageReader):
(WebCore::PNGImageDecoder::PNGImageDecoder):
(WebCore::PNGImageDecoder::frameBufferAtIndex):
(WebCore::PNGImageDecoder::headerAvailable):
(WebCore::PNGImageDecoder::rowAvailable):
(WebCore::PNGImageDecoder::pngComplete):
(WebCore::PNGImageDecoder::readChunks):
(WebCore::PNGImageDecoder::frameHeader):
(WebCore::PNGImageDecoder::init):
(WebCore::PNGImageDecoder::clearFrameBufferCache):
(WebCore::PNGImageDecoder::initFrameBuffer):
(WebCore::PNGImageDecoder::frameComplete):
(WebCore::PNGImageDecoder::processingStart):
(WebCore::PNGImageDecoder::processingFinish):
(WebCore::PNGImageDecoder::fallbackNotAnimated):
* platform/image-decoders/png/PNGImageDecoder.h:
(WebCore::PNGImageDecoder::frameCount):
(WebCore::PNGImageDecoder::repetitionCount):
(WebCore::PNGImageDecoder::isComplete):
Source/WTF:
* wtf/FeatureDefines.h:
LayoutTests:
* fast/images/animated-png-expected.html: Added.
* fast/images/animated-png.html: Added.
* fast/images/resources/apng00-ref.png: Added.
* fast/images/resources/apng00.png: Added.
* fast/images/resources/apng01-ref.png: Added.
* fast/images/resources/apng01.png: Added.
* fast/images/resources/apng02-ref.png: Added.
* fast/images/resources/apng02.png: Added.
* fast/images/resources/apng04-ref.png: Added.
* fast/images/resources/apng04.png: Added.
* fast/images/resources/apng08-ref.png: Added.
* fast/images/resources/apng08.png: Added.
* fast/images/resources/apng10-ref.png: Added.
* fast/images/resources/apng10.png: Added.
* fast/images/resources/apng11-ref.png: Added.
* fast/images/resources/apng11.png: Added.
* fast/images/resources/apng12-ref.png: Added.
* fast/images/resources/apng12.png: Added.
* fast/images/resources/apng14-ref.png: Added.
* fast/images/resources/apng14.png: Added.
* fast/images/resources/apng18-ref.png: Added.
* fast/images/resources/apng18.png: Added.
* fast/images/resources/apng24-ref.png: Added.
* fast/images/resources/apng24.png: Added.
* fast/images/resources/apng26-ref.png: Added.
* fast/images/resources/apng26.png: Added.
* platform/mac/TestExpectations:
Commit: ceb943e660dd23faeed313a8694a25f9c751daff
https://github.com/WebKit/WebKit/commit/ceb943e660dd23faeed313a8694a25f9c751daff
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitUserContent.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp
M Source/WebKit2/UIProcess/API/gtk/docs/webkit2gtk-docs.sgml
Log Message:
-----------
Merge r181555 - Unreviewed. Add new Notification classes to GTK+ API documentation.
Add WebKitNotification and WebKitNotificationPermissionRequest to
the documentation and fix some other typos causing warnings when
generating HTML documentation.
* UIProcess/API/gtk/WebKitUserContent.cpp:
* UIProcess/API/gtk/WebKitWebView.cpp:
(webkit_web_view_class_init):
* UIProcess/API/gtk/docs/webkit2gtk-docs.sgml:
Commit: 0160b44365c75f5be2b1a167a5174fda74343165
https://github.com/WebKit/WebKit/commit/0160b44365c75f5be2b1a167a5174fda74343165
Author: Brady Eidson <beidson at apple.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/icon/IconController.cpp
Log Message:
-----------
Merge r181565 - URLs visited during private browsing show up in WebpageIcons.db
rdar://problem/11254910 and https://bugs.webkit.org/show_bug.cgi?id=142733
Patch by Sam Weinig. Reviewed by Brady Eidson.
* loader/icon/IconController.cpp:
(WebCore::IconController::startLoader): Bail early here if the page is using an ephemeral session.
(WebCore::IconController::continueLoadWithDecision): Instead of here.
Commit: d906c79718d8847ca7d47f71b7eeae52a92839af
https://github.com/WebKit/WebKit/commit/d906c79718d8847ca7d47f71b7eeae52a92839af
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/ARMAssembler.h
M Source/JavaScriptCore/assembler/ARMv7Assembler.h
M Source/JavaScriptCore/assembler/AbstractMacroAssembler.h
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/WTF/ChangeLog
M Source/WTF/wtf/Platform.h
Log Message:
-----------
Merge r181570 - [ARM] Enable generating idiv instructions if it is supported
https://bugs.webkit.org/show_bug.cgi?id=142725
Reviewed by Michael Saboff.
Source/JavaScriptCore:
* assembler/ARMAssembler.h: Added sdiv and udiv implementation for ARM Traditional instruction set.
(JSC::ARMAssembler::sdiv):
(JSC::ARMAssembler::udiv):
* assembler/ARMv7Assembler.h: Use HAVE(ARM_IDIV_INSTRUCTIONS) instead of CPU(APPLE_ARMV7S).
* assembler/AbstractMacroAssembler.h:
(JSC::isARMv7IDIVSupported):
(JSC::optimizeForARMv7IDIVSupported):
(JSC::isARMv7s): Renamed to isARMv7IDIVSupported().
(JSC::optimizeForARMv7s): Renamed to optimizeForARMv7IDIVSupported().
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
Source/WTF:
* wtf/Platform.h: Set HAVE_ARM_IDIV_INSTRUCTIONS based on GCC macro too.
Commit: 70c032fe46694b316399da21d7c27a7b44e0bc4e
https://github.com/WebKit/WebKit/commit/70c032fe46694b316399da21d7c27a7b44e0bc4e
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/Plugins/PluginView.cpp
Log Message:
-----------
Merge r181599 - ASSERT(m_plugin) on plugins/snapshotting/snapshot-plugin-not-quite-blocked-by-image.html
https://bugs.webkit.org/show_bug.cgi?id=142637
Reviewed by Dean Jackson.
* WebProcess/Plugins/PluginView.cpp: (WebKit::PluginView::pluginSnapshotTimerFired):
m_plugin can be legitimately null.
Commit: a4b00036d895dea975cc137bfa21b48282e448d2
https://github.com/WebKit/WebKit/commit/a4b00036d895dea975cc137bfa21b48282e448d2
Author: Joanmarie Diggs <jdiggs at igalia.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/platform/gtk/accessibility/no-notification-for-unrendered-iframe-children-expected.txt
A LayoutTests/platform/gtk/accessibility/no-notification-for-unrendered-iframe-children.html
M Source/WebCore/ChangeLog
M Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp
Log Message:
-----------
Merge r181600 - AX: Crash viewing http://www.last.fm/
https://bugs.webkit.org/show_bug.cgi?id=142309
Reviewed by Chris Fleizach.
Source/WebCore:
The crash occurs when a not-yet-rendered object emits a children-changed
signal. If an assistive technology is listening, AT-SPI2 will attempt to
create and cache the state set for the child being added and the creation
of the state set assumes a rendered object.
Test: platform/gtk/accessibility/no-notification-for-unrendered-iframe-children.html
* accessibility/atk/AXObjectCacheAtk.cpp:
(WebCore::AXObjectCache::attachWrapper):
LayoutTests:
This test doesn't verify the absence of the crash because the crash seems
to require that an assistive technology is listening for events, and that
AT-SPI2 is caching the tree for that assistive technology -- something we
cannot count on being the case on our bots. (I suspect that the reason non-
assistive technology users of Epiphany were getting hit by this is because
Caribou was listening for events in the background, thus they were AT users
without realizing it. That Caribou issue is in theory now resolved.) What
this test does verify is the absence of children-changed:add accessibility
signals for non-rendered objects, which is the source of the crash given
the aforementioned environment.
* platform/gtk/accessibility/no-notification-for-unrendered-iframe-children-expected.txt: Added.
* platform/gtk/accessibility/no-notification-for-unrendered-iframe-children.html: Added.
Commit: f6e2a5cc6274cc952872745370b3cb228bc57a3a
https://github.com/WebKit/WebKit/commit/f6e2a5cc6274cc952872745370b3cb228bc57a3a
Author: Gwang Yoon Hwang <yoon at igalia.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/LayerTreeHost.h
Log Message:
-----------
Merge r181620 - REGRESSION(r180924): Unable to build WebKitGTK+ with threaded compositor
Unreviewed build fix.
* WebProcess/WebPage/LayerTreeHost.h:
Remove duplicated declaration of setNativeSurfaceHandleForCompositing.
Commit: 56b9ffbdcd1dc25d5966ecdc1f945a0c7d9d6bbd
https://github.com/WebKit/WebKit/commit/56b9ffbdcd1dc25d5966ecdc1f945a0c7d9d6bbd
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
A Source/ThirdParty/ANGLE/ANGLE/ShaderLang.h
M Source/ThirdParty/ANGLE/ChangeLog
M Source/WebCore/CMakeLists.txt
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/ANGLEWebKitBridge.h
M Source/WebCore/platform/graphics/cairo/GraphicsContext3DCairo.cpp
M Source/WebKit2/CMakeLists.txt
M Source/WebKit2/ChangeLog
Log Message:
-----------
Merge r181629 - [CMake] Use a forwarding header for ANGLE's ShaderLang.h to avoid picking up ANGLE's EGL headers
https://bugs.webkit.org/show_bug.cgi?id=142530
Reviewed by Darin Adler.
Source/ThirdParty/ANGLE:
* ANGLE/ShaderLang.h: Added. Includes include/GLSLANG/ShaderLang.h. Used in WebCore
so we can avoid using ANGLE's EGL headers and use the system-default headers instead.
Source/WebCore:
Include the ANGLE's ShaderLang.h through the new forwarding header. This allows
us to not list Source/ThirdParty/ANGLE/include in the list of inclusion directories
and thus avoid ANGLE's EGL and GLES2/GLES3 headers, defaulting to the system-provided
headers instead.
Source/ThirdParty/ANGLE/include/KHR is still used because ANGLE's khrplatform.h is
required by the ShaderLang.h header. Source/ThirdParty/ANGLE/src is not used for the
whole WebCore library anymore, only the ANGLESupport library.
* CMakeLists.txt:
* platform/graphics/ANGLEWebKitBridge.h:
* platform/graphics/cairo/GraphicsContext3DCairo.cpp:
Source/WebKit2:
* CMakeLists.txt: Replace the Source/ThirdParty/ANGLE/include/GLSLANG entry
in the list of inclusion directories for WebKit2 with Source/ThirdParty/ANGLE,
possible due to the new forwarding header for ANGLE's ShaderLang.h.
Commit: eabed9fcee277d1352fc9eb613adba16abe1ca88
https://github.com/WebKit/WebKit/commit/eabed9fcee277d1352fc9eb613adba16abe1ca88
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/gobject/DOMObjectCache.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestDOMNode.cpp
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/WebProcessTest.cpp
Log Message:
-----------
Merge r181631 - [GTK] WebKitDOM objects leaking
https://bugs.webkit.org/show_bug.cgi?id=118788
Reviewed by Darin Adler and Sergio Villar Senin.
Source/WebCore:
Use a DOMwindowObserver class, derived from DOMWindowProperty to
be notified when the window object is detached from the frame to
clear the DOM objects associated to that frame in that case too.
* bindings/gobject/DOMObjectCache.cpp:
Tools:
Update DOMObjectCache unit test to check that DOM objects are also
released when new contents are loaded in the web view, and the old
document is detached from the frame.
* TestWebKitAPI/Tests/WebKit2Gtk/TestDOMNode.cpp:
(testWebKitDOMObjectCache):
* TestWebKitAPI/Tests/WebKit2Gtk/WebProcessTest.cpp:
(runTest):
Commit: 9307397a5a3fff828b05ab7d84ae24db4dc87740
https://github.com/WebKit/WebKit/commit/9307397a5a3fff828b05ab7d84ae24db4dc87740
Author: Piotr Drąg <piotrdrag at gmail.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebCore/platform/gtk/po/ChangeLog
M Source/WebCore/platform/gtk/po/pl.po
Log Message:
-----------
Merge r181639 - [l10n] Updated Polish translation of WebKitGTK+
https://bugs.webkit.org/show_bug.cgi?id=142306
Patch by Piotr Drąg <piotrdrag at gmail.com> on 2015-03-17
Reviewed by Carlos Garcia Campos.
* pl.po:
Commit: 1f10b8019c3f81219a0c9f654a8448c94ad0a6ae
https://github.com/WebKit/WebKit/commit/1f10b8019c3f81219a0c9f654a8448c94ad0a6ae
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/gobject/WebKitDOMCustomUnstable.h
M Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm
Log Message:
-----------
Merge r181643 - [GTK] Wrong transfer annotations used in GObject DOM bindings
https://bugs.webkit.org/show_bug.cgi?id=142780
Reviewed by Gustavo Noronha Silva.
We are using transfer none for all methods returning a GObject DOM
Object. That's not true. Only objects derived from Node are
automatically released by the DOM object cache and can be transfer
none. All other objects are added to the cache only to avoid
creating the same wrapper twice for the same core object, but
caller should release the returned reference.
* bindings/gobject/WebKitDOMCustomUnstable.h:
* bindings/scripts/CodeGeneratorGObject.pm:
(GetTransferTypeForReturnType):
(GenerateFunction):
Commit: ca8c763980dcf1a3449bbcd9df06c6ed46ad7062
https://github.com/WebKit/WebKit/commit/ca8c763980dcf1a3449bbcd9df06c6ed46ad7062
Author: Yosef Or Boczko <yoseforb at gnome.org>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M Source/WebCore/platform/gtk/po/ChangeLog
M Source/WebCore/platform/gtk/po/he.po
Log Message:
-----------
Merge r181645 - [l10n] Updated Hebrew translation of WebKitGTK+
https://bugs.webkit.org/show_bug.cgi?id=142781
Patch by Yosef Or Boczko <yoseforb at gnome.org> on 2015-03-17
Reviewed by Carlos Garcia Campos.
* he.po:
Commit: c159fdd0a0369dc60329112356b8b7fde61f2e43
https://github.com/WebKit/WebKit/commit/c159fdd0a0369dc60329112356b8b7fde61f2e43
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-03-17 (Tue, 17 Mar 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.7.92 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.7.92.
Commit: e5254710ee4a3575916b9f5373ea393e0ff4dcfe
https://github.com/WebKit/WebKit/commit/e5254710ee4a3575916b9f5373ea393e0ff4dcfe
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-19 (Thu, 19 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/gtk/ScrollbarThemeGtk.cpp
Log Message:
-----------
Merge r181744 - [GTK] Scrollbars look bad with GTK+ 3.16
https://bugs.webkit.org/show_bug.cgi?id=140800
Reviewed by Sergio Villar Senin.
Take margin into account when rendering scrollbars. This fixes the
huge scrollbars rendered with GTK+ 3.16. We don't need to check
the GTK+ version because in previous versions the marging were 0,
so the same code just works.
* platform/gtk/ScrollbarThemeGtk.cpp:
(WebCore::adjustRectAccordingToMargin):
(WebCore::ScrollbarThemeGtk::paintTrackBackground):
(WebCore::ScrollbarThemeGtk::paintThumb):
Commit: fac5bf964a6400da2921f2a84e7ea1f482b2cbb5
https://github.com/WebKit/WebKit/commit/fac5bf964a6400da2921f2a84e7ea1f482b2cbb5
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-20 (Fri, 20 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/cairo/ImageBufferCairo.cpp
Log Message:
-----------
Merge r181787 - [GTK] Crash due to empty drag image during drag-and-drop
https://bugs.webkit.org/show_bug.cgi?id=142671
Reviewed by Philippe Normand.
Return early from ImageBuffer constructor if an empty size is
given. This is a speculative fix for a crash while starting a drag
and drop operation, that I haven't been able to reproduce.
* platform/graphics/cairo/ImageBufferCairo.cpp:
(WebCore::ImageBuffer::ImageBuffer):
Commit: b26e9d6e180e81717ee82c501c4f97254ccc4793
https://github.com/WebKit/WebKit/commit/b26e9d6e180e81717ee82c501c4f97254ccc4793
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-20 (Fri, 20 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/cairo/BackingStoreCairo.cpp
Log Message:
-----------
Merge r181789 - [GTK] Properly guard X11-specific code in BackingStore::createBackend()
https://bugs.webkit.org/show_bug.cgi?id=142875
Reviewed by Martin Robinson.
* UIProcess/cairo/BackingStoreCairo.cpp:
(WebKit::BackingStore::createBackend): Guard the GTK- and X11-specific
bit of code with PLATFORM(GTK) and PLATFORM(X11). Testing GDK_WINDOWING_X11
ensures that the GTK+ dependency has X11 support, but does not ensure
that WebKitGTK+ has been configured to build for X11 environments (which
is what PLATFORM(X11) ensures).
Commit: c351e78dfeaa966604e1f20e090ba4904d766185
https://github.com/WebKit/WebKit/commit/c351e78dfeaa966604e1f20e090ba4904d766185
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-20 (Fri, 20 Mar 2015)
Changed paths:
M ChangeLog
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r181793 - [GTK] Search for the Wayland dependency when enabling Wayland target
https://bugs.webkit.org/show_bug.cgi?id=142876
Reviewed by Carlos Garcia Campos.
* Source/cmake/OptionsGTK.cmake: The Wayland dependency isn't a public
requirement of either the GTK+ or GDK pkg-config files, so we have to
search for it ourselves when WebKitGTK+ has been configured to support
the Wayland windowing target.
Commit: 8f88f2264028aee65b0c906d3d06262861feea1f
https://github.com/WebKit/WebKit/commit/8f88f2264028aee65b0c906d3d06262861feea1f
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-20 (Fri, 20 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
Log Message:
-----------
Merge r181798 - [GTK] Disable accelerated compositing on Wayland
https://bugs.webkit.org/show_bug.cgi?id=142877
Reviewed by Carlos Garcia Campos.
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseCreateWebPage): As was done in the past, we should disable
accelerated compositing on Wayland until the proper support for it lands.
Commit: 678bfe49ae16ba872983d180a253250e14c08c19
https://github.com/WebKit/WebKit/commit/678bfe49ae16ba872983d180a253250e14c08c19
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-03-23 (Mon, 23 Mar 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
M Source/WebKit2/UIProcess/gtk/RedirectedXCompositeWindow.cpp
M Source/WebKit2/UIProcess/gtk/RedirectedXCompositeWindow.h
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r181847 - [GTK] Add a configure option to build without Redirected XComposite Window
https://bugs.webkit.org/show_bug.cgi?id=142865
Reviewed by Žan Doberšek.
.:
The Redirected XComposite Window was added to support some
features like GtkOverlay, but in cases where we don't need such
features, it's more efficient to use the XID of the WebKitWebView
window as the native surface handle for the accelerated
compositing. This patch adds USE_REDIRECTED_XCOMPOSITE_WINDOW,
that is enabled by default for X11 target when OpenGL is enabled.
* Source/cmake/OptionsGTK.cmake:
Source/WebKit2:
Use USE(REDIRECTED_XCOMPOSITE_WINDOW) instead of
USE(TEXTURE_MAPPER_GL) && PLATFORM(X11).
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseRealize): Use the XID of the WebKitWebView
window as native surface handle when REDIRECTED_XCOMPOSITE_WINDOW
is disabled.
(webkitWebViewRenderAcceleratedCompositingResults):
(resizeWebKitWebViewBaseFromAllocation):
(webkitWebViewBaseEnterAcceleratedCompositingMode):
(webkitWebViewBaseExitAcceleratedCompositingMode):
* UIProcess/gtk/RedirectedXCompositeWindow.cpp:
* UIProcess/gtk/RedirectedXCompositeWindow.h:
Commit: 7691ce2f0d706e4934c573fd522f2aa6ad0fac93
https://github.com/WebKit/WebKit/commit/7691ce2f0d706e4934c573fd522f2aa6ad0fac93
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-03-23 (Mon, 23 Mar 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.8.0 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.8.0.
Commit: f825885c94e0ea27b85a4709a633680a6c830f0e
https://github.com/WebKit/WebKit/commit/f825885c94e0ea27b85a4709a633680a6c830f0e
Author: Manuel Rego Casasnovas <rego at igalia.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/css3/flexbox/flex-item-text-background-not-interleaved-expected.html
A LayoutTests/css3/flexbox/flex-item-text-background-not-interleaved.html
M LayoutTests/fast/css-grid-layout/float-not-protruding-into-next-grid-item-expected.html
M LayoutTests/fast/css-grid-layout/float-not-protruding-into-next-grid-item.html
A LayoutTests/fast/css-grid-layout/grid-item-text-background-not-interleaved-expected.html
A LayoutTests/fast/css-grid-layout/grid-item-text-background-not-interleaved.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/InlineElementBox.cpp
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/RenderBlock.h
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/RenderElement.h
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
Merge r181691 - Flex and grid items should be painted as inline-blocks
https://bugs.webkit.org/show_bug.cgi?id=142266
Reviewed by Darin Adler.
Source/WebCore:
Based on Blink r157004 by <cbiesinger at chromium.org>.
https://src.chromium.org/viewvc/blink?revision=157004&view=revision
Both flexbox and grid specs define that the painting order of flex/grid
items is the same as inline blocks. See
http://dev.w3.org/csswg/css-flexbox/#painting and
http://dev.w3.org/csswg/css-grid/#z-order.
Extracted inline blocks painting code from InlineElementBox and moved to
a helper method that will be reused for flexboxes and grids.
Tests: css3/flexbox/flex-item-text-background-not-interleaved.html
fast/css-grid-layout/grid-item-text-background-not-interleaved.html
* rendering/InlineElementBox.cpp:
(WebCore::InlineElementBox::paint): Move code to
RenderElement::paintAsInlineBlock().
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::paintChild): Add new argument to paint children
as inline blocks.
* rendering/RenderBlock.h: Define PaintType enmu and modify paintChild()
signature to add the new argument.
* rendering/RenderElement.cpp:
(WebCore::paintPhase): Paint element in a phase.
(WebCore::RenderElement::paintAsInlineBlock): Code extracted from
InlineElementBox::paint().
* rendering/RenderElement.h: Add new method signature.
* rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::paintChildren): Call
RenderBlock::paintChild() with the new argument.
* rendering/RenderGrid.cpp:
(WebCore::RenderGrid::paintChildren): Ditto.
LayoutTests:
* css3/flexbox/flex-item-text-background-not-interleaved-expected.html: Added.
* css3/flexbox/flex-item-text-background-not-interleaved.html: Added.
* fast/css-grid-layout/float-not-protruding-into-next-grid-item-expected.html:
Add some vertical space to avoid issues with backgrounds.
* fast/css-grid-layout/float-not-protruding-into-next-grid-item.html:
Ditto.
* fast/css-grid-layout/grid-item-text-background-not-interleaved-expected.html: Added.
* fast/css-grid-layout/grid-item-text-background-not-interleaved.html: Added.
Commit: 074d97386911b1eae6d72507e66d4b1d37e8d762
https://github.com/WebKit/WebKit/commit/074d97386911b1eae6d72507e66d4b1d37e8d762
Author: Anders Carlsson <andersca at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/Cookie.h
Log Message:
-----------
Merge r181709 - Pass cookies by reference in CookieHash functions
https://bugs.webkit.org/show_bug.cgi?id=142839
Reviewed by Sam Weinig.
* platform/Cookie.h:
(WebCore::CookieHash::hash):
(WebCore::CookieHash::equal):
Commit: b38659a351b138b695f64a75f67e6d8631e8bcaa
https://github.com/WebKit/WebKit/commit/b38659a351b138b695f64a75f67e6d8631e8bcaa
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/repaint/multiple-backgrounds-style-change-expected.txt
A LayoutTests/fast/repaint/multiple-backgrounds-style-change.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/style/FillLayer.cpp
M Source/WebCore/rendering/style/FillLayer.h
Log Message:
-----------
Merge r181710 - Avoid repaints when changing transform on an element with multiple background images
https://bugs.webkit.org/show_bug.cgi?id=142841
Reviewed by Zalan Bujtas.
Source/WebCore:
Replace the cheap test for changed images in RenderElement::updateFillImages()
with an exhaustive test that walks the entire list of background images,
since any ensuing repaint is way more expensive than a slightly more expensive check here.
Test: fast/repaint/multiple-backgrounds-style-change.html
* rendering/RenderElement.cpp:
(WebCore::RenderElement::updateFillImages):
* rendering/style/FillLayer.cpp:
(WebCore::layerImagesIdentical): See if both images are the same (either none
or both mask images, and same image pointer).
(WebCore::FillLayer::imagesIdentical): Walk the two FillLayer lists, checking the images
on each one. Returns false if we reach the end of one list before the other, or the images
are different.
* rendering/style/FillLayer.h: New static function; static because
it compares two FillLayer lists, and I think that makes more sense than
a member function.
LayoutTests:
Test that changes transform on a composited element with 2 background images,
and tests for no repaints.
* fast/repaint/multiple-backgrounds-style-change-expected.txt: Added.
* fast/repaint/multiple-backgrounds-style-change.html: Added.
Commit: 114d6aca3ba154d066cf0a698306839ee9fb12b1
https://github.com/WebKit/WebKit/commit/114d6aca3ba154d066cf0a698306839ee9fb12b1
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/as-image/svg-no-intrinsic-size-switching-expected.html
A LayoutTests/svg/as-image/svg-no-intrinsic-size-switching.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderImage.cpp
M Source/WebCore/rendering/RenderImage.h
M Source/WebCore/rendering/svg/RenderSVGForeignObject.cpp
Log Message:
-----------
Merge r181720 - Switching between two SVG images with no intrinsic sizes causes them to get the default SVG size instead of the container size.
https://bugs.webkit.org/show_bug.cgi?id=142805.
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-03-18
Reviewed by Darin Adler.
Source/WebCore:
The bug happens due to wrong logic in RenderImage::imageDimensionsChanged().
This function decides to setNeedsLayout() if the intrinsic size of the image
changes. If the size does not change, it only repaints the image rectangle.
When switching the src of the an image between two SVG images and both of
them have no intrinsic size, we do not updateInnerContentRect() and this
means an SVGImageForContainer is not going to be created for this image.
When the image is drawn, it is drawn directly from the SVGImage. And this
means the drawing has to be scaled by container_size / SVG_default_intrinsic_size
After figuring out that I need to updateInnerContentRect() to fix this bug,
I found out Blink has already changed this code to do the same thing. But
they also did more clean-up in this function. Here is the link
https://codereview.chromium.org/114323004. I think their change seems correct
although they did not say what exactly they were trying to fix.
The plan for repaintOrMarkForLayout(), which is the new name of this function,
is the following:
-- setNeedLayout() if the intrinsic size changes and it affects the size
of the image.
-- updateInnerContentRect() if the intrinsic size did not change but the
image has exiting layout.
-- repaint the image rectangle if layout is not needed.
This change also removes the call to computeLogicalWidthInRegion(), which is
almost running a layout for the image. This call figures out whether the image
needs to setNeedsLayout(). This call is unnecessary; the image needs to run a
layout if the intrinsic size has changed and it affects the size of the image.
Test: svg/as-image/svg-no-intrinsic-size-switching.html
* rendering/RenderImage.cpp:
(WebCore::RenderImage::styleDidChange): Change the function call.
(WebCore::RenderImage::imageChanged): Rename local variable and change the
function call.
(WebCore::RenderImage::updateIntrinsicSizeIfNeeded): Simplify this function.
Call setIntrinsicSize() with the new size unless the image is in error state.
(WebCore::RenderImage::repaintOrMarkForLayout): This a better name for this
function since it is called even if the intrinsic size was not changed.
(WebCore::RenderImage::imageDimensionsChanged): Deleted.
* rendering/RenderImage.h: Rename imageDimensionsChanged() and change the
updateIntrinsicSizeIfNeeded() to return void.
* rendering/svg/RenderSVGForeignObject.cpp:
(WebCore::RenderSVGForeignObject::paint): Code cleanup. This function can
only handle the paint phases PaintPhaseForeground and PaintPhaseSelection.
Use this information to simplify the logic and order of painting there.
LayoutTests:
* svg/as-image/svg-no-intrinsic-size-switching-expected.html: Added.
* svg/as-image/svg-no-intrinsic-size-switching.html: Added.
Ensure that switching the source of an <img> element between two SVG images,
which have no intrinsic sizes, gets the image the size of the container and
not the default SVG intrinsic size which is 300x150 pixels.
Commit: 1bc74215ba38af139be9ad7a1d8c652a787b8570
https://github.com/WebKit/WebKit/commit/1bc74215ba38af139be9ad7a1d8c652a787b8570
Author: Andreas Kling <akling at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/JSCallee.cpp
M Source/JavaScriptCore/runtime/JSCallee.h
Log Message:
-----------
Merge r181765 - JSCallee unnecessarily overrides a bunch of things in the method table.
<https://webkit.org/b/142855>
Reviewed by Geoffrey Garen.
Remove JSCallee method table overrides that simply call to base class.
This makes JSFunction property slot lookups slightly more efficient since
they can take the fast path when passing over JSCallee in the base class chain.
* runtime/JSCallee.cpp:
(JSC::JSCallee::getOwnPropertySlot): Deleted.
(JSC::JSCallee::getOwnNonIndexPropertyNames): Deleted.
(JSC::JSCallee::put): Deleted.
(JSC::JSCallee::deleteProperty): Deleted.
(JSC::JSCallee::defineOwnProperty): Deleted.
* runtime/JSCallee.h:
Commit: 16a4b4daf7e3d18d226d00e90e7158e6aed7f855
https://github.com/WebKit/WebKit/commit/16a4b4daf7e3d18d226d00e90e7158e6aed7f855
Author: Joseph Pecoraro <pecoraro at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/editing/selection/click-after-last-inline-crash-expected.txt
A LayoutTests/editing/selection/click-after-last-inline-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RootInlineBox.cpp
Log Message:
-----------
Merge r181773 - Source/WebCore:
REGRESSION (r109593): Clicking after last inline element could cause a crash.
https://bugs.webkit.org/show_bug.cgi?id=142880
rdar://problem/17222294
Reviewed by Ryosuke Niwa.
Test: editing/selection/click-after-last-inline-crash.html
* rendering/RootInlineBox.cpp:
(WebCore::RootInlineBox::closestLeafChildForLogicalLeftPosition):
LayoutTests:
Web Inspector: Adopt ES6 Class Syntax for all Model Objects
https://bugs.webkit.org/show_bug.cgi?id=142858
Patch by Joseph Pecoraro <pecoraro at apple.com> on 2015-03-19
Reviewed by Timothy Hatcher.
* inspector/model/parse-script-syntax-tree.html:
This test was calling a constructor without "new". Class
syntax enforces "new" and threw an exception.
Commit: 2b52f0de667e76f1190eec1650794b9ce9159d96
https://github.com/WebKit/WebKit/commit/2b52f0de667e76f1190eec1650794b9ce9159d96
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGOperations.cpp
M Source/JavaScriptCore/jit/JITOperations.cpp
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp
M Source/JavaScriptCore/runtime/CommonSlowPaths.h
M Source/JavaScriptCore/runtime/JSCJSValue.h
M Source/JavaScriptCore/runtime/JSCJSValueInlines.h
M Source/JavaScriptCore/runtime/ObjectConstructor.cpp
M Source/JavaScriptCore/runtime/ObjectPrototype.cpp
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/js/JSDOMWindowCustom.cpp
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
M Source/WebCore/bindings/scripts/test/JS/JSTestCustomNamedGetter.cpp
M Source/WebCore/bindings/scripts/test/JS/JSTestEventTarget.cpp
M Source/WebCore/bindings/scripts/test/JS/JSTestInterface.cpp
Log Message:
-----------
Merge r181814 - REGRESSION (r179429): Potential Use after free in JavaScriptCore`WTF::StringImpl::ref + 83
https://bugs.webkit.org/show_bug.cgi?id=142410
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
Before this patch, added function JSValue::toPropertyKey returns PropertyName.
Since PropertyName doesn't have AtomicStringImpl ownership,
if Identifier is implicitly converted to PropertyName and Identifier is destructed,
PropertyName may refer freed AtomicStringImpl*.
This patch changes the result type of JSValue::toPropertyName from PropertyName to Identifier,
to keep AtomicStringImpl* ownership after the toPropertyName call is done.
And receive the result value as Identifier type to keep ownership in the caller side.
To catch the result of toPropertyKey as is, we catch the result of toPropertyName as auto.
However, now we don't need to have both Identifier and PropertyName.
So we'll merge PropertyName to Identifier in the subsequent patch.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* jit/JITOperations.cpp:
(JSC::getByVal):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toPropertyKey):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorDefineProperty):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncPropertyIsEnumerable):
Source/WebCore:
The same issues are found in the existing code; PropertyName does not have ownership.
This patch rewrite the point that should have ownership to Identifier.
* bindings/js/JSDOMWindowCustom.cpp:
(WebCore::JSDOMWindow::getOwnPropertySlotByIndex):
(WebCore::JSDOMWindow::putByIndex):
* bindings/js/ReadableStreamJSSource.cpp:
(WebCore::getInternalSlotFromObject):
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateImplementation):
* bindings/scripts/test/JS/JSTestCustomNamedGetter.cpp:
(WebCore::JSTestCustomNamedGetter::getOwnPropertySlotByIndex):
* bindings/scripts/test/JS/JSTestEventTarget.cpp:
(WebCore::JSTestEventTarget::getOwnPropertySlotByIndex):
* bindings/scripts/test/JS/JSTestInterface.cpp:
(WebCore::JSTestInterface::putByIndex):
Commit: dcda52206f3e5870771372e3e0a17554b03c6334
https://github.com/WebKit/WebKit/commit/dcda52206f3e5870771372e3e0a17554b03c6334
Author: Andreas Kling <akling at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp
M Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h
Log Message:
-----------
Merge r181828 - Make UnlinkedFunctionExecutable fit in a 128-byte cell.
<https://webkit.org/b/142939>
Reviewed by Mark Hahnenberg.
Re-arrange the members of UnlinkedFunctionExecutable so it can fit inside
a 128-byte heap cell instead of requiring a 256-byte one.
Threw in a static_assert to catch anyone pushing it over the limit again.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::functionMode):
Commit: c09badf945651ac2dc10fad111604ca1c31e9368
https://github.com/WebKit/WebKit/commit/c09badf945651ac2dc10fad111604ca1c31e9368
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGOSRExitCompiler32_64.cpp
M Source/JavaScriptCore/dfg/DFGOSRExitCompiler64.cpp
M Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp
Log Message:
-----------
Merge r181835 - DFG OSR exit shouldn't assume that the frame count for exit is greater than the frame count in DFG
https://bugs.webkit.org/show_bug.cgi?id=142948
Reviewed by Sam Weinig.
It's necessary to ensure that the stack pointer accounts for the extent of our stack usage
since a signal may clobber the area below the stack pointer. When the DFG is executing,
the stack pointer accounts for the DFG's worst-case stack usage. When we OSR exit back to
baseline, we will use a different amount of stack. This is because baseline is a different
compiler. It will make different decisions. So it will use a different amount of stack.
This gets tricky when we are in the process of doing an OSR exit, because we are sort of
incrementally transforming the stack from how it looked in the DFG to how it will look in
baseline. The most conservative approach would be to set the stack pointer to the max of
DFG and baseline.
When this code was written, a reckless assumption was made: that the stack usage in
baseline is always at least as large as the stack usage in DFG. Based on this incorrect
assumption, the code first adjusts the stack pointer to account for the baseline stack
usage. This sort of usually works, because usually baseline does happen to use more stack.
But that's not an invariant. Nobody guarantees this. We will never make any changes that
would make this be guaranteed, because that would be antithetical to how optimizing
compilers work. The DFG should be allowed to use however much stack it decides that it
should use in order to get good performance, and it shouldn't try to guarantee that it
always uses less stack than baseline.
As such, we must always assume that the frame size for DFG execution (i.e.
frameRegisterCount) and the frame size in baseline once we exit (i.e.
requiredRegisterCountForExit) are two independent quantities and they have no
relationship.
Fortunately, though, this code can be made correct by just moving the stack adjustment to
just before we do conversions. This is because we have since changed the OSR exit
algorithm to first lift up all state from the DFG state into a scratch buffer, and then to
drop it out of the scratch buffer and into the stack according to the baseline layout. The
point just before conversions is the point where we have finished reading the DFG frame
and will not read it anymore, and we haven't started writing the baseline frame. So, at
this point it is safe to set the stack pointer to account for the frame size at exit.
This is benign because baseline happens to create larger frames than DFG.
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget):
Commit: 7e834f3632712e000d643a17c86f5447acfeec56
https://github.com/WebKit/WebKit/commit/7e834f3632712e000d643a17c86f5447acfeec56
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitBackForwardList.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitBackForwardListPrivate.h
Log Message:
-----------
Merge r181850 - [GTK][WK2] webkitBackForwardListChanged() should operate on a Vector reference
https://bugs.webkit.org/show_bug.cgi?id=142963
Reviewed by Carlos Garcia Campos.
* UIProcess/API/gtk/WebKitBackForwardList.cpp:
(webkitBackForwardListChanged): This function only reads from the passed-in
Vector of removed items, so only a const lvalue reference to the Vector
is needed.
* UIProcess/API/gtk/WebKitBackForwardListPrivate.h:
Commit: e8ba31ad2d5f391013dc4d9e95102658a3636e59
https://github.com/WebKit/WebKit/commit/e8ba31ad2d5f391013dc4d9e95102658a3636e59
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
Log Message:
-----------
Merge r181851 - [GTK] Use std::abs() in ClickCounter::currentClickCountForGdkButtonEvent()
https://bugs.webkit.org/show_bug.cgi?id=142964
Reviewed by Carlos Garcia Campos.
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(ClickCounter::currentClickCountForGdkButtonEvent): Use the STL's std::abs()
instead of C's abs(). The templated nature of std::abs() ensures the proper
computation that matches the types of the passed-in values, and shuts down
a warning when compiling with Clang.
Commit: 932950e518ceafb79d2f4f383a7b7d5613bf0361
https://github.com/WebKit/WebKit/commit/932950e518ceafb79d2f4f383a7b7d5613bf0361
Author: Anders Carlsson <andersca at apple.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/Plugins/NPObjectMessageReceiver.cpp
Log Message:
-----------
Merge r181864 - Source/WebKit2:
Make platform/mac-wk2/plugins/destroy-during-async-npp-new.html work again.
https://bugs.webkit.org/show_bug.cgi?id=133692
rdar://problem/17255947
Reviewed by Alexey Proskuryakov.
Add plug-in destruction protectors around message receiver code that can call out to NPObjects or JavaScript
where we need the plug-in to stay around after the call.
* Shared/Plugins/NPObjectMessageReceiver.cpp:
(WebKit::NPObjectMessageReceiver::invoke):
(WebKit::NPObjectMessageReceiver::invokeDefault):
(WebKit::NPObjectMessageReceiver::getProperty):
(WebKit::NPObjectMessageReceiver::setProperty):
(WebKit::NPObjectMessageReceiver::construct):
LayoutTests:
Make platform/mac-wk2/plugins/destroy-during-async-npp-new.html work again
https://bugs.webkit.org/show_bug.cgi?id=133692
rdar://problem/17255947
Reviewed by Alexey Proskuryakov.
* platform/mac-wk2/TestExpectations:
Unskip test.
Commit: 232f755c5f878e7001ab09e173aed959739fcaf9
https://github.com/WebKit/WebKit/commit/232f755c5f878e7001ab09e173aed959739fcaf9
Author: Yoav Weiss <yoav at yoav.ws>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
R LayoutTests/canvas/philip/tests/2d.drawImage.incomplete-expected.txt
A LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.emptysrc-expected.txt
A LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.emptysrc.html
R LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.html
A LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.nosrc-expected.txt
A LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.nosrc.html
A LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.removedsrc-expected.txt
A LayoutTests/canvas/philip/tests/2d.drawImage.incomplete.removedsrc.html
R LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete-expected.txt
R LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.empty-expected.txt
R LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.empty.html
A LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.emptysrc-expected.txt
A LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.emptysrc.html
R LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.html
R LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.omitted-expected.txt
R LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.omitted.html
A LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.removedsrc-expected.txt
A LayoutTests/canvas/philip/tests/2d.pattern.image.incomplete.removedsrc.html
R LayoutTests/fast/canvas/canvas-empty-image-pattern-expected.png
M LayoutTests/fast/canvas/canvas-empty-image-pattern-expected.txt
M LayoutTests/fast/canvas/canvas-empty-image-pattern.html
M Source/WebCore/ChangeLog
M Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp
Log Message:
-----------
Merge r181888 - Update empty image canvas tests and fix a related bug
https://bugs.webkit.org/show_bug.cgi?id=142694
Reviewed by Chris Dumez.
Source/WebCore:
During the work on https://bugs.webkit.org/show_bug.cgi?id=142677
we encountered an issue with canvas tests related to empty image handling
when drawn or used as a pattern. After updating these tests, an issue with
pattern handling was encountered.
The spec, as well as Chrome's implementation, say that when an empty image
is used as a pattern, createPattern should return null. See
https://html.spec.whatwg.org/multipage/scripting.html#fill-and-stroke-styles:check-the-usability-of-the-image-argument
Instead, createPattern returned an exception in this case.
This patch fixes that and makes sure that it returns a null when image loading hasn't started.
Tests: canvas/philip/tests/2d.drawImage.incomplete.emptysrc.html
canvas/philip/tests/2d.drawImage.incomplete.nosrc.html
canvas/philip/tests/2d.drawImage.incomplete.removedsrc.html
canvas/philip/tests/2d.pattern.image.incomplete.emptysrc.html
canvas/philip/tests/2d.pattern.image.incomplete.removedsrc.html
* html/canvas/CanvasRenderingContext2D.cpp:
(WebCore::CanvasRenderingContext2D::createPattern): Return "null" if image is not fully decodeable.
LayoutTests:
Tests below imported from https://github.com/w3c/web-platform-tests/tree/master/2dcontext/drawing-images-to-the-canvas
* canvas/philip/tests/2d.drawImage.incomplete-expected.txt: Removed.
* canvas/philip/tests/2d.drawImage.incomplete.emptysrc-expected.txt: Added.
* canvas/philip/tests/2d.drawImage.incomplete.emptysrc.html: Added.
* canvas/philip/tests/2d.drawImage.incomplete.html: Removed.
* canvas/philip/tests/2d.drawImage.incomplete.nosrc-expected.txt: Added.
* canvas/philip/tests/2d.drawImage.incomplete.nosrc.html: Added.
* canvas/philip/tests/2d.drawImage.incomplete.removedsrc-expected.txt: Added.
* canvas/philip/tests/2d.drawImage.incomplete.removedsrc.html: Added.
Tests below imported from https://github.com/w3c/web-platform-tests/tree/master/2dcontext/fill-and-stroke-styles
* canvas/philip/tests/2d.pattern.image.incomplete-expected.txt: Removed.
* canvas/philip/tests/2d.pattern.image.incomplete.empty-expected.txt: Removed.
* canvas/philip/tests/2d.pattern.image.incomplete.empty.html: Removed.
* canvas/philip/tests/2d.pattern.image.incomplete.emptysrc-expected.txt: Added.
* canvas/philip/tests/2d.pattern.image.incomplete.emptysrc.html: Added.
* canvas/philip/tests/2d.pattern.image.incomplete.html: Removed.
* canvas/philip/tests/2d.pattern.image.incomplete.omitted-expected.txt: Removed.
* canvas/philip/tests/2d.pattern.image.incomplete.omitted.html: Removed.
* canvas/philip/tests/2d.pattern.image.incomplete.removedsrc-expected.txt: Added.
This test currently fails and will be fixed in https://bugs.webkit.org/show_bug.cgi?id=142677
* canvas/philip/tests/2d.pattern.image.incomplete.removedsrc.html: Added.
Test below imported from https://chromium.googlesource.com/chromium/blink/+/master/LayoutTests/fast/canvas/
* fast/canvas/canvas-empty-image-pattern.html: Aligned with spec/Chrome.
* fast/canvas/canvas-empty-image-pattern-expected.txt: Aligned with spec/Chrome.
* TestExpectations: Added 2d.pattern.image.incomplete.removedsrc.html as an expected failure.
Commit: 2e9ee329b6d994efa5f050605bdb3be3282db864
https://github.com/WebKit/WebKit/commit/2e9ee329b6d994efa5f050605bdb3be3282db864
Author: Yoav Weiss <yoav at yoav.ws>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/canvas/philip/tests/2d.drawImage.image.incomplete.omitted-expected.txt
A LayoutTests/fast/dom/HTMLImageElement/image-empty-src-expected.html
A LayoutTests/fast/dom/HTMLImageElement/image-empty-src.html
A LayoutTests/fast/dom/HTMLImageElement/image-empty-srcset-expected.html
A LayoutTests/fast/dom/HTMLImageElement/image-empty-srcset.html
A LayoutTests/fast/dom/HTMLImageElement/image-remove-src-expected.html
A LayoutTests/fast/dom/HTMLImageElement/image-remove-src.html
A LayoutTests/fast/dom/HTMLImageElement/image-remove-srcset-expected.html
A LayoutTests/fast/dom/HTMLImageElement/image-remove-srcset.html
R LayoutTests/platform/mac/canvas/philip/tests/2d.drawImage.image.incomplete.omitted-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ImageLoader.cpp
Log Message:
-----------
Merge r181897 - Stop image from displaying when src attribute is removed or emptied
https://bugs.webkit.org/show_bug.cgi?id=142677
Reviewed by Chris Dumez.
Source/WebCore:
Previously, we ignored empty attribute as failed URL, and didn't update the
renderer when an image was removed. This patch fixes that.
Tests: fast/dom/HTMLImageElement/image-empty-src.html
fast/dom/HTMLImageElement/image-remove-src.html
* loader/ImageLoader.cpp:
(WebCore::ImageLoader::updateFromElement):
LayoutTests:
* fast/dom/HTMLImageElement/image-empty-src-expected.html: Added.
* fast/dom/HTMLImageElement/image-empty-src.html: Added.
* fast/dom/HTMLImageElement/image-remove-src-expected.html: Added.
* fast/dom/HTMLImageElement/image-remove-src.html: Added.
* fast/dom/HTMLImageElement/image-empty-srcset-expected.html: Added.
* fast/dom/HTMLImageElement/image-empty-srcset.html: Added.
* fast/dom/HTMLImageElement/image-remove-srcset-expected.html: Added.
* fast/dom/HTMLImageElement/image-remove-srcset.html: Added.
Commit: 06a81ad331f666b9942c89d7e3b3d1b046a3cbe8
https://github.com/WebKit/WebKit/commit/06a81ad331f666b9942c89d7e3b3d1b046a3cbe8
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.h
Log Message:
-----------
Merge r181937 - [WK2] Clean up DrawingAreaImpl vtable overrides
https://bugs.webkit.org/show_bug.cgi?id=143044
Reviewed by Carlos Garcia Campos.
Declare virtual methods of the DrawingAreaImpl class as overridden where necessary.
* WebProcess/WebPage/DrawingAreaImpl.h:
(WebKit::DrawingAreaImpl::layerTreeStateIsFrozen): Deleted.
(WebKit::DrawingAreaImpl::layerTreeHost): Deleted.
Commit: 405e9609a16ea4b5d65c72aab87920a5218bf087
https://github.com/WebKit/WebKit/commit/405e9609a16ea4b5d65c72aab87920a5218bf087
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebPageProxy.h
Log Message:
-----------
Merge r181938 - [GTK][WK2] WebPageProxy::failedToShowPopupMenu() virtual method should be marked as override
https://bugs.webkit.org/show_bug.cgi?id=143045
Reviewed by Carlos Garcia Campos.
* UIProcess/WebPageProxy.h: Mark the failedToShowPopupMenu(), inherited from
the WebPopupMenuProxy::Client class, as overridden.
Commit: c799bcc3d3d8583ba8efa6f54e97e8fd2b4be630
https://github.com/WebKit/WebKit/commit/c799bcc3d3d8583ba8efa6f54e97e8fd2b4be630
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-03-25 (Wed, 25 Mar 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebCoreSupport/WebUserMediaClient.h
Log Message:
-----------
Merge r181943 - [WK2] WebUserMediaClient::pageDestroyed() virtual method should be marked as override
https://bugs.webkit.org/show_bug.cgi?id=143046
Reviewed by Carlos Garcia Campos.
* WebProcess/WebCoreSupport/WebUserMediaClient.h: Mark the WebUserMediaClient::pageDestroyed()
method, inherited from the WebCore::UserMediaClient, as an override.
Commit: 1a5d2ac05600345cdc038683467b0ca26708fe33
https://github.com/WebKit/WebKit/commit/1a5d2ac05600345cdc038683467b0ca26708fe33
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-04-06 (Mon, 06 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/inline/crash-when-position-property-is-changed-and-no-longer-in-continuation-expected.txt
A LayoutTests/fast/inline/crash-when-position-property-is-changed-and-no-longer-in-continuation.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderInline.cpp
Log Message:
-----------
Merge r182051 - Inline continuation code should not take anonymous containing wrapper granted.
https://bugs.webkit.org/show_bug.cgi?id=133312
Reviewed by Dave Hyatt.
It's wrong to assume that when RenderInline is part of an inline continuation, its containing block
is an anonymous wrapper and its sibling might be a block level renderer.
When the inline continuation is no longer needed, for example when the block level renderer that initiated the continuation
is detached from the render tree, the inline renderes still continue to form continuation.(however they no longer require
anonymous wrappers)
Source/WebCore:
Test: fast/inline/crash-when-position-property-is-changed-and-no-longer-in-continuation.html
* rendering/RenderInline.cpp:
(WebCore::updateStyleOfAnonymousBlockContinuations):
(WebCore::RenderInline::styleDidChange):
LayoutTests:
* fast/inline/crash-when-position-property-is-changed-and-no-longer-in-continuation-expected.txt: Added.
* fast/inline/crash-when-position-property-is-changed-and-no-longer-in-continuation.html: Added.
Commit: 67be963b63ff31cb48756705f1284b103c1ccd36
https://github.com/WebKit/WebKit/commit/67be963b63ff31cb48756705f1284b103c1ccd36
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-04-06 (Mon, 06 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/PlatformGTK.cmake
R Source/WebCore/platform/gtk/DragIcon.cpp
R Source/WebCore/platform/gtk/DragIcon.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp
M Source/WebKit2/UIProcess/gtk/DragAndDropHandler.cpp
M Source/WebKit2/UIProcess/gtk/DragAndDropHandler.h
Log Message:
-----------
Merge r182175 - [GTK] DnD icon/widget has odd background
https://bugs.webkit.org/show_bug.cgi?id=143217
Reviewed by Martin Robinson.
Source/WebCore:
Remove DragIcon class since it's no longer needed with GTK+3 and
the GTK+2 code there is unused. GTK+ knows what to do with a cairo
surface, I guess we migrated the GTK+2 code to GTK+3 without
realizing that using the surface was enough.
* PlatformGTK.cmake:
* platform/gtk/DragIcon.cpp: Removed.
* platform/gtk/DragIcon.h: Removed.
Source/WebKit2:
Use gtk_drag_set_icon_surface() to set the drag icon image,
instead of DragIcon class.
* UIProcess/API/gtk/WebKitWebView.cpp:
* UIProcess/gtk/DragAndDropHandler.cpp:
(WebKit::DragAndDropHandler::startDrag):
* UIProcess/gtk/DragAndDropHandler.h:
Commit: 80c361cb729ea12ece21bfba7372ecc0893f70fd
https://github.com/WebKit/WebKit/commit/80c361cb729ea12ece21bfba7372ecc0893f70fd
Author: Tobias Reiss <tobi+webkit at basecode.de>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebInspectorUI/ChangeLog
M Source/WebInspectorUI/UserInterface/Models/DOMNodeStyles.js
Log Message:
-----------
Merge r181916 - Web Inspector: REGRESSION (r179286): ReferenceError: Can't find variable: selector
https://bugs.webkit.org/show_bug.cgi?id=143022
Patch by Tobias Reiss <tobi+webkit at basecode.de> on 2015-03-24
Reviewed by Timothy Hatcher.
Fix a regression where a missing variable statement causes a ReferenceError.
* UserInterface/Models/DOMNodeStyles.js:
Commit: d1841ec1ca23af5efa42b71bd2fe8e82035a42b3
https://github.com/WebKit/WebKit/commit/d1841ec1ca23af5efa42b71bd2fe8e82035a42b3
Author: Zhuo Li <zachli at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/http/tests/security/isolatedWorld/bypass-main-world-csp-expected.txt
M LayoutTests/http/tests/security/isolatedWorld/bypass-main-world-csp.html
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/js/ScriptController.cpp
Log Message:
-----------
Merge r181925 - Scripts running in isolated world should not subject to a page's CSP about 'eval'.
https://bugs.webkit.org/show_bug.cgi?id=141316.
Patch by Zhuo Li <zachli at apple.com> on 2015-03-24
Reviewed by Geoffrey Garen.
Source/WebCore:
* bindings/js/ScriptController.cpp:
(WebCore::ScriptController::initScript):
We should not impose the main world Content Security Policy onto the isolated world.
LayoutTests:
I added a new Content Security Policy directive, "script-src", so that we do not
allow 'unsafe-eval' in the main world.
Also I have to copy the whole function instead of using eval because
eval is subject to the main world Content Security Policy now.
* http/tests/security/isolatedWorld/bypass-main-world-csp-expected.txt:
* http/tests/security/isolatedWorld/bypass-main-world-csp.html:
Commit: c09df9ee808683b6abb08e38aba300c0a7d8a8e9
https://github.com/WebKit/WebKit/commit/c09df9ee808683b6abb08e38aba300c0a7d8a8e9
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/API/JSContextRef.cpp
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/llint/LowLevelInterpreter.asm
Log Message:
-----------
Merge r181981 - REGRESSION(169139): LLINT intermittently fails JSC testapi tests.
<https://webkit.org/b/135719>
Reviewed by Geoffrey Garen.
This is a regression introduced in http://trac.webkit.org/changeset/169139 which
changed VM::watchdog from an embedded field into a std::unique_ptr, but did not
update the LLINT to access it as such.
The issue has only manifested so far on the CLoop tests because those are LLINT
only. In the non-CLoop cases, the JIT kicks in and does the right thing, thereby
hiding the bug in the LLINT.
* API/JSContextRef.cpp:
(createWatchdogIfNeeded):
(JSContextGroupSetExecutionTimeLimit):
(JSContextGroupClearExecutionTimeLimit):
* llint/LowLevelInterpreter.asm:
Commit: 94fee7e1bd6cd1c498691436821784d332ba5b4d
https://github.com/WebKit/WebKit/commit/94fee7e1bd6cd1c498691436821784d332ba5b4d
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
Log Message:
-----------
Merge r181991 - [WK2] WebFrameLoaderClient::dispatchDecidePolicyForResponse() should always call the FramePolicyFunction
https://bugs.webkit.org/show_bug.cgi?id=143036
<rdar://problem/20252438>
<rdar://problem/13811738>
Reviewed by Alexey Proskuryakov.
WebFrameLoaderClient::dispatchDecidePolicyForResponse() should always
call the FramePolicyFunction. Previously, it would fail to do in 2
cases:
- m_frame->page() returns null
or
- webPage->sendSync() returns false
If the FramePolicyFunction is not called, we will fail to clear the
callback in the PolicyChecker and
DocumentLoader::continueAfterContentPolicy() will not be called.
DocumentLoader::continueAfterContentPolicy() is in charge of resetting
m_waitingForContentPolicy flag to false. This could therefore explain
the following assertion being hit in DocumentLoader::detachFromFrame()
(see <rdar://problem/20252438>):
RELEASE_ASSERT(!m_waitingForContentPolicy)
Also, as the PolicyChecker callback is not cleared, it could make it
possible for DocumentLoader::continueAfterContentPolicy() to be called
*after* the load is finished, when later canceling the PolicyCallback:
FrameLoader::stopAllLoaders()
-> PolicyChecker::stopCheck()
-> PolicyCallback::cancel()
-> DocumentLoader::continueAfterContentPolicy(PolicyIgnore)
Calling continueAfterContentPolicy(PolicyIgnore) after the load is
finished would be bad and could explain some of the crashes we've seen
in DocumentLoader::continueAfterContentPolicy() ->
DocumentLoader:: stopLoadingForPolicyChange() (see
<rdar://problem/13811738>).
This patch also applies the same fix to
dispatchDecidePolicyForNewWindowAction() and
dispatchDecidePolicyForNavigationAction() as they use the same pattern.
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse):
(WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNewWindowAction):
(WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction):
Commit: ac74973cb6a7074e2bdcfc8c687ca5247627f42c
https://github.com/WebKit/WebKit/commit/ac74973cb6a7074e2bdcfc8c687ca5247627f42c
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/NativeWebTouchEvent.h
M Source/WebKit2/Shared/WebEvent.h
M Source/WebKit2/Shared/WebTouchEvent.cpp
M Source/WebKit2/Shared/efl/WebEventFactory.cpp
M Source/WebKit2/Shared/gtk/NativeWebTouchEventGtk.cpp
M Source/WebKit2/Shared/gtk/WebEventFactory.cpp
M Source/WebKit2/Shared/gtk/WebEventFactory.h
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
Log Message:
-----------
Merge r182005 - Avoid the Vector<> copy in WebTouchEvent constructor
https://bugs.webkit.org/show_bug.cgi?id=143043
Reviewed by Carlos Garcia Campos.
Have the WebTouchEvent accept a Vector<> rvalue.
The relevant code is updated so the Vector<> object is moved
through the call chain and finally into the WebTouchEvent constructor.
* Shared/NativeWebTouchEvent.h:
* Shared/WebEvent.h:
* Shared/WebTouchEvent.cpp:
(WebKit::WebTouchEvent::WebTouchEvent):
* Shared/efl/WebEventFactory.cpp:
(WebKit::WebEventFactory::createWebTouchEvent):
* Shared/gtk/NativeWebTouchEventGtk.cpp:
(WebKit::NativeWebTouchEvent::NativeWebTouchEvent):
* Shared/gtk/WebEventFactory.cpp:
(WebKit::WebEventFactory::createWebTouchEvent):
* Shared/gtk/WebEventFactory.h:
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseTouchEvent):
Commit: 195f59d0506abc483cdaf04ba92ff61b78f0d71d
https://github.com/WebKit/WebKit/commit/195f59d0506abc483cdaf04ba92ff61b78f0d71d
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/Font.cpp
Log Message:
-----------
Merge r182015 - Crash when laying out (char)0
https://bugs.webkit.org/show_bug.cgi?id=143103
Reviewed by Dean Jackson.
We currently cache a character -> Font mapping in a HashMap.
However, keys in Hashmaps can't be 0. This patch simply skips
the cache in this case.
No new tests, for now. I'm having trouble creating a test because
the site that causes this bug generates their page using script,
and the script is all minified, and difficult to understand. I
will contact the owner of the site and ask for and unminified
version of their sources. However, I don't want to that to block
this tiny fix from going in.
* platform/graphics/Font.cpp:
(WebCore::Font::systemFallbackFontForCharacter):
Commit: f8611a8d1de66e5fe5d652386028ffd562b01f07
https://github.com/WebKit/WebKit/commit/f8611a8d1de66e5fe5d652386028ffd562b01f07
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/js/regress-142792-expected.txt
A LayoutTests/js/regress-142792.html
A LayoutTests/js/script-tests/regress-142792.js
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/ARM64Assembler.h
Log Message:
-----------
Merge r182058 - Objects with numeric properties intermittently get a phantom 'length' property
https://bugs.webkit.org/show_bug.cgi?id=142792
Reviewed by Csaba Osztrogonác.
Source/JavaScriptCore:
Fixed a > (greater than) that should be a >> (right shift) in the code that disassembles
test and branch instructions. This function is used for linking tbz/tbnz branches between
two seperately JIT'ed sections of code. Sometime we'd create a bogus tbz instruction in
the failure case checks in the GetById array length stub created for "obj.length" access.
If the failure case code address was at a negative offset from the stub, we'd look for bit 1
being set when we should have been looking for bit 0.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::disassembleTestAndBranchImmediate):
LayoutTests:
New regression test.
* js/regress-142792-expected.txt: Added.
* js/regress-142792.html: Added.
* js/script-tests/regress-142792.js: Added.
(isArrayLike):
(filter):
Commit: 2a016fe267df95fc412bd5450b2baaad6a28ffea
https://github.com/WebKit/WebKit/commit/2a016fe267df95fc412bd5450b2baaad6a28ffea
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/filters/feMorphology-radius-cases-expected.svg
A LayoutTests/svg/filters/feMorphology-radius-cases.svg
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/filters/FEMorphology.cpp
M Source/WebCore/platform/graphics/filters/FEMorphology.h
Log Message:
-----------
Merge r182067 - FEMorphology::platformApplyGeneric() should bail out if the radius is less than or equal to zero.
https://bugs.webkit.org/show_bug.cgi?id=142885.
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-03-27
Reviewed by Dean Jackson.
Source/WebCore:
FEMorphology class implementation code clean up.
Tests: svg/filters/feMorphology-radius-cases.svg
* platform/graphics/filters/FEMorphology.cpp:
(WebCore::shouldSupersedeExtremum): Reuse code instead of repeating it and
use < and > instead of =< and >=.
(WebCore::pixelArrayIndex): Returns the array index of a pixel in an image
buffer, given: position(x, y), image width and the color channel.
(WebCore::columnExtremum): Returns the extremum of a column of pixels.
(WebCore::kernelExtremum): Returns the extremum of a filter kernel.
(WebCore::FEMorphology::platformApplyGeneric): Apply some code clean-up.
The kernel size should be equal to radius of the filter. The extra pixel
was causing the resulted image to be asymmetric in some cases.
(WebCore::FEMorphology::platformApplyDegenerate):
(WebCore::FEMorphology::platformApplySoftware): After applying scaling, we
still need to check the resulted radius is negative (overflow case) or less
than one (zero radius case) and treat these cases differently.
(WebCore::FEMorphology::morphologyOperator): Deleted.
(WebCore::FEMorphology::radiusX): Deleted.
(WebCore::FEMorphology::radiusY): Deleted.
* platform/graphics/filters/FEMorphology.h:
(WebCore::FEMorphology::morphologyOperator):
(WebCore::FEMorphology::radiusX):
(WebCore::FEMorphology::radiusY):
Move a single line functions from the source file to the header file.
LayoutTests:
* svg/filters/feMorphology-radius-cases-expected.svg: Added.
* svg/filters/feMorphology-radius-cases.svg: Added.
Test different cases for radius of the feMorphology filter. There are three
cases for the radius:
1. radius < 0: This is an error case, the source image should not be rendered.
2. radius = 0: This case is treated as if the filter never exists.
3. radius > 0: If the scaled radius is > 0, the filter is applied.
Commit: 98fad83d9e633efd026da6c35398d38e23943b80
https://github.com/WebKit/WebKit/commit/98fad83d9e633efd026da6c35398d38e23943b80
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/API/JSCallbackObject.h
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/heap/IncrementalSweeper.h
M Source/JavaScriptCore/jit/JITThunks.h
M Source/JavaScriptCore/runtime/JSGlobalObjectDebuggable.h
M Source/JavaScriptCore/runtime/RegExpCache.h
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/geolocation/GeolocationController.h
M Source/WebCore/Modules/geolocation/NavigatorGeolocation.h
M Source/WebCore/Modules/indexeddb/DOMWindowIndexedDatabase.h
M Source/WebCore/Modules/notifications/NotificationController.h
M Source/WebCore/Modules/webdatabase/DatabaseServer.h
M Source/WebCore/css/CSSFontFaceSource.h
M Source/WebCore/html/HTMLMediaSession.h
M Source/WebCore/inspector/InspectorIndexedDBAgent.h
M Source/WebCore/inspector/InspectorReplayAgent.h
M Source/WebCore/page/CaptionUserPreferencesMediaAF.h
M Source/WebCore/page/PageConsoleClient.h
M Source/WebCore/page/PageDebuggable.h
M Source/WebCore/page/animation/CSSPropertyAnimation.cpp
M Source/WebCore/page/mac/ServicesOverlayController.h
M Source/WebCore/platform/RemoteCommandListener.h
M Source/WebCore/platform/Timer.h
M Source/WebCore/platform/audio/MediaSessionManager.h
M Source/WebCore/platform/mac/SystemSleepListenerMac.h
M Source/WebCore/platform/mac/ThemeMac.h
M Source/WebCore/rendering/svg/RenderSVGResourceSolidColor.h
M Source/WebCore/replay/ReplayController.h
Log Message:
-----------
Merge r182068 - Make some more objects use FastMalloc
https://bugs.webkit.org/show_bug.cgi?id=143122
Reviewed by Csaba Osztrogonác.
Source/JavaScriptCore:
* API/JSCallbackObject.h:
* heap/IncrementalSweeper.h:
* jit/JITThunks.h:
* runtime/JSGlobalObjectDebuggable.h:
* runtime/RegExpCache.h:
Source/WebCore:
* Modules/geolocation/GeolocationController.h:
* Modules/geolocation/NavigatorGeolocation.h:
* Modules/indexeddb/DOMWindowIndexedDatabase.h:
* Modules/notifications/NotificationController.h:
* Modules/webdatabase/DatabaseServer.h:
* css/CSSFontFaceSource.h:
* html/HTMLMediaSession.h:
* inspector/InspectorIndexedDBAgent.h:
* inspector/InspectorReplayAgent.h:
* page/CaptionUserPreferencesMediaAF.h:
* page/PageConsoleClient.h:
* page/PageDebuggable.h:
* page/animation/CSSPropertyAnimation.cpp:
* page/mac/ServicesOverlayController.h:
* platform/RemoteCommandListener.h:
* platform/Timer.h:
* platform/audio/MediaSessionManager.h:
* platform/mac/SystemSleepListenerMac.h:
* platform/mac/ThemeMac.h:
* rendering/svg/RenderSVGResourceSolidColor.h:
* replay/ReplayController.h:
Commit: 18b6f69d59c28fbfdd37ae0be4fa0cb4a9b8a171
https://github.com/WebKit/WebKit/commit/18b6f69d59c28fbfdd37ae0be4fa0cb4a9b8a171
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Merge 182069 - HTMLMediaElement will fire 'seeked' before seek completes, leading to currentTime discontinuities.
https://bugs.webkit.org/show_bug.cgi?id=143132
Reviewed by Eric Carlson.
When seeking, if the ready state rises to >= HAVE_CURRENT_DATA, we will fire the 'seeked'
event and continue playback. However, if a media engine updates the ready state before its
seek operation actually completes, the currentTime it returns may still be the time before
the seek.
Wait until both the ready state rises to HAVE_CURRENT_DATA and m_player->seeking() returns
false before firing the 'seeked' event.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::parseAttribute):
Commit: 445140d149f21e6c3bb8b4e113b71457b83394aa
https://github.com/WebKit/WebKit/commit/445140d149f21e6c3bb8b4e113b71457b83394aa
Author: Andreas Kling <akling at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebBackForwardList.cpp
M Source/WebKit2/UIProcess/WebPageProxy.cpp
M Source/WebKit2/UIProcess/WebProcessProxy.cpp
M Source/WebKit2/UIProcess/WebProcessProxy.h
Log Message:
-----------
Merge r182084 - WebProcessProxy should not retain WebBackForwardListItems forever.
<https://webkit.org/b/143152>
<rdar://problem/19925709>
Reviewed by Anders Carlsson.
Have WebProcessProxy actually forget about a WebBackForwardListItem after it's removed from
the WebBackForwardList.
This ensures that we don't accumulate too many of these objects, which can get quite large
due to the session state encoded in them.
We already have graceful handling of the case where an incoming IPC message references
a removed back/forward list item.
* UIProcess/WebBackForwardList.cpp:
(WebKit::WebBackForwardList::didRemoveItem):
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::backForwardRemovedItem):
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::removeBackForwardItem):
* UIProcess/WebProcessProxy.h:
Commit: 4c19c4957296f050b2031db6d561742225103ca3
https://github.com/WebKit/WebKit/commit/4c19c4957296f050b2031db6d561742225103ca3
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
Log Message:
-----------
Merge r182091 - Fix flakey dfg-int8array.js and dfg-int16array.js tests for ARM64
https://bugs.webkit.org/show_bug.cgi?id=138390
Reviewed by Mark Lam.
Source/JavaScriptCore:
Changed load8Signed() and load16Signed() to only sign extend the loaded value to 32 bits
instead of 64 bits. This is what X86-64 does.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16Signed):
(JSC::MacroAssemblerARM64::load8Signed):
LayoutTests:
Reenabled the tests for ARM64/iOS. Left the tests disabled for ARM64/linux and will let linux
developers test and reenable under existing but https://bugs.webkit.org/show_bug.cgi?id=142629.
* js/script-tests/dfg-int16array.js:
* js/script-tests/dfg-int8array.js:
Commit: acb5e37199c53bef15e284adf5a80eafc1beb36e
https://github.com/WebKit/WebKit/commit/acb5e37199c53bef15e284adf5a80eafc1beb36e
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/MacroAssemblerARM.h
M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h
M Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h
M Source/JavaScriptCore/assembler/MacroAssemblerSH4.h
M Source/JavaScriptCore/assembler/MacroAssemblerX86Common.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/jit/JITPropertyAccess.cpp
Log Message:
-----------
Merge r182098 - load8Signed() and load16Signed() should be renamed to avoid confusion
https://bugs.webkit.org/show_bug.cgi?id=143168
Reviewed by Benjamin Poulain.
Renamed load8Signed() to load8SignedExtendTo32() and load16Signed() to load16SignedExtendTo32().
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::load8SignedExtendTo32):
(JSC::MacroAssemblerARM::load16SignedExtendTo32):
(JSC::MacroAssemblerARM::load8Signed): Deleted.
(JSC::MacroAssemblerARM::load16Signed): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16SignedExtendTo32):
(JSC::MacroAssemblerARM64::load8SignedExtendTo32):
(JSC::MacroAssemblerARM64::load16Signed): Deleted.
(JSC::MacroAssemblerARM64::load8Signed): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::load16SignedExtendTo32):
(JSC::MacroAssemblerARMv7::load8SignedExtendTo32):
(JSC::MacroAssemblerARMv7::load16Signed): Deleted.
(JSC::MacroAssemblerARMv7::load8Signed): Deleted.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
(JSC::MacroAssemblerMIPS::load16SignedExtendTo32):
(JSC::MacroAssemblerMIPS::load8Signed): Deleted.
(JSC::MacroAssemblerMIPS::load16Signed): Deleted.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::load8SignedExtendTo32):
(JSC::MacroAssemblerSH4::load8):
(JSC::MacroAssemblerSH4::load16SignedExtendTo32):
(JSC::MacroAssemblerSH4::load16):
(JSC::MacroAssemblerSH4::load8Signed): Deleted.
(JSC::MacroAssemblerSH4::load16Signed): Deleted.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::load8SignedExtendTo32):
(JSC::MacroAssemblerX86Common::load16SignedExtendTo32):
(JSC::MacroAssemblerX86Common::load8Signed): Deleted.
(JSC::MacroAssemblerX86Common::load16Signed): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayGetByVal):
Commit: 59b4310e149dc2bfb84ed770cd1454ab371ecb9a
https://github.com/WebKit/WebKit/commit/59b4310e149dc2bfb84ed770cd1454ab371ecb9a
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Merge r182116 - Optimize RenderLayer::intersectsDamageRect() slightly
https://bugs.webkit.org/show_bug.cgi?id=143186
Reviewed by Zalan Bujtas.
We can early return from RenderLayer::intersectsDamageRect() if the
damageRect is empty, since nothing will intersect with the empty rect.
Slight performance gain when scrolling overflow-scroll with lots of nested,
clipping layers.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects):
Commit: d06d298b6ed3a229ffbab0d4cca5300248d44bd7
https://github.com/WebKit/WebKit/commit/d06d298b6ed3a229ffbab0d4cca5300248d44bd7
Author: Darin Adler <darin at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/htmlcollection-length-after-item-2-expected.txt
A LayoutTests/fast/dom/htmlcollection-length-after-item-2.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/CollectionIndexCache.h
Log Message:
-----------
Merge r182125 - HTMLCollection caches incorrect length if item(0) is called before length on an empty collection
https://bugs.webkit.org/show_bug.cgi?id=143203
Source/WebCore:
rdar://problem/18460462
Reviewed by Antti Koivisto.
Test: fast/dom/htmlcollection-length-after-item-2.html
* dom/CollectionIndexCache.h:
(CollectionIndexCache::nodeAt): If we hit the end looking for index 0, cache a length
of 0, not a length of 1.
LayoutTests:
Reviewed by Antti Koivisto.
* fast/dom/htmlcollection-length-after-item-2-expected.txt: Added.
* fast/dom/htmlcollection-length-after-item-2.html: Added.
Commit: 088ec3096d729752891976386ab5ac9f32750a15
https://github.com/WebKit/WebKit/commit/088ec3096d729752891976386ab5ac9f32750a15
Author: Benjamin Poulain <benjamin at webkit.org>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/css/currentColor-on-before-after-pseudo-elements-expected.html
A LayoutTests/fast/css/currentColor-on-before-after-pseudo-elements.html
A LayoutTests/fast/css/currentColor-style-update-reftest-expected.html
A LayoutTests/fast/css/currentColor-style-update-reftest.html
A LayoutTests/fast/css/currentColor-value-style-update-expected.txt
A LayoutTests/fast/css/currentColor-value-style-update.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/ElementRuleCollector.cpp
M Source/WebCore/css/StyleResolver.cpp
M Source/WebCore/css/StyleResolver.h
Log Message:
-----------
Merge r182130 - `currentColor` computes to the same colour on all elements, even if 'color' is inherited differently
https://bugs.webkit.org/show_bug.cgi?id=133420
Reviewed by Darin Adler.
Source/WebCore:
When resolving a style with the help of the property cache, we were
completely ignoring currentColor.
Since you can set currentColor on properties that are not inherited,
those properties would just be copied from the cached style, which
may have a completely different inherited color.
This pacth fixes the issue by preventing any MatchResult from hitting
the cache if it contains any non-inherited property that would require
resolution by the cache:
-Using the inherit value.
-Using the currentColor value.
Tests: fast/css/currentColor-on-before-after-pseudo-elements.html
fast/css/currentColor-style-update-reftest.html
fast/css/currentColor-value-style-update.html
* css/ElementRuleCollector.cpp:
(WebCore::ElementRuleCollector::addElementStyleProperties):
(WebCore::ElementRuleCollector::matchAuthorRules):
(WebCore::ElementRuleCollector::matchUserRules):
(WebCore::ElementRuleCollector::matchUARules):
* css/StyleResolver.cpp:
(WebCore::StyleResolver::MatchResult::addMatchedProperties):
(WebCore::StyleResolver::styleForKeyframe):
(WebCore::StyleResolver::pseudoStyleForElement):
(WebCore::StyleResolver::styleForPage):
(WebCore::StyleResolver::findFromMatchedPropertiesCache):
(WebCore::StyleResolver::addToMatchedPropertiesCache):
(WebCore::extractDirectionAndWritingMode):
(WebCore::StyleResolver::applyMatchedProperties):
(WebCore::StyleResolver::CascadedProperties::addStyleProperties):
(WebCore::StyleResolver::CascadedProperties::addMatches):
* css/StyleResolver.h:
(WebCore::StyleResolver::MatchResult::matchedProperties):
LayoutTests:
* fast/css/currentColor-on-before-after-pseudo-elements-expected.html: Added.
* fast/css/currentColor-on-before-after-pseudo-elements.html: Added.
* fast/css/currentColor-style-update-reftest-expected.html: Added.
* fast/css/currentColor-style-update-reftest.html: Added.
* fast/css/currentColor-value-style-update-expected.txt: Added.
* fast/css/currentColor-value-style-update.html: Added.
Commit: a67b6d03532ed24b4beeaaca99b2fd1bd87cae15
https://github.com/WebKit/WebKit/commit/a67b6d03532ed24b4beeaaca99b2fd1bd87cae15
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
Log Message:
-----------
Merge r182176 - Unreviewed. Fix GTK+ build with REDIRECTED_XCOMPOSITE_WINDOW disabled in X11 platform.
Also fix some unused parameter warnings when
REDIRECTED_XCOMPOSITE_WINDOW is disabled.
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewRenderAcceleratedCompositingResults):
(resizeWebKitWebViewBaseFromAllocation):
Commit: 06a4f590add66ac50bf8a01bcee406a0600430b6
https://github.com/WebKit/WebKit/commit/06a4f590add66ac50bf8a01bcee406a0600430b6
Author: Beth Dakin <bdakin at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-reduced-content-expected.txt
A LayoutTests/platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-reduced-content.html
A LayoutTests/platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-zero-delta-wheel-events-expected.txt
A LayoutTests/platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-zero-delta-wheel-events.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Merge r182191 - REGRESSION (r173484): Reducing content of scrollable region does not reset scroll
position
https://bugs.webkit.org/show_bug.cgi?id=138525
-and corresponding-
rdar://problem/18166043
Reviewed by Simon Fraser.
Source/WebCore:
The change that caused this regression was correct. That change does not allow
RenderLayer to update scroll position after a layout if a rubber-band is currently
happening. The change caused this regression because all of the member variables
in ScrollController that attempt to keep track of the current state of the scroll
gesture (m_inScrollGesture, m_momentumScrollInProgress, and
m_snapRubberbandTimerIsActive) all indicated that a momentum scroll gesture was
still in action for this div even though it very much is not when the bug happens.
Those variables were never properly re-set because the
PlatformWheelEventPhaseEnded events never got dispatched to the ScrollController,
which brought the investigation back to Element.
We must still dispatch events that have zero delta so that the default event
handlers can handle them, but we should stopPropagation() so that these events are
not sent to the DOM. Websites will break if they get wheel events with no delta.
* dom/Element.cpp:
(WebCore::Element::dispatchWheelEvent):
LayoutTests:
* platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-reduced-content-expected.txt: Added.
* platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-reduced-content.html: Added.
* platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-zero-delta-wheel-events-expected.txt: Added.
* platform/mac-wk2/tiled-drawing/scrolling/overflow-scroll-zero-delta-wheel-events.html: Added.
Commit: aa8eaac9e1066f82360ec94e185ef706a690e2dd
https://github.com/WebKit/WebKit/commit/aa8eaac9e1066f82360ec94e185ef706a690e2dd
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/borders/border-image-fill-inline-no-border-expected.html
A LayoutTests/fast/borders/border-image-fill-inline-no-border.html
A LayoutTests/fast/borders/border-image-fill-no-border-expected.html
A LayoutTests/fast/borders/border-image-fill-no-border.html
A LayoutTests/fast/borders/resources/button-border-cropped.svg
A LayoutTests/fast/borders/resources/button-border.svg
A LayoutTests/fast/borders/resources/svg-100x100-intrinsic.svg
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/InlineFlowBox.cpp
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBoxModelObject.cpp
M Source/WebCore/rendering/RenderTable.cpp
M Source/WebCore/rendering/style/BorderData.h
M Source/WebCore/rendering/style/RenderStyle.h
Log Message:
-----------
Merge r182197 - border-image with 'fill' keyword does not fill the middle area unless the border width is greater than zero.
https://bugs.webkit.org/show_bug.cgi?id=142650.
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-03-31
Reviewed by Simon Fraser.
Source/WebCore:
The decoration of a RenderBox, a RenderTable or an InlineFlowBox should be
drawn if its RenderStyle has a non-zero width border or the border-image
has the keyword fill.
Tests: fast/borders/border-image-fill-inline-no-border.html
fast/borders/border-image-fill-no-border.html
* rendering/InlineFlowBox.cpp:
(WebCore::InlineFlowBox::paintBoxDecorations):
* rendering/RenderBox.cpp:
(WebCore::RenderBox::paintBoxDecorations):
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::hasBoxDecorationStyle):
* rendering/RenderTable.cpp:
(WebCore::RenderTable::paintBoxDecorations):
* rendering/style/BorderData.h:
(WebCore::BorderData::hasFill):
* rendering/style/RenderStyle.h:
LayoutTests:
Add tests to ensure the middle area of a RenderBox is going to be drawn
even if the border width is not greater than zero.
* fast/borders/border-image-fill-inline-no-border-expected.html: Added.
* fast/borders/border-image-fill-inline-no-border.html: Added.
* fast/borders/border-image-fill-no-border-expected.html: Added.
* fast/borders/border-image-fill-no-border.html: Added.
* fast/borders/resources/button-border-cropped.svg: Added.
* fast/borders/resources/button-border.svg: Added.
* fast/borders/resources/svg-100x100-intrinsic.svg: Added.
Commit: 859688b195439fcfbea197f4c371e3c326e9ea1b
https://github.com/WebKit/WebKit/commit/859688b195439fcfbea197f4c371e3c326e9ea1b
Author: Carlos Alberto Lopez Perez <clopez at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/PlatformGTK.cmake
Log Message:
-----------
Merge r182232 - [CMake][GTK] Use the right variable to include the Wayland headers.
https://bugs.webkit.org/show_bug.cgi?id=143304
Reviewed by Carlos Garcia Campos.
No new tests, no behavior changes.
* PlatformGTK.cmake: Use the right variable WAYLAND_INCLUDE_DIRS.
Commit: d2718232dde371467f1387a1772caba4d6dbcfe4
https://github.com/WebKit/WebKit/commit/d2718232dde371467f1387a1772caba4d6dbcfe4
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderTableCaption.cpp
M Source/WebCore/rendering/RenderTableCaption.h
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderTableCell.h
M Source/WebCore/rendering/RenderTableCol.cpp
M Source/WebCore/rendering/RenderTableCol.h
M Source/WebCore/rendering/RenderTableRow.h
M Source/WebCore/rendering/RenderTableSection.cpp
M Source/WebCore/rendering/RenderTableSection.h
Log Message:
-----------
Merge r180241 - Minor RenderTable* class cleanups.
https://bugs.webkit.org/show_bug.cgi?id=141707
Reviewed by Andreas Kling.
Use in-class initializer where possible.
Remove redundant code.
Move multiline implementations out of class declaration.
No change in functionality.
* rendering/RenderTableCaption.cpp:
(WebCore::RenderTableCaption::insertedIntoTree):
(WebCore::RenderTableCaption::willBeRemovedFromTree):
(WebCore::RenderTableCaption::containingBlockLogicalWidthForContent): Deleted.
* rendering/RenderTableCaption.h:
* rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::RenderTableCell):
* rendering/RenderTableCell.h:
(WebCore::RenderTableCell::colSpan):
(WebCore::RenderTableCell::rowSpan):
(WebCore::RenderTableCell::setCol):
(WebCore::RenderTableCell::col):
(WebCore::RenderTableCell::section):
(WebCore::RenderTableCell::table):
(WebCore::RenderTableCell::rowIndex):
(WebCore::RenderTableCell::styleOrColLogicalWidth):
(WebCore::RenderTableCell::logicalHeightForRowSizing):
(WebCore::RenderTableCell::isBaselineAligned):
(WebCore::RenderTableCell::borderAdjoiningTableStart):
(WebCore::RenderTableCell::borderAdjoiningTableEnd):
(WebCore::RenderTableCell::borderAdjoiningCellBefore):
(WebCore::RenderTableCell::borderAdjoiningCellAfter):
* rendering/RenderTableCol.cpp:
(WebCore::RenderTableCol::RenderTableCol):
* rendering/RenderTableCol.h:
(WebCore::RenderTableCol::enclosingColumnGroupIfAdjacentBefore):
(WebCore::RenderTableCol::enclosingColumnGroupIfAdjacentAfter):
* rendering/RenderTableRow.h:
(WebCore::RenderTableRow::setRowIndex):
(WebCore::RenderTableRow::rowIndex):
(WebCore::RenderTableRow::borderAdjoiningTableStart):
(WebCore::RenderTableRow::borderAdjoiningTableEnd):
(WebCore::RenderTableRow::table):
(WebCore::RenderTableSection::firstRow):
(WebCore::RenderTableSection::lastRow):
* rendering/RenderTableSection.cpp:
(WebCore::RenderTableSection::RenderTableSection):
(WebCore::RenderTableSection::dirtiedRows):
(WebCore::RenderTableSection::dirtiedColumns):
(WebCore::RenderTableSection::paintObject):
(WebCore::RenderTableSection::nodeAtPoint):
* rendering/RenderTableSection.h:
(WebCore::CellSpan::CellSpan):
(WebCore::RenderTableSection::borderAdjoiningTableStart):
(WebCore::RenderTableSection::borderAdjoiningTableEnd):
(WebCore::RenderTableSection::cellAt):
(WebCore::RenderTableSection::primaryCellAt):
(WebCore::RenderTableSection::rowRendererAt):
(WebCore::RenderTableSection::outerBorderLeft):
(WebCore::RenderTableSection::outerBorderRight):
(WebCore::RenderTableSection::outerBorderTop):
(WebCore::RenderTableSection::outerBorderBottom):
(WebCore::RenderTableSection::numRows):
(WebCore::RenderTableSection::recalcCellsIfNeeded):
(WebCore::RenderTableSection::rowBaseline):
(WebCore::RenderTableSection::fullTableRowSpan):
(WebCore::CellSpan::start): Deleted.
(WebCore::CellSpan::end): Deleted.
Commit: c8d6ff174d8772f2ec0dbf730653ab9a56b6f9e3
https://github.com/WebKit/WebKit/commit/c8d6ff174d8772f2ec0dbf730653ab9a56b6f9e3
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderTable.cpp
M Source/WebCore/rendering/RenderTable.h
M Source/WebCore/rendering/RenderTableCell.cpp
M Source/WebCore/rendering/RenderTableCell.h
M Source/WebCore/rendering/RenderTableCol.cpp
M Source/WebCore/rendering/RenderTableRow.cpp
M Source/WebCore/rendering/RenderTableSection.cpp
M Source/WebCore/rendering/RenderTableSection.h
Log Message:
-----------
Merge r182235 - Lots of time spent querying table cell borders, when there are none.
https://bugs.webkit.org/show_bug.cgi?id=143277
Reviewed by Simon Fraser.
This patch speeds up collapsed border queries by using existing collapsed border
cache to calculate repaint rects and by introducing a fast path for zero width collapsed borders.
It reduces the number of calls to recompute collapsed borders from 36 000 to 1 600, while loading a page with a table of 400 rows (1 cell per row).
When scrolling the same page all the way down to the bottom, the number of calls to recompute collapsed borders falls from 290 000 to 0.
Covered by existing tests.
* rendering/RenderTable.cpp:
(WebCore::RenderTable::styleDidChange): This moves invalidation time from RenderTable::layout() to styleDidChange().
(WebCore::RenderTable::invalidateCollapsedBorders):
(WebCore::RenderTable::recalcCollapsedBorders):
* rendering/RenderTable.h:
(WebCore::RenderTable::collapsedBordersAreValid):
(WebCore::RenderTable::invalidateCollapsedBorders): Deleted.
* rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::RenderTableCell):
(WebCore::RenderTableCell::willBeRemovedFromTree): Invalidate caches so that when repaint rect is calculated, we don't end up using stale values.
(WebCore::RenderTableCell::styleDidChange): Same as willBeRemovedFromTree.
(WebCore::RenderTableCell::collapsedStartBorder): Check if collapsed border is zero -also query cache.
(WebCore::RenderTableCell::collapsedEndBorder):
(WebCore::RenderTableCell::collapsedBeforeBorder):
(WebCore::RenderTableCell::collapsedAfterBorder):
(WebCore::RenderTableCell::cachedCollapsedLeftBorder):
(WebCore::RenderTableCell::cachedCollapsedRightBorder):
(WebCore::RenderTableCell::cachedCollapsedTopBorder):
(WebCore::RenderTableCell::cachedCollapsedBottomBorder):
(WebCore::RenderTableCell::paintCollapsedBorders):
(WebCore::RenderTableCell::cellAtLeft): Deleted.
(WebCore::RenderTableCell::cellAtRight): Deleted.
(WebCore::RenderTableCell::cellAtTop): Deleted.
(WebCore::RenderTableCell::cellAtBottom): Deleted.
* rendering/RenderTableCell.h:
(WebCore::RenderTableCell::invalidateHasEmptyCollapsedBorders):
* rendering/RenderTableCol.cpp:
(WebCore::RenderTableCol::styleDidChange):
* rendering/RenderTableRow.cpp:
(WebCore::RenderTableRow::styleDidChange):
(WebCore::RenderTableRow::addChild):
* rendering/RenderTableSection.cpp:
(WebCore::RenderTableSection::styleDidChange):
(WebCore::RenderTableSection::clearCachedCollapsedBorders): This is just an extra safety to invalidate collapsed border cache. This is always
called together with RenderTable::invalidateCollapsedBorders() -and that should prevent the RenderCells to use the cache.
(WebCore::RenderTableSection::removeCachedCollapsedBorders):
(WebCore::RenderTableSection::setCachedCollapsedBorder):
(WebCore::RenderTableSection::cachedCollapsedBorder):
* rendering/RenderTableSection.h:
Commit: 5da092399dae1c28d514182d15b4147895565a6b
https://github.com/WebKit/WebKit/commit/5da092399dae1c28d514182d15b4147895565a6b
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebProcessProxy.cpp
Log Message:
-----------
Merge r182285 - Make checkURLReceivedFromWebProcess not rely on details of platform URL implementation.
https://bugs.webkit.org/show_bug.cgi?id=143222
rdar://problem/19978997
Reviewed by Sam Weinig.
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::checkURLReceivedFromWebProcess):
Commit: 59def073b434f35f6e206f8a24738ab045efb940
https://github.com/WebKit/WebKit/commit/59def073b434f35f6e206f8a24738ab045efb940
Author: Andreas Kling <akling at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
Log Message:
-----------
Merge r182370 - URI encoding/escaping should use efficient string building instead of calling snprintf().
<https://webkit.org/b/143426>
Reviewed by Gavin Barraclough.
I saw 0.5% of main thread time in snprintf() on <http://polymerlabs.github.io/benchmarks/>
which seemed pretty silly. This change gets that down to nothing in favor of using our
existing JSStringBuilder and HexNumber.h facilities.
These APIs are well-exercised by our existing test suite.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):
(JSC::globalFuncEscape):
Commit: 19325f7442425544607a70d2abd70787c95564e2
https://github.com/WebKit/WebKit/commit/19325f7442425544607a70d2abd70787c95564e2
Author: Darin Adler <darin at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
Log Message:
-----------
Merge r182374 - FrameView code uses page() without null checking
https://bugs.webkit.org/show_bug.cgi?id=143425
rdar://problem/18920601
Reviewed by Anders Carlsson.
While we don't have tests that cover this, we are seeing crashes coming in
that indicate the shouldEnableSpeculativeTilingDuringLoading function is
being called when the page is null. This patch adds null checks to all the
places in FrameView that use page() without doing null checking.
* page/FrameView.cpp:
(WebCore::FrameView::layout): If page is null, don't try to do the
auto-sizing logic that involves the textAutosizingWidth value from the page.
(WebCore::FrameView::setFixedVisibleContentRect): Get settings from the
frame rather than the page to avoid possible null-dereference.
(WebCore::FrameView::scrollPositionChanged): Check the page for null when
getting the event throttling delay.
(WebCore::FrameView::updateLayerFlushThrottling): Check the page for null,
and return early if it is null.
(WebCore::shouldEnableSpeculativeTilingDuringLoading): Check the page for
null, and return false if it is null.
(WebCore::FrameView::performPostLayoutTasks): Guard the code that calls
didLayout on the page client by a check if the page is null.
(WebCore::FrameView::pagination): Don't call Page::pagination on a null
page here.
(WebCore::FrameView::visibleContentScaleFactor): Use a scale factor of 1
if the page is null.
(WebCore::FrameView::setVisibleScrollerThumbRect): Don't call through to
the page client if the page is null.
(WebCore::FrameView::scrollbarStyleChanged): Ditto.
(WebCore::FrameView::setScrollPinningBehavior): Check the page for null
before asking it for the scrolling coordinator.
Commit: df12bd48f1d10a68a98efb1f3a2a6f0eaf798588
https://github.com/WebKit/WebKit/commit/df12bd48f1d10a68a98efb1f3a2a6f0eaf798588
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/UserScript.h
M Source/WebCore/page/UserStyleSheet.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/WebCoreArgumentCoders.cpp
Log Message:
-----------
Merge r182378 - UserScript, UserStyleSheet constructors should take in Vector<String> rvalue references
https://bugs.webkit.org/show_bug.cgi?id=143411
Reviewed by Darin Adler.
Have the UserScript and UserStyleSheet constructors take in Vector<String>
rvalue references for the whitelist and blacklist parameters. Both classes
store these Vector<String> objects, so the referenced objects can simply be
moved into the member variable.
Because the constructor is now demanding an rvalue, it's up to the caller
to move in the desired object if possible, or create an explicit copy
otherwise.
* page/UserScript.h:
(WebCore::UserScript::UserScript):
* page/UserStyleSheet.h:
(WebCore::UserStyleSheet::UserStyleSheet):
Source/WebKit2:
UserScript, UserStyleSheet constructors should take in Vector<String> rvalues
https://bugs.webkit.org/show_bug.cgi?id=143411
Reviewed by Darin Adler.
Move the whitelist and blacklist Vector<String> objects into the
UserScript and UserStyleSheet constructors in ArgumentCoder<T>::decode
functions.
* Shared/WebCoreArgumentCoders.cpp:
(IPC::ArgumentCoder<UserStyleSheet>::decode):
(IPC::ArgumentCoder<UserScript>::decode):
Commit: 88bd47406236e72d991d0f720a3a0cac5927e838
https://github.com/WebKit/WebKit/commit/88bd47406236e72d991d0f720a3a0cac5927e838
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/fileapi/FileList.h
Log Message:
-----------
Merge r182379 - FileList constructor should move the passed-in Vector<> rvalue reference into the member variable
https://bugs.webkit.org/show_bug.cgi?id=143412
Reviewed by Darin Adler.
* fileapi/FileList.h:
(WebCore::FileList::FileList): An explicit move of the passed-in rvalue
reference into the member variable is required, otherwise a copy is
performed since an rvalue reference is just an lvalue.
Commit: cf84ae17ebf0f40569dddc64a353a0c60f7cddef
https://github.com/WebKit/WebKit/commit/cf84ae17ebf0f40569dddc64a353a0c60f7cddef
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/API/APIArray.cpp
M Source/WebKit2/Shared/API/APIArray.h
Log Message:
-----------
Merge r182388 - [WK2] API::Array::copy() should move the resulting Vector<> of copies into the Array::create() call
https://bugs.webkit.org/show_bug.cgi?id=143413
Reviewed by Darin Adler.
Move the Vector<> object containing the copied elements into the Array::create()
call, avoiding copying all the elements again.
While here, change the Vector<> parameters for Array::create() and the Array
constructor to rvalue references. This will ensure that the passed-in object
is moved into the Array::create() call if possible, or explicitly copied
otherwise. The constructor is moved into the header for inlining opportunities
and the unnecessary parameter in the create(Vector<>&&) method declaration
removed.
* Shared/API/APIArray.cpp:
(API::Array::create):
(API::Array::copy):
(API::Array::Array): Deleted.
* Shared/API/APIArray.h:
Commit: 1dc9ee1365b4b9291439d4e321752b05eaba410b
https://github.com/WebKit/WebKit/commit/1dc9ee1365b4b9291439d4e321752b05eaba410b
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp
A Source/JavaScriptCore/tests/stress/for-in-array-mode.js
Log Message:
-----------
Merge r182444 - In the 64-bit DFG and FTL, Array::Double case for HasIndexedProperty should set its result to true when all is well.
<https://webkit.org/b/143396>
Reviewed by Filip Pizlo.
The DFG was neglecting to set the result boolean. The FTL was setting it with
an inverted value. Both of these are now resolved.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileHasIndexedProperty):
* tests/stress/for-in-array-mode.js: Added.
(.):
(test):
Commit: 4ac8efc968de51e3536c4dedbc4f1d1630b6f5aa
https://github.com/WebKit/WebKit/commit/4ac8efc968de51e3536c4dedbc4f1d1630b6f5aa
Author: Anders Carlsson <andersca at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebInspectorProxy.cpp
M Source/WebKit2/UIProcess/WebInspectorProxy.h
M Source/WebKit2/UIProcess/WebProcessProxy.cpp
Log Message:
-----------
Merge r182447 - Create the web inspector process pool lazily
https://bugs.webkit.org/show_bug.cgi?id=143456
rdar://problem/20146520
Reviewed by Mark Lam.
Add and implement WebInspectorProxy::isInspectorProcessPool instead of always creating the inspector process pool
when trying to determine if a given process pool is the inspector process pool.
This should speed up initialization somewhat and avoid creating a storage manager for example.
* UIProcess/WebInspectorProxy.cpp:
(WebKit::WebInspectorProxy::inspectorProcessPool):
(WebKit::WebInspectorProxy::isInspectorProcessPool):
* UIProcess/WebInspectorProxy.h:
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::getLaunchOptions):
Commit: 3029d0cee09df8ea3467974e31aecb0bd5244a69
https://github.com/WebKit/WebKit/commit/3029d0cee09df8ea3467974e31aecb0bd5244a69
Author: Alberto Garcia <berto at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M CMakeLists.txt
M ChangeLog
M Source/JavaScriptCore/CMakeLists.txt
M Source/JavaScriptCore/ChangeLog
Log Message:
-----------
Merge r182450 - [GTK] Fix HPPA build
https://bugs.webkit.org/show_bug.cgi?id=143453
Reviewed by Darin Adler.
Add HPPA to the list of supported CPUs.
* CMakeLists.txt:
Commit: be1ab2e3759de665708446862e8cfe24856aa005
https://github.com/WebKit/WebKit/commit/be1ab2e3759de665708446862e8cfe24856aa005
Author: Philippe Normand <pnormand at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
A Source/WebCore/platform/graphics/gstreamer/GUniquePtrGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp
Log Message:
-----------
Merge r182523 - [GStreamer] extra-headers and keep-alive properties for HTTP source element
https://bugs.webkit.org/show_bug.cgi?id=143480
Reviewed by Carlos Garcia Campos.
Keep the resource loader around when persistent HTTP connection
support is enabled. The keep-alive property is set to false by
default. Also before sending the HTTP request we now check the
contents of the extra-headers GstStructure and set additional
headers based on the structure contents.
Patch inspired by GStreamer's souphttpsrc element.
* platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(webkit_web_src_init):
(webKitWebSrcFinalize):
(webKitWebSrcSetProperty):
(webKitWebSrcGetProperty):
(webKitWebSrcStop): Clear resource loader only for non-persistent connections.
(webKitWebSrcSetExtraHeader): Utility function to append headers
to an existing request based on a GValue contents.
(webKitWebSrcProcessExtraHeaders): Parse a GValue and set headers
based on its contents.
(webKitWebSrcStart): Extra headers and persistent connection
support. The resource loader is now lazily initialized here.
Commit: b79d7ebe0de6612dce5d295fcfb2a73410c04f3b
https://github.com/WebKit/WebKit/commit/b79d7ebe0de6612dce5d295fcfb2a73410c04f3b
Author: Philippe Normand <pnormand at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp
Log Message:
-----------
Merge r182534 - [GStreamer] compress property for the HTTP source element
https://bugs.webkit.org/show_bug.cgi?id=143518
Reviewed by Carlos Garcia Campos.
Added a compress property so the default behavior or not
requesting content encoded to the server can be overridden if
needed. This is useful for adaptive streaming playback.
* platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(webKitWebSrcSetProperty):
(webKitWebSrcGetProperty):
(webKitWebSrcStart):
Commit: 0b3abadd72d46e920e7f338adfa8975e8a147ac7
https://github.com/WebKit/WebKit/commit/0b3abadd72d46e920e7f338adfa8975e8a147ac7
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/gobject/DOMObjectCache.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/DOMNodeTest.cpp
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebExtensions.cpp
M Tools/TestWebKitAPI/gtk/WebKit2Gtk/WebViewTest.cpp
M Tools/TestWebKitAPI/gtk/WebKit2Gtk/WebViewTest.h
Log Message:
-----------
Merge r182537 - [GTK] Crash in DOMObjectCache when a wrapped object owned by the cache is unreffed by the user
https://bugs.webkit.org/show_bug.cgi?id=143521
Reviewed by Martin Robinson.
This is a case we claim to support, but it only works if the
object has only one reference. In that case, when the user unrefs
it, the weak ref notify callback removes the object from the
cache. However, if the object has more than one ref, the cache
doesn't know the user unreffed it, and when clearing the cache we
try to remove more references than what the object actually has,
causing a crash in g_object_unref.
* bindings/gobject/DOMObjectCache.cpp:
(WebKit::DOMObjectCacheData::clearObject):
Commit: 40fc6085faf4ac3464e1478ccb9a10b89b16ca3c
https://github.com/WebKit/WebKit/commit/40fc6085faf4ac3464e1478ccb9a10b89b16ca3c
Author: changseok.oh at collabora.com <changseok.oh at collabora.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/backgrounds/selection-background-color-of-image-list-style.html
A LayoutTests/fast/backgrounds/selection-background-color-of-list-style.html
A LayoutTests/platform/gtk/fast/backgrounds/selection-background-color-of-image-list-style-expected.png
A LayoutTests/platform/gtk/fast/backgrounds/selection-background-color-of-image-list-style-expected.txt
A LayoutTests/platform/gtk/fast/backgrounds/selection-background-color-of-list-style-expected.png
A LayoutTests/platform/gtk/fast/backgrounds/selection-background-color-of-list-style-expected.txt
A LayoutTests/platform/mac/fast/backgrounds/selection-background-color-of-image-list-style-expected.png
A LayoutTests/platform/mac/fast/backgrounds/selection-background-color-of-image-list-style-expected.txt
A LayoutTests/platform/mac/fast/backgrounds/selection-background-color-of-list-style-expected.png
A LayoutTests/platform/mac/fast/backgrounds/selection-background-color-of-list-style-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderListMarker.cpp
Log Message:
-----------
Merge r182546 - Fill list style background with same color with that of list background.
https://bugs.webkit.org/show_bug.cgi?id=143483
Reviewed by Simon Fraser.
Source/WebCore:
LayoutListMarker does not have a node so its selectionBackgroundColor alway returns
the default theme color for selection. We can make it more natural by filling
the same color with that of LayoutListItem into it.
Tests: fast/backgrounds/selection-background-color-of-image-list-style.html
fast/backgrounds/selection-background-color-of-list-style.html
* rendering/RenderListMarker.cpp:
(WebCore::RenderListMarker::paint):
LayoutTests:
* fast/backgrounds/selection-background-color-of-image-list-style.html: Added.
* fast/backgrounds/selection-background-color-of-list-style.html: Added.
* platform/gtk/fast/backgrounds/selection-background-color-of-image-list-style-expected.png: Added.
* platform/gtk/fast/backgrounds/selection-background-color-of-image-list-style-expected.txt: Added.
* platform/gtk/fast/backgrounds/selection-background-color-of-list-style-expected.png: Added.
* platform/gtk/fast/backgrounds/selection-background-color-of-list-style-expected.txt: Added.
* platform/mac/fast/backgrounds/selection-background-color-of-image-list-style-expected.png: Added.
* platform/mac/fast/backgrounds/selection-background-color-of-image-list-style-expected.txt: Added.
* platform/mac/fast/backgrounds/selection-background-color-of-list-style-expected.png: Added.
* platform/mac/fast/backgrounds/selection-background-color-of-list-style-expected.txt: Added.
Commit: 17bf59ec92fd1ca17d4924639f963cf7d7f5040f
https://github.com/WebKit/WebKit/commit/17bf59ec92fd1ca17d4924639f963cf7d7f5040f
Author: Bem Jones-Bey <bjonesbe at adobe.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/shapes/shape-outside-floats/shape-outside-floats-circle-negative-radius-crash-expected.txt
A LayoutTests/fast/shapes/shape-outside-floats/shape-outside-floats-circle-negative-radius-crash.html
A LayoutTests/fast/shapes/shape-outside-floats/shape-outside-floats-ellipse-negative-width-crash-expected.txt
A LayoutTests/fast/shapes/shape-outside-floats/shape-outside-floats-ellipse-negative-width-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/shapes/ShapeOutsideInfo.cpp
M Source/WebCore/rendering/style/BasicShapes.cpp
Log Message:
-----------
Merge r182560 - [CSS Shapes] Properly handle negative reference box widths and center coordinates
https://bugs.webkit.org/show_bug.cgi?id=142610
Reviewed by Rob Buis.
Source/WebCore:
Fix a few cases where values that should not be negative end up that
way.
This patch is based on a couple of Blink patches by Rob Buis.
Tests: fast/shapes/shape-outside-floats/shape-outside-floats-circle-negative-radius-crash.html
fast/shapes/shape-outside-floats/shape-outside-floats-ellipse-negative-width-crash.html
* rendering/shapes/ShapeOutsideInfo.cpp:
(WebCore::ShapeOutsideInfo::computeDeltasForContainingBlockLine): A
negative margin box width means that the shape has no extent, so
clamp to zero.
* rendering/style/BasicShapes.cpp:
(WebCore::BasicShapeCircle::floatValueForRadiusInBox): When computing
the radii, take the absolute value, since the radii is based on
the distance, which is always positive.
(WebCore::BasicShapeEllipse::floatValueForRadiusInBox): Ditto.
LayoutTests:
Tests for the cases that trigger asserts.
* fast/shapes/shape-outside-floats/shape-outside-floats-circle-negative-radius-crash-expected.txt: Added.
* fast/shapes/shape-outside-floats/shape-outside-floats-circle-negative-radius-crash.html: Added.
* fast/shapes/shape-outside-floats/shape-outside-floats-ellipse-negative-width-crash-expected.txt: Added.
* fast/shapes/shape-outside-floats/shape-outside-floats-ellipse-negative-width-crash.html: Added.
Commit: 8076d206f334c6f55952133c4479e181903cfadc
https://github.com/WebKit/WebKit/commit/8076d206f334c6f55952133c4479e181903cfadc
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Makefile.shared
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGIntegerCheckCombiningPhase.cpp
Log Message:
-----------
Merge r182562 - DFG::IntegerCheckCombiningPhase's wrap-around check shouldn't trigger C++ undef behavior on wrap-around
https://bugs.webkit.org/show_bug.cgi?id=143532
Reviewed by Gavin Barraclough.
Oh the irony! We were protecting an optimization that only worked if there was no wrap-around in JavaScript.
But the C++ code had wrap-around, which is undef in C++. So, if the compiler was smart enough, our compiler
would think that there never was wrap-around.
This fixes a failure in stress/tricky-array-boiunds-checks.js when JSC is compiled with bleeding-edge clang.
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::isValid):
Commit: e47fc6186ba16ed13490ea156561cb5fdc2bae80
https://github.com/WebKit/WebKit/commit/e47fc6186ba16ed13490ea156561cb5fdc2bae80
Author: Filip Pizlo <fpizlo at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/js/regress/script-tests/sorting-benchmark.js
A LayoutTests/js/regress/sorting-benchmark-expected.txt
A LayoutTests/js/regress/sorting-benchmark.html
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/JSArray.cpp
A Source/JavaScriptCore/tests/stress/sort-array-with-undecided.js
Log Message:
-----------
Merge r182567 - JSArray::sortNumeric should handle ArrayWithUndecided
https://bugs.webkit.org/show_bug.cgi?id=143535
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
ArrayWithUndecided is what you get if you haven't stored anything into the array yet. We need to handle it.
* runtime/JSArray.cpp:
(JSC::JSArray::sortNumeric):
* tests/stress/sort-array-with-undecided.js: Added.
LayoutTests:
Upload the original test that first spotted this. Shortened it a bit so that it runs fast enough.
* js/regress/script-tests/sorting-benchmark.js: Added.
(log):
(bottom_up_merge_sort):
(aMinusB):
(verify):
(benchmark):
(makeArrays):
* js/regress/sorting-benchmark-expected.txt: Added.
* js/regress/sorting-benchmark.html: Added.
Commit: 0c31e29dcaa67a4633bce4a19087725a2edd9ff8
https://github.com/WebKit/WebKit/commit/0c31e29dcaa67a4633bce4a19087725a2edd9ff8
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
Log Message:
-----------
Merge r182643 - REGRESSION (182567): regress/script-tests/sorting-benchmark.js fails on 32 bit dfg-eager tests
https://bugs.webkit.org/show_bug.cgi?id=143582
Reviewed by Mark Lam.
For 32 bit builds, we favor spilling unboxed values. The ASSERT at the root of this bug doesn't
fire for 64 bit builds, because we spill an "Other" value as a full JS value (DataFormatJS).
For 32 bit builds however, if we are able, we spill Other values as JSCell* (DataFormatCell).
The fix is to add a check in fillSpeculateInt32Internal() before the ASSERT that always OSR exits
if the spillFormat is DataFormatCell. Had we spilled in DataFormatJS and the value was a JSCell*,
we would still OSR exit after the speculation check.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode): Fixed an error in a comment while debugging.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
Commit: fb3058aa7b5580a71ee313273f238d1431489db3
https://github.com/WebKit/WebKit/commit/fb3058aa7b5580a71ee313273f238d1431489db3
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/text-combine-style-change-no-layout-expected.html
A LayoutTests/fast/text/text-combine-style-change-no-layout.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderCombineText.cpp
Log Message:
-----------
Merge r182609 - Text-combine erroneously draws vertically after non-layout-causing style change
https://bugs.webkit.org/show_bug.cgi?id=143461
<rdar://problem/19285490>
Reviewed by Darin Adler.
Source/WebCore:
RenderCombineText::styleDidChange() unconditionally uncombines its text. Layout then
recombines it. However, if there is a style change that does not cause layout, the
RenderCombineText will be left uncombined until the next layout.
Test: fast/text/text-combine-style-change-no-layout.html
* rendering/RenderCombineText.cpp:
(WebCore::RenderCombineText::styleDidChange):
LayoutTests:
* fast/text/text-combine-style-change-no-layout-expected.html: Added.
* fast/text/text-combine-style-change-no-layout.html: Added.
Commit: 95a2ddbf0b2e5546c73bbab988e1aca90c45d09b
https://github.com/WebKit/WebKit/commit/95a2ddbf0b2e5546c73bbab988e1aca90c45d09b
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/jit/RegisterSet.cpp
Log Message:
-----------
Merge r182634 - [ARM] Fix calleeSaveRegisters() on non iOS platforms after r180516
https://bugs.webkit.org/show_bug.cgi?id=143368
Reviewed by Michael Saboff.
* jit/RegisterSet.cpp:
(JSC::RegisterSet::calleeSaveRegisters):
Commit: 172eb45cf4f6757c4ad4599773fa9bdaa6b0b680
https://github.com/WebKit/WebKit/commit/172eb45cf4f6757c4ad4599773fa9bdaa6b0b680
Author: Sungmann Cho <sungmann.cho at navercorp.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WebKit2/CMakeLists.txt
M Source/WebKit2/ChangeLog
R Source/WebKit2/Shared/Plugins/PluginModuleInfo.cpp
M Source/WebKit2/WebKit2.xcodeproj/project.pbxproj
Log Message:
-----------
Merge r182671 - Remove PluginModuleInfo.cpp from WebKit2
https://bugs.webkit.org/show_bug.cgi?id=143643
Patch by Sungmann Cho <sungmann.cho at navercorp.com> on 2015-04-12
Reviewed by Darin Adler.
Remove PluginModuleInfo.cpp from WebKit2 because it is totally empty.
No new tests, no behavior change.
* CMakeLists.txt:
* Shared/Plugins/PluginModuleInfo.cpp: Removed.
* WebKit2.xcodeproj/project.pbxproj:
Commit: bde41a192a74208d4838124bf740fe1a4e8c259b
https://github.com/WebKit/WebKit/commit/bde41a192a74208d4838124bf740fe1a4e8c259b
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/forms/listbox-visible-size-expected.txt
A LayoutTests/fast/forms/listbox-visible-size.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderListBox.h
Log Message:
-----------
Merge r182672 - Selects don't scroll at some aspect ratios
https://bugs.webkit.org/show_bug.cgi?id=143649
rdar://problem/19365694
Reviewed by Darin Adler.
Source/WebCore:
Fix width/height flip in RenderListBox which caused us to fail to scroll when
the list was wider than the scroll height.
We're generally confused about RenderListBox scroll offsets (webkit.org/b/143648)
but this fixes the immediate problem.
Test: fast/forms/listbox-visible-size.html
* rendering/RenderListBox.h:
LayoutTests:
* fast/forms/listbox-visible-size-expected.txt: Added.
* fast/forms/listbox-visible-size.html: Added.
Commit: b82f1dfe1a35994ea44fc0a7fb4c4a7cde920b8c
https://github.com/WebKit/WebKit/commit/b82f1dfe1a35994ea44fc0a7fb4c4a7cde920b8c
Author: Michael Catanzaro <mcatanzaro at gnome.org>
Date: 2015-04-13 (Mon, 13 Apr 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/SaturatedArithmetic.h
Log Message:
-----------
Merge r182676 - Fix -Wparentheses warning with GCC 5 in SaturatedArithmetic.h
https://bugs.webkit.org/show_bug.cgi?id=143457
Reviewed by Benjamin Poulain.
Tested by WTF.SaturatedArithmeticAddition and WTF.SaturatedArithmeticSubtraction.
* wtf/SaturatedArithmetic.h:
(signedAddOverflows): Use && instead of & to avoid triggering -Wparentheses in newer
versions of GCC and Clang, and to improve the clarity of the function.
(signedSubtractOverflows): Changed correspondingly, although there was no warning here.
Commit: 39e79687eb2777bc254fe73bb0b9451d4cfe0e59
https://github.com/WebKit/WebKit/commit/39e79687eb2777bc254fe73bb0b9451d4cfe0e59
Author: Darin Adler <darin at apple.com>
Date: 2015-04-14 (Tue, 14 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/NavigationScheduler.cpp
Log Message:
-----------
Merge r182734 - Remove needless recreation of URL in NavigationScheduler::scheduleLocationChange
https://bugs.webkit.org/show_bug.cgi?id=143662
Reviewed by Sam Weinig.
* loader/NavigationScheduler.cpp:
(WebCore::NavigationScheduler::scheduleLocationChange): Removed unnecessary code
to convert a URL to a String and then back into a URL.
Commit: 7b32011349c226cfa32eb1399c65661850886165
https://github.com/WebKit/WebKit/commit/7b32011349c226cfa32eb1399c65661850886165
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-04-14 (Tue, 14 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/geometry/fixed-transformed.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/style/RenderStyle.cpp
M Source/WebCore/rendering/style/StyleTransformData.h
Log Message:
-----------
Merge r182743 - Fixed position element is truncated if moved onscreen by a transform
https://bugs.webkit.org/show_bug.cgi?id=143655
Source/WebCore:
rdar://problem/15020044
Reviewed by Darin Adler.
Our "don't do layout if transform changes" code was too aggressive.
If an element changes between having a transform and not having one, we
really need to do a layout since so much else depends on transforms. In
this particular case, we clip position:fixed elements to the viewport if
they are not transformed, and were failing to re-evaluate this when a
transform was added. Doing a layout fixes this.
Test: compositing/geometry/fixed-transformed.html
* rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::changeRequiresLayout):
* rendering/style/StyleTransformData.h:
(WebCore::StyleTransformData::hasTransform):
LayoutTests:
Reviewed by Darin Adler.
Test that moves a position:fixed element on-screen using a transform.
* compositing/geometry/fixed-transformed.html: Added.
Commit: e6eb16e7d9d3356a081107b4e38dc0a5b32238df
https://github.com/WebKit/WebKit/commit/e6eb16e7d9d3356a081107b4e38dc0a5b32238df
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-04-14 (Tue, 14 Apr 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/canvas/canvas-tainted-after-draw-image-expected.txt
A LayoutTests/http/tests/canvas/canvas-tainted-after-draw-image.html
A LayoutTests/http/tests/canvas/resources/100x100-lime-rect.svg
M Source/WebCore/ChangeLog
M Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp
Log Message:
-----------
Merge r182750 - Canvas drawImage() has a security hole when the image isn't yet fully loaded.
https://bugs.webkit.org/show_bug.cgi?id=58681.
Reviewed by Darin Adler.
Source/WebCore:
There is a race condition which may happen if an image from a different
origin is drawn on a canvas before it finishes loading. The check to taint
the canvas comes before drawing it. This check returns false if the image
is not completely loaded because we check the URL of the resource response.
If after this check and before the drawing, the image finishes loading, the
canvas will not be tainted but the image will be drawn.
The fix is to move the check to taint the canvas after drawing the image.
The only problem with this solution is basically the opposite of this bug:
we will become stricter than before with images which are from a different
origin and before they finish loading. The image has not finished loading,
so we do not draw it. Before we check for tainting, the image finishes
loading. So we decide to taint the canvas even the image is not drawn.
But this should not be a security issue anymore. I personally do not know
if it is even a correctness issue or not.
Test: http/tests/canvas/canvas-tainted-after-draw-image.html
* html/canvas/CanvasRenderingContext2D.cpp:
(WebCore::CanvasRenderingContext2D::drawImage):
LayoutTests:
This test confirms when we load an image from a different origin and try
drawing it on a canvas, the canvas is tainted if the image is completely
loaded and drawn. Otherwise the image is not drawn.
* http/tests/canvas/canvas-tainted-after-draw-image-expected.txt: Added.
* http/tests/canvas/canvas-tainted-after-draw-image.html: Added.
* http/tests/canvas/resources: Added.
* http/tests/canvas/resources/100x100-lime-rect.svg: Added.
Commit: e40fe477219cfc35dc1f5216f72e5638887fa75d
https://github.com/WebKit/WebKit/commit/e40fe477219cfc35dc1f5216f72e5638887fa75d
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-04-14 (Tue, 14 Apr 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
M Source/WebCore/rendering/RenderView.cpp
M Source/WebCore/rendering/RenderView.h
Log Message:
-----------
Merge r182773 - Regression: Scrolling on popsci.com spends too much time in FrameView::viewportsContentsChanged()
https://bugs.webkit.org/show_bug.cgi?id=143675
Reviewed by Simon Fraser.
Optimize resumeVisibleImageAnimationsIncludingSubframes() so that the FrameViews'
windowClipRect gets computed less often:
- Cache the FrameView's windowClipRect before resuming image animations in subframes
as calling windowClipRect() on those subframes' view is going to call windowClipRect()
on their ancestors. This avoids a lot of unnecessary windowClipRect recomputations
in deep frame trees.
- Stop traversing the Frame tree if the current frame does not have a content
renderer, as this means the subframes won't have one either.
- Stop traversing the Frame tree if the current frame's view has an empty
windowClipRect() as this means the windowClipRect will be empty for those
subframes as well.
On popsci.com, this cuts down the number of uncached windowClipRect() calls by
approximately half. I see viewportsContentsChanged() at ~0.4% when scrolling
on popsci.com after this change.
* page/FrameView.cpp:
(WebCore::FrameView::resumeVisibleImageAnimationsIncludingSubframes):
(WebCore::FrameView::windowClipRect):
* page/FrameView.h:
* rendering/RenderView.cpp:
(WebCore::RenderView::resumePausedImageAnimationsIfNeeded):
* rendering/RenderView.h:
Commit: a9eccf5757249d9c571d02f6a3e112bea3b9842e
https://github.com/WebKit/WebKit/commit/a9eccf5757249d9c571d02f6a3e112bea3b9842e
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-04-14 (Tue, 14 Apr 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.8.1 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.8.1.
Commit: 2071bfeb767ed967944ee5e26e590950f362e1ae
https://github.com/WebKit/WebKit/commit/2071bfeb767ed967944ee5e26e590950f362e1ae
Author: Brady Eidson <beidson at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Merge r182810 - Media elements not in a page shouldn't load.
https://bugs.webkit.org/show_bug.cgi?id=143720
Reviewed by Jer Noble.
No new tests (Theoretical problem noticed in code review).
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::loadResource): Make sure the frame is in a page.
Commit: 77a7385aeacc8e880917456dc5e2c3b0ee671562
https://github.com/WebKit/WebKit/commit/77a7385aeacc8e880917456dc5e2c3b0ee671562
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
Log Message:
-----------
Merge r182827 - DFG register fillSpeculate*() functions should validate incoming spill format is compatible with requested fill format
https://bugs.webkit.org/show_bug.cgi?id=143727
Reviewed by Geoffrey Garen.
Used the result of AbstractInterpreter<>::filter() to check that the current spill format is compatible
with the requested fill format. If filter() reports a contradiction, then we force an OSR exit.
Removed individual checks made redundant by the new check.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
Commit: 7a221a93bbb2872e06cf80abe206d1b6b8ab65f4
https://github.com/WebKit/WebKit/commit/7a221a93bbb2872e06cf80abe206d1b6b8ab65f4
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/inline/inline-with-column-span-and-remove-block-child-crash-expected.txt
A LayoutTests/fast/inline/inline-with-column-span-and-remove-block-child-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderInline.cpp
Log Message:
-----------
Merge r182835 - Make inline continuation style change logic consistent.
https://bugs.webkit.org/show_bug.cgi?id=143737
rdar://problem/20486596
Reviewed by Simon Fraser.
Do not force RenderBlock type-casting on the first sibling of the continuation's container.
The first sibling of the container of a continuation should be handled as the rest of the siblings.
Source/WebCore:
Test: fast/inline/inline-with-column-span-and-remove-block-child-crash.html
* rendering/RenderInline.cpp:
(WebCore::updateStyleOfAnonymousBlockContinuations):
(WebCore::RenderInline::styleDidChange):
LayoutTests:
* fast/inline/inline-with-column-span-and-remove-block-child-crash-expected.txt: Added.
* fast/inline/inline-with-column-span-and-remove-block-child-crash.html: Added.
Commit: 9e8483b2c807c671be5195251cbefdf31e6b4e7c
https://github.com/WebKit/WebKit/commit/9e8483b2c807c671be5195251cbefdf31e6b4e7c
Author: Jordan Harband <ljharb at gmail.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/js/number-constructor-expected.txt
M LayoutTests/js/script-tests/number-constructor.js
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/NumberConstructor.cpp
Log Message:
-----------
Merge r182863 - Number.parseInt in nightly r182673 has wrong length
https://bugs.webkit.org/show_bug.cgi?id=143657
Patch by Jordan Harband <ljharb at gmail.com> on 2015-04-15
Reviewed by Benjamin Poulain.
Source/JavaScriptCore:
Correcting funciton length from 1, to 2, to match spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
LayoutTests:
* js/number-constructor-expected.txt:
* js/script-tests/number-constructor.js:
Commit: da5757270596353144f5ff5794e0c0dfff7fedcb
https://github.com/WebKit/WebKit/commit/da5757270596353144f5ff5794e0c0dfff7fedcb
Author: Joonghun Park <jh718.park at samsung.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/WorkerThreadableLoader.cpp
M Source/WebCore/loader/cache/MemoryCache.cpp
M Source/WebCore/platform/CrossThreadCopier.h
M Source/WebCore/platform/network/ResourceRequestBase.cpp
M Source/WebCore/platform/network/ResourceRequestBase.h
M Source/WebCore/platform/network/cf/ResourceRequest.h
M Source/WebCore/platform/network/cf/ResourceRequestCFNet.cpp
M Source/WebCore/platform/network/curl/ResourceRequest.h
M Source/WebCore/platform/network/soup/ResourceRequest.h
Log Message:
-----------
Merge r181136 - Use std::unique_ptr instead of PassOwnPtr|OwnPtr for ResourceRequest
https://bugs.webkit.org/show_bug.cgi?id=142349
Patch by Joonghun Park <jh718.park at samsung.com> on 2015-03-05
Reviewed by Darin Adler.
No new tests, no behavior changes.
* loader/WorkerThreadableLoader.cpp:
(WebCore::WorkerThreadableLoader::MainThreadBridge::MainThreadBridge):
* loader/cache/MemoryCache.cpp:
(WebCore::MemoryCache::removeRequestFromSessionCaches):
* platform/CrossThreadCopier.h:
* platform/network/ResourceRequestBase.cpp:
(WebCore::ResourceRequestBase::adopt):
(WebCore::ResourceRequestBase::copyData):
* platform/network/ResourceRequestBase.h:
* platform/network/cf/ResourceRequest.h:
* platform/network/cf/ResourceRequestCFNet.cpp:
(WebCore::ResourceRequest::doPlatformCopyData):
(WebCore::ResourceRequest::doPlatformAdopt):
* platform/network/curl/ResourceRequest.h:
(WebCore::ResourceRequest::doPlatformCopyData):
(WebCore::ResourceRequest::doPlatformAdopt):
* platform/network/soup/ResourceRequest.h:
(WebCore::ResourceRequest::doPlatformCopyData):
(WebCore::ResourceRequest::doPlatformAdopt):
Commit: 89f3435ac797ceef62dbcf3d41c1e8a4a96e2ee4
https://github.com/WebKit/WebKit/commit/89f3435ac797ceef62dbcf3d41c1e8a4a96e2ee4
Author: Joonghun Park <jh718.park at samsung.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/WorkerThreadableLoader.cpp
M Source/WebCore/platform/CrossThreadCopier.h
M Source/WebCore/platform/network/ResourceResponseBase.cpp
M Source/WebCore/platform/network/ResourceResponseBase.h
M Source/WebCore/platform/network/cf/ResourceResponse.h
M Source/WebCore/platform/network/curl/ResourceResponse.h
M Source/WebCore/platform/network/soup/ResourceResponse.h
Log Message:
-----------
Merge r182707 - Use std::unique_ptr instead of PassOwnPtr|OwnPtr for ResourceResponse
https://bugs.webkit.org/show_bug.cgi?id=143056
Patch by Joonghun Park <jh718.park at samsung.com> on 2015-04-13
Reviewed by Gyuyoung Kim.
No new tests, no behavior changes.
* loader/WorkerThreadableLoader.cpp:
(WebCore::WorkerThreadableLoader::MainThreadBridge::MainThreadBridge):
(WebCore::WorkerThreadableLoader::MainThreadBridge::didReceiveResponse):
* platform/CrossThreadCopier.h:
* platform/network/ResourceResponseBase.cpp:
(WebCore::ResourceResponseBase::adopt):
(WebCore::ResourceResponseBase::copyData):
* platform/network/ResourceResponseBase.h:
* platform/network/cf/ResourceResponse.h:
(WebCore::ResourceResponse::doPlatformCopyData):
(WebCore::ResourceResponse::doPlatformAdopt):
* platform/network/curl/ResourceResponse.h:
(WebCore::ResourceResponse::doPlatformCopyData):
(WebCore::ResourceResponse::doPlatformAdopt):
* platform/network/soup/ResourceResponse.h:
(WebCore::ResourceResponse::doPlatformCopyData):
(WebCore::ResourceResponse::doPlatformAdopt):
Commit: 0999b8761f5795529c5fc6c388a6d112fb02a98e
https://github.com/WebKit/WebKit/commit/0999b8761f5795529c5fc6c388a6d112fb02a98e
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ThreadableLoader.cpp
M Source/WebCore/loader/ThreadableLoader.h
M Source/WebCore/loader/WorkerThreadableLoader.cpp
M Source/WebCore/platform/CrossThreadCopier.h
Log Message:
-----------
Merge r182866 - No thread safety when passing ThreadableLoaderOptions from a worker thread
https://bugs.webkit.org/show_bug.cgi?id=143790
Reviewed by Geoffrey Garen.
* loader/ThreadableLoader.h:
* loader/ThreadableLoader.cpp: (WebCore::ThreadableLoaderOptions::isolatedCopy): Added.
* loader/WorkerThreadableLoader.cpp:
(WebCore::WorkerThreadableLoader::MainThreadBridge::MainThreadBridge): Don't just send
a structure with strings to a different thread, that's bad.
* platform/CrossThreadCopier.h: I think that this is dead code, but for this bug,
just removing a clearly wrong specialization.
Commit: a191d5e36cb11ab4837d93c70e562ade9f6933f8
https://github.com/WebKit/WebKit/commit/a191d5e36cb11ab4837d93c70e562ade9f6933f8
Author: Jordan Harband <ljharb at gmail.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/js/math-expected.txt
M LayoutTests/js/script-tests/math.js
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/MathObject.cpp
Log Message:
-----------
Merge r182868 - Math.imul has wrong length in Safari 8.0.4
https://bugs.webkit.org/show_bug.cgi?id=143658
Patch by Jordan Harband <ljharb at gmail.com> on 2015-04-15
Reviewed by Benjamin Poulain.
Source/JavaScriptCore:
Correcting function length from 1, to 2, to match spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.imul
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
LayoutTests:
* js/script-tests/math.js:
Commit: 849e786d0976b6d058fcdec9328ed1d3ee5df659
https://github.com/WebKit/WebKit/commit/849e786d0976b6d058fcdec9328ed1d3ee5df659
Author: Jordan Harband <ljharb at gmail.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/js/script-tests/string-includes.js
M LayoutTests/js/string-includes-expected.txt
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/StringPrototype.cpp
Log Message:
-----------
Merge r182872 - String.prototype.startsWith/endsWith/includes have wrong length in r182673
https://bugs.webkit.org/show_bug.cgi?id=143659
Patch by Jordan Harband <ljharb at gmail.com> on 2015-04-15
Reviewed by Benjamin Poulain.
Source/JavaScriptCore:
Fix lengths of String.prototype.{includes,startsWith,endsWith} per spec
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
LayoutTests:
* js/script-tests/string-includes.js:
* js/string-includes-expected.txt:
Commit: 8d1f3925360cb87423456e089651041cf2737a5d
https://github.com/WebKit/WebKit/commit/8d1f3925360cb87423456e089651041cf2737a5d
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/GraphicsLayer.cpp
Log Message:
-----------
Merge r182880 - We should dump GraphicsLayer's anchorPoint z component
https://bugs.webkit.org/show_bug.cgi?id=143815
Reviewed by Tim Horton.
We didn't include the z component of a layer's anchor point when dumping.
Dump if it's non-zero (to avoid having to change lots of test output).
No test with non-zero z appears to dump layers.
* platform/graphics/GraphicsLayer.cpp:
(WebCore::GraphicsLayer::dumpProperties):
* rendering/style/RenderStyle.cpp:
(WebCore::requireTransformOrigin): Remove a FIXME which, on further consideration,
is wrong.
Commit: a9de41a10064f8787e4155b3de4bfebf943bd6d8
https://github.com/WebKit/WebKit/commit/a9de41a10064f8787e4155b3de4bfebf943bd6d8
Author: Brady Eidson <beidson at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Merge r182918 - Media element can manipulate DOM during Document destruction.
rdar://problem/20553898 and https://bugs.webkit.org/show_bug.cgi?id=143780
Patch by Brady Eidson <beidson at apple.com> on 2015-04-16
Reviewed by Jer Noble.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::configureMediaControls): Bail if the element has no active document.
Commit: dbdd35c1c2670a30e8d255401e2941d0b972d6ee
https://github.com/WebKit/WebKit/commit/dbdd35c1c2670a30e8d255401e2941d0b972d6ee
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestLoaderClient.cpp
Log Message:
-----------
Merge r182943 - [SOUP] Redirect to non HTTP destination is broken
https://bugs.webkit.org/show_bug.cgi?id=143866
Reviewed by Sergio Villar Senin.
Source/WebCore:
This is because we are passing true unconditionally as
isHTTPFamilyRequest parameter of
createSoupRequestAndMessageForHandle in continueAfterWillSendRequest.
We don't actually need to pass isHTTPFamilyRequest parameter to
createSoupRequestAndMessageForHandle, since it can simply check
that from the given request.
Covered by unit tets and also cache/disk-cache/disk-cache-redirect-to-data.html.
* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::continueAfterWillSendRequest):
(WebCore::createSoupRequestAndMessageForHandle):
(WebCore::ResourceHandle::start):
Tools:
Add a unit test to check that redirect to a data URI works.
* TestWebKitAPI/Tests/WebKit2Gtk/TestLoaderClient.cpp:
(testRedirectToDataURI):
(serverCallback):
(beforeAll):
Commit: c6e4a53851b702af2f07b52e20a5f6173e2e2f01
https://github.com/WebKit/WebKit/commit/c6e4a53851b702af2f07b52e20a5f6173e2e2f01
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderTableCell.cpp
Log Message:
-----------
Merge r182962 - RenderTableCell::computeCollapsed*Border() should check if the cell is still attached to the render tree.
https://bugs.webkit.org/show_bug.cgi?id=143887
rdar://problem/20568989
Reviewed by Simon Fraser.
Detached table cell has no access to its parent table. This is a speculative fix to
avoid dereferencing the invalid table pointer.
* rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::computeCollapsedStartBorder):
(WebCore::RenderTableCell::computeCollapsedEndBorder):
(WebCore::RenderTableCell::computeCollapsedBeforeBorder):
(WebCore::RenderTableCell::computeCollapsedAfterBorder):
Commit: 851f444bae1f42b275acf24d17efc24279f85c81
https://github.com/WebKit/WebKit/commit/851f444bae1f42b275acf24d17efc24279f85c81
Author: Bem Jones-Bey <bjonesbe at adobe.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/shapes/shape-outside-floats/shape-outside-negative-line-height-crash-expected.txt
A LayoutTests/fast/shapes/shape-outside-floats/shape-outside-negative-line-height-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/style/RenderStyle.cpp
Log Message:
-----------
Merge r182974 - Large values for line-height cause integer overflow in RenderStyle::computedLineHeight
https://bugs.webkit.org/show_bug.cgi?id=143863
Reviewed by Rob Buis.
Source/WebCore:
When we compute huge values for line-height through percentage or CSS
calc, we'll overflow the integer and later on
ShapeOutsideInfo::computeDeltasForContainingBlockLine will ASSERT
because it expects non-negative line height. So for the computed
line-height, clamp to an integer range to avoid overflow. Note that
the code path for percentages here is safe because LayoutUnit clamps
to an int on conversion.
This is based on a Blink patch by Rob Buis.
Test: fast/shapes/shape-outside-floats/shape-outside-negative-line-height-crash.html
* rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::computedLineHeight): Clamp line-height to an
int to avoid overflow.
LayoutTests:
Simplified test from a fuzzer.
* fast/shapes/shape-outside-floats/shape-outside-negative-line-height-crash-expected.txt: Added.
* fast/shapes/shape-outside-floats/shape-outside-negative-line-height-crash.html: Added.
Commit: 13efa1b4c0253c22e66954116748a3b4871e1c78
https://github.com/WebKit/WebKit/commit/13efa1b4c0253c22e66954116748a3b4871e1c78
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebCoreSupport/WebDiagnosticLoggingClient.cpp
Log Message:
-----------
Merge r182979 - Possible null pointer dereference in WebDiagnosticLoggingClient::logDiagnosticMessageWithValue()
https://bugs.webkit.org/show_bug.cgi?id=143899
<rdar://problem/20584215>
Reviewed by Anders Carlsson.
WebDiagnosticLoggingClient::logDiagnosticMessage*() methods failed to
check that m_page.corePage() was non-null before dereferencing, thus
causing crashes when it is null.
* WebProcess/WebCoreSupport/WebDiagnosticLoggingClient.cpp:
(WebKit::WebDiagnosticLoggingClient::logDiagnosticMessage):
(WebKit::WebDiagnosticLoggingClient::logDiagnosticMessageWithResult):
(WebKit::WebDiagnosticLoggingClient::logDiagnosticMessageWithValue):
Commit: 39e7e92e2e3689f5e14fa08d4044d9d9c1a70342
https://github.com/WebKit/WebKit/commit/39e7e92e2e3689f5e14fa08d4044d9d9c1a70342
Author: Tim Horton <thorton at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/Platform/IPC/Connection.cpp
M Source/WebKit2/UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm
Log Message:
-----------
Merge r182980 - Clients sometimes block for 500ms in waitForPossibleGeometryUpdates
https://bugs.webkit.org/show_bug.cgi?id=143901
<rdar://problem/20488655>
Reviewed by Anders Carlsson.
* Platform/IPC/Connection.cpp:
(IPC::Connection::waitForMessage):
InterruptWaitingIfSyncMessageArrives already cancels waitForMessage if
a sync message arrives while waiting, but it should also avoid waiting
if there's a sync message already in the queue when the waiting starts,
as that will have the same nasty effect.
* UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm:
(WebKit::TiledCoreAnimationDrawingAreaProxy::waitForPossibleGeometryUpdate):
If a synchronous message comes in from the Web process while we're waiting,
cancel our synchronous wait for DidUpdateGeometry. This will cause the size
change to not synchronize with the Web process' painting, but that is better
than pointlessly blocking for 500ms.
Commit: 3c5c6c6731c01c8ee9c37584fea16f97b51f69e1
https://github.com/WebKit/WebKit/commit/3c5c6c6731c01c8ee9c37584fea16f97b51f69e1
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/css/data-uri-mask-expected.html
A LayoutTests/http/tests/css/data-uri-mask.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSParser.cpp
M Source/WebCore/svg/SVGURIReference.h
Log Message:
-----------
Merge r183053 - REGRESSION (r177494): -webkit-mask-image: with data URI fails on non-local files
https://bugs.webkit.org/show_bug.cgi?id=141857
Reviewed by Dirk Schulze.
Source/WebCore:
r177494 regressed loading of data URIs in masks with remote content, triggering
a cross-domain error which occurs because the mask loading happened via a separate
SVGDocument.
Fix by checking for data URIs at parsing time, which is what we used to do.
Test: http/tests/css/data-uri-mask.html
* css/CSSParser.cpp:
(WebCore::CSSParser::parseMaskImage):
* svg/SVGURIReference.h:
(WebCore::SVGURIReference::isExternalURIReference):
LayoutTests:
Ref test with a masked green square. Has to be an http test to trigger the
origin checking.
* http/tests/css/data-uri-mask-expected.html: Added.
* http/tests/css/data-uri-mask.html: Added.
Commit: 8a1f16d9b155d1c8e419c1a46da425b6aa618d90
https://github.com/WebKit/WebKit/commit/8a1f16d9b155d1c8e419c1a46da425b6aa618d90
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/ContainerNode.cpp
M Source/WebCore/dom/ContainerNodeAlgorithms.h
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/EventDispatcher.cpp
M Source/WebCore/dom/EventTarget.cpp
M Source/WebCore/dom/Node.cpp
M Source/WebCore/dom/ScriptExecutionContext.cpp
M Source/WebCore/dom/WebKitNamedFlow.cpp
Log Message:
-----------
Merge r183064 - Use ASSERT_WITH_SECURITY_IMPLICATION() for NoEventDispatchAssertion
https://bugs.webkit.org/show_bug.cgi?id=143971
Reviewed by Darin Adler.
Use ASSERT_WITH_SECURITY_IMPLICATION() for NoEventDispatchAssertion as
firing JS events can cause arbitrary JS execution which often leads to
security bugs when event firing is forbidden. For e.g. firing events
from ActiveDOMObject::suspend() means JS can construct or destroy
ActiveDOMObjects while we are iterating over them.
* dom/ContainerNode.cpp:
(WebCore::dispatchChildInsertionEvents):
(WebCore::dispatchChildRemovalEvents):
* dom/ContainerNodeAlgorithms.h:
(WebCore::ChildNodeInsertionNotifier::notify):
* dom/Document.cpp:
(WebCore::Document::dispatchWindowEvent):
(WebCore::Document::dispatchWindowLoadEvent):
* dom/Element.cpp:
(WebCore::Element::dispatchFocusInEvent):
(WebCore::Element::dispatchFocusOutEvent):
* dom/EventDispatcher.cpp:
(WebCore::EventDispatcher::dispatchEvent):
* dom/EventTarget.cpp:
(WebCore::EventTarget::fireEventListeners):
* dom/Node.cpp:
(WebCore::Node::dispatchSubtreeModifiedEvent):
(WebCore::Node::dispatchDOMActivateEvent):
* dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::canSuspendActiveDOMObjectsForPageCache):
(WebCore::ScriptExecutionContext::suspendActiveDOMObjects):
(WebCore::ScriptExecutionContext::resumeActiveDOMObjects):
(WebCore::ScriptExecutionContext::stopActiveDOMObjects):
(WebCore::ScriptExecutionContext::willDestroyActiveDOMObject):
* dom/WebKitNamedFlow.cpp:
(WebCore::WebKitNamedFlow::dispatchRegionOversetChangeEvent):
Commit: 2cdd2a2a4a1867b705c09b3cd6e8fd61dc7d62f5
https://github.com/WebKit/WebKit/commit/2cdd2a2a4a1867b705c09b3cd6e8fd61dc7d62f5
Author: Jinwoo Song <jinwoo7.song at samsung.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/platform/efl/TestExpectations
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/cairo/PathCairo.cpp
Log Message:
-----------
Merge r183088 - [Cairo] Implement Path::addPath
https://bugs.webkit.org/show_bug.cgi?id=130580
Reviewed by Dirk Schulze.
Source/WebCore:
Add support for addPath method for ports using cairo.
This patch is originally authored by Jae Hyun Park <jaepark at webkit.org>.
Test: fast/canvas/canvas-path-addPath.html
* platform/graphics/cairo/PathCairo.cpp:
(WebCore::Path::addPath): Implement addPath for cairo.
LayoutTests:
Enable addPath testcase in EFL port.
* platform/efl/TestExpectations:
Commit: abe8de86a6dc08161f1425f81a057f4606cf4c30
https://github.com/WebKit/WebKit/commit/abe8de86a6dc08161f1425f81a057f4606cf4c30
Author: Antti Koivisto <koivisto at iki.fi>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/ScriptRunner.cpp
Log Message:
-----------
Merge r183178 - CrashTracer: WebProcess at com.apple.WebCore: WebCore::toScriptElementIfPossible + 4
https://bugs.webkit.org/show_bug.cgi?id=144050
rdar://problem/15534973
Reviewed by Chris Dumez.
We are seeing null Element pointer crashes with this stack:
47 com.apple.WebCore: WebCore::toScriptElementIfPossible + 4 <==
47 com.apple.WebCore: WebCore::ScriptRunner::timerFired + 452
47 com.apple.WebCore: WebCore::ThreadTimers::sharedTimerFiredInternal + 175
The most likely cause seems to be that this code
ASSERT(m_pendingAsyncScripts.contains(scriptElement));
m_scriptsToExecuteSoon.append(m_pendingAsyncScripts.take(scriptElement));
in ScriptRunner::notifyScriptReady fails to find scriptElement and we are left with a null entry in
m_scriptsToExecuteSoon. However I haven't managed to repro this or find the exact path how this
could happen. The related code is fragile with lot of state (in ScriptElement class)
and involves many opportunities for re-entry via scripts.
No repro, no test case.
* dom/ScriptRunner.cpp:
(WebCore::ScriptRunner::timerFired):
Paper this over by adding a null check. We could check m_pendingAsyncScripts.take() above
but this also covers possibility this is caused by something else.
Commit: 65e9950f54d3cec47546fbaf16484c6bc9ebdba0
https://github.com/WebKit/WebKit/commit/65e9950f54d3cec47546fbaf16484c6bc9ebdba0
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/EmptyClients.h
M Source/WebCore/page/DiagnosticLoggingClient.h
M Source/WebCore/page/MainFrame.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebCoreSupport/WebDiagnosticLoggingClient.cpp
M Source/WebKit2/WebProcess/WebCoreSupport/WebDiagnosticLoggingClient.h
Log Message:
-----------
Merge r183179 - [WK2] WebDiagnosticLoggingClient is leaking
https://bugs.webkit.org/show_bug.cgi?id=144089
<rdar://problem/19706214>
Reviewed by Darin Adler.
WebDiagnosticLoggingClient is leaking. It is constructed inside WebPage
constructor but there is no code destroying it.
This patch adds a new xxxDestroyed() virtual function to
DiagnosticLoggingClient and that is overriden in
WebDiagnosticLoggingClient to call "delete this". This is the same
pattern as for other WK2 clients (e.g. WebFrameLoaderClient,
WebProgressTrackerClient).
Source/WebCore:
* loader/EmptyClients.h:
* page/DiagnosticLoggingClient.h:
* page/MainFrame.cpp:
(WebCore::MainFrame::~MainFrame):
Source/WebKit2:
* WebProcess/WebCoreSupport/WebDiagnosticLoggingClient.cpp:
(WebKit::WebDiagnosticLoggingClient::mainFrameDestroyed):
* WebProcess/WebCoreSupport/WebDiagnosticLoggingClient.h:
Commit: a1f4b4c74f6ed8d818fe517fa9595ec136a63d49
https://github.com/WebKit/WebKit/commit/a1f4b4c74f6ed8d818fe517fa9595ec136a63d49
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/soup/SoupNetworkSession.cpp
M Source/WebCore/platform/network/soup/SoupNetworkSession.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/NetworkProcess/soup/NetworkProcessSoup.cpp
M Source/WebKit2/WebProcess/soup/WebProcessSoup.cpp
Log Message:
-----------
Merge r183255 - [SOUP] Use a webkit subdirectory for the disk cache
https://bugs.webkit.org/show_bug.cgi?id=144048
Reviewed by Martin Robinson.
Source/WebCore:
Add a static method to SoupNetworkSession to clear a soup cache
given its directory.
* platform/network/soup/SoupNetworkSession.cpp:
(WebCore::strIsNumeric):
(WebCore::SoupNetworkSession::clearCache):
* platform/network/soup/SoupNetworkSession.h:
Source/WebKit2:
Recent versions of libsoup remove any file in cache dir not
referenced by the index when the cache is loaded to workaround
leaked resources when load/dump is unbalanced for whatever reason,
like a crash. We currently use $XDG_CACHE_HOME/app-name as default
disk cache directory, but that directory could be used by apps to
cache other things, and the soup cache might end up deleting other
stuff. The soup cache assumes the given directory is only for the
disk cache, so we should ensure that.
* NetworkProcess/soup/NetworkProcessSoup.cpp:
(WebKit::NetworkProcess::platformInitializeNetworkProcess): Append
webkit to the given disk cache and clear the previous soup cache if it exists.
* WebProcess/soup/WebProcessSoup.cpp:
(WebKit::WebProcess::platformInitializeWebProcess): Ditto.
Commit: f7233c6026253e7e70a8f0d9bb3d96f12f1f3e1d
https://github.com/WebKit/WebKit/commit/f7233c6026253e7e70a8f0d9bb3d96f12f1f3e1d
Author: Matthew Mirman <mmirman at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/js/script-tests/sloppy-getter-setter-global-object.js
A LayoutTests/js/sloppy-getter-setter-global-object-expected.txt
A LayoutTests/js/sloppy-getter-setter-global-object.html
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
Log Message:
-----------
Merge r183275 - Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
https://bugs.webkit.org/show_bug.cgi?id=141865
rdar://problem/19927273
Reviewed by Filip Pizlo.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter):
LayoutTests:
Added tests to ensure that Object.prototype.__proto__ native getter and setter do not coerce undefined to this
https://bugs.webkit.org/show_bug.cgi?id=141865
rdar://problem/19927273
Reviewed by Filip Pizlo.
* js/script-tests/sloppy-getter-setter-global-object.js: Added.
* js/sloppy-getter-setter-global-object-expected.txt: Added.
* js/sloppy-getter-setter-global-object.html: Added.
Commit: 1e6219974fa4aacb6cf38475e7bedd7f2b52b3d5
https://github.com/WebKit/WebKit/commit/1e6219974fa4aacb6cf38475e7bedd7f2b52b3d5
Author: Brady Eidson <beidson at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/security/cors-post-redirect-301-expected.txt
A LayoutTests/http/tests/security/cors-post-redirect-301.html
A LayoutTests/http/tests/security/cors-post-redirect-302-expected.txt
A LayoutTests/http/tests/security/cors-post-redirect-302.html
A LayoutTests/http/tests/security/cors-post-redirect-307-expected.txt
A LayoutTests/http/tests/security/cors-post-redirect-307.html
A LayoutTests/http/tests/security/cors-post-redirect-308-expected.txt
A LayoutTests/http/tests/security/cors-post-redirect-308.html
A LayoutTests/http/tests/security/resources/cors-post-redirect-target.php
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/cf/ResourceHandleCFNet.cpp
M Source/WebCore/platform/network/mac/ResourceHandleMac.mm
M Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp
Log Message:
-----------
Merge r183280,r183672 - Origin header is preserved on cross-origin redirects.
https://bugs.webkit.org/show_bug.cgi?id=144157.
Reviewed by Sam Weinig.
Source/WebCore:
Tests: http/tests/security/cors-post-redirect-301.html
http/tests/security/cors-post-redirect-302.html
http/tests/security/cors-post-redirect-307.html
http/tests/security/cors-post-redirect-308.html
* platform/network/cf/ResourceHandleCFNet.cpp:
(WebCore::ResourceHandle::willSendRequest): Always clear any origin header for cross-origin redirects.
* platform/network/mac/ResourceHandleMac.mm:
(WebCore::ResourceHandle::willSendRequest): Ditto.
LayoutTests:
* http/tests/security/cors-post-redirect-301-expected.txt: Added.
* http/tests/security/cors-post-redirect-301.html: Added.
* http/tests/security/cors-post-redirect-302-expected.txt: Added.
* http/tests/security/cors-post-redirect-302.html: Added.
* http/tests/security/cors-post-redirect-307-expected.txt: Added.
* http/tests/security/cors-post-redirect-307.html: Added.
* http/tests/security/cors-post-redirect-308-expected.txt: Added.
* http/tests/security/cors-post-redirect-308.html: Added.
* http/tests/security/resources/cors-post-redirect-target.php: Added.
[GTK] New CORS tests from r183280 fail on WebKitGTK+
https://bugs.webkit.org/show_bug.cgi?id=144469
Reviewed by Sergio Villar Senin.
No new tests. This causes failing tests to pass.
* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::doRedirect): Clear the origin header on cross-origin redirects.
Commit: 2fc4c7972306264d83b8555c54908bb7a3d55050
https://github.com/WebKit/WebKit/commit/2fc4c7972306264d83b8555c54908bb7a3d55050
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/JSObject.cpp
A Source/JavaScriptCore/tests/stress/int32array-transition-on-nan.js
Log Message:
-----------
Merge r183291 - [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
https://bugs.webkit.org/show_bug.cgi?id=144169
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-04-24
Reviewed by Geoffrey Garen.
* runtime/JSObject.cpp:
(JSC::JSObject::convertInt32ForValue):
DoubleArray do not store NaN, they are used for holes.
What happened was:
1) We fail to insert the NaN in the Int32 array because it is a double.
2) We were converting the array to DoubleArray.
3) We were trying to insert the value again. We would fail again because
DoubleArray does not store NaN.
4) We would convert the DoubleArrayt to Contiguous Array, converting the values
to boxed values.
* tests/stress/int32array-transition-on-nan.js: Added.
The behavior is not really observable. This only test nothing crashes in those
cases.
(insertNaNWhileFilling):
(testInsertNaNWhileFilling):
(insertNaNAfterFilling):
(testInsertNaNAfterFilling):
(pushNaNWhileFilling):
(testPushNaNWhileFilling):
Commit: 57868d456d8dc648bd5142f64e9ebadbe5337e95
https://github.com/WebKit/WebKit/commit/57868d456d8dc648bd5142f64e9ebadbe5337e95
Author: Yoav Weiss <yoav at yoav.ws>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/media/mq-viewport-units-expected.txt
A LayoutTests/fast/media/mq-viewport-units.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSPrimitiveValue.h
M Source/WebCore/css/MediaQueryExp.cpp
Log Message:
-----------
Merge r183404 - Fix viewport units in Media Queries
https://bugs.webkit.org/show_bug.cgi?id=144260
Reviewed by Darin Adler.
Source/WebCore:
This patch makes sure that viewport units are considered "length units"
in the context of Media Queries, by having MediaQueryExp use the unit logic
that is in CSSPrimitiveValue.
It does that by turning the relevant methods in CSSPrimitiveValue into static.
It also makes sure that the logic for "resolution units" is not maintained separately
in MediaQueryExp, to avoid similiar issues in the future with resolution units.
Test: fast/media/mq-viewport-units.html
* css/CSSPrimitiveValue.h:
(WebCore::CSSPrimitiveValue::isViewportPercentageLength): Added a static variant.
(WebCore::CSSPrimitiveValue::isLength): Added a static variant.
(WebCore::CSSPrimitiveValue::isResolution): Added a static variant.
* css/MediaQueryExp.cpp:
(WebCore::featureWithValidPositiveLenghtOrNumber): Call CSSPrimitiveValue's length unit logic.
(WebCore::featureWithValidDensity): Call CSSPrimitiveValue's resolution unit logic.
LayoutTests:
These tests make sure that viewport units are working as expected inside of Media Queries.
* fast/media/mq-viewport-units-expected.txt: Added.
* fast/media/mq-viewport-units.html: Added.
Commit: c66c9765414f1b0a964635079646333d1c582cdf
https://github.com/WebKit/WebKit/commit/c66c9765414f1b0a964635079646333d1c582cdf
Author: Daniel Bates <dbates at webkit.org>
Date: 2015-05-11 (Mon, 11 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/forms/change-form-id-to-be-unique-expected.txt
A LayoutTests/fast/forms/change-form-id-to-be-unique-then-submit-form-expected.txt
A LayoutTests/fast/forms/change-form-id-to-be-unique-then-submit-form.html
A LayoutTests/fast/forms/change-form-id-to-be-unique.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/TreeScope.cpp
M Source/WebCore/dom/TreeScope.h
Log Message:
-----------
Merge r183436 - Form control may be associated with the wrong HTML Form element after form id change
https://bugs.webkit.org/show_bug.cgi?id=133456
<rdar://problem/17095055>
Reviewed by Andy Estes.
Source/WebCore:
Fixes an issue where a form control may be associated with the wrong HTML Form element
after the id of the HTML Form element associated with the form control is changed when
there is more than one HTML Form element with the same id in the document. Specifically,
a form control that has an HTML form attribute value X will always be associated with
some HTML Form element f where f.id = X regardless of whether f.id is subsequently
changed.
Tests: fast/forms/change-form-id-to-be-unique-then-submit-form.html
fast/forms/change-form-id-to-be-unique.html
* dom/Element.cpp:
(WebCore::Element::attributeChanged): Notify observers when the id of an element changed.
(WebCore::Element::updateId): Added parameter NotifyObservers (defaults to NotifyObservers::Yes),
as to whether we should notify observers of the id change.
(WebCore::Element::updateIdForTreeScope): Ditto.
(WebCore::Element::willModifyAttribute): Do not notify observers of the id change immediately. As
indicated by the name of this method, we plan to modify the DOM attribute id of the element, but
we have not actually modified it when this method is called. Instead we will notify observers
in Element::attributeChanged(), which is called after the DOM attribute id is modified.
(WebCore::Element::cloneAttributesFromElement): Ditto.
* dom/Element.h: Defined enum class NotifyObservers.
* dom/TreeScope.cpp:
(WebCore::TreeScope::addElementById): Added boolean parameter notifyObservers (defaults to true)
as to whether we should dispatch a notification to all observers.
(WebCore::TreeScope::removeElementById): Ditto.
* dom/TreeScope.h:
LayoutTests:
Add tests to ensure that we associate the correct HTML Form element with a
<select> after changing the id of its associated HTML form element.
* fast/forms/change-form-id-to-be-unique-expected.txt: Added.
* fast/forms/change-form-id-to-be-unique-then-submit-form-expected.txt: Added.
* fast/forms/change-form-id-to-be-unique-then-submit-form.html: Added.
* fast/forms/change-form-id-to-be-unique.html: Added.
Commit: 96fc6f62098d71290cacc342d91cb11fc6e0acf6
https://github.com/WebKit/WebKit/commit/96fc6f62098d71290cacc342d91cb11fc6e0acf6
Author: Alex Christensen <achristensen at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/HashTable.h
Log Message:
-----------
Merge r183504 - Properly reset deleted count when clearing HashTables.
https://bugs.webkit.org/show_bug.cgi?id=144343
Reviewed by Andreas Kling.
* wtf/HashTable.h:
(WTF::KeyTraits>::clear):
Reset m_deletedCount, which appears to have been forgotten.
Commit: 43cd0f25e512efbc350a76f56e5964d65a8a4799
https://github.com/WebKit/WebKit/commit/43cd0f25e512efbc350a76f56e5964d65a8a4799
Author: Hyungwook Lee <hyungwook.lee at navercorp.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/editing/execCommand/crash-140261-expected.txt
A LayoutTests/editing/execCommand/crash-140261.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderView.cpp
Log Message:
-----------
Merge r183538 - Fix crash in WebCore::LogicalSelectionOffsetCaches::ContainingBlockInfo::setBlock().
https://bugs.webkit.org/show_bug.cgi?id=140261
Patch by Hyungwook Lee <hyungwook.lee at navercorp.com> on 2015-04-29
Reviewed by Darin Adler.
Source/WebCore:
We need to check whether RenderObject is valid in RenderView::fooSubtreeSelection functions
because invalid object has caused a crash. This patch adds isValidObjectForNewSelection(), and use it.
* rendering/RenderView.cpp:
(WebCore::isValidObjectForNewSelection):
(WebCore::RenderView::clearSubtreeSelection):
(WebCore::RenderView::applySubtreeSelection):
LayoutTests:
* editing/execCommand/crash-140261-expected.txt: Added.
* editing/execCommand/crash-140261.html: Added.
Commit: dd2555ddcfb872d49956cb3514b9efaab3e656e6
https://github.com/WebKit/WebKit/commit/dd2555ddcfb872d49956cb3514b9efaab3e656e6
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
A Source/JavaScriptCore/tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js
Log Message:
-----------
Merge r183564 - Safari WebKit crash when loading Google Spreadsheet.
https://bugs.webkit.org/show_bug.cgi?id=144020
Reviewed by Filip Pizlo.
The bug is that the object allocation sinking phase did not account for a case
where a property of a sunken object is only initialized on one path and not
another. As a result, on the path where the property is not initialized, we'll
encounter an Upsilon with a BottomValue (which is not allowed by definition).
The fix is to use a JSConstant(undefined) as the bottom value instead (of
BottomValue). If the property is uninitialized, it should still be accessible
and have the value undefined.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
* tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
(foo):
(foo2):
Commit: 4e2d685a858ad0a4efa1d057b345c84af2e99777
https://github.com/WebKit/WebKit/commit/4e2d685a858ad0a4efa1d057b345c84af2e99777
Author: David Hyatt <hyatt at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBoxModelObject.cpp
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLineBoxList.cpp
M Source/WebCore/rendering/RenderView.cpp
M Source/WebCore/rendering/RenderView.h
Log Message:
-----------
Merge r183636 - Avoid containingBlock() calls when no writing mode flipping is needed.
https://bugs.webkit.org/show_bug.cgi?id=144407
Reviewed by Simon Fraser.
Add a bool to RenderView that indicates whether or not any flipped blocks have been
added to the view. Once tainted, the view just stays dirty forever. If no flipped
blocks are ever seen, we can then optimize away calls to containingBlock().
The motivation for this patch is to improve layer position updating, which makes many
calls to topLeftLocationOffset(), one of the functions that can be optimized by this
change.
* rendering/RenderBox.cpp:
(WebCore::RenderBox::layoutOverflowRectForPropagation):
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::updateFromStyle):
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderLineBoxList.cpp:
(WebCore::RenderLineBoxList::rangeIntersectsRect):
* rendering/RenderView.cpp:
(WebCore::RenderView::RenderView):
* rendering/RenderView.h:
Commit: b1d813273013ec2d7fcc1f4c2663c0c686decdb1
https://github.com/WebKit/WebKit/commit/b1d813273013ec2d7fcc1f4c2663c0c686decdb1
Author: Brady Eidson <beidson at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/storage/websql/alter-to-info-table-expected.txt
A LayoutTests/storage/websql/alter-to-info-table.html
A LayoutTests/storage/websql/alter-to-info-table.js
M LayoutTests/storage/websql/test-authorizer-expected.txt
M LayoutTests/storage/websql/test-authorizer.js
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/webdatabase/DatabaseBackendBase.cpp
Log Message:
-----------
Merge r183646 - Javascript using WebSQL can create their own WebKit info table.
<rdar://problem/20688792> and https://bugs.webkit.org/show_bug.cgi?id=144466
Reviewed by Alex Christensen.
Source/WebCore:
Test: storage/websql/alter-to-info-table.html
* Modules/webdatabase/DatabaseBackendBase.cpp:
(WebCore::DatabaseBackendBase::databaseInfoTableName): Return the info table name.
(WebCore::fullyQualifiedInfoTableName): Append "main." to the info table name.
(WebCore::DatabaseBackendBase::DatabaseBackendBase): Use the fully qualified name.
(WebCore::DatabaseBackendBase::performOpenAndVerify): Ditto.
(WebCore::DatabaseBackendBase::getVersionFromDatabase): Ditto.
(WebCore::DatabaseBackendBase::setVersionInDatabase): Ditto.
LayoutTests:
* storage/websql/alter-to-info-table-expected.txt: Added.
* storage/websql/alter-to-info-table.html: Added.
* storage/websql/alter-to-info-table.js: Added.
Commit: c568fcb6e48e380f0cb7fd313661859139e1e8d2
https://github.com/WebKit/WebKit/commit/c568fcb6e48e380f0cb7fd313661859139e1e8d2
Author: Oliver Hunt <oliver at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
Log Message:
-----------
Merge r183648 - DOM bindings should not be using a reference type to point to a temporary object
https://bugs.webkit.org/show_bug.cgi?id=144474
Reviewed by Beth Dakin.
The DOM bindings will currently try and use a local reference to point
to a temporary object. This currently works as a by product of the compiler's
stack layout. This patch removes the dependency on undefined behaviour
by ensuring that we use a value rather than reference type.
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateParametersCheck):
(GetNativeTypeForCallbacks):
Commit: e7a82c6676d9f510bd1ee8c3fb4f6b86e83b84ee
https://github.com/WebKit/WebKit/commit/e7a82c6676d9f510bd1ee8c3fb4f6b86e83b84ee
Author: Dan Bernstein <mitz at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebPageProxy.cpp
M Source/WebKit2/UIProcess/WebPageProxy.h
M Source/WebKit2/UIProcess/WebPageProxy.messages.in
M Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
M Source/WebKit2/WebProcess/WebPage/WebPage.h
M Source/WebKit2/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKit2Cocoa/LoadAlternateHTMLString.mm
Log Message:
-----------
Merge r183698 - Back/forward navigation to an error page in Safari breaks the back-forward list
https://bugs.webkit.org/show_bug.cgi?id=144501
Reviewed by Darin Adler.
Test: TestWebKitAPI/Tests/WebKit2Cocoa/LoadAlternateHTMLString.mm
Normally, loading substitute data (such as an error page) creates a new back-forward list
item. FrameLoader has a mechanism that detects when a substitute data load occurs during
handling of a provisional load error and prevents the creation of a new back-forwards list
item in that case if the unreachable URL is the same as the failing provisional URL. This
mechanism was broken in WebKit2, where handling the provisional load error is asynchronous.
The fix is to capture some state (namely, the failing provisional URL) when dispatching the
load error and allow it to be restored when loading the substitute data.
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::FrameLoader): Removed initialization of
m_delegateIsHandlingProvisionalLoadError.
(WebCore::FrameLoader::shouldReloadToHandleUnreachableURL): Instead of checking
m_delegateIsHandlingProvisionalLoadError and if true using the provisional document loader’s
URL, check m_provisionalLoadErrorBeingHandledURL.
(WebCore::FrameLoader::checkLoadCompleteForThisFrame): Instead of checking and setting
m_delegateIsHandlingProvisionalLoadError, use m_provisionalLoadErrorBeingHandledURL.
* loader/FrameLoader.h:
(WebCore::FrameLoader::provisionalLoadErrorBeingHandledURL): Added this getter. The client
can call this from its override of dispatchDidFailProvisionalLoad and store the result.
(WebCore::FrameLoader::setProvisionalLoadErrorBeingHandledURL): Added this setter. The
client can call this prior to loading substitute data if it’s done as part of handling a
previously-dispatched didFailProvisionalLoad.
Source/WebKit2:
WebKit2 part of <rdar://problem/8636045> Back/forward navigation to an error page in Safari breaks the back-forward list
https://bugs.webkit.org/show_bug.cgi?id=144501
Reviewed by Darin Adler.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::loadAlternateHTMLString): If this is called during
didFailProvisionalLoadForFrame, send back the provisional URL captured at the time of
failure.
(WebKit::WebPageProxy::didFailProvisionalLoadForFrame): Get the provisioinal URL and keep
it in new member variable m_failingProvisionalLoadURL for the duration of the client’s
handling of this message.
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in: Added provisionalURL parameter to
DidFailProvisionalLoadForFrame.
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::dispatchDidFailProvisionalLoad): Send the URL for this error
to the UI process.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::loadAlternateHTMLString): Temporarily restore the loader’s state to
reflect the provisional load error being handled.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in: Added provisionalLoadErrorURL parameter to
LoadAlternateHTMLString.
Commit: 4e6eba23078480293744f6c7ded94d3f70e37733
https://github.com/WebKit/WebKit/commit/4e6eba23078480293744f6c7ded94d3f70e37733
Author: Andreas Kling <akling at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/HTMLImageElement/remove-name-id-attribute-from-image-expected.txt
A LayoutTests/fast/dom/HTMLImageElement/remove-name-id-attribute-from-image.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Merge r183706 - Reproducible crash removing name attribute from <img> node
<https://webkit.org/b/144371>
<rdar://problem/17198583>
Reviewed by Darin Adler.
Source/WebCore:
The problem here was with HTMLImageElement::getNameAttribute(), which relies
on Element::hasName() to avoid slow attribute lookups when the attribute
is already known not to be present. Unfortunately hasName() uses an ElementData
flag that wasn't getting updated until after the call to parseAttribute().
This patch fixes the issue by moving the code that updates the hasName() flag
before the parseAttribute() virtual dispatch.
Test: fast/dom/HTMLImageElement/remove-name-id-attribute-from-image.html
* dom/Element.cpp:
(WebCore::Element::attributeChanged):
LayoutTests:
* fast/dom/HTMLImageElement/remove-name-id-attribute-from-image-expected.txt: Added.
* fast/dom/HTMLImageElement/remove-name-id-attribute-from-image.html: Added.
Commit: 9110d48aafb6234d8dfb0c197993d1b324018f88
https://github.com/WebKit/WebKit/commit/9110d48aafb6234d8dfb0c197993d1b324018f88
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/gobject/DOMObjectCache.cpp
Log Message:
-----------
Merge r183729 - [GTK] API tests crashing on debug builds due to extra unref
https://bugs.webkit.org/show_bug.cgi?id=144508
Reviewed by Mario Sanchez Prada.
The problem is that we were assuming that when a new DOMWindow is
created, the DOM object cache was notified about the previous
DOMWindow being destroyed before objects for the new DOMWindow are
added to the cache. However, that's not always the case and we
only create a DOMWindowObserver for the first DOMWindow. We need
to keep a pointer to the DOMWindow being observed to clear() the
cache and create a new DOMWindowObserver when it changes in the
Frame.
Fixes crashes in several unit tests in debug builds.
* bindings/gobject/DOMObjectCache.cpp:
Commit: 99b34bf35aca76dabe4321e93d709fc024b7fedc
https://github.com/WebKit/WebKit/commit/99b34bf35aca76dabe4321e93d709fc024b7fedc
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/linux/MemoryPressureHandlerLinux.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/Shared/linux/WebMemorySamplerLinux.cpp
Log Message:
-----------
Merge r183740 - [ARM] Don't compare unsigned chars to EOF (-1)
https://bugs.webkit.org/show_bug.cgi?id=144439
Reviewed by Geoffrey Garen.
Source/WebCore:
* platform/linux/MemoryPressureHandlerLinux.cpp:
(WebKit::nextToken): Don't cast return value of fgetc() to char.
Source/WebKit2:
* Shared/linux/WebMemorySamplerLinux.cpp:
(WebKit::nextToken): Don't cast return value of fgetc() to char.
Commit: 4e8e1a3a0eee538ee1ac2ecc5e699932027bc862
https://github.com/WebKit/WebKit/commit/4e8e1a3a0eee538ee1ac2ecc5e699932027bc862
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M ChangeLog
M Source/cmake/OptionsCommon.cmake
Log Message:
-----------
Merge r183741 - [cmake] Disable GNU Gold linker on Cortex A53
https://bugs.webkit.org/show_bug.cgi?id=144382
Reviewed by Carlos Garcia Campos.
* Source/cmake/OptionsCommon.cmake:
Commit: 4779587e0fd4797d9eafb3b0f07ced39607d8322
https://github.com/WebKit/WebKit/commit/4779587e0fd4797d9eafb3b0f07ced39607d8322
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/css/negative-calc-values-expected.txt
A LayoutTests/fast/css/negative-calc-values.html
A LayoutTests/fast/css/padding-calc-value-expected.txt
A LayoutTests/fast/css/padding-calc-value.html
M LayoutTests/fast/css/text-shadow-calc-value-expected.txt
M LayoutTests/fast/css/text-shadow-calc-value.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/CSSCalculationValue.h
M Source/WebCore/css/CSSParser.cpp
Log Message:
-----------
Merge r183765 - REGRESSION (r178156): CSS Parser incorrectly rejects valid calc() in padding-right property
https://bugs.webkit.org/show_bug.cgi?id=144584
<rdar://problem/20796829>
Reviewed by Darin Adler.
Source/WebCore:
The CSS parser was rejecting calculated values at parsing time if it
considered the value was negative and the CSS property did not allow
negative values. However, doing so at this point will not always work
because we don't necessarily know the font-size yet (for e.g. for
calc(0.5em - 2px). Also, rejecting negative calculated values is not
the right behavior as the the specification. The specification says
we should clamp:
http://dev.w3.org/csswg/css-values-3/#calc-range
This patch updates validateCalculationUnit() to stop marking the value
as invalid if it is negative. Instead, let the CSSCalcValue's permitted
range clamp the value as needed.
This bug was causing the bottom graphic on aldentrio.com to not be
rendered properly.
Test: fast/css/negative-calc-values.html
fast/css/padding-calc-value.html
* css/CSSParser.cpp:
(WebCore::CSSParser::validateCalculationUnit):
LayoutTests:
* fast/css/negative-calc-values-expected.txt: Added.
* fast/css/negative-calc-values.html: Added.
Add a layout test that assigns negative calc() values to properties
whose values cannot be negative to verify that values are clamped as
per the specification:
http://dev.w3.org/csswg/css-values-3/#calc-range
* fast/css/padding-calc-value-expected.txt: Added.
* fast/css/padding-calc-value.html: Added.
Add a layout test to test that using calc(.5em - 2px) for padding-right
CSS property works as intended. It used to be resolved as 0px instead
of "2*font-size - 2px".
* fast/css/text-shadow-calc-value-expected.txt:
* fast/css/text-shadow-calc-value.html:
Update test to match what the specification says:
http://dev.w3.org/csswg/css-values-3/#calc-range
"width: calc(5px - 10px);" is equivalent to "width: 0px;" since widths
smaller than 0px are not allowed.
Commit: 426ff972b5e5baea988d504380f94df9822ff4e9
https://github.com/WebKit/WebKit/commit/426ff972b5e5baea988d504380f94df9822ff4e9
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/Window/resources/test-frame.html
A LayoutTests/fast/dom/Window/window-open-activeWindow-null-frame-expected.txt
A LayoutTests/fast/dom/Window/window-open-activeWindow-null-frame.html
M Source/WebCore/ChangeLog
M Source/WebCore/inspector/InspectorFrontendClientLocal.cpp
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/page/DOMWindow.cpp
Log Message:
-----------
Merge r183781 - Crash at com.apple.WebKit.WebContent at com.apple.WebCore: WebCore::createWindow + 185
https://bugs.webkit.org/show_bug.cgi?id=144597
<rdar://problem/20361579>
Reviewed by Andreas Kling.
Source/WebCore:
Test: fast/dom/Window/window-open-activeWindow-null-frame.html
In our implementation of window.open(), we make sure that the window
which window.open() is called has a frame. However, we did not have the
same check for the activeDOMWindow (i.e. the lexicalGlobalObject) causing
us to crash in WebCore::createWindow() when dereferencing it.
This patch updates WebCore::createWindow() takes a reference to the
openerFrame instead of a pointer to make it clear the implementation
expects it to be non-null. A null check is then added for the frame
at the call site: DOMWindow::createWindow().
* inspector/InspectorFrontendClientLocal.cpp:
(WebCore::InspectorFrontendClientLocal::openInNewTab):
* loader/FrameLoader.cpp:
(WebCore::isDocumentSandboxed):
(WebCore::FrameLoader::submitForm):
(WebCore::createWindow):
Take a reference to openerFrame instead of a pointer as the
implementation expects it to be non-null.
* loader/FrameLoader.h:
* page/DOMWindow.cpp:
(WebCore::DOMWindow::createWindow):
Add null check for activeFrame before passing it to
WebCore::createWindow().
LayoutTests:
Add a layout test to cover the case where window.open() is called on a
window that is different than the activeDOMWindow and where the
activeDOMWindow does not have a frame.
* fast/dom/Window/resources/test-frame.html: Added.
* fast/dom/Window/window-open-activeWindow-null-frame-expected.txt: Added.
* fast/dom/Window/window-open-activeWindow-null-frame.html: Added.
Commit: 6de95c87f1b7debef81b8fe0fff975f58ce52102
https://github.com/WebKit/WebKit/commit/6de95c87f1b7debef81b8fe0fff975f58ce52102
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/rendering/RenderFrameBase.cpp
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderView.h
M Source/WebCore/rendering/RenderWidget.cpp
M Source/WebCore/rendering/RenderWidget.h
Log Message:
-----------
Merge r183788 - RenderWidget::setWidgetGeometry() can end up destroying *this*.
https://bugs.webkit.org/show_bug.cgi?id=144601
Reviewed by Andreas Kling.
This is a speculative fix to ensure we don't crash on an invalid *this* renderer
while flattening the current iframe.
Calling RenderWidget::setWidgetGeometry() can result in destroying the current renderer.
While it is not a issue in case of normal layout flow as widget positions are updated at post layout,
frame flattening initiates this action in the middle of layout.
This patch re-introduces refcount model for RenderWidgets so that the renderer is protected during layout
when frame flattening is in use.
* rendering/RenderFrameBase.cpp:
(WebCore::RenderFrameBase::layoutWithFlattening): Let's be paranoid about child view.
* rendering/RenderObject.cpp:
(WebCore::RenderObject::destroy):
* rendering/FrameView.cpp:
(WebCore::FrameView::layout):
* rendering/RenderView.h:
* rendering/RenderWidget.cpp:
(WebCore::RenderWidget::~RenderWidget):
* rendering/RenderWidget.h:
(WebCore::RenderWidget::ref):
(WebCore::RenderWidget::deref):
Commit: de883173726a9309fabb470539e44b378cc1da1d
https://github.com/WebKit/WebKit/commit/de883173726a9309fabb470539e44b378cc1da1d
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WebKit2/Platform/gtk/WorkQueueGtk.cpp
Log Message:
-----------
Merge r183800 - [GTK] Async operations running in the WorkQueue thread should schedule their sources to the WorkQueue main lopp
https://bugs.webkit.org/show_bug.cgi?id=144541
Reviewed by Žan Doberšek.
Source/WTF:
They are currently sent to the main thread run loop, because we
are not setting the WorkQueue main context as the default one in
the worker thread.
* wtf/gtk/WorkQueueGtk.cpp:
(WTF::WorkQueue::platformInitialize): Call
g_main_context_push_thread_default() to set the WorkQueue main
context as the default of the thread before running the main loop,
and g_main_context_pop_thread_default() when the main loop quits.
Commit: 85da21f0f21fcaf5adf5b539fcd100aa857ca17e
https://github.com/WebKit/WebKit/commit/85da21f0f21fcaf5adf5b539fcd100aa857ca17e
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/EventHandler.cpp
Log Message:
-----------
Merge r183855 - EventHandler::m_eventHandlerWillResetCapturingMouseEventsElement is incorrectly initialized
https://bugs.webkit.org/show_bug.cgi?id=144583
Reviewed by Daniel Bates.
* page/EventHandler.cpp:
(WebCore::EventHandler::EventHandler): The
m_eventHandlerWillResetCapturingMouseEventsElement is a boolean,
so initialize it to false, instead of to nullptr.
Commit: 4d12d98984a795d18042e7276d1ac5a3a16901fb
https://github.com/WebKit/WebKit/commit/4d12d98984a795d18042e7276d1ac5a3a16901fb
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit2/Shared/Authentication/AuthenticationManager.cpp
Log Message:
-----------
Merge r183861 - NetworkResourceLoader::cleanup() should clear ResourceHandle client pointer.
https://bugs.webkit.org/show_bug.cgi?id=144641
rdar://problem/20250960
Reviewed by David Kilzer.
* NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::cleanup):
Clear the client pointer.
* Shared/Authentication/AuthenticationManager.cpp:
(WebKit::AuthenticationManager::useCredentialForChallenge):
(WebKit::AuthenticationManager::continueWithoutCredentialForChallenge):
(WebKit::AuthenticationManager::cancelChallenge):
(WebKit::AuthenticationManager::performDefaultHandling):
(WebKit::AuthenticationManager::rejectProtectionSpaceAndContinue):
Updated comments, which were not accurate, at least on Mac.
Commit: c91c3de607994c750d6c9bfd1e63f60bbb9b258b
https://github.com/WebKit/WebKit/commit/c91c3de607994c750d6c9bfd1e63f60bbb9b258b
Author: David Hyatt <hyatt at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBoxModelObject.cpp
Log Message:
-----------
Merge r183879 - Optimize relativePositionOffset() to avoid doing unnecessary work
https://bugs.webkit.org/show_bug.cgi?id=144698
Reviewed by Simon Fraser.
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::relativePositionOffset):
Patch relativePositionOffset to avoid doing unnecessary work in the common case where
all values of top/left/right/bottom are either auto or fixed. We no longer fetch
containingBlock() into a local always, but instead just invoke the function only
when necessary.
Also avoid computing the percentage-relative maximum for the top/right/bottom/left lengths
when they are fixed values, since that maximum won't be examined at all.
Commit: faa94285f7fe1dd76391b1cc8a438a89ddd9610b
https://github.com/WebKit/WebKit/commit/faa94285f7fe1dd76391b1cc8a438a89ddd9610b
Author: David Hyatt <hyatt at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderBoxModelObject.cpp
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLineBoxList.cpp
M Source/WebCore/rendering/RenderView.cpp
M Source/WebCore/rendering/RenderView.h
Log Message:
-----------
Merge r183885 - Optimize topLeftLocationOffset() addition in updateLayerPosition
https://bugs.webkit.org/show_bug.cgi?id=144704
Reviewed by Dean Jackson.
* page/FrameView.cpp:
(WebCore::FrameView::FrameView):
* page/FrameView.h:
Move the hasFlippedBlocks bit to FrameView instead of RenderView. Works better for inlining
the check in any renderer header, and it also makes more sense conceptually, since the RenderView
itself could be a flipped block.
* rendering/RenderBox.cpp:
(WebCore::RenderBox::layoutOverflowRectForPropagation):
Change over to the FrameView bit.
* rendering/RenderBox.h:
(WebCore::RenderBox::applyTopLeftLocationOffset):
Add a new inlined function that can apply the top left location offset to a point without
multiple LayoutSize creations and copies. It invokes a helper for flipping that is not
inlined only in the case where actual flipped blocks exist in the render tree.
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::updateFromStyle):
Set the bit on the FrameView now instead of the RenderView.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateLayerPosition):
Call the new applyTopLeftLocationOffset function so that the point can have offsets added
in without any extra copies.
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderLineBoxList.cpp:
(WebCore::RenderLineBoxList::rangeIntersectsRect):
Switch over to the bit on the FrameView.
* rendering/RenderView.cpp:
(WebCore::RenderView::RenderView):
* rendering/RenderView.h:
Get rid of the bit on the RenderView.
Commit: 22cb891d294ddf11eda5f1fb2a1f7efc0abfb170
https://github.com/WebKit/WebKit/commit/22cb891d294ddf11eda5f1fb2a1f7efc0abfb170
Author: David Hyatt <hyatt at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Merge r183887 - RenderLayer::currentTransform computes a pixel snapped rect it doesn't use.
https://bugs.webkit.org/show_bug.cgi?id=144708
Reviewed by Simon Fraser.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::currentTransform):
Only compute a pixel snapped rect if we actually end up needing it. The common case
is that this rect is not needed, so pushing it inside the two if statements
speeds up the common case.
Commit: 433a53d710a2172f8d1c14a57f2ab697aaf8e7fa
https://github.com/WebKit/WebKit/commit/433a53d710a2172f8d1c14a57f2ab697aaf8e7fa
Author: David Hyatt <hyatt at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
Log Message:
-----------
Merge r183891 - Avoid copies in scrollOffsetForFixedPosition() and inline it.
https://bugs.webkit.org/show_bug.cgi?id=144709
Reviewed by Simon Fraser.
* page/FrameView.cpp:
(WebCore::FrameView::frameScaleFactor):
Added so that scrollOffsetForFixedPosition() can be inlined without having to
reference Frame's implementation.
(WebCore::FrameView::scrollOffsetForFixedPosition): Deleted.
Moved this to the header.
* page/FrameView.h:
Inline scrollOffsetForFixedPosition() and get rid of all the copying
it was doing.
Commit: 33cb6d394b44b863aea255c74d6cf1ebdc659e50
https://github.com/WebKit/WebKit/commit/33cb6d394b44b863aea255c74d6cf1ebdc659e50
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/RunLoop.h
M Source/WTF/wtf/gtk/RunLoopGtk.cpp
Log Message:
-----------
Merge r183921 - [GTK] Clean up RunLoop implementation
https://bugs.webkit.org/show_bug.cgi?id=144729
Reviewed by Carlos Garcia Campos.
Clean up the RunLoop implementation for the GTK port,
removing unnecessary methods and using simpler variable names.
Nested GMainLoops in RunLoop::run() are now created for the
RunLoop's GMainContext, and not for the default context (enforced
through the null argument to g_main_loop_new()).
* wtf/RunLoop.h:
* wtf/gtk/RunLoopGtk.cpp:
(WTF::RunLoop::RunLoop):
(WTF::RunLoop::~RunLoop):
(WTF::RunLoop::run):
(WTF::RunLoop::stop):
(WTF::RunLoop::wakeUp):
(WTF::RunLoop::TimerBase::start):
(WTF::RunLoop::innermostLoop): Deleted.
(WTF::RunLoop::pushNestedMainLoop): Deleted.
(WTF::RunLoop::popNestedMainLoop): Deleted.
Commit: 6b0c4a9013fe32f0b1384cde128f08ae4ea89d79
https://github.com/WebKit/WebKit/commit/6b0c4a9013fe32f0b1384cde128f08ae4ea89d79
Author: Ada Chan <adachan at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebBackForwardList.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKit2/WKPageCopySessionStateWithFiltering.cpp
Log Message:
-----------
Merge r183933 - Fix a couple of cases where the backForwardListState's currentIndex is not set correctly in WebBackForwardList::backForwardListState().
https://bugs.webkit.org/show_bug.cgi?id=144666
Reviewed by Darin Adler.
* UIProcess/WebBackForwardList.cpp:
(WebKit::WebBackForwardList::backForwardListState):
If the first item is filtered out and the currentIndex is 0, don't decrement currentIndex.
If all the items are filtered out, set currentIndex to the uninitialized value.
Tools:
Add a test for WKPageCopySessionState() with filtering.
https://bugs.webkit.org/show_bug.cgi?id=144666
Reviewed by Darin Adler.
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKit2/WKPageCopySessionStateWithFiltering.cpp: Added.
(TestWebKitAPI::didFinishLoadForFrame):
(TestWebKitAPI::setPageLoaderClient):
(TestWebKitAPI::filterFirstItemCallback):
(TestWebKitAPI::filterAllItemsCallback):
(TestWebKitAPI::createSessionStates):
(TestWebKitAPI::TEST):
Commit: 46b49fcb64d29c5a2bbd9a9acd0fad67941153f9
https://github.com/WebKit/WebKit/commit/46b49fcb64d29c5a2bbd9a9acd0fad67941153f9
Author: Sungmann Cho <sungmann.cho at navercorp.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/Plugins/Netscape/NetscapePlugin.cpp
M Source/WebKit2/WebProcess/Plugins/Netscape/NetscapePlugin.h
Log Message:
-----------
Merge r183941 - Add PLUGIN_ARCHITECTURE(X11) around m_frameRectInWindowCoordinates in NetscapePlugin.
https://bugs.webkit.org/show_bug.cgi?id=144490
Patch by Sungmann Cho <sungmann.cho at navercorp.com> on 2015-05-07
Reviewed by Darin Adler.
m_frameRectInWindowCoordinates in NetscapePlugin is currently being used only for
the windowed plugins, and the windowed plugins are only supported on X11. So we can
guard it with PLUGIN_ARCHITECTURE(X11).
No new tests, no behavior change.
* WebProcess/Plugins/Netscape/NetscapePlugin.cpp:
(WebKit::NetscapePlugin::geometryDidChange):
* WebProcess/Plugins/Netscape/NetscapePlugin.h:
Commit: ec031c61f9781d0488252f188c23e0922acb32c0
https://github.com/WebKit/WebKit/commit/ec031c61f9781d0488252f188c23e0922acb32c0
Author: Yoav Weiss <yoav at yoav.ws>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/HTMLImageElement/sizes/image-sizes-invalids-expected.txt
A LayoutTests/fast/dom/HTMLImageElement/sizes/image-sizes-invalids.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/SourceSizeList.cpp
Log Message:
-----------
Merge r183948 - Fix sizes crash and add invalid value tests.
https://bugs.webkit.org/show_bug.cgi?id=144739
Reviewed by Darin Adler.
Source/WebCore:
Make sure that only CSS length are allowed when the sizes parser is calling computeLength.
Also make sure that for invalid lengths, the 100vw default is used instead.
Test: fast/dom/HTMLImageElement/sizes/image-sizes-invalids.html
* css/SourceSizeList.cpp:
(WebCore::computeLength):
(WebCore::defaultLength):
(WebCore::parseSizesAttribute):
LayoutTests:
Add tests that make sure that invalid values are properly handled, and a 100vw
source-size length is being used for srcset and for intrinsic dimension calculation.
* fast/dom/HTMLImageElement/sizes/image-sizes-invalids-expected.txt: Added.
* fast/dom/HTMLImageElement/sizes/image-sizes-invalids.html: Added.
Commit: 62beef3aa20e694bf680ff02608cfd874edd0e9f
https://github.com/WebKit/WebKit/commit/62beef3aa20e694bf680ff02608cfd874edd0e9f
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/ancestor-compositing-layer-is-on-subpixel-position-expected.html
A LayoutTests/compositing/ancestor-compositing-layer-is-on-subpixel-position.html
M LayoutTests/platform/mac/compositing/layer-creation/overlap-animation-container-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerBacking.cpp
Log Message:
-----------
Merge r183950 - REGRESSION (r164449): Subpixel rendering: http://www.apple.com/iphone-6/ "Faster wireless." image displays vertical black line on 1x displays at specific window width.
https://bugs.webkit.org/show_bug.cgi?id=144723
rdar://problem/18307094
Reviewed by Simon Fraser.
This patch ensures that the backing store's graphics layer is always positioned on a device pixel boundary.
While calculating the backing store's graphics layer location, its ancestor layer's compositing bounds is taken into account.
However the compositing bounds is an unsnapped value, so in order to place the graphics layer properly,
we need to pixel align the ancestor compositing bounds before using it to adjust the child's graphics layer position.
Source/WebCore:
Test: compositing/ancestor-compositing-layer-is-on-subpixel-position.html
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateGeometry):
LayoutTests:
* compositing/ancestor-compositing-layer-is-on-subpixel-position-expected.html: Added.
* compositing/ancestor-compositing-layer-is-on-subpixel-position.html: Added.
* platform/mac/compositing/layer-creation/overlap-animation-container-expected.txt: progression.
Commit: 6cc00f632858b97c98ed884be28f04c7d59b0128
https://github.com/WebKit/WebKit/commit/6cc00f632858b97c98ed884be28f04c7d59b0128
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Allocator.cpp
M Source/bmalloc/bmalloc/Deallocator.cpp
M Source/bmalloc/bmalloc/Heap.cpp
M Source/bmalloc/bmalloc/Heap.h
M Source/bmalloc/bmalloc/LargeObject.h
Log Message:
-----------
Merge r183959 - Release assert in com.apple.WebKit.WebContent under JavaScriptCore: JSC::JSONProtoFuncStringify
https://bugs.webkit.org/show_bug.cgi?id=144758
Reviewed by Andreas Kling.
This was an out-of-memory error when trying to shrink a string builder.
bmalloc was missing the optimization that allowed realloc() to shrink
without copying. So, let's add it.
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::reallocate): Added Large and XLarge cases for
shrinking without copying. This isn't possible for small and medium
objects, and probably not very profitable, either.
* bmalloc/Heap.cpp:
(bmalloc::Heap::findXLarge):
(bmalloc::Heap::deallocateXLarge):
* bmalloc/Heap.h: Refactored this code to return a reference to an
XLarge range. This makes the code reusable, and also makes it easier
for realloc() to update metadata.
* bmalloc/LargeObject.h:
(bmalloc::LargeObject::split): Allow allocated objects to split because
that's what realloc() wants to do, and there's nothing intrinsically
wrong with it.
Commit: d1616499feae4eabbd24e5eee8a397c0494babde
https://github.com/WebKit/WebKit/commit/d1616499feae4eabbd24e5eee8a397c0494babde
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/websockets/WebSocketChannel.cpp
M Source/WebCore/platform/network/cf/SocketStreamHandleCFNet.cpp
Log Message:
-----------
Merge r184005 - Crashes in SocketStreamHandleBase::close
https://bugs.webkit.org/show_bug.cgi?id=144767
rdar://problem/20486538
Reviewed by Brady Eidson.
This is a speculative fix, I could not reproduce the crash.
* Modules/websockets/WebSocketChannel.cpp: (WebCore::WebSocketChannel::processFrame):
Normally, processOutgoingFrameQueue() closes the handle in the end when called in
OutgoingFrameQueueClosing state. But there is no definitive protection against
processing two CLOSE frames, in which case we'd try to close the handle twice.
* platform/network/cf/SocketStreamHandleCFNet.cpp:
(WebCore::SocketStreamHandle::readStreamCallback): Passing empty data to the client
results in the socket being closed, which makes no sense here.
Commit: 0a49cdfb0f50c0ab1d2005f8cfab5681dc355004
https://github.com/WebKit/WebKit/commit/0a49cdfb0f50c0ab1d2005f8cfab5681dc355004
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/css/WebKitCSSMatrix.cpp
Log Message:
-----------
Merge r184070 - Reduce TransformationMatrix copies in WebKitCSSMatrix operations
https://bugs.webkit.org/show_bug.cgi?id=144795
Reviewed by Darin Adler.
Instead of copying the TransformationMatrix member, performing
the operation on it and then copying it again when creating
the new WebKitCSSMatrix object, copy it just once by first
creating the new WebKitCSSMatrix object and then performing
the operation on that object's TransformationMatrix directly.
* css/WebKitCSSMatrix.cpp:
(WebCore::WebKitCSSMatrix::multiply):
(WebCore::WebKitCSSMatrix::translate):
(WebCore::WebKitCSSMatrix::scale):
(WebCore::WebKitCSSMatrix::rotate):
(WebCore::WebKitCSSMatrix::rotateAxisAngle):
(WebCore::WebKitCSSMatrix::skewX):
(WebCore::WebKitCSSMatrix::skewY):
Commit: e01b97f3e188b20cba81d43457f586c8a0422c2a
https://github.com/WebKit/WebKit/commit/e01b97f3e188b20cba81d43457f586c8a0422c2a
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WebKit2/Platform/WorkQueue.h
M Source/WebKit2/Platform/gtk/WorkQueueGtk.cpp
Log Message:
-----------
Merge r184072 - [GTK] WorkQueue objects are not released
https://bugs.webkit.org/show_bug.cgi?id=144824
Reviewed by Žan Doberšek.
Do not keep a reference of the WorkQueue for the entire life of
its worker thread, since every task scheduled on the WorkQueue
already takes a reference. Instead, take a reference of the main
loop to make sure that when the worker thread starts, the main
loop hasn't been released to avoid runtime warnings (see
webkit.org/b/140998). Also removed the g_main_context_pop_thread_default()
from the thread body, since the thread-specific context queue will
be freed anyway when the thread exits.
If the WorkQueue is released early, before the thread has started,
schedule a main loop quit in the context, to make sure it will
be the first thing run by the main loop and the thread will exit.
* wtf/WorkQueue.h: Remove unused event loop mutex.
* wtf/gtk/WorkQueueGtk.cpp:
(WTF::WorkQueue::platformInitialize):
(WTF::WorkQueue::platformInvalidate):
Commit: 0312c5c1147534e81b7469c7270fc511fde6a68e
https://github.com/WebKit/WebKit/commit/0312c5c1147534e81b7469c7270fc511fde6a68e
Author: Chris Fleizach <cfleizach at apple.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/accessibility/menu-list-crash2-expected.txt
A LayoutTests/accessibility/menu-list-crash2.html
M Source/WebCore/ChangeLog
M Source/WebCore/accessibility/AccessibilityMenuList.cpp
Log Message:
-----------
Merge r184097 - AX: Crash at WebCore::AccessibilityMenuList::addChildren()
https://bugs.webkit.org/show_bug.cgi?id=144860
Reviewed by Mario Sanchez Prada.
Source/WebCore:
There were some unsafe pointer accesses in AccessibilityMenuList code that needed to be cleaned up.
Test: accessibility/menu-list-crash2.html
* accessibility/AccessibilityMenuList.cpp:
(WebCore::AccessibilityMenuList::addChildren):
LayoutTests:
* accessibility/menu-list-crash2-expected.txt: Added.
* accessibility/menu-list-crash2.html: Added.
Commit: 3320061934c2807a0e08bd2a79f020b0a1e2aec9
https://github.com/WebKit/WebKit/commit/3320061934c2807a0e08bd2a79f020b0a1e2aec9
Author: Antti Koivisto <koivisto at iki.fi>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/MaskImageOperation.cpp
Log Message:
-----------
Merge r184104 - WebContent crash under com.apple.WebCore: WebCore::WebKitCSSResourceValue::isCSSValueNone const + 6
https://bugs.webkit.org/show_bug.cgi?id=144870
rdar://problem/20727702
Reviewed by Simon Fraser.
No repro but we are seeing null pointer crashes like this:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.WebCore 0x00007fff92da5706 WebCore::WebKitCSSResourceValue::isCSSValueNone() const + 6
1 com.apple.WebCore 0x00007fff93382b48 WebCore::MaskImageOperation::isCSSValueNone() const + 24
2 com.apple.WebCore 0x00007fff92e0475e WebCore::FillLayer::hasNonEmptyMaskImage() const + 30
* platform/graphics/MaskImageOperation.cpp:
(WebCore::MaskImageOperation::MaskImageOperation):
(WebCore::MaskImageOperation::isCSSValueNone):
This would crash like this if both m_styleImage and m_cssMaskImageValue are null.
There are no obvious guarantees that this doesn't happen. Two of the constructor variants allow it
and there is setImage which may turn m_styleImage null later too.
Fix by making null m_cssMaskImageValue always signify CSSValueNone.
(WebCore::MaskImageOperation::cssValue):
Commit: f069a2b11a5c1667058152b6055297319ba0026e
https://github.com/WebKit/WebKit/commit/f069a2b11a5c1667058152b6055297319ba0026e
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
Log Message:
-----------
Merge r184154 - Clean up redundant resources in case of failure in GLContextEGL context creation methods
https://bugs.webkit.org/show_bug.cgi?id=144878
Reviewed by Martin Robinson.
GLContextEGL::createWindowContext() and GLContextEGL::createPixmapContext() methods
should clean up the freshly-created resources when prematurely returning due to a
failure.
* platform/graphics/egl/GLContextEGL.cpp:
(WebCore::GLContextEGL::createWindowContext):
(WebCore::GLContextEGL::createPixmapContext):
Commit: 3f423dba759d725fcdfd2f9c02b1dc04e80c4d16
https://github.com/WebKit/WebKit/commit/3f423dba759d725fcdfd2f9c02b1dc04e80c4d16
Author: Gabor Loki <loki at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/ARM64Assembler.h
Log Message:
-----------
Merge r184170 - Workaround for Cortex-A53 erratum 843419
https://bugs.webkit.org/show_bug.cgi?id=144680
Reviewed by Michael Saboff.
This patch is about to give simple workaround for Cortex-A53 erratum 843419.
It inserts nops after ADRP instruction to avoid wrong address accesses.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::adrp):
(JSC::ARM64Assembler::nopCortexA53Fix843419):
Commit: 075f785f49b035b5f2926b2a5c720b9050202d14
https://github.com/WebKit/WebKit/commit/075f785f49b035b5f2926b2a5c720b9050202d14
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ThreadableLoader.cpp
Log Message:
-----------
Unreviewed. Fix the build with RESOURCE_TIMING disabled.
* loader/ThreadableLoader.cpp:
(WebCore::ThreadableLoaderOptions::isolatedCopy):
Commit: 954970647e963d3a7c7498c2b10c99cc86fdcc05
https://github.com/WebKit/WebKit/commit/954970647e963d3a7c7498c2b10c99cc86fdcc05
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-05-12 (Tue, 12 May 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.8.2 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.8.2.
Commit: 9729bed4ca03ebaba8bdcc5b469d874df333dacd
https://github.com/WebKit/WebKit/commit/9729bed4ca03ebaba8bdcc5b469d874df333dacd
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
M Source/WebCore/platform/graphics/egl/GLContextEGL.h
Log Message:
-----------
Merge r184273 - [EGL][X11] XPixmap created in GLContextEGL::createPixmapContext() is leaked
https://bugs.webkit.org/show_bug.cgi?id=144909
Reviewed by Sergio Villar Senin and Žan Doberšek.
The pixmap is created and passed to eglCreatePixmapSurface(), but
never released. eglCreatePixmapSurface() doesn't take the
ownership of the pixmap, so we should explicitly free it when the
GLContextEGL is destroyed.
* platform/graphics/egl/GLContextEGL.cpp:
(WebCore::GLContextEGL::createPixmapContext): Use XUniquePixmap
and transfer the ownership to the context by using the new
constructor that receives a XUniquePixmap&&.
(WebCore::GLContextEGL::createContext): createPixmapContext() is
now only defined for X11.
(WebCore::GLContextEGL::GLContextEGL): New constructor that
receives a XUniquePixmap&&.
* platform/graphics/egl/GLContextEGL.h: Add new constructor and
initialize the cairo device when defined to simplify constructors.
Commit: 616d42f97fcadea57c46d85edf51a3614ed3623e
https://github.com/WebKit/WebKit/commit/616d42f97fcadea57c46d85edf51a3614ed3623e
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/simple-line-layout-text-stroke-width-expected.txt
A LayoutTests/fast/text/simple-line-layout-text-stroke-width.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/SimpleLineLayoutFunctions.cpp
Log Message:
-----------
Merge r184219 - REGRESSION(r175617): Some text doesn't render on internationalculinarycenter.com
https://bugs.webkit.org/show_bug.cgi?id=144917
rdar://problem/20545878
Reviewed by Andreas Kling.
This patch ensures that text stroke width value is taken into account while
calculating visual overflow for simple line layout.
Ceiling the text stroke width value matches the normal text layout behaviour.
Source/WebCore:
Test: fast/text/simple-line-layout-text-stroke-width.html
* rendering/SimpleLineLayoutFunctions.cpp:
(WebCore::SimpleLineLayout::paintFlow):
(WebCore::SimpleLineLayout::collectFlowOverflow):
LayoutTests:
* fast/text/simple-line-layout-text-stroke-width-expected.txt: Added.
* fast/text/simple-line-layout-text-stroke-width.html: Added.
Commit: fabdceda1b5462564dc620e10b069fb6729df125
https://github.com/WebKit/WebKit/commit/fabdceda1b5462564dc620e10b069fb6729df125
Author: David Hyatt <hyatt at apple.com>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/InlineTextBox.cpp
Log Message:
-----------
Merge r184293 - Don't compute selection painting info when we don't have selection.
https://bugs.webkit.org/show_bug.cgi?id=144920
<rdar://problem/20919920>
Reviewed by Simon Fraser.
* rendering/InlineTextBox.cpp:
(WebCore::InlineTextBox::paint):
Just set the selection paint style to the text paint style when we don't have a selection
at all. Computing the selection style takes time in the case where a ::selection pseudo is
used on the page, so we don't want to waste time computing that info unless it's actually
needed.
Commit: d047090dfb73a21271383e3e269533d40376dc95
https://github.com/WebKit/WebKit/commit/d047090dfb73a21271383e3e269533d40376dc95
Author: David Kilzer <ddkilzer at webkit.org>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Merge r184323 - REGRESION (r179958): Crash in WebCore::DocumentLoader::detachFromFrame when -[id<WebPolicyDelegate> decidePolicyForMIMEType:request:frame:decisionListener:] fails to call -[id<WebPolicyDecisionListener> download|ignore|use]
<http://webkit.org/b/144975>
Reviewed by Andy Estes.
This change reverts r179958. It changes RELEASE_ASSERT*()
statements back to Debug-only ASSERT*() statements.
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::~DocumentLoader):
(WebCore::DocumentLoader::continueAfterContentPolicy):
(WebCore::DocumentLoader::detachFromFrame):
Commit: 21db90efda3df8af9f2eb965b9c41bd3a73e091d
https://github.com/WebKit/WebKit/commit/21db90efda3df8af9f2eb965b9c41bd3a73e091d
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp
M Source/WebKit2/UIProcess/Launcher/gtk/ProcessLauncherGtk.cpp
Log Message:
-----------
Merge r184334 - [GTK] Add missing ENABLE(NETSCAPE_PLUGIN_API) build guards
https://bugs.webkit.org/show_bug.cgi?id=144994
Reviewed by Carlos Garcia Campos.
This fixes the build when configured with Netscape plugin API
support disabled.
* UIProcess/API/gtk/WebKitWebContext.cpp:
(webkit_web_context_set_additional_plugins_directory):
(webkitWebContextGetPluginThread):
* UIProcess/Launcher/gtk/ProcessLauncherGtk.cpp:
(WebKit::ProcessLauncher::launchProcess):
Commit: fb3580f021aa34ce64f7ef9df564df6db0cf8f4d
https://github.com/WebKit/WebKit/commit/fb3580f021aa34ce64f7ef9df564df6db0cf8f4d
Author: Andreas Kling <akling at apple.com>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/StringPrototype.cpp
Log Message:
-----------
Merge r184346 - String.prototype.split() should create efficient substrings.
<https://webkit.org/b/144985>
<rdar://problem/20949344>
Reviewed by Geoffrey Garen.
Teach split() how to make substring JSStrings instead of relying on StringImpl's
substring sharing mechanism. The optimization works by deferring the construction
of a StringImpl until the substring's value is actually needed.
This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
Out of ~70000 substrings created by split(), only ~2000 of them get reified.
* runtime/StringPrototype.cpp:
(JSC::jsSubstring):
(JSC::splitStringByOneCharacterImpl):
(JSC::stringProtoFuncSplit):
Commit: 48d03fcbd61db2b0e0df89c929ad15e21c355628
https://github.com/WebKit/WebKit/commit/48d03fcbd61db2b0e0df89c929ad15e21c355628
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/editing/inserting/insert-table-in-paragraph-crash-expected.txt
A LayoutTests/editing/inserting/insert-table-in-paragraph-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/editing/ReplaceSelectionCommand.cpp
M Source/WebCore/editing/ReplaceSelectionCommand.h
Log Message:
-----------
Merge r184355 - Crash in ReplaceSelectionCommand::removeRedundantStylesAndKeepStyleSpanInline
https://bugs.webkit.org/show_bug.cgi?id=119068
Reviewed by Enrica Casucci.
Source/WebCore:
The bug was caused by makeInsertedContentRoundTrippableWithHTMLTreeBuilder not updating
nodes kept tracked by insertedNodes and moveNodeOutOfAncestor stumbling upon it.
Fixed the bug by updating insertedNodes in makeInsertedContentRoundTrippableWithHTMLTreeBuilder.
Test: editing/inserting/insert-table-in-paragraph-crash.html
* editing/ReplaceSelectionCommand.cpp:
(WebCore::ReplaceSelectionCommand::makeInsertedContentRoundTrippableWithHTMLTreeBuilder):
(WebCore::ReplaceSelectionCommand::moveNodeOutOfAncestor):
* editing/ReplaceSelectionCommand.h:
LayoutTests:
Added a test based on https://chromium.googlesource.com/chromium/blink/+/3500267482e60550ce84fadd6c0db883937ce744
* editing/inserting/insert-table-in-paragraph-crash-expected.txt: Added.
* editing/inserting/insert-table-in-paragraph-crash.html: Added.
Commit: 2446ebd8a55d8fcb34c3c85096fe9664a3cc3af5
https://github.com/WebKit/WebKit/commit/2446ebd8a55d8fcb34c3c85096fe9664a3cc3af5
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/composited-parent-clipping-layer-on-subpixel-position-expected.html
A LayoutTests/compositing/composited-parent-clipping-layer-on-subpixel-position.html
A LayoutTests/compositing/parent-clipping-layer-on-subpixel-position-expected.html
A LayoutTests/compositing/parent-clipping-layer-on-subpixel-position.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerBacking.cpp
Log Message:
-----------
Merge r184373 - Images on www.fitstylelife.com jiggle on hover.
https://bugs.webkit.org/show_bug.cgi?id=145020
rdar://problem/20885337
Reviewed by Simon Fraser.
This patch ensures that the clipping layer of a composited content is pixel snapped properly.
Source/WebCore:
Tests: compositing/composited-parent-clipping-layer-on-subpixel-position.html
compositing/parent-clipping-layer-on-subpixel-position.html
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateGeometry):
LayoutTests:
* compositing/composited-parent-clipping-layer-on-subpixel-position-expected.html: Added.
* compositing/composited-parent-clipping-layer-on-subpixel-position.html: Added.
* compositing/parent-clipping-layer-on-subpixel-position-expected.html: Added.
* compositing/parent-clipping-layer-on-subpixel-position.html: Added.
Commit: da169a8f144d07b20e5582489f5063526342f0d1
https://github.com/WebKit/WebKit/commit/da169a8f144d07b20e5582489f5063526342f0d1
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
REGRESSION(r183861): [SOUP] Downloads are broken when using the Network Process
https://bugs.webkit.org/show_bug.cgi?id=144738
When converting the main resource handle to a download, the
NetworkResourceLoader is aborted, but the ResourceHandle shouldn't
be cleaned up because it's still used for the download.
* NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::cleanup):
Commit: e6bc44e637d3f441b2ad591cfbacfe862efd147e
https://github.com/WebKit/WebKit/commit/e6bc44e637d3f441b2ad591cfbacfe862efd147e
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-05-15 (Fri, 15 May 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.8.3 release.
.:
* Source/cmake/OptionsGTK.cmake:
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.8.3.
Commit: e83219d36e14d0945a36a261e9166838bab991fd
https://github.com/WebKit/WebKit/commit/e83219d36e14d0945a36a261e9166838bab991fd
Author: Jer Noble <jer.noble at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderFlowThread.cpp
M Source/WebCore/rendering/RenderFlowThread.h
Log Message:
-----------
Merge r184394 - Crash in RenderFlowThread::popFlowThreadLayoutState() due to mismatched push/pop count
https://bugs.webkit.org/show_bug.cgi?id=145042
Reviewed by David Hyatt.
RenderFlowThread previously used a ListHashSet to store its stack of active objects. This
is problematic because, if the same object is pushed twice, only a single entry of that
object is added to the stack. After this occurs, a matching number of pushes will pop too
many items off the stack, causing a crash when popping a stack with zero items. This
specifically happens in FrameView::layout(), which will push its root renderer on the stack
of active items, and then ask the root to layout(), which will attempt to push itself on the
stack of active items.
Instead of a ListHashSet, use a Vector, which has similar memory characteristics and no
uniqueness requirements.
* rendering/RenderFlowThread.cpp:
(WebCore::RenderFlowThread::pushFlowThreadLayoutState):
(WebCore::RenderFlowThread::popFlowThreadLayoutState):
* rendering/RenderFlowThread.h:
Commit: 6007774657e9da0037162fcbe4bb2ae29ba6cbe5
https://github.com/WebKit/WebKit/commit/6007774657e9da0037162fcbe4bb2ae29ba6cbe5
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
Log Message:
-----------
Merge r184414 - [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
https://bugs.webkit.org/show_bug.cgi?id=144976
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-05-15
Reviewed by Michael Saboff.
Failing the conversion on zero is pretty dangerous as we discovered on x86.
This patch does not really impact performance significantly because
r184220 removed the zero checks from Kraken. This patch is just to be
on the safe side for cases not covered by existing benchmarks.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
Commit: f10506305bde612c6672f7b4b7d89c9e985af38b
https://github.com/WebKit/WebKit/commit/f10506305bde612c6672f7b4b7d89c9e985af38b
Author: Antti Koivisto <koivisto at iki.fi>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/security/canvas-remote-read-data-url-image-redirect-expected.txt
A LayoutTests/http/tests/security/canvas-remote-read-data-url-image-redirect.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/ScriptElement.cpp
M Source/WebCore/dom/ScriptExecutionContext.cpp
M Source/WebCore/html/canvas/CanvasRenderingContext.cpp
M Source/WebCore/loader/ImageLoader.cpp
M Source/WebCore/loader/MediaResourceLoader.cpp
M Source/WebCore/loader/TextTrackLoader.cpp
M Source/WebCore/loader/cache/CachedImage.cpp
M Source/WebCore/loader/cache/CachedResource.cpp
M Source/WebCore/loader/cache/CachedResource.h
Log Message:
-----------
Merge r184434 - When redirecting to data URL use HTTP response for same origin policy checks
https://bugs.webkit.org/show_bug.cgi?id=145054
rdar://problem/20299050
Reviewed by Alexey Proskuryakov.
Source/WebCore:
Test: http/tests/security/canvas-remote-read-data-url-image-redirect.html
* dom/ScriptElement.cpp:
(WebCore::ScriptElement::notifyFinished):
* dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::sanitizeScriptError):
* html/canvas/CanvasRenderingContext.cpp:
(WebCore::CanvasRenderingContext::wouldTaintOrigin):
* loader/ImageLoader.cpp:
(WebCore::ImageLoader::notifyFinished):
* loader/MediaResourceLoader.cpp:
(WebCore::MediaResourceLoader::responseReceived):
* loader/TextTrackLoader.cpp:
(WebCore::TextTrackLoader::notifyFinished):
* loader/cache/CachedImage.cpp:
(WebCore::CachedImage::isOriginClean):
* loader/cache/CachedResource.cpp:
(WebCore::CachedResource::passesAccessControlCheck):
(WebCore::CachedResource::passesSameOriginPolicyCheck):
Factor repeatedly used same origin policy test into a function.
(WebCore::CachedResource::redirectReceived):
When redirecting to a data URL save the redirect response.
(WebCore::CachedResource::responseForSameOriginPolicyChecks):
In case we got redirected to data use that response instead of the final data response for policy checks.
* loader/cache/CachedResource.h:
LayoutTests:
* http/tests/security/canvas-remote-read-data-url-image-redirect-expected.txt: Added.
* http/tests/security/canvas-remote-read-data-url-image-redirect.html: Added.
Commit: 0ab408e133f7c460716ef4f1c0a3d7aaf17d9c44
https://github.com/WebKit/WebKit/commit/0ab408e133f7c460716ef4f1c0a3d7aaf17d9c44
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/borders/dashed-border-on-subpixel-position-expected.html
A LayoutTests/fast/borders/dashed-border-on-subpixel-position.html
A LayoutTests/fast/borders/dotted-border-on-subpixel-position-expected.html
A LayoutTests/fast/borders/dotted-border-on-subpixel-position.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBoxModelObject.cpp
Log Message:
-----------
Merge r184440 - REGRESSION (Subpixel): Dashed underline is missing when box is positioned at subpixels.
https://bugs.webkit.org/show_bug.cgi?id=145097
rdar://problem/18588415
Reviewed by Simon Fraser.
Dashed and dotted border painting needs clipping in order to properly display corners.
Similarly to solid border's quad calculation, we pixelsnap the border positions before computing the clipping quad values.
Source/WebCore:
Test: fast/borders/dashed-border-on-subpixel-position.html
fast/borders/dotted-border-on-subpixel-position.html
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::clipBorderSidePolygon):
LayoutTests:
* fast/borders/dashed-border-on-subpixel-position-expected.html: Added.
* fast/borders/dashed-border-on-subpixel-position.html: Added.
* fast/borders/dotted-border-on-subpixel-position-expected.html: Added.
* fast/borders/dotted-border-on-subpixel-position.html: Added.
Commit: ea24307be53907ecc9850f063f9643182ce1a5b2
https://github.com/WebKit/WebKit/commit/ea24307be53907ecc9850f063f9643182ce1a5b2
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/fileapi/FileReaderLoader.cpp
Log Message:
-----------
Merge r184443 - Crash when uploading huge files to YouTube or Google Drive
https://bugs.webkit.org/show_bug.cgi?id=145083
rdar://problem/15468529
Reviewed by Darin Adler.
This fixes the crash, but uploading will fail.
* fileapi/FileReaderLoader.cpp:
(WebCore::FileReaderLoader::start): Tell SubresourceLoader to not store a copy of
all received data, FileReaderLoader has its own buffer.
(WebCore::FileReaderLoader::didReceiveResponse): Fixed a bounds check - not every
64-bit value that doesn't fit into 32 bits is negative. With this, FileReader fails
on huge files right away, as intended.
(WebCore::FileReaderLoader::didReceiveData): Fixed multiple bugs in code that's
executed when size is not available upfront. This is the code that used to crash,
but with the above fix, it's not executed by YouTube.
Not only overflow was handled incorrectly, but even simply growing a buffer for
append was buggy.
Commit: 69d1650d9bbfe55414c26b086ea51614f06ebd02
https://github.com/WebKit/WebKit/commit/69d1650d9bbfe55414c26b086ea51614f06ebd02
Author: Benjamin Poulain <benjamin at webkit.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/assembler/AssemblerBuffer.h
M Source/WTF/ChangeLog
M Source/WTF/wtf/FastMalloc.cpp
M Source/WTF/wtf/FastMalloc.h
M Source/WTF/wtf/Vector.h
Log Message:
-----------
Merge r184448 - Do not use fastMallocGoodSize anywhere
https://bugs.webkit.org/show_bug.cgi?id=145103
Reviewed by Michael Saboff.
Source/JavaScriptCore:
* assembler/AssemblerBuffer.h:
(JSC::AssemblerData::AssemblerData):
(JSC::AssemblerData::grow):
Source/WTF:
It is silly we see fastMallocGoodSize in profiles, it does absolutely nothing.
This patch keeps fastMallocGoodSize() around for older code linking
with newer WebKit, but remove any use of it inside WebKit.
* wtf/FastMalloc.cpp:
(WTF::fastMallocGoodSize):
* wtf/FastMalloc.h:
* wtf/Vector.h:
(WTF::VectorBufferBase::allocateBuffer):
(WTF::VectorBufferBase::tryAllocateBuffer):
(WTF::VectorBufferBase::reallocateBuffer):
Commit: 731373b7a1f27a6fb28c3e174d353d8de645e123
https://github.com/WebKit/WebKit/commit/731373b7a1f27a6fb28c3e174d353d8de645e123
Author: Anders Carlsson <andersca at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h
M Source/WTF/ChangeLog
M Source/WTF/WTF.vcxproj/WTF.vcxproj
M Source/WTF/WTF.vcxproj/WTF.vcxproj.filters
M Source/WTF/WTF.xcodeproj/project.pbxproj
M Source/WTF/wtf/CMakeLists.txt
R Source/WTF/wtf/Compression.cpp
R Source/WTF/wtf/Compression.h
Log Message:
-----------
Merge r180968 - Remove unused compression code
https://bugs.webkit.org/show_bug.cgi?id=142237
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
* bytecode/UnlinkedCodeBlock.h:
Source/WTF:
* WTF.vcxproj/WTF.vcxproj:
* WTF.vcxproj/WTF.vcxproj.filters:
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/Compression.cpp: Removed.
* wtf/Compression.h: Removed.
Commit: 63fa48aacb868417c1ac85de20be68d2a164a37f
https://github.com/WebKit/WebKit/commit/63fa48aacb868417c1ac85de20be68d2a164a37f
Author: Andreas Kling <akling at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
Log Message:
-----------
Merge r184501 - [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
<https://webkit.org/b/145115>
Reviewed by Anders Carlsson.
We were calling strchr() for every character when doing URL encoding/decoding and it stood out
like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
5.5% progression on Kraken/stanford-crypto-sha256-iterative.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::makeCharacterBitmap):
(JSC::encode):
(JSC::decode):
(JSC::globalFuncDecodeURI):
(JSC::globalFuncDecodeURIComponent):
(JSC::globalFuncEncodeURI):
(JSC::globalFuncEncodeURIComponent):
(JSC::globalFuncEscape):
Commit: f020c033993373fc148d7d6f3fe0064b51bba0d2
https://github.com/WebKit/WebKit/commit/f020c033993373fc148d7d6f3fe0064b51bba0d2
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/dtoa.cpp
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/Modules/webdatabase/SQLException.cpp
M Source/WebCore/dom/DOMCoreException.cpp
M Source/WebCore/inspector/NetworkResourcesData.cpp
M Source/WebCore/loader/icon/IconDatabase.cpp
M Source/WebCore/page/AutoscrollController.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/platform/RuntimeApplicationChecksIOS.mm
M Source/WebCore/platform/audio/HRTFElevation.cpp
M Source/WebCore/platform/audio/mac/AudioHardwareListenerMac.cpp
M Source/WebCore/platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebCore/platform/mac/ScrollAnimatorMac.mm
M Source/WebCore/platform/mac/ScrollbarThemeMac.mm
M Source/WebCore/platform/mac/WebCoreNSURLExtras.mm
M Source/WebCore/platform/mock/ScrollbarThemeMock.cpp
M Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp
M Source/WebCore/platform/text/ios/LocalizedDateCache.mm
M Source/WebCore/rendering/RenderBlockLineLayout.cpp
M Source/WebCore/rendering/RenderBoxModelObject.cpp
M Source/WebCore/rendering/RenderFrameBase.cpp
M Source/WebCore/rendering/RenderTableSection.cpp
M Source/WebCore/rendering/RenderThemeIOS.mm
M Source/WebCore/rendering/RenderThemeMac.mm
M Source/WebKit2/ChangeLog
M Source/WebKit2/Platform/IPC/MessageEncoder.cpp
M Source/WebKit2/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit2/UIProcess/Plugins/mac/PluginProcessProxyMac.mm
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Merge r184555 - Mark static variables as const when possible
https://bugs.webkit.org/show_bug.cgi?id=145161
Reviewed by Andreas Kling.
Source/WebCore:
* Modules/mediasession/WebMediaSessionManager.cpp:
* Modules/mediasource/SourceBuffer.cpp:
* Modules/webdatabase/SQLException.cpp:
* dom/DOMCoreException.cpp:
* inspector/NetworkResourcesData.cpp:
* loader/icon/IconDatabase.cpp:
(WebCore::urlForLogging):
* page/AutoscrollController.cpp:
* page/Page.cpp:
* platform/RuntimeApplicationChecksIOS.mm:
(WebCore::applicationIsAdSheet):
(WebCore::applicationIsMobileMail):
(WebCore::applicationIsMobileSafari):
(WebCore::applicationIsDumpRenderTree):
(WebCore::applicationIsWebApp):
(WebCore::applicationIsOkCupid):
(WebCore::applicationIsFacebook):
(WebCore::applicationIsEpicurious):
(WebCore::applicationIsDaijisenDictionary):
(WebCore::applicationIsNASAHD):
(WebCore::applicationIsMASH):
(WebCore::applicationIsTheEconomistOnIPhone):
(WebCore::applicationIsWebProcess):
(WebCore::applicationIsIBooksOnIOS):
* platform/audio/HRTFElevation.cpp:
* platform/audio/mac/AudioHardwareListenerMac.cpp:
(WebCore::processIsRunningPropertyDescriptor):
(WebCore::outputDevicePropertyDescriptor):
* platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm:
* platform/graphics/ca/GraphicsLayerCA.cpp:
* platform/graphics/mac/FontCacheMac.mm:
(WebCore::toCoreTextFontWeight):
(WebCore::toAppKitFontWeight):
(WebCore::toNSFontWeight):
* platform/mac/ScrollAnimatorMac.mm:
(supportsUIStateTransitionProgress):
(supportsExpansionTransitionProgress):
(supportsContentAreaScrolledInDirection):
* platform/mac/ScrollbarThemeMac.mm:
* platform/mac/WebCoreNSURLExtras.mm:
(WebCore::dataForURLComponentType):
* platform/mock/ScrollbarThemeMock.cpp:
* platform/text/icu/UTextProviderLatin1.cpp:
* platform/text/ios/LocalizedDateCache.mm:
(WebCore::LocalizedDateCache::calculateMaximumWidth):
* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlockFlow::matchedEndLine):
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::paintTranslucentBorderSides):
* rendering/RenderFrameBase.cpp:
(WebCore::shouldExpandFrame):
* rendering/RenderTableSection.cpp:
* rendering/RenderThemeIOS.mm:
(WebCore::getInsetGradient):
(WebCore::getShineGradient):
(WebCore::getShadeGradient):
(WebCore::getConvexGradient):
(WebCore::getConcaveGradient):
(WebCore::getSliderTrackGradient):
(WebCore::getReadonlySliderTrackGradient):
(WebCore::getSliderThumbOpaquePressedGradient):
(WebCore::RenderThemeIOS::paintCheckboxDecorations):
(WebCore::RenderThemeIOS::paintRadioDecorations):
* rendering/RenderThemeMac.mm:
(WebCore::toFontWeight):
(WebCore::TopGradientInterpolate):
(WebCore::BottomGradientInterpolate):
(WebCore::MainGradientInterpolate):
(WebCore::TrackGradientInterpolate):
Source/WebKit2:
* Platform/IPC/MessageEncoder.cpp:
* UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::networkProcessLatencyQOS):
(WebKit::networkProcessThroughputQOS):
(WebKit::webProcessLatencyQOS):
(WebKit::webProcessThroughputQOS):
* UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
(WebKit::PluginProcessProxy::pluginNeedsExecutableHeap):
(WebKit::pluginProcessLatencyQOS):
(WebKit::pluginProcessThroughputQOS):
* WebProcess/WebPage/WebPage.cpp:
Source/WTF:
* wtf/dtoa.cpp:
(WTF::pow5mult):
Commit: 8e18d86fe8273db17811ff2f0e0083962cd91ea5
https://github.com/WebKit/WebKit/commit/8e18d86fe8273db17811ff2f0e0083962cd91ea5
Author: Beth Dakin <bdakin at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Merge r184576 - Crash in WebCore::RenderLayer::updateScrollbarsAfterLayout
https://bugs.webkit.org/show_bug.cgi?id=145142
Reviewed by Simon Fraser.
I have not been able to reproduce this crash, but according to symbolication
m_vBar is null. It seems like this crash was probably caused by
http://trac.webkit.org/changeset/173668 which made it so that overflow:scroll
behaves like overflow:auto when the scrollbars are overlay. I can see how you
could encounter this crash with that change if the layout caused
styleRequiresScrollbar() to return true when it used to return false. Then this
code, by failing to null-check the scrollbars, assumes that
styleRequiresScrollbar() could not have changed based on a layout. But it could
change if the css changed the scrollbars to be custom or if the user managed
switch to legacy style scrollbars at just the wrong time. Or I suppose it could
also happen if the user has legacy scrollbars and the style switched from auto to
scroll during the layout.
Anyway, we should null-check the scrollbars. This is a speculative fix.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateScrollbarsAfterLayout):
Commit: bed855167bc926adf2e5b95a238a0e1e64a6f0fd
https://github.com/WebKit/WebKit/commit/bed855167bc926adf2e5b95a238a0e1e64a6f0fd
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/block/crash-when-anonymous-blocks-are-merged-with-simple-line-layout-expected.txt
A LayoutTests/fast/block/crash-when-anonymous-blocks-are-merged-with-simple-line-layout.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderElement.cpp
Log Message:
-----------
Merge r184577 - Merged anonymous blocks should invalidate simple line layout path.
https://bugs.webkit.org/show_bug.cgi?id=145104
rdar://problem/20980930
Reviewed by Antti Koivisto.
When anonymous blocks are merged together, it's not guaranteed that the final block can use simple line layout.
This patch ensures that the flow block, where the other block's content gets moved to, is no longer on simple line layout path.
Whether the final flow block ends up using inline boxes or simple line layout will be determined during the next layout.
Source/WebCore:
Test: fast/block/crash-when-anonymous-blocks-are-merged-with-simple-line-layout.html
* rendering/RenderElement.cpp:
(WebCore::RenderElement::insertChildInternal):
LayoutTests:
* fast/block/crash-when-anonymous-blocks-are-merged-with-simple-line-layout-expected.txt: Added.
* fast/block/crash-when-anonymous-blocks-are-merged-with-simple-line-layout.html: Added.
Commit: 5442966d4ee3afb83e86a3addd990d8fee2cd535
https://github.com/WebKit/WebKit/commit/5442966d4ee3afb83e86a3addd990d8fee2cd535
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/llint/LLIntOfflineAsmConfig.h
M Source/JavaScriptCore/llint/LowLevelInterpreter.asm
Log Message:
-----------
Merge r184581 - Fix the build of a universal binary with ARMv7k of JavaScriptCore.
https://bugs.webkit.org/show_bug.cgi?id=145143
Reviewed by Geoffrey Garen.
The offlineasm works in 3 phases:
Phase 1:
Parse the llint asm files for config options and desired offsets.
Let's say the offlineasm discovers C unique options and O unique offsets.
The offlineasm will then generate a LLIntDesiredOffsets.h file with
C x C build configurations, each with a set of O offsets.
Each of these build configurations is given a unique configuration index number.
Phase 2:
Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.
If we're building a fat binary with 2 configurations: armv7, and armv7k,
then the fat binary will contain 2 blobs of offsets, one for each of these
build configurations.
Phase 3:
Parse the llint asm files and emit asm code using the offsets that are
extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
configuration index number.
In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
source. As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
the set of C unique options.
For armv7k builds, OFFLINE_ASM_ARMv7 is also true. As a result, for an armv7k
target, we will end up building armv7 source. In general, this is fine except:
1. armv7k has different alignment requirements from armv7. Hence, their offset
values (in JSCLLIntOffsetsExtractor) will be different.
2. The offlineasm was never told that it needed to make a different configuration
for armv7k builds. Hence, the armv7k build of LLIntDesiredOffsets.h will
build the armv7 configuration, and consequently, the armv7k blob of offsets in
JSCLLIntOffsetsExtractor will have the same configuration index number as
the armv7 blob of offsets.
In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
looking for the armv7 build's configuration index number, it discovers the
armv7k blob which has the same configuration number. As a result, it
erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
and all round badness.
The fix is to add a simple "if ARMv7k" statement to the llint asm files. While
the if statement has no body, it does make the offlineasm aware of the need for
ARMv7k as a configuration option. As a result, it will generate an armv7k
variant configuration in the LLIntDesiredOffsets.h file with its own unique
configuration index number. With that, the JSCLLIntOffsetsExtractor fat binary
will no longer have duplicate configuration index numbers for the armv7 and
armv7k blobs of offsets, and the issue is resolved.
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
Commit: d5a3bb9b4f00a208c562aacc032ddf7042647d0e
https://github.com/WebKit/WebKit/commit/d5a3bb9b4f00a208c562aacc032ddf7042647d0e
Author: Brady Eidson <beidson at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/appcache/resources/x-frame-options-prevents-framing-test.html
A LayoutTests/http/tests/appcache/resources/x-frame-options-prevents-framing.manifest
A LayoutTests/http/tests/appcache/x-frame-options-prevents-framing-expected.txt
A LayoutTests/http/tests/appcache/x-frame-options-prevents-framing.php
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/SubstituteData.h
M Source/WebCore/loader/appcache/ApplicationCacheHost.cpp
M Source/WebCore/platform/network/ResourceResponseBase.h
M Source/WebKit/mac/ChangeLog
M Source/WebKit/mac/WebView/WebFrame.mm
M Source/WebKit/win/ChangeLog
M Source/WebKit/win/WebFrame.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Merge r184598 - X-Frame-Options headers not respected when loading from application cache.
<rdar://problem/14877623> and https://bugs.webkit.org/show_bug.cgi?id=131800
Reviewed by Alexey Proskuryakov.
Source/WebCore:
Test: http/tests/appcache/x-frame-options-prevents-framing.php
This patch updates SubstituteData to hold on to a ResourceResponse instead of just a URL.
It also updates all users of SubstituteData to reflect this.
Finally it updates ApplicationCacheHost to put the full response (including x-frame-options header)
in the SubstituteData so they can be checked at the appropriate times.
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::handleSubstituteDataLoadNow):
(WebCore::DocumentLoader::responseReceived): Update an ASSERT to reflect that it's okay to not have
a main resource as long as you have a substitute identifier for it.
(WebCore::DocumentLoader::documentURL):
(WebCore::DocumentLoader::contentFilterDidDecide):
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadArchive):
(WebCore::FrameLoader::defaultSubstituteDataForURL):
* loader/SubstituteData.h:
(WebCore::SubstituteData::SubstituteData):
(WebCore::SubstituteData::shouldRevealToSessionHistory):
(WebCore::SubstituteData::mimeType):
(WebCore::SubstituteData::textEncoding):
(WebCore::SubstituteData::response):
(WebCore::SubstituteData::responseURL): Deleted.
* loader/appcache/ApplicationCacheHost.cpp:
(WebCore::ApplicationCacheHost::maybeLoadMainResource): Put the full ResourceResponse here, which
includes x-frame-options headers sent back when the resources was initially loaded from the network.
* platform/network/ResourceResponseBase.h:
Source/WebKit/mac:
* WebView/WebFrame.mm:
(-[WebFrame _loadData:MIMEType:textEncodingName:baseURL:unreachableURL:]):
Source/WebKit/win:
* WebFrame.cpp:
(WebFrame::loadData):
Source/WebKit2:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::loadDataImpl):
LayoutTests:
* http/tests/appcache/resources/x-frame-options-prevents-framing-test.html: Added.
* http/tests/appcache/resources/x-frame-options-prevents-framing.manifest: Added.
* http/tests/appcache/x-frame-options-prevents-framing-expected.txt: Added.
* http/tests/appcache/x-frame-options-prevents-framing.php: Added.
Commit: 4e7693ab45be9fbf71da659b93703bf16cfd0e74
https://github.com/WebKit/WebKit/commit/4e7693ab45be9fbf71da659b93703bf16cfd0e74
Author: Antti Koivisto <koivisto at iki.fi>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/css/StyleInvalidationAnalysis.cpp
Log Message:
-----------
Merge r184615 - Crash under WebCore::invalidateStyleRecursively
https://bugs.webkit.org/show_bug.cgi?id=145186
rdar://problem/19736838
Reviewed by Andreas Kling
We have seen crashes where we run out of stack under invalidateStyleRecursively in StyleInvalidationAnalysis
on some devices.
Switch to iterative algorithm.
* css/StyleInvalidationAnalysis.cpp:
(WebCore::StyleInvalidationAnalysis::StyleInvalidationAnalysis):
(WebCore::invalidateIfNeeded):
(WebCore::invalidateStyleForTree):
(WebCore::StyleInvalidationAnalysis::invalidateStyle):
(WebCore::invalidateStyleRecursively): Deleted.
Commit: 4a30d0770867900dc13544ab04dd37155969d369
https://github.com/WebKit/WebKit/commit/4a30d0770867900dc13544ab04dd37155969d369
Author: Marcos Chavarría Teijeiro <mchavarria at igalia.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/InjectedBundle/API/gtk/WebKitWebExtension.cpp
Log Message:
-----------
Merge r184638 - [GTK] Add some documentation to WebKitWebExtension
https://bugs.webkit.org/show_bug.cgi?id=142786
Patch by Marcos Chavarría Teijeiro <mchavarria at igalia.com> on 2015-05-20
Reviewed by Carlos Garcia Campos.
WebKitWebExtension API documentation lacks of some details and the information
available is in some contributors blog posts. I add the section
documentation with a small guide about how to use WebExtensions.
The code examples were taken from Carlos García and Adrián Pérez blog
posts.
* WebProcess/InjectedBundle/API/gtk/WebKitWebExtension.cpp:
Commit: c81e6b09f50c7189385729bd36ee757a513ef5a0
https://github.com/WebKit/WebKit/commit/c81e6b09f50c7189385729bd36ee757a513ef5a0
Author: Alexey Proskuryakov <ap at webkit.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ThreadableLoader.cpp
M Source/WebCore/loader/ThreadableLoader.h
Log Message:
-----------
Merge r184657 - ThreadableLoaderOptions::isolatedCopy() doesn't produce a copy that is safe for sending to another thread
https://bugs.webkit.org/show_bug.cgi?id=145217
Reviewed by Anders Carlsson.
Caught by existing tests, rarely. I don't know how to catch such bugs more reliably.
* loader/ThreadableLoader.cpp: (WebCore::ThreadableLoaderOptions::isolatedCopy):
* loader/ThreadableLoader.h:
Commit: a21459dbb1c55d757cfe0cc8e6a2ecb0cee2c36c
https://github.com/WebKit/WebKit/commit/a21459dbb1c55d757cfe0cc8e6a2ecb0cee2c36c
Author: Antti Koivisto <koivisto at iki.fi>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/forms/select/select-painting-expected.html
A LayoutTests/fast/forms/select/select-painting.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderListBox.cpp
M Source/WebCore/rendering/RenderMenuList.cpp
Log Message:
-----------
Merge r184675 - REGRESSION (r172591): Can no longer style <optgroup> with colors (LayoutTests/fast/forms/select/optgroup-rendering.html)
https://bugs.webkit.org/show_bug.cgi?id=145227
Source/WebCore:
rdar://problem/20967472
Reviewed by Darin Adler.
Test: fast/forms/select/select-painting.html
Use computedStyle() consistently for option and optgroup items.
* rendering/RenderListBox.cpp:
(WebCore::RenderListBox::paintItemForeground):
(WebCore::RenderListBox::paintItemBackground):
We can always use computedStyle() and it can't be null. If there was renderer style it would return that.
* rendering/RenderMenuList.cpp:
(RenderMenuList::itemStyle):
(RenderMenuList::getItemBackgroundColor):
LayoutTests:
Reviewed by Darin Adler.
Add ref test for select painting.
* fast/forms/select/select-painting-expected.html: Added.
* fast/forms/select/select-painting.html: Added.
Commit: bcc5b65b4faec1da298e01fe410f36bf8a797267
https://github.com/WebKit/WebKit/commit/bcc5b65b4faec1da298e01fe410f36bf8a797267
Author: Gavin Barraclough <barraclough at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Merge r184692 - dispatchViewStateChange should not wait for sync reply if the page isn't visible
https://bugs.webkit.org/show_bug.cgi?id=145242
<rdar://problem/20967937>
Reviewed by Ben Poulain.
This is particularly problematic on iOS, since if the page isn't visible the process is likely suspended.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::dispatchViewStateChange):
(WebKit::WebPageProxy::waitForDidUpdateViewState):
Commit: b6aa572ae5dd0cf7359a300f2d48ee478c9ef524
https://github.com/WebKit/WebKit/commit/b6aa572ae5dd0cf7359a300f2d48ee478c9ef524
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/text/text-default-font-size-expected.html
A LayoutTests/svg/text/text-default-font-size.html
M Source/WebCore/ChangeLog
M Source/WebCore/page/Settings.in
Log Message:
-----------
Merge r184719 - SVG as image uses very tiny default font-size
https://bugs.webkit.org/show_bug.cgi?id=68090
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-05-21
Reviewed by Darin Adler.
Source/WebCore:
When loading a document, WebKit creates a Page object and then changes its setting
from the browser's preferences. This is true for interactive resources also, such as a
stand-alone SVG or an SVG embedded in an <object> tag for example. For non-interactive
resources, like an SVG embedded in an <img> tag for example, this function is called
after loading the resource is finished. This function creates an artificial page and
fabricates a scoped settings for it. This turns out to be problematic for cases like
the default font size because its initial value is zero. We cannot go from WebCore to
WebKit to ask for the global settings. But we can inherit the global settings from the
the master page. This is not the best solution because of two reasons. (1) Once the
resource is cached and the styles for the text elements are calculated, nothing can
change the values of styles except removing the resource itself from the cache if the
browser's preferences change. Also there is no mechanism to notify this artificial
page if the browser's preferences change. (2) An image like a non-interactive SVG,
should be displayed the same way regardless of the browser's preferences. A user may
be able to change the default font size for other text. But this should not affect
images even if they are vector images like SVG. An easy and more agreeable solution
is to hard-code the default font size for this case and do not depend on the global
settings at all.
Test: svg/text/text-default-font-size.html
* page/Settings.in: Set the initial value of the setting defaultFontSize to be 16.
LayoutTests:
* svg/text/text-default-font-size-expected.html: Added.
* svg/text/text-default-font-size.html: Added.
Ensure the default font size for non-interactive SVG images is not zero.
Commit: 34c469478262a561ca34abebe9310746eeecf3bb
https://github.com/WebKit/WebKit/commit/34c469478262a561ca34abebe9310746eeecf3bb
Author: Jordi Mas <jmas at softcatala.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/platform/gtk/po/ChangeLog
A Source/WebCore/platform/gtk/po/ca.po
Log Message:
-----------
Merge r184766 - [l10n] Add Catalan translation for WebKitGTK+
https://bugs.webkit.org/show_bug.cgi?id=142928
Patch by Jordi Mas <jmas at softcatala.org> on 2015-05-22
Reviewed by Carlos Garcia Campos.
* ca.po: Added.
Commit: 859dc7239cde9024583bcb2358d1e662ad001a96
https://github.com/WebKit/WebKit/commit/859dc7239cde9024583bcb2358d1e662ad001a96
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/BitmapImage.cpp
M Source/WebCore/platform/graphics/BitmapImage.h
Log Message:
-----------
Merge r184793 - [CG] Regression(r78652): Partially decoded images are not properly removed from MemoryCache when pruning
https://bugs.webkit.org/show_bug.cgi?id=145310
Reviewed by Antti Koivisto.
r78652 added partially decoded images to the MemoryCache's list of live
decoded resources so that they can be pruned on memory pressure. This
was needed because CG decodes part of the image to determine its
properties (e.g. its size). On memory pressure, we call
BitmapImage::destroyDecodedData() which clears the ImageSource and
frees up this extra decoded data.
However, we would fail to remove such partially decoded images from the
MemoryCache's list of live resources when pruning. This is because
BitmapImage::destroyMetadataAndNotify() fails to take into account the
decoded properties size when no frame has been cleared. We would thus
fail to detect a decoded size change and not call
CachedImage::decodedSizeChanged(). As a result, the CachedImage's
decoded size is not reset to 0 and we don't remove it from live decoded
resources.
This patch updates BitmapImage::destroyMetadataAndNotify() to account
for m_decodedPropertiesSize even if frameBytesCleared is 0. This way,
images for which we have't decoded any frames yet will correctly report
that we cleared the decoded data used to determine the image properties
and their decoded size will be properly reset to 0. As a result, these
will be removed from the MemoryCache's list of live decoded resources.
* platform/graphics/BitmapImage.cpp:
(WebCore::BitmapImage::destroyDecodedData):
(WebCore::BitmapImage::destroyMetadataAndNotify):
(WebCore::BitmapImage::dataChanged):
* platform/graphics/BitmapImage.h:
Commit: f87412b557f4d2a21503a86dff5538c047ef92ae
https://github.com/WebKit/WebKit/commit/f87412b557f4d2a21503a86dff5538c047ef92ae
Author: Mark Lam <mark.lam at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Merge r184816 - Document::ensurePlugInsInjectedScript() should evaluate the injected script on its own frame.
https://bugs.webkit.org/show_bug.cgi?id=145328
Reviewed by Jon Lee.
trac.webkit.org/r184329 fixed HTMLPlugInImageElement::didAddUserAgentShadowRoot()
to use the document's frame instead of the page's main frame. However,
Document::ensurePlugInsInjectedScript() is still evaluating the injected script on
the main frame.
As a result, HTMLPlugInImageElement::didAddUserAgentShadowRoot()'s attempt to get
the injected createOverlay function from the document frame's global object will
fail. Fixing Document::ensurePlugInsInjectedScript() to evaluating the injected
script on the document's frame fixes the issue.
No new tests.
* dom/Document.cpp:
(WebCore::Document::ensurePlugInsInjectedScript):
Commit: 6339dc714ebc8dd0f5871e3d5271f5c68d366e0b
https://github.com/WebKit/WebKit/commit/6339dc714ebc8dd0f5871e3d5271f5c68d366e0b
Author: Sam Weinig <sam at webkit.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/gobject/WebKitDOMCustom.cpp
M Source/WebCore/page/UserMessageHandler.cpp
M Source/WebCore/page/UserMessageHandler.h
M Source/WebCore/page/UserMessageHandler.idl
M Source/WebCore/page/UserMessageHandlerDescriptor.cpp
M Source/WebCore/page/UserMessageHandlerDescriptor.h
M Source/WebCore/page/UserMessageHandlersNamespace.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/UserContent/WebUserContentController.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Cocoa/UserContentController.mm
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/WebExtensionTest.cpp
Log Message:
-----------
Merge r184846 - Crash when using a removed ScriptMessageHandler
<rdar://problem/20888499>
https://bugs.webkit.org/show_bug.cgi?id=145359
Reviewed by Dan Bernstein.
Source/WebCore:
Added tests:
WKUserContentController.ScriptMessageHandlerBasicRemove
WKUserContentController.ScriptMessageHandlerCallRemovedHandler
* page/UserMessageHandler.cpp:
(WebCore::UserMessageHandler::~UserMessageHandler):
(WebCore::UserMessageHandler::postMessage):
(WebCore::UserMessageHandler::name):
* page/UserMessageHandler.h:
(WebCore::UserMessageHandler::create):
* page/UserMessageHandler.idl:
* page/UserMessageHandlerDescriptor.cpp:
(WebCore::UserMessageHandlerDescriptor::UserMessageHandlerDescriptor):
* page/UserMessageHandlerDescriptor.h:
(WebCore::UserMessageHandlerDescriptor::client):
(WebCore::UserMessageHandlerDescriptor::invalidateClient):
Add support for invalidating the descriptor and throw an exception if someone tries
to post a message using an invalidated descriptor.
* page/UserMessageHandlersNamespace.cpp:
(WebCore::UserMessageHandlersNamespace::handler):
Add logic to remove message handlers if their descriptor has been invalidated.
Source/WebKit2:
* WebProcess/UserContent/WebUserContentController.cpp:
(WebKit::WebUserMessageHandlerDescriptorProxy::~WebUserMessageHandlerDescriptorProxy):
Invalidate the descriptor when the message handler client (as implemented by WebUserMessageHandlerDescriptorProxy)
goes away. This will happen if a script message handler is removed at the API level or the WebUserContentController
is destroyed (which will happen if all the pages get destroyed).
Tools:
* TestWebKitAPI/Tests/WebKit2Cocoa/UserContentController.mm:
Add tests for removing script message handlers.
Commit: fcc6a55fc8d39a63eace71143ca70275660c2a5a
https://github.com/WebKit/WebKit/commit/fcc6a55fc8d39a63eace71143ca70275660c2a5a
Author: Csaba Osztrogonác <ossy at webkit.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/CMakeLists.txt
M Source/WebCore/ChangeLog
Log Message:
-----------
Merge r184857 - [ARM] Build SVGPathElement.cpp with -O2 due to a GCC bug
https://bugs.webkit.org/show_bug.cgi?id=145377
Reviewed by Carlos Garcia Campos.
* CMakeLists.txt:
Commit: 9ca3d627a41db2114a307f324254bb2c99602cc9
https://github.com/WebKit/WebKit/commit/9ca3d627a41db2114a307f324254bb2c99602cc9
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/css/svg-resource-fragment-identifier-order-expected.html
A LayoutTests/svg/css/svg-resource-fragment-identifier-order.html
M Source/WebCore/ChangeLog
M Source/WebCore/svg/graphics/SVGImage.cpp
Log Message:
-----------
Merge r184874 - SVG fragment identifier rendering issue
https://bugs.webkit.org/show_bug.cgi?id=137328
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-05-26
Reviewed by Darin Adler.
Source/WebCore:
This is a follow up for http://trac.webkit.org/changeset/164983. In this
changeset, scrolling to the fragment should have been added before the
the paint to guarantee setting the proper display position for the SVG
fragment.
Test: svg/css/svg-resource-fragment-identifier-order.html
* svg/graphics/SVGImage.cpp:
(WebCore::SVGImage::draw): Move view->scrollToFragment() before calling
view->paint().
LayoutTests:
* svg/css/svg-resource-fragment-identifier-order-expected.html: Added.
* svg/css/svg-resource-fragment-identifier-order.html: Added.
Ensure the SVG fragment is drawn correctly when the same SVG image is
referenced multiple times.
Commit: d70b14736094dac6ec69154ce61ec8d98549989c
https://github.com/WebKit/WebKit/commit/d70b14736094dac6ec69154ce61ec8d98549989c
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Allocator.cpp
M Source/bmalloc/bmalloc/BAssert.h
M Source/bmalloc/bmalloc/Sizes.h
Log Message:
-----------
Merge r184883 - Integer overflow in XLarge allocation (due to unchecked roundUpToMultipleOf)
https://bugs.webkit.org/show_bug.cgi?id=145385
Reviewed by Andreas Kling.
Added some checking to verify that round-up operations will not overflow
a size_t.
The simplest way to do this was to introduce a notion of xLargeMax, like
we have for smallMax, mediumMax, and largeMax. It's a bit surprising at
first to think that there is an xLargeMax, since xLarge is what we use
to handle the biggest things. But computers have limits, so it makes sense.
FWIW, TCMalloc used to have an xLargeMax too, which it called kMaxValidPages.
No test because this bug was found by code inspection and I don't know
of a practical way to convince WebKit to make an allocation this large.
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::tryAllocate):
(bmalloc::Allocator::allocate):
(bmalloc::Allocator::reallocate):
(bmalloc::Allocator::allocateSlowCase): Check against xLargeMax to avoid
overflow when rounding up.
* bmalloc/BAssert.h: Added support for explicit crashing.
* bmalloc/Sizes.h:
Commit: 7f071a95d030d9cecc933d320b04dbd103d227fb
https://github.com/WebKit/WebKit/commit/7f071a95d030d9cecc933d320b04dbd103d227fb
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/block/float/crash-when-floating-object-is-removed-expected.txt
A LayoutTests/fast/block/float/crash-when-floating-object-is-removed.xhtml
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBlockFlow.cpp
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
Log Message:
-----------
Merge r184885 - Overhanging float sets are not cleaned up properly when floating renderer is destroyed.
https://bugs.webkit.org/show_bug.cgi?id=145323
rdar://problem/20980628
Reviewed by Dave Hyatt.
This patch ensures when an overhanging float renderer is destroyed,
all the sibling containers' floating object set(m_floatingObjects) gets properly cleaned up.
When an overhanging float is present, we cache the renderer on the parent and on the affected
sibling containers too. (RenderBlockFlow::m_floatingObjects) These caches(sets) get cleared and repopulated
during ::layout(). In order to have a float renderer removed from a set, a layout needs to be initiated on the container.
This is normally done through RenderBlockFlow::markSiblingsWithFloatsForLayout() and RenderBlockFlow::markAllDescendantsWithFloatsForLayout().
However, when the float container's parent's writing direction changes (and we promote the children containers to new formatting contexts),
the layout propagation through siblings does not work anymore.
The avoidsFloats() check in RenderBlockFlow::markSiblingsWithFloatsForLayout() has very little performance gain, but it prevents us
from propagating layout to siblings when certain properties of the parent container changes.
Source/WebCore:
Test: fast/block/float/crash-when-floating-object-is-removed.xhtml
* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout):
* rendering/RenderBox.cpp:
(WebCore::outermostBlockContainingFloatingObject):
(WebCore::RenderBox::removeFloatingOrPositionedChildFromBlockLists):
(WebCore::RenderBox::outermostBlockContainingFloatingObject): Deleted.
* rendering/RenderBox.h:
LayoutTests:
* fast/block/float/crash-when-floating-object-is-removed-expected.txt: Added.
* fast/block/float/crash-when-floating-object-is-removed.xhtml: Added.
Commit: b8275b6dbbf4f22d96d5affe53a1dafec7b4dda2
https://github.com/WebKit/WebKit/commit/b8275b6dbbf4f22d96d5affe53a1dafec7b4dda2
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp
Log Message:
-----------
Merge r184965 - Crash under ICU with ASAN during editing/selection/move-by-word-visually-crash-test-5.html
https://bugs.webkit.org/show_bug.cgi?id=145429
<rdar://problem/20992218>
Reviewed by Alexey Proskuryakov.
WebKit uses some strings which contain the lower 8-bits of UTF-16 (thereby saving space). However,
ICU doesn't understand this encoding. When we want to use ICU functions with strings in this encoding,
we create a UTextProvider which converts our encoded strings to UTF-16 for ICU, one chunk at a time.
This object contains a vtable which we populate to perform the conversion.
The WebKit function which actually returns the UTF-16 chunks has two relevant arguments: an index into
the encoded string which ICU is requesting, and a direction from that index which ICU is interested
in. This function populates a "chunk" which is characterized by a pointer to a buffer, the length of
the populated data in the buffer, and an offset into the chunk which represents the index that the
requested character was put into.
When ICU requests data going backward, we fill in the chunk accordingly, with the requested character
all the way at the end. We then set the offset equal to the length of the buffer. However, this length
value is stale from the previous time the function ran. Therefore, ICU was reading the wrong index in
the chunk when expecting the requested character.
Covered by editing/selection/move-by-word-visually-crash-test-5.html.
* platform/text/icu/UTextProviderLatin1.cpp:
(WebCore::uTextLatin1Access):
Commit: 6bea461051c1b910de8318860f423da4fce2eec5
https://github.com/WebKit/WebKit/commit/6bea461051c1b910de8318860f423da4fce2eec5
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/hidpi-text-selection-gap-between-words-expected.html
A LayoutTests/fast/text/hidpi-text-selection-gap-between-words.html
M LayoutTests/platform/mac/platform/mac/editing/input/caret-primary-bidi-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/FontCascade.cpp
M Source/WebCore/platform/graphics/cocoa/FontCascadeCocoa.mm
Log Message:
-----------
Merge r184970 - Subpixel rendering: Pixel crack in text selection of simple text in <textarea>.
https://bugs.webkit.org/show_bug.cgi?id=145393
rdar://problem/19918941
Reviewed by Darin Adler.
Float to LayoutUnit conversion is lossy. To ensure that selection
painting always lines up (snaps) properly, the calculated width needs to
be adjusted by ceiling the float to the next LayoutUnit value.
Source/WebCore:
Test: fast/text/hidpi-text-selection-gap-between-words.html
* platform/graphics/FontCascade.cpp:
(WebCore::FontCascade::adjustSelectionRectForSimpleText):
* platform/graphics/cocoa/FontCascadeCocoa.mm:
(WebCore::FontCascade::adjustSelectionRectForComplexText):
LayoutTests:
* fast/text/hidpi-text-selection-gap-between-words-expected.html: Added.
* fast/text/hidpi-text-selection-gap-between-words.html: Added.
* platform/mac/platform/mac/editing/input/caret-primary-bidi-expected.txt:
Commit: fd3a1ca7d497be92f7d444087e8e99afa4d212fe
https://github.com/WebKit/WebKit/commit/fd3a1ca7d497be92f7d444087e8e99afa4d212fe
Author: Brady Eidson <beidson at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/sql/SQLiteDatabase.cpp
M Source/WebCore/platform/sql/SQLiteDatabase.h
Log Message:
-----------
Merge r185003 - WebSQL default functions can bypass authorizer.
<rdar://problem/21048994> and https://bugs.webkit.org/show_bug.cgi?id=145463
Reviewed by Sam Weinig and Alexey Proskuryakov.
No new tests yet.
* platform/sql/SQLiteDatabase.cpp:
(WebCore::unauthorizedSQLFunction): Function to install into SQLite to override some built-in functions.
(WebCore::SQLiteDatabase::open):
(WebCore::SQLiteDatabase::overrideUnauthorizedFunctions): Install function overrides for functions that
take arbitrary input that are also meant to be disabled by virtue of them not being whitelisted.
* platform/sql/SQLiteDatabase.h:
Commit: db81d7fae27ba54ec0e4013be6719e244e496d5f
https://github.com/WebKit/WebKit/commit/db81d7fae27ba54ec0e4013be6719e244e496d5f
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/history/PageCache.cpp
M Source/WebCore/page/DiagnosticLoggingKeys.cpp
M Source/WebCore/page/DiagnosticLoggingKeys.h
Log Message:
-----------
Merge r185017 - WebContent crash in WebCore::Page::sessionID() const + 0 (Page.cpp:1660)
https://bugs.webkit.org/show_bug.cgi?id=145422
<rdar://problem/20613631>
Reviewed by Brady Eidson.
We sometimes crash when destroying a PageCache CachedFrame because its
DocumentLoader is still loading. This should never happen as we are not
supposed to let pages are still have pending loads into the PageCache.
However, we were using DocumentLoader::isLoadingInAPISense() as check
in PageCache::canCachePageContainingThisFrame() which is not exactly
what we want. isLoadingInAPISense() no longer considers subresource
loads once the frame as loaded. This means if the JS triggers a new
load in a subframe after it has been loaded, then isLoadingInAPISense()
will return false, despite the pending load.
This patch replaces the isLoadingInAPISense() check with isLoading()
as this will consider all pending loads, even after the frame is
loaded.
In most cases, using isLoadingInAPISense() was not an issue because
we call DocumentLoader::stopLoading() in all subframes before starting
a provisional load. However, nothing seems to prevent JS from
triggering a new load after that and before the new load gets committed
(which is when we save the page into PageCache).
No new test as we don't have a reliable reproduction case and the
issue is timing related.
* history/PageCache.cpp:
(WebCore::logCanCacheFrameDecision):
(WebCore::PageCache::canCachePageContainingThisFrame):
* page/DiagnosticLoggingKeys.cpp:
(WebCore::DiagnosticLoggingKeys::isLoading):
(WebCore::DiagnosticLoggingKeys::loadingAPISenseKey): Deleted.
* page/DiagnosticLoggingKeys.h:
Commit: 1491b791aba39b227cbdae4f0f9c2a7f0cf26d8a
https://github.com/WebKit/WebKit/commit/1491b791aba39b227cbdae4f0f9c2a7f0cf26d8a
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/navigation/image-load-in-pagehide-handler-expected.txt
A LayoutTests/http/tests/navigation/image-load-in-pagehide-handler.html
A LayoutTests/http/tests/navigation/resources/frame-do-load.html
A LayoutTests/http/tests/navigation/resources/frame-pagehide-starts-load-in-subframe.html
A LayoutTests/http/tests/navigation/resources/frame-pagehide-starts-load.html
A LayoutTests/http/tests/navigation/resources/image-load-in-pagehide-handler-2.html
A LayoutTests/http/tests/navigation/subframe-pagehide-handler-starts-load-expected.txt
A LayoutTests/http/tests/navigation/subframe-pagehide-handler-starts-load.html
A LayoutTests/http/tests/navigation/subframe-pagehide-handler-starts-load2-expected.txt
A LayoutTests/http/tests/navigation/subframe-pagehide-handler-starts-load2.html
M Source/WebCore/ChangeLog
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/loader/ImageLoader.cpp
M Source/WebCore/loader/cache/CachedResource.cpp
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebCore/page/Chrome.cpp
M Source/WebCore/page/Chrome.h
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/page/DOMWindow.cpp
M Source/WebCore/page/Page.h
Log Message:
-----------
Merge r185337 - WebContent crash in WebCore::Page::sessionID() const + 0 (Page.cpp:1660)
https://bugs.webkit.org/show_bug.cgi?id=145748
<rdar://problem/21226577>
Reviewed by Brady Eidson.
Source/WebCore:
We would sometimes crash when pruning the PageCache because it was
possible for frames to still be loading while in the PageCache and
we would try to stop the load when the CachedFrame is destroyed. This
code path was not supposed to be exercised as we were not supposed to
have pages still loading inside the PageCache.
r185017 made sure we don't insert into the PageCache pages that are
still loading. However, nothing was preventing content from starting
new loads in their 'pagehide' event handlers, *after* the decision
to put the page in the PageCache was made.
This patch prevents content from starting loads from a 'pagehide'
event handler so that we can no longer have content that is loading
inside the PageCache. 'ping' image loads still go through though as
these are specially handled and use PingLoaders.
Tests: http/tests/navigation/image-load-in-pagehide-handler.html
http/tests/navigation/subframe-pagehide-handler-starts-load.html
http/tests/navigation/subframe-pagehide-handler-starts-load2.html
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::FrameLoader):
(WebCore::FrameLoader::stopLoading):
(WebCore::FrameLoader::loadURL):
(WebCore::FrameLoader::loadWithDocumentLoader):
(WebCore::FrameLoader::stopAllLoaders):
(WebCore::FrameLoader::handleBeforeUnloadEvent):
* loader/FrameLoader.h:
(WebCore::FrameLoader::pageDismissalEventBeingDispatched):
(WebCore::FrameLoader::PageDismissalEventType::PageDismissalEventType):
(WebCore::FrameLoader::PageDismissalEventType::operator Page::DismissalType):
Add wrapper class for m_pageDismissalEventBeingDispatched member type.
The wrapper takes care of updating the m_dismissalEventBeingDispatched
member on the Page every time the member on FrameLoader is updated. We
now cache this information on the Page so that clients can cheaply
query if a dismissal event is being dispatched in any of the Page's
frame, without having to traverse the frame tree.
* loader/ImageLoader.cpp:
(WebCore::pageIsBeingDismissed):
* loader/cache/CachedResource.cpp:
(WebCore::CachedResource::load):
Abort the load early if we are currently dispatching a 'pagehide'
event. We don't allow new loads at such point because we've already
made the decision to add the Page to the PageCache.
* loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestImage):
* page/Chrome.cpp:
(WebCore::Chrome::runModal): Deleted.
(WebCore::Chrome::setToolbarsVisible): Deleted.
(WebCore::Chrome::toolbarsVisible): Deleted.
(WebCore::Chrome::runJavaScriptConfirm): Deleted.
(WebCore::Chrome::runJavaScriptPrompt): Deleted.
(WebCore::Chrome::shouldInterruptJavaScript): Deleted.
* page/Chrome.h:
* page/ChromeClient.h:
* page/DOMWindow.cpp:
(WebCore::DOMWindow::canShowModalDialogNow):
Drop ChromeClient::shouldRunModalDialogDuringPageDismissal() and code
using it as it is unused and I did not think it was worth updating
this code.
* page/Page.h:
(WebCore::Page::dismissalEventBeingDispatched):
(WebCore::Page::setDismissalEventBeingDispatched):
Add a m_dismissalEventBeingDispatched member to the Page so that we can
easily query if a dismissal event is being dispatched in any of the
frames, without having to traverse the frame tree. I suspect more call
sites of FrameLoader::pageDismissalEventBeingDispatched() may actually
want this but I did not make such change in this patch. It is important
to check all the frames and not simply the current one because a frame's
pagehide event handler may trigger a load in another frame.
LayoutTests:
* http/tests/navigation/image-load-in-pagehide-handler-expected.txt: Added.
* http/tests/navigation/image-load-in-pagehide-handler.html: Added.
* http/tests/navigation/resources/image-load-in-pagehide-handler-2.html: Added.
Add layout test to make sure that ping loads in 'pagehide' handlers are
still going through after this change.
* http/tests/navigation/resources/frame-do-load.html: Added.
* http/tests/navigation/resources/frame-pagehide-starts-load-in-subframe.html: Added.
* http/tests/navigation/resources/frame-pagehide-starts-load.html: Added.
* http/tests/navigation/subframe-pagehide-handler-starts-load-expected.txt: Added.
* http/tests/navigation/subframe-pagehide-handler-starts-load.html: Added.
* http/tests/navigation/subframe-pagehide-handler-starts-load2-expected.txt: Added.
* http/tests/navigation/subframe-pagehide-handler-starts-load2.html: Added.
Add layout tests to make sure we don't crash if a frame starts an XHR load
from the 'pagehide' event handler. One of the tests covers the case where a
frame's pagehide handler starts a load in a subframe as this case is
requires a bit more handling.
Commit: 7411c6b76440b1bd8b055ae53b3c946d17bc8828
https://github.com/WebKit/WebKit/commit/7411c6b76440b1bd8b055ae53b3c946d17bc8828
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/loader/ImageLoader.cpp
M Source/WebCore/loader/cache/CachedResource.cpp
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
Log Message:
-----------
Merge r186005 - Prevent new loads while in PageCache (or being added to PageCache)
https://bugs.webkit.org/show_bug.cgi?id=146299
<rdar://problem/21523788>
Reviewed by Darin Adler.
Generalize the change in r185337 to prevent new loads while in the
PageCache (or being added to the PageCache), instead of merely
preventing new loads in pagehide event handlers. We should never
have any pages that are still loading inside the PageCache.
The fix in r185337 was apparently insufficient to address the
problem so generalizing the check / policy will hopefully catch
more cases where content is able to start loads while being added
to the PageCache. This patch also removes some of the complexity
added in r185337 as it is no longer needed.
No new tests, already covered by:
http/tests/navigation/image-load-in-pagehide-handler.html
http/tests/navigation/subframe-pagehide-handler-starts-load.html
http/tests/navigation/subframe-pagehide-handler-starts-load2.html
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::stopLoading):
(WebCore::FrameLoader::loadURL):
(WebCore::FrameLoader::loadWithDocumentLoader):
(WebCore::FrameLoader::stopAllLoaders):
(WebCore::FrameLoader::handleBeforeUnloadEvent):
(WebCore::FrameLoader::FrameLoader): Deleted.
* loader/FrameLoader.h:
(WebCore::FrameLoader::pageDismissalEventBeingDispatched):
* loader/ImageLoader.cpp:
(WebCore::pageIsBeingDismissed):
* loader/cache/CachedResource.cpp:
(WebCore::CachedResource::load):
* loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestImage):
* page/Page.cpp:
(WebCore::Page::inPageCache):
* page/Page.h:
(WebCore::Page::group): Deleted.
Commit: 93ead657c276331e0c855383e9374e0fc8d55b21
https://github.com/WebKit/WebKit/commit/93ead657c276331e0c855383e9374e0fc8d55b21
Author: Brady Eidson <beidson at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/sql/SQLiteDatabase.cpp
Log Message:
-----------
Merge r185018 - Review feedback followup for r185003.
https://bugs.webkit.org/show_bug.cgi?id=145463
Reviewed by Darin Adler.
* platform/sql/SQLiteDatabase.cpp:
(WebCore::SQLiteDatabase::overrideUnauthorizedFunctions): `static const` one thing, c++-style cast another.
Commit: 01f5f2e9c66d336d8a55c458c619a5d72347c9b8
https://github.com/WebKit/WebKit/commit/01f5f2e9c66d336d8a55c458c619a5d72347c9b8
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/sibling-layer-does-not-get-composited-overflow-hidden-case-expected.html
A LayoutTests/compositing/sibling-layer-does-not-get-composited-overflow-hidden-case.html
A LayoutTests/compositing/sibling-layer-does-not-get-composited-transform-case-expected.html
A LayoutTests/compositing/sibling-layer-does-not-get-composited-transform-case.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Merge r185019 - Text disappears shortly after page load on Nexus 7 site.
https://bugs.webkit.org/show_bug.cgi?id=145467
rdar://problem/18327239
Reviewed by Simon Fraser.
This patch ensures that overlap testing for composited layers works properly when the sibling
layer gets composited through its child.
When a layer gets composited through its child content, the recursive overlap testing should build up the
overlapmap stack so that sibling content is intersected both against the child and its parent bounds.
Source/WebCore:
Tests: compositing/sibling-layer-does-not-get-composited-overflow-hidden-case.html
compositing/sibling-layer-does-not-get-composited-transform-case.html
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::addToOverlapMapRecursive):
(WebCore::RenderLayerCompositor::OverlapMap::contains): Deleted.
LayoutTests:
* compositing/sibling-layer-does-not-get-composited-overflow-hidden-case-expected.html: Added.
* compositing/sibling-layer-does-not-get-composited-overflow-hidden-case.html: Added.
* compositing/sibling-layer-does-not-get-composited-transform-case-expected.html: Added.
* compositing/sibling-layer-does-not-get-composited-transform-case.html: Added.
Commit: b23162f11fb3435fa8231f3175d29ed771260b92
https://github.com/WebKit/WebKit/commit/b23162f11fb3435fa8231f3175d29ed771260b92
Author: Joseph Pecoraro <joepeck at webkit.org>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/WebInspector.cpp
M Source/WebKit2/WebProcess/WebPage/WebInspector.h
Log Message:
-----------
Merge r185030 - Web Inspector: Crash closing a related tab with Web Inspector open while page is refreshing
https://bugs.webkit.org/show_bug.cgi?id=145488
Reviewed by Alexey Proskuryakov.
* WebProcess/WebPage/WebInspector.h:
* WebProcess/WebPage/WebInspector.cpp:
(WebKit::WebInspector::~WebInspector):
Ensure, no matter how we close, that we have invalidated the
frontend connection of which we are the client.
(WebKit::WebInspector::createInspectorPage):
This member variable will never be null.
Commit: 80d327a074f4ad6a5f50be4e77f7aab4e3c99e68
https://github.com/WebKit/WebKit/commit/80d327a074f4ad6a5f50be4e77f7aab4e3c99e68
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/cssjit/SelectorCompiler.cpp
Log Message:
-----------
Merge r185071 - [CSS JIT] Fail to compile when we are out of executable memory
https://bugs.webkit.org/show_bug.cgi?id=145483
rdar://problem/21166612
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-06-01
Reviewed by Andreas Kling.
We should use a soft failure when the Linker fails to allocate
executable memory for the CSS JIT. We will just fallback to slow
code when that happen, better slow CSS than crashing.
Credit to Chris for finding this problem.
* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::SelectorCodeGenerator::compile):
Commit: b83de36eae92860d627584bbd7ff6e1c51c5c7ed
https://github.com/WebKit/WebKit/commit/b83de36eae92860d627584bbd7ff6e1c51c5c7ed
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/CallLinkInfo.h
M Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.cpp
M Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.h
Log Message:
-----------
Merge r185084 - Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::revertCall + 24
https://bugs.webkit.org/show_bug.cgi?id=145527
Reviewed by Filip Pizlo.
If a CallLinkInfo is GC'ed, we need to notify any PolymorphicCallNode's that reference it.
Added plumbling to clear the m_callLinkInfo of a PolymorphicCallNode when that CallLinkInfo
is going away.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::~CallLinkInfo):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlink):
(JSC::PolymorphicCallNode::clearCallLinkInfo):
(JSC::PolymorphicCallCase::dump):
(JSC::PolymorphicCallStubRoutine::edges):
(JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
(JSC::PolymorphicCallStubRoutine::visitWeak):
* jit/PolymorphicCallStubRoutine.h:
(JSC::PolymorphicCallNode::hasCallLinkInfo):
Commit: 2387ad33e1699841e18d544658253bdb024b350c
https://github.com/WebKit/WebKit/commit/2387ad33e1699841e18d544658253bdb024b350c
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/layer-creation/zoomed-clip-intersection-expected.txt
A LayoutTests/compositing/layer-creation/zoomed-clip-intersection.html
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/LayoutRect.cpp
M Source/WebCore/platform/graphics/LayoutRect.h
Log Message:
-----------
Merge r185093 - REGRESSION (179771): zooming on facebook images covers image
https://bugs.webkit.org/show_bug.cgi?id=145485
Reviewed by Simon Fraser.
Scaling an infinite rect should always produce an infinite rect.
(Based on Simon Fraser's patch)
Source/WebCore:
Test: compositing/layer-creation/zoomed-clip-intersection.html
* platform/graphics/LayoutRect.cpp:
(WebCore::LayoutRect::scale):
LayoutTests:
* compositing/layer-creation/zoomed-clip-intersection-expected.txt: Added.
* compositing/layer-creation/zoomed-clip-intersection.html: Added.
Commit: cbe91c9c9d2c25f891d031b5f2f8276fd5939167
https://github.com/WebKit/WebKit/commit/cbe91c9c9d2c25f891d031b5f2f8276fd5939167
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/child-layer-with-subpixel-gap-needs-repaint-when-parent-moves-expected.html
A LayoutTests/compositing/child-layer-with-subpixel-gap-needs-repaint-when-parent-moves.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerBacking.h
Log Message:
-----------
Merge r185152 - Subpixel rendering: Composited layer with subpixel gap does not get painted properly when its position changes.
https://bugs.webkit.org/show_bug.cgi?id=145587
Reviewed by Simon Fraser.
The composited layer always snaps to an enclosing device pixel (floors) while the renderer rounds.
At certain positions (for example 0.5px on a 1x display), a gap is formed between the layer(0px) and its renderer(1px).
In such cases, when the the renderer moves to a position (1.1px) where the gap is closed, we need to issue repaint on the layer
in order to get the renderering right.
Source/WebCore:
Test: compositing/child-layer-with-subpixel-gap-needs-repaint-when-parent-moves.html
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAfterLayout):
(WebCore::devicePixelFractionGapFromRendererChanged):
(WebCore::RenderLayerBacking::updateGeometry):
* rendering/RenderLayerBacking.h:
LayoutTests:
* compositing/child-layer-with-subpixel-gap-needs-repaint-when-parent-moves-expected.html: Added.
* compositing/child-layer-with-subpixel-gap-needs-repaint-when-parent-moves.html: Added.
Commit: 467ede25e4a5914710f924506572d210edbc62f2
https://github.com/WebKit/WebKit/commit/467ede25e4a5914710f924506572d210edbc62f2
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/SVGGlyph.cpp
Log Message:
-----------
Merge r185195 - Shrink the ArabicCharShapingMode enum in SVGGlyph.cpp
https://bugs.webkit.org/show_bug.cgi?id=145564
Reviewed by Darin Adler.
Shrink the ArabicCharShapingMode enum to just one byte.
This drops the size of the static s_arabicCharShapingMode
array of ArabicCharShapingMode values from 888 bytes to 222.
* platform/graphics/SVGGlyph.cpp:
(WebCore::processArabicFormDetection):
Commit: fc5cf26c0eec44a4a6083c8c351d260b386620dd
https://github.com/WebKit/WebKit/commit/fc5cf26c0eec44a4a6083c8c351d260b386620dd
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/EventDispatcher.cpp
M Source/WebCore/page/animation/AnimationController.cpp
Log Message:
-----------
Merge r185232 - Crash in EventDispatcher::dispatchEvent entering a location on Google Maps
https://bugs.webkit.org/show_bug.cgi?id=145677
rdar://problem/20698280
Reviewed by Dean Jackson.
If a transition is running on a pseudo-element, and the host element is removed
from the DOM just as the transition ends, and there is a transition event listener,
then we'd crash with a null dereference in event dispatch code.
AnimationController tries to clean up running animations when renderers are destroyed,
but omitted to remove the element from two vectors that store element references.
Elements are only added to these vectors briefly on animation end, before firing
events, but failure to remove the vector entries could result in attempting
to fire an event on a pseudo-element with no host element.
Also convert EventDispatcher code to be more robust to potentially null event
targets, since it's not clear that eventTargetRespectingTargetRules() can always
manage to return a non-null node.
Hard to make a test because this is timing sensitive.
* dom/EventDispatcher.cpp:
(WebCore::eventTargetRespectingTargetRules):
(WebCore::EventDispatcher::dispatchScopedEvent):
(WebCore::EventDispatcher::dispatchEvent):
(WebCore::EventPath::EventPath):
* page/animation/AnimationController.cpp:
(WebCore::AnimationControllerPrivate::clear):
Commit: 0f6a2cf8630c61787f45822723f7b1e8f5ec287e
https://github.com/WebKit/WebKit/commit/0f6a2cf8630c61787f45822723f7b1e8f5ec287e
Author: David Hyatt <hyatt at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/decorations-vertical-underline-expected.html
A LayoutTests/fast/text/decorations-vertical-underline.html
M Source/WebCore/ChangeLog
M Source/WebCore/style/InlineTextBoxStyle.cpp
Log Message:
-----------
Merge r185256 - Underlines too close in vertical Chinese text.
https://bugs.webkit.org/show_bug.cgi?id=145651
<rdar://problem/11105920>
Reviewed by Simon Fraser.
Source/WebCore:
Added fast/text/decorations-vertical-underline.html
* style/InlineTextBoxStyle.cpp:
(WebCore::computeUnderlineOffset):
Make sure the to map text-underline-position: auto to under when a line has an ideographic baseline.
LayoutTests:
* fast/text/decorations-vertical-underline-expected.html: Added.
* fast/text/decorations-vertical-underline.html: Added.
Commit: eb4c9b54fd65134af4a2457fcb4bfeb2bc458087
https://github.com/WebKit/WebKit/commit/eb4c9b54fd65134af4a2457fcb4bfeb2bc458087
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-06 (Mon, 06 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
R LayoutTests/fast/canvas/canvas-outside-viewport-timer-throttling-expected.txt
R LayoutTests/fast/canvas/canvas-outside-viewport-timer-throttling.html
R LayoutTests/fast/dom/nested-timer-display-none-element-throttling-expected.txt
R LayoutTests/fast/dom/nested-timer-display-none-element-throttling.html
R LayoutTests/fast/dom/repeating-timer-display-none-element-throttling-expected.txt
R LayoutTests/fast/dom/repeating-timer-display-none-element-throttling.html
R LayoutTests/fast/dom/repeating-timer-element-overflow-hidden-throttling-expected.txt
R LayoutTests/fast/dom/repeating-timer-element-overflow-hidden-throttling.html
R LayoutTests/fast/dom/resources/timer-throttling-iframe.html
R LayoutTests/fast/dom/timer-throttle-on-scrolling-iframe-away-expected.txt
R LayoutTests/fast/dom/timer-throttle-on-scrolling-iframe-away.html
R LayoutTests/fast/dom/timer-unthrottle-on-layout-expected.txt
R LayoutTests/fast/dom/timer-unthrottle-on-layout.html
R LayoutTests/fast/dom/timer-unthrottle-on-scroll-expected.txt
R LayoutTests/fast/dom/timer-unthrottle-on-scroll.html
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/js/JSCSSStyleDeclarationCustom.cpp
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/ElementRareData.cpp
M Source/WebCore/dom/ElementRareData.h
M Source/WebCore/dom/Node.cpp
M Source/WebCore/html/HTMLCanvasElement.cpp
M Source/WebCore/page/DOMTimer.cpp
M Source/WebCore/page/DOMTimer.h
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
Log Message:
-----------
Merge r185269 - Regression(r176212): Broke app switching on iCloud.com
https://bugs.webkit.org/show_bug.cgi?id=145708
<rdar://problem/21235277>
Reviewed by Simon Fraser.
Source/WebCore:
Roll out r176212 and follow-up fixes for now, to fix iCloud.com.
We can reconsider later how to do this in a safer way.
* bindings/js/JSCSSStyleDeclarationCustom.cpp:
(WebCore::JSCSSStyleDeclaration::putDelegate): Deleted.
(WebCore::JSCSSStyleDeclaration::getOwnPropertyNames): Deleted.
* dom/Element.cpp:
* dom/Element.h:
* dom/ElementRareData.cpp:
* dom/ElementRareData.h:
(WebCore::ElementRareData::ElementRareData):
(WebCore::ElementRareData::~ElementRareData): Deleted.
* dom/Node.cpp:
(WebCore::Node::materializeRareData):
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::notifyObserversCanvasChanged): Deleted.
* page/DOMTimer.cpp:
(WebCore::DOMTimerFireState::scriptMadeNonUserObservableChanges): Deleted.
(WebCore::DOMTimerFireState::scriptMadeUserObservableChanges): Deleted.
(WebCore::NestedTimersMap::instanceForContext): Deleted.
(WebCore::DOMTimer::install): Deleted.
(WebCore::DOMTimer::fired): Deleted.
(WebCore::DOMTimer::alignedFireTime): Deleted.
(WebCore::DOMTimer::activeDOMObjectName): Deleted.
* page/DOMTimer.h:
* page/FrameView.cpp:
(WebCore::FrameView::reset): Deleted.
(WebCore::FrameView::viewportContentsChanged): Deleted.
(WebCore::FrameView::autoSizeIfEnabled): Deleted.
* page/FrameView.h:
LayoutTests:
Remove layout tests covering DOM Timer throttling.
* fast/canvas/canvas-outside-viewport-timer-throttling-expected.txt: Removed.
* fast/canvas/canvas-outside-viewport-timer-throttling.html: Removed.
* fast/dom/nested-timer-display-none-element-throttling-expected.txt: Removed.
* fast/dom/nested-timer-display-none-element-throttling.html: Removed.
* fast/dom/repeating-timer-display-none-element-throttling-expected.txt: Removed.
* fast/dom/repeating-timer-display-none-element-throttling.html: Removed.
* fast/dom/repeating-timer-element-overflow-hidden-throttling-expected.txt: Removed.
* fast/dom/repeating-timer-element-overflow-hidden-throttling.html: Removed.
* fast/dom/resources/timer-throttling-iframe.html: Removed.
* fast/dom/timer-throttle-on-scrolling-iframe-away-expected.txt: Removed.
* fast/dom/timer-throttle-on-scrolling-iframe-away.html: Removed.
* fast/dom/timer-unthrottle-on-layout-expected.txt: Removed.
* fast/dom/timer-unthrottle-on-layout.html: Removed.
* fast/dom/timer-unthrottle-on-scroll-expected.txt: Removed.
* fast/dom/timer-unthrottle-on-scroll.html: Removed.
Commit: c1ef0df28adf5b8b79bbf85f87c223c0fe72748b
https://github.com/WebKit/WebKit/commit/c1ef0df28adf5b8b79bbf85f87c223c0fe72748b
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/PositionIterator.cpp
M Source/WebCore/editing/htmlediting.cpp
Log Message:
-----------
Merge r185287 - Typing is slow in Gmail on iPads
https://bugs.webkit.org/show_bug.cgi?id=145686
Reviewed by Enrica Casucci.
The bug was caused by nextCandidate and nextVisuallyDistinctCandidate traversing through each character
in a text node without a renderer. Skip any node that doesn't have a renderer in both of those functions
and corresponding previous* functions.
It's fine to skip unrendered nodes in PositionIterator because only other clients of PositionIterator
are Position::upstream and Position::downstream and they don't care about un-rendered nodes either.
* dom/PositionIterator.cpp:
(WebCore::PositionIterator::increment):
(WebCore::PositionIterator::decrement):
* editing/htmlediting.cpp:
(WebCore::nextVisuallyDistinctCandidate):
(WebCore::previousVisuallyDistinctCandidate):
Commit: c110325a8e6ff7b87957212c5f3ebab7e5197729
https://github.com/WebKit/WebKit/commit/c110325a8e6ff7b87957212c5f3ebab7e5197729
Author: Darin Adler <darin at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/images/animated-gif-no-layout-expected.html
A LayoutTests/fast/images/animated-gif-no-layout.html
A LayoutTests/fast/images/gif-loop-count-expected.html
R LayoutTests/fast/images/gif-loop-count-expected.png
R LayoutTests/fast/images/gif-loop-count-expected.txt
M LayoutTests/platform/wk2/TestExpectations
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderImage.cpp
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
Log Message:
-----------
Merge r185310 - REGRESSION (r181720): Unnecessary layout triggered any time animated GIF advances to a new frame
https://bugs.webkit.org/show_bug.cgi?id=145733
Reviewed by Andreas Kling.
Source/WebCore:
Test: fast/images/animated-gif-no-layout.html
* rendering/RenderImage.cpp:
(WebCore::RenderImage::styleDidChange): Correctly pass ImageSizeChangeNone in cases
where we don't need to report a change in intrinsic size that happened outside the
repaintOrMarkForLayout function.
(WebCore::RenderImage::repaintOrMarkForLayout): Move work that should only be done
when size changed inside the if statement.
* testing/Internals.cpp:
(WebCore::Internals::layoutCount): Added.
* testing/Internals.h: Added layoutCount.
* testing/Internals.idl: Ditto.
LayoutTests:
* TestExpectations: Expect image failures on the animated GIF tests (the one
old one I am fixing and the one new one I am adding) because they don't yet work
under DumpRenderTree.
* fast/images/animated-gif-no-layout-expected.html: Added.
* fast/images/animated-gif-no-layout.html: Added.
* fast/images/gif-loop-count-expected.html: Added. This test was worthless as a render
tree dump test, and only valuable as a pixel test. And that hid the fact that it was
failing under WebKit1. Changing it to a reference test makes it a valuable test again.
* fast/images/gif-loop-count-expected.png: Removed.
* fast/images/gif-loop-count-expected.txt: Removed.
* platform/wk2/TestExpectations: Expect successes on these two tests.
Commit: 468319c7029174e016b495bbca205c3a4001b14f
https://github.com/WebKit/WebKit/commit/468319c7029174e016b495bbca205c3a4001b14f
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/filters/feComposite-background-rect-control-operators-expected.svg
A LayoutTests/svg/filters/feComposite-background-rect-control-operators.svg
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/IntRect.h
M Source/WebCore/platform/graphics/filters/FEComposite.cpp
M Source/WebCore/platform/graphics/filters/FilterEffect.cpp
M Source/WebCore/platform/graphics/filters/FilterEffect.h
Log Message:
-----------
Merge r185392 - feComposite filter does not clip the paint rect to its effect rect when the operator is 'in' or 'atop'
https://bugs.webkit.org/show_bug.cgi?id=137856
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-06-09
Reviewed by Darin Adler.
Source/WebCore:
There was bug in calculating the absolutePaintRect of the feComposite filter
when the operator is equal to 'in' or 'atop'. The absolutePaintRect was set
to the absolutePaintRect of the background FilterEffect which is correct.
What was missing is clipping this rectangle to the maxEffectRect of the
filter which we do for other operators.
Tests: svg/filters/feComposite-background-rect-control-operators.svg
* platform/graphics/IntRect.h:
(WebCore::operator-=):
(WebCore::operator-): Add new operators to IntRect.
* platform/graphics/filters/FEComposite.cpp:
(WebCore::FEComposite::determineAbsolutePaintRect): Make sure the filter
absolutePaintRect is clipped to maxEffectRect for all operators.
(WebCore::FEComposite::platformApplySoftware): Code clean-up.
* platform/graphics/filters/FilterEffect.cpp:
(WebCore::FilterEffect::determineAbsolutePaintRect): Move the clipping
part to a separate function.
(WebCore::FilterEffect::clipAbsolutePaintRect): Clip the absolutePaintRect
to the maxEffectRect of the filter.
* platform/graphics/filters/FilterEffect.h:
LayoutTests:
* svg/filters/feComposite-background-rect-control-operators-expected.svg: Added.
* svg/filters/feComposite-background-rect-control-operators.svg: Added.
Ensure the painting rect of the feComposite filter with operator 'in' or
'atop' is clipped to its bounding rectangle
Commit: de07bfeb077c04240c16fe19f330dd62aba94b0c
https://github.com/WebKit/WebKit/commit/de07bfeb077c04240c16fe19f330dd62aba94b0c
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/css/svg-resource-fragment-identifier-background-expected.html
A LayoutTests/svg/css/svg-resource-fragment-identifier-background.html
M Source/WebCore/ChangeLog
M Source/WebCore/loader/cache/CachedImage.cpp
M Source/WebCore/svg/graphics/SVGImage.cpp
M Source/WebCore/svg/graphics/SVGImage.h
M Source/WebCore/svg/graphics/SVGImageCache.cpp
M Source/WebCore/svg/graphics/SVGImageCache.h
M Source/WebCore/svg/graphics/SVGImageForContainer.cpp
Log Message:
-----------
Merge r185395 - SVG Fragment is not rendered if it is the css background image of an HTML element
https://bugs.webkit.org/show_bug.cgi?id=91790
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-06-09
Reviewed by Darin Adler.
Source/WebCore:
To show an SVG fragment, the SVGImage has to scrollToFragment() using
the resource url. The changes http://trac.webkit.org/changeset/164804
and http://trac.webkit.org/changeset/164983 set the url of SVGImage to
to be used later in SVGImage::draw(). The problem is the SVGImage url
is only set when it is the src of an <img> tag. We did not do the same
thing when the SVGImage is the css background image of an HTML element.
The fix is to set the url of the SVGImage always when it's created by
the CachedImage. The CachedImage must have a valid url when the SVGImage
is created.
Test: svg/css/svg-resource-fragment-identifier-background.html
* loader/cache/CachedImage.cpp:
(WebCore::CachedImage::load):
(WebCore::CachedImage::checkShouldPaintBrokenImage):
Replace the calls resourceRequest().url() and m_resourceRequest.url() by
calling url() since they are all the same.
(WebCore::CachedImage::createImage): Pass the resource url to SVGImage
and change ImageObserver& by ImageObserver*, since null is not legal.
* svg/graphics/SVGImage.cpp:
(WebCore::SVGImage::SVGImage):
* svg/graphics/SVGImage.h: Add a url parameter to SVGImage constructor.
* svg/graphics/SVGImageCache.cpp:
(WebCore::SVGImageCache::findImageForRenderer): Add a new helper function.
(WebCore::SVGImageCache::imageSizeForRenderer):
(WebCore::SVGImageCache::imageForRenderer): Code clean up.
* svg/graphics/SVGImageCache.h: Make imageForRenderer() const.
* svg/graphics/SVGImageForContainer.cpp: Remove unneeded header file.
LayoutTests:
* svg/css/svg-resource-fragment-identifier-background-expected.html: Added.
* svg/css/svg-resource-fragment-identifier-background.html: Added.
Ensure that the SVG fragment is displayed correctly when it's used as a
css background image.
Commit: f083aedab4e05913360eedc8b6f8bb24620c359c
https://github.com/WebKit/WebKit/commit/f083aedab4e05913360eedc8b6f8bb24620c359c
Author: Andreas Kling <akling at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/GraphicsContext.cpp
M Source/WebCore/platform/graphics/GraphicsContext.h
Log Message:
-----------
Merge r185396 - GraphicsContext state stack wasting lots of memory when empty.
<https://webkit.org/b/145817>
Reviewed by Geoffrey Garen.
Give the GraphicsContextState stack an inline capacity of 1, and make sure
to free any heap-allocated backing store when the stack goes empty.
The 1 is because HTMLCanvasElement keeps one "save" on the underlying
GraphicsContext at all times, and this prevents those canvases from always
sitting on an empty stack with 16 capacity.
This saves ~520 kB on cnet.com video pages.
* platform/graphics/GraphicsContext.cpp:
(WebCore::GraphicsContext::restore):
* platform/graphics/GraphicsContext.h:
Commit: 114ac21755883fa438a85a31791f383310369ef9
https://github.com/WebKit/WebKit/commit/114ac21755883fa438a85a31791f383310369ef9
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Merge r185403 - Protect FrameView from being destroyed in Document::recalcStyle()
https://bugs.webkit.org/show_bug.cgi?id=143033
rdar://problem/20326871
Reviewed by Andreas Kling.
This patch ensures that FrameView stays valid in Document::recalcStyle().
It follows the defensive pattern we use to deal with the refcounted FrameView (see EventDispatcher::dispatchEvent)
When the iframe destroys itself in the onBeforeLoad callback (as the result of
PostResolutionCallbackDisabler -> HTMLObjectElement::updateWidget -> guardedDispatchBeforeLoadEvent),
we detach the frame and release the FrameView. However Document::recalcStyle() expects
the FrameView to stay valid.
Covered by fast/frames/flattening/crash-remove-iframe-during-object-beforeload.html.
* dom/Document.cpp:
(WebCore::Document::recalcStyle):
Commit: 5715628bbf00f3e7e10e2452768bafa92dd6738b
https://github.com/WebKit/WebKit/commit/5715628bbf00f3e7e10e2452768bafa92dd6738b
Author: Alex Christensen <achristensen at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/PerformanceTiming.cpp
M Source/WebCore/page/PerformanceTiming.h
Log Message:
-----------
Merge r185434 - [Web Timing] Fix flaky test.
https://bugs.webkit.org/show_bug.cgi?id=145846
Patch by Alex Christensen <achristensen at webkit.org> on 2015-06-10
Reviewed by Alexey Proskuryakov.
The timing data is gathered in ResourceHandle::getConnectionTimingData as
millisecond deltas from the fetch start time, not the navigation start time.
The difference between navigation and fetch start time is usually so small that
it only caused one flaky test, but this should fix that flakiness. This patch
corrects how the millisecond deltas are used.
* page/PerformanceTiming.cpp:
(WebCore::PerformanceTiming::domainLookupStart):
(WebCore::PerformanceTiming::domainLookupEnd):
(WebCore::PerformanceTiming::connectStart):
(WebCore::PerformanceTiming::connectEnd):
(WebCore::PerformanceTiming::secureConnectionStart):
(WebCore::PerformanceTiming::requestStart):
(WebCore::PerformanceTiming::responseStart):
(WebCore::PerformanceTiming::responseEnd):
(WebCore::PerformanceTiming::documentLoadTiming):
(WebCore::PerformanceTiming::resourceLoadTimeRelativeToFetchStart):
(WebCore::PerformanceTiming::monotonicTimeToIntegerMilliseconds):
(WebCore::PerformanceTiming::resourceLoadTimeRelativeToAbsolute): Deleted.
* page/PerformanceTiming.h:
Commit: a4fea307e92876308cf97d4d875d0e34a07ad467
https://github.com/WebKit/WebKit/commit/a4fea307e92876308cf97d4d875d0e34a07ad467
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/dom/ContainerNodeAlgorithms.h
M Source/WebCore/dom/Node.h
M Source/WebCore/html/HTMLFrameElementBase.cpp
M Source/WebCore/html/HTMLFrameElementBase.h
M Source/WebCore/svg/SVGFEImageElement.cpp
M Source/WebCore/svg/SVGFEImageElement.h
M Source/WebCore/svg/SVGMPathElement.cpp
M Source/WebCore/svg/SVGMPathElement.h
M Source/WebCore/svg/SVGTRefElement.cpp
M Source/WebCore/svg/SVGTRefElement.h
M Source/WebCore/svg/SVGTextPathElement.cpp
M Source/WebCore/svg/SVGTextPathElement.h
M Source/WebCore/svg/animation/SVGSMILElement.cpp
M Source/WebCore/svg/animation/SVGSMILElement.h
Log Message:
-----------
Merge r185423 - Drop unused argument for Node::didNotifySubtreeInsertions()
https://bugs.webkit.org/show_bug.cgi?id=145845
Reviewed by Andreas Kling.
* dom/ContainerNodeAlgorithms.h:
(WebCore::ChildNodeInsertionNotifier::notify):
* dom/Node.h:
(WebCore::Node::didNotifySubtreeInsertions):
* html/HTMLFrameElementBase.cpp:
(WebCore::HTMLFrameElementBase::didNotifySubtreeInsertions):
* html/HTMLFrameElementBase.h:
* svg/SVGFEImageElement.cpp:
(WebCore::SVGFEImageElement::didNotifySubtreeInsertions):
* svg/SVGFEImageElement.h:
* svg/SVGMPathElement.cpp:
(WebCore::SVGMPathElement::didNotifySubtreeInsertions):
* svg/SVGMPathElement.h:
* svg/SVGTRefElement.cpp:
(WebCore::SVGTRefElement::didNotifySubtreeInsertions):
* svg/SVGTRefElement.h:
* svg/SVGTextPathElement.cpp:
(WebCore::SVGTextPathElement::didNotifySubtreeInsertions):
* svg/SVGTextPathElement.h:
* svg/animation/SVGSMILElement.cpp:
(WebCore::SVGSMILElement::didNotifySubtreeInsertions):
* svg/animation/SVGSMILElement.h:
Commit: 6f918bace47e5aed38e9843e0842a0407c7b66a7
https://github.com/WebKit/WebKit/commit/6f918bace47e5aed38e9843e0842a0407c7b66a7
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/script-getElementById-during-insertion-expected.txt
A LayoutTests/fast/dom/script-getElementById-during-insertion.html
A LayoutTests/fast/dom/script-remove-child-id-map-expected.txt
A LayoutTests/fast/dom/script-remove-child-id-map.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/ContainerNode.cpp
M Source/WebCore/dom/ContainerNodeAlgorithms.cpp
M Source/WebCore/dom/ContainerNodeAlgorithms.h
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Merge r185435 - ASSERT_WITH_SECURITY_IMPLICATION in WebCore::DocumentOrderedMap::getElementById
https://bugs.webkit.org/show_bug.cgi?id=145857
<rdar://problem/16798440>
Reviewed by Darin Adler.
Source/WebCore:
Make sure Node::insertedInto() gets called on the inserted node and its
descendants after its insertion into the tree but *before*
ContainerNode::childrenChanged() is called on the parent node. This is
needed so that the descendants know they've been inserted into the tree
(and their InDocumentFlag flag gets set) before the parent node does
anything with them in childrenChanged().
In the case of <rdar://problem/16798440>, executing HTMLScriptElement's
childrenChanged() after appending a child to a script element was causing
the script to be executed. The script would call getElementBy() which
would traverse the DOM tree and find a matching Element in the newly
inserted subtree. However, the matching Element's InDocumentFlag flag was
not set yet because the element's insertedInto() method has not been called
yet at this point. This would cause us to hit an assertion as
DocumentOrderedMap::getElementById() is only supposed to return elements
that are in a Document.
This patch is based on Blink r178976 by <esprehn at chromium.org>:
https://src.chromium.org/viewvc/blink?view=rev&revision=178976
Tests: fast/dom/script-getElementById-during-insertion.html
fast/dom/script-remove-child-id-map.html
* dom/ContainerNode.cpp:
(WebCore::ContainerNode::notifyChildInserted):
(WebCore::ContainerNode::notifyChildRemoved):
(WebCore::ContainerNode::removeChildren):
(WebCore::ContainerNode::parserInsertBefore): Deleted.
(WebCore::ContainerNode::removeChild): Deleted.
(WebCore::ContainerNode::parserRemoveChild): Deleted.
(WebCore::ContainerNode::parserAppendChild): Deleted.
(WebCore::ContainerNode::childrenChanged): Deleted.
(WebCore::ContainerNode::setAttributeEventListener): Deleted.
(WebCore::ContainerNode::querySelector): Deleted.
* dom/ContainerNodeAlgorithms.cpp:
(WebCore::ChildNodeInsertionNotifier::notifyDescendantInsertedIntoDocument):
(WebCore::ChildNodeInsertionNotifier::notifyDescendantInsertedIntoTree):
* dom/ContainerNodeAlgorithms.h:
(WebCore::ChildNodeInsertionNotifier::notifyNodeInsertedIntoDocument):
(WebCore::ChildNodeInsertionNotifier::notifyNodeInsertedIntoTree):
(WebCore::ChildNodeInsertionNotifier::notify):
(WebCore::ChildNodeRemovalNotifier::notifyNodeRemovedFromDocument): Deleted.
* dom/Element.cpp:
(WebCore::Element::addShadowRoot):
LayoutTests:
Add layout tests covering different crashes caused by the same bug.
* fast/dom/script-getElementById-during-insertion-expected.txt: Added.
* fast/dom/script-getElementById-during-insertion.html: Added.
Reduction test case for <rdar://problem/16798440>.
* fast/dom/script-remove-child-id-map-expected.txt: Added.
* fast/dom/script-remove-child-id-map.html: Added.
Test imported from Blink r178976.
Commit: 0340e2b9a3af5b73f243c1d5651c38c81c647798
https://github.com/WebKit/WebKit/commit/0340e2b9a3af5b73f243c1d5651c38c81c647798
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/platform/ScrollView.cpp
M Source/WebCore/platform/mac/WidgetMac.mm
M Source/WebCore/rendering/RenderFrameBase.cpp
M Source/WebCore/rendering/RenderFrameBase.h
M Source/WebCore/rendering/RenderWidget.cpp
M Source/WebCore/rendering/RenderWidget.h
Log Message:
-----------
Merge r185484 - Do not crash when the descendant frame tree is destroyed during layout.
https://bugs.webkit.org/show_bug.cgi?id=144540
rdar://problem/20793184
Reviewed by Andreas Kling.
Source/WebCore:
Widget::setFrameRect(), through WebHTMLView layout, could trigger a style recalc, which in turn
could initiate an onBeforeLoad callback.
If javascript happens to destroy the current iframe in the onBeforeLoad callback, we lose the descendant
render tree, including the child FrameView (the iframe element's view). However the RenderIFrame
object stays protected until after the layout is done. (see protectRenderWidgetUntilLayoutIsDone())
Climbing back on the callstack, we need to make sure that
1. the root widget of the descendant render tree (FrameView) stays valid as long as it is needed.
2. RenderFrameBase::layoutWithFlattening() can handle the case when the associated widget (child FrameView) is set to nullptr.
(see RenderWidget::willBeDestroyed() -> setWidget(nullptr))
(and later, when layout is finished this (RenderIFrame) object gets destroyed too.)
Covered by fast/frames/flattening/crash-remove-iframe-during-object-beforeload.html.
* page/FrameView.cpp:
(WebCore::FrameView::setFrameRect):
(WebCore::FrameView::updateEmbeddedObject):
(WebCore::FrameView::updateWidgetPositions):
* platform/ScrollView.cpp:
(WebCore::ScrollView::setFrameRect):
* platform/mac/WidgetMac.mm:
(WebCore::Widget::setFrameRect):
* rendering/RenderFrameBase.cpp:
(WebCore::RenderFrameBase::layoutWithFlattening):
(WebCore::RenderFrameBase::childRenderView):
(WebCore::RenderFrameBase::peformLayoutWithFlattening):
* rendering/RenderFrameBase.h:
* rendering/RenderWidget.cpp:
(WebCore::RenderWidget::updateWidgetPosition):
* rendering/RenderWidget.h:
LayoutTests:
Unskip fast/frames/flattening/crash-remove-iframe-during-object-beforeload.html.
* TestExpectations:
Commit: cafa6d5967d53a7afaed618ce49bd138fc24a75f
https://github.com/WebKit/WebKit/commit/cafa6d5967d53a7afaed618ce49bd138fc24a75f
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/EmptyClients.h
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoaderClient.h
M Source/WebKit/mac/ChangeLog
M Source/WebKit/mac/WebCoreSupport/WebFrameLoaderClient.h
M Source/WebKit/win/ChangeLog
M Source/WebKit/win/WebCoreSupport/WebFrameLoaderClient.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
M Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.h
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
M Source/WebKit2/WebProcess/WebPage/WebPage.h
Log Message:
-----------
Merge r185542 - [WK2] API::Navigation objects are leaked on history navigation to HistoryItems in PageCache
https://bugs.webkit.org/show_bug.cgi?id=145948
Reviewed by Darin Adler.
Source/WebCore:
API::Navigation objects were leaked on history navigation to
HistoryItems in PageCache. In such case, we would create 2 Navigation
objects instead of 1 and the first one would be leaked. The reason
we create the second one is because we fail to pass along the
navigationID from the UIProcess to the WebProcess and then back to the
UIProcess. On the IPC back to the UIProcess, the navigationID ends up
being 0 so the UIProcess creates a new Navigation object, thinking that
the load was triggered by the WebContent process.
We now pass along the navigationID, even if the HistoryItem is in the
PageCache and we end up reusing the cached DocumentLoader, instead of
creating a new one. A new updateCachedDocumentLoader() delegate is
added to the FrameLoaderClient, similarly to the pre-existing
createDocumentLoader() but for the case where the DocumentLoader gets
reused.
* loader/EmptyClients.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadDifferentDocumentItem):
* loader/FrameLoaderClient.h:
Source/WebKit/mac:
Add empty implementation for new
FrameLoaderClient::updatedCachedDocumentLoader().
* WebCoreSupport/WebFrameLoaderClient.h:
Source/WebKit/win:
Add empty implementation for new
FrameLoaderClient::updatedCachedDocumentLoader().
* WebCoreSupport/WebFrameLoaderClient.h:
Source/WebKit2:
API::Navigation objects were leaked on history navigation to
HistoryItems in PageCache. In such case, we would create 2 Navigation
objects instead of 1 and the first one would be leaked. The reason
we create the second one is because we fail to pass along the
navigationID from the UIProcess to the WebProcess and then back to the
UIProcess. On the IPC back to the UIProcess, the navigationID ends up
being 0 so the UIProcess creates a new Navigation object, thinking that
the load was triggered by the WebContent process.
We now pass along the navigationID, even if the HistoryItem is in the
PageCache and we end up reusing the cached DocumentLoader, instead of
creating a new one. A new updateCachedDocumentLoader() delegate is
added to the FrameLoaderClient, similarly to the pre-existing
createDocumentLoader() but for the case where the DocumentLoader gets
reused.
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::updateCachedDocumentLoader):
* WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::goForward):
(WebKit::WebPage::goBack):
(WebKit::WebPage::goToBackForwardItem):
(WebKit::WebPage::updateCachedDocumentLoader):
* WebProcess/WebPage/WebPage.h:
Commit: 6574ef7250929db09fa7bc4278320f8cef7f5f84
https://github.com/WebKit/WebKit/commit/6574ef7250929db09fa7bc4278320f8cef7f5f84
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/inline/crash-when-child-renderer-is-removed-and-line-stays-clean-expected.txt
A LayoutTests/fast/inline/crash-when-child-renderer-is-removed-and-line-stays-clean.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderInline.cpp
M Source/WebCore/rendering/RootInlineBox.cpp
Log Message:
-----------
Merge r185572 - RootInlineBox::m_lineBreakObj becomes invalid when a child renderer is removed and the line does not get marked dirty.
https://bugs.webkit.org/show_bug.cgi?id=145988
rdar://problem/20959137
Reviewed by David Hyatt.
This patch ensures that we find the right first inline box so that we can dirty the
the appropriate line boxes.
With marking the right line boxes dirty, now we can update RootInlineBox::m_lineBreakObj at the next layout.
Source/WebCore:
Test: fast/inline/crash-when-child-renderer-is-removed-and-line-stays-clean.html
* rendering/RenderInline.cpp:
(WebCore::RenderInline::culledInlineFirstLineBox):
(WebCore::RenderInline::culledInlineLastLineBox):
* rendering/RootInlineBox.cpp:
(WebCore::RootInlineBox::setLineBreakInfo): Deleted. Remove misleading assert and comment.
LayoutTests:
* fast/inline/crash-when-child-renderer-is-removed-and-line-stays-clean-expected.txt: Added.
* fast/inline/crash-when-child-renderer-is-removed-and-line-stays-clean.html: Added.
Commit: b78dadc82a0b405748aa31c82bf3ff7ac685bcdd
https://github.com/WebKit/WebKit/commit/b78dadc82a0b405748aa31c82bf3ff7ac685bcdd
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Merge r185643 - WebProcess crashes after too many redirect error when there's an active NPAPI plugin
https://bugs.webkit.org/show_bug.cgi?id=146019
Reviewed by Darin Adler.
This happens with the GTK+ port after a navigation action ends up
in an infinite redirection and the ResourceHandle fails with too
many redirections error. I should actually happen after any error
is reported by the ResourceHnalder before the load is
committed. But tt only happens if there's an active NPAPI
plugin. The problem is that FrameLoader::receivedMainResourceError()
is called recursively because DocumentLoader::stopLoading() ends up
calling mainReceivedError() that calls FrameLoader::receivedMainResourceError()
again. DocumentLoader::stopLoading() checks if the document is
still loading, which can happen if the main resource is loading,
if there's any subresource loading or if there's a plugin
loading. So, in case of being loading, those cases are handled
individually to cancel the main resource, or set an error in the
document loader and cancel subresources and plugins, except for
this case of plugins, that mainReceivedError is called instead of
setting cancelled error on the document loader.
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::stopLoading): If the document is still
loading because there are active plugins, set the cancelled error
on the document instead of calling mainReceivedError again.
Commit: 444290aa13bf66ebe46a5cc86bd9fe0bc7dbc53c
https://github.com/WebKit/WebKit/commit/444290aa13bf66ebe46a5cc86bd9fe0bc7dbc53c
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/gtk/WebProcessPoolGtk.cpp
Log Message:
-----------
Merge r185651 - [GTK] WEBKIT_CACHE_MODEL_DOCUMENT_VIEWER doesn't disable memory cache when set before the web process is launched
https://bugs.webkit.org/show_bug.cgi?id=146053
Reviewed by Martin Robinson.
The cache is disabled in WebProcess::platformSetCacheModel() when
the cache model is CacheModelDocumentViewer, but it's enabled
again by WebProcess::setMemoryCacheDisabled() when
memoryCacheDisabled creation parameter is processed. We need to
make sure the cache model and memoryCacheDisabled parameters are consistent.
* UIProcess/gtk/WebProcessPoolGtk.cpp:
(WebKit::WebProcessPool::platformInitializeWebProcess): Initialize
memoryCacheDisabled parameter to true if memory cache was
explicitly disabled or cache model is CacheModelDocumentViewer.
Commit: 733b409b05ad9770e59f2f76a427960a4c07d826
https://github.com/WebKit/WebKit/commit/733b409b05ad9770e59f2f76a427960a4c07d826
Author: Andreas Kling <akling at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/bytecode/ArrayProfile.h
M Source/JavaScriptCore/dfg/DFGCommonData.h
M Source/WTF/ChangeLog
M Source/WTF/wtf/SegmentedVector.h
Log Message:
-----------
Merge r185639 - Remove unused template parameter InlineCapacity from SegmentedVector.
<https://webkit.org/b/146044>
Reviewed by Anders Carlsson.
Source/JavaScriptCore:
* bytecode/ArrayProfile.h:
* dfg/DFGCommonData.h:
Source/WTF:
* wtf/SegmentedVector.h:
(WTF::SegmentedVectorIterator::operator=):
(WTF::SegmentedVectorIterator::SegmentedVectorIterator):
(WTF::SegmentedVector::at):
Commit: 8e0115375d968f1caadd3e22830b45fbd7601776
https://github.com/WebKit/WebKit/commit/8e0115375d968f1caadd3e22830b45fbd7601776
Author: Andreas Kling <akling at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/SegmentedVector.h
Log Message:
-----------
Merge r185663 - SegmentedVector should waste less memory.
<https://webkit.org/b/146069>
Reviewed by Anders Carlsson.
We were wasting sizeof(Vector) on every segment in SegmentVector.
The segments were using inline capacity, and would never go beyond it,
so all the size/capacity/out-of-line-buffer metadata was useless.
Change the internal representation to Vector<T[SegmentSize]> instead.
This saves 16 bytes per segment, so lower SegmentSize -> bigger savings!
* wtf/SegmentedVector.h:
(WTF::SegmentedVectorIterator::operator*):
(WTF::SegmentedVectorIterator::operator->):
(WTF::SegmentedVectorIterator::operator++):
(WTF::SegmentedVectorIterator::operator==):
(WTF::SegmentedVectorIterator::operator!=):
(WTF::SegmentedVectorIterator::SegmentedVectorIterator):
(WTF::SegmentedVector::at):
(WTF::SegmentedVector::append):
(WTF::SegmentedVector::removeLast):
(WTF::SegmentedVector::grow):
(WTF::SegmentedVector::begin):
(WTF::SegmentedVector::end):
(WTF::SegmentedVector::deleteAllSegments):
(WTF::SegmentedVector::ensureSegmentsFor):
(WTF::SegmentedVector::ensureSegment):
(WTF::SegmentedVector::allocateSegment):
(WTF::SegmentedVectorIterator::operator=): Deleted.
(WTF::SegmentedVector::SegmentedVector): Deleted.
Commit: 721f3cdedbc9da7e4b681956672c465ec353e55a
https://github.com/WebKit/WebKit/commit/721f3cdedbc9da7e4b681956672c465ec353e55a
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/backing/form-controls-backing-expected.txt
A LayoutTests/compositing/backing/form-controls-backing.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerBacking.cpp
Log Message:
-----------
Merge r185666 - REGRESSION (r173283-r173296): Amazon.com front page has no caret in the search field
https://bugs.webkit.org/show_bug.cgi?id=146073
rdar://problem/21022203
Reviewed by Tim Horton.
Source/WebCore:
Text controls (text inputs and textareas) need backing store even when empty, because
they need to be able to paint a caret.
Test: compositing/backing/form-controls-backing.html
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::isSimpleContainerCompositingLayer):
LayoutTests:
Dump layers for composited text inputs and textareas.
* compositing/backing/form-controls-backing-expected.txt: Added.
* compositing/backing/form-controls-backing.html: Added.
Commit: 201b92da339f14ae0dc4da5d54542a3f788f2480
https://github.com/WebKit/WebKit/commit/201b92da339f14ae0dc4da5d54542a3f788f2480
Author: Joseph Pecoraro <pecoraro at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/DOMWindow.cpp
Log Message:
-----------
Merge r185712 - Crash under WebCore::DOMWindow::dispatchMessageEventWithOriginCheck attempting to log console message
https://bugs.webkit.org/show_bug.cgi?id=146093
Patch by Joseph Pecoraro <pecoraro at apple.com> on 2015-06-18
Reviewed by Timothy Hatcher.
* page/DOMWindow.cpp:
(WebCore::DOMWindow::dispatchMessageEventWithOriginCheck):
The console could be null so null check its use.
Commit: 8dc4faa0170dd2e83f87fc8a80dda428778c7d8e
https://github.com/WebKit/WebKit/commit/8dc4faa0170dd2e83f87fc8a80dda428778c7d8e
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/cssjit/SelectorCompiler.cpp
M Source/WebCore/cssjit/StackAllocator.h
Log Message:
-----------
Merge r185719 - [CSS JIT][ARMv7] The pseudo element early exit trashes r6
https://bugs.webkit.org/show_bug.cgi?id=146078
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-06-18
Reviewed by Alex Christensen.
The pseudo element early failure runs before we generate the prologue.
The reason is that we can often exit immediately on function entry, before
we even touch any memory.
On ARMv7, we don't have many spare registers so the MacroAssembler
uses r6 as a scratch register and the client code is expected to save
it.
In the early failure case, we were not pushing r6 before using the MacroAssembler
and its value could be trashed.
This patch push the macro assembler registers separately from the prologue.
For restoring the registers, a new function generateFunctionEnding() encapsulate
the pop() and ret().
* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::SelectorCodeGenerator::pushMacroAssemblerRegisters):
(WebCore::SelectorCompiler::SelectorCodeGenerator::popMacroAssemblerRegisters):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generatePrologue):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateEpilogue):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateSelectorChecker):
* cssjit/StackAllocator.h:
(WebCore::StackAllocator::operator=):
We have a new case for the stack allocator: some stack changes are conditional
at compile time instead of runtime. This is easy to deal with by overriding
the stack if a path is not taken at compile time.
Commit: 4dc294d9f7f652158787bbbdf1157051c731c1df
https://github.com/WebKit/WebKit/commit/4dc294d9f7f652158787bbbdf1157051c731c1df
Author: Brent Fulgham <bfulgham at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/BitmapImage.cpp
M Source/WebCore/platform/graphics/cairo/ImageBufferCairo.cpp
M Source/WebCore/platform/graphics/filters/FETile.cpp
M Source/WebCore/platform/graphics/filters/FilterEffect.cpp
M Source/WebCore/svg/graphics/SVGImage.cpp
M Source/WebKit/mac/ChangeLog
M Source/WebKit/mac/WebCoreSupport/WebContextMenuClient.mm
Log Message:
-----------
Merge r185766 - All calls of ImageBuffer::create should null check the return value
https://bugs.webkit.org/show_bug.cgi?id=22132
Reviewed by Zalan Bujtas.
ImageBuffer::create returns nullptr for a number of reasons, and should be
expected to do so. We missed this check in a few places, resulting in
crashes on some systems. Likewise, ImageBuffer::copyImage may return nullptr
in normal use and should be checked.
Source/WebCore:
* platform/graphics/BitmapImage.cpp:
(WebCore::BitmapImage::drawPattern): Add nullptr check for create and copyImage. Remove
extra call to 'setImageObserver'.
* platform/graphics/cairo/ImageBufferCairo.cpp:
(WebCore::ImageBuffer::drawPattern): Add nullptr check for copyImage.
* platform/graphics/cg/ImageBufferCG.cpp:
(WebCore::ImageBuffer::drawPattern): Add nullptr checks for copyImage.
* platform/graphics/filters/FETile.cpp:
(WebCore::FETile::platformApplySoftware): Add nullptr check for copyImage.
* platform/graphics/filters/FilterEffect.cpp:
(WebCore::FilterEffect::asImageBuffer): Add nullptr check for create.
(WebCore::FilterEffect::openCLImageToImageBuffer): Ditto.
* platform/graphics/texmap/BitmapTexture.cpp:
(WebCore::BitmapTexture::updateContents): Add nullptr checks for create and copyImage.
* svg/graphics/SVGImage.cpp:
(WebCore::SVGImage::drawPatternForContainer): Add nullptr check for copyImage.
Source/WebKit/mac:
* WebCoreSupport/WebContextMenuClient.mm:
(WebContextMenuClient::imageForCurrentSharingServicePickerItem): Add nullptr check
for copyImage.
Commit: b9eccaed852b30676677ab0eabaa190bfb891259
https://github.com/WebKit/WebKit/commit/b9eccaed852b30676677ab0eabaa190bfb891259
Author: Andy Estes <aestes at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/element-removed-while-inserting-parent-crash-expected.txt
A LayoutTests/fast/dom/element-removed-while-inserting-parent-crash.html
A LayoutTests/fast/dom/named-map-removed-while-inserting-parent-crash-expected.txt
A LayoutTests/fast/dom/named-map-removed-while-inserting-parent-crash.html
A LayoutTests/fast/forms/form-control-removed-while-inserting-parent-crash-expected.txt
A LayoutTests/fast/forms/form-control-removed-while-inserting-parent-crash.html
A LayoutTests/svg/dom/element-removed-while-inserting-parent-crash-expected.txt
A LayoutTests/svg/dom/element-removed-while-inserting-parent-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/dom/ScriptElement.cpp
M Source/WebCore/dom/ScriptElement.h
M Source/WebCore/html/HTMLScriptElement.cpp
M Source/WebCore/html/HTMLScriptElement.h
M Source/WebCore/svg/SVGScriptElement.cpp
M Source/WebCore/svg/SVGScriptElement.h
Log Message:
-----------
Merge r185769 - Various assertion failures occur when executing script in the midst of DOM insertion
https://bugs.webkit.org/show_bug.cgi?id=132482
Reviewed by Darin Adler.
Source/WebCore:
Prior to this change, when an element containing a <script> child was inserted into a document, the script was
executed in ScriptElement::insertedInto(). That script can access nodes that follow it in the newly-inserted
hierarchy but are not yet fully inserted, leading to at least the following problems:
- The script could remove a node that is not yet marked as in the document.
- The script could remove a named <map> that has yet to be added to TreeScope::m_imageMapsByName.
- The script could remove a form control that has yet to be added to FormController::m_formElementsWithState.
These scenarios all result in assertion failures. This change ensures that each node in the newly-inserted
hierarchy is fully inserted before executing any scripts.
Tests: fast/dom/element-removed-while-inserting-parent-crash.html
fast/dom/named-map-removed-while-inserting-parent-crash.html
fast/forms/form-control-removed-while-inserting-parent-crash.html
svg/dom/element-removed-while-inserting-parent-crash.html
* dom/ScriptElement.cpp:
(WebCore::ScriptElement::shouldNotifySubtreeInsertions): Renamed from insertedInto().
Returned true in the case where insertedInto() would've called prepareScript().
(WebCore::ScriptElement::didNotifySubtreeInsertions): Called prepareScript().
(WebCore::ScriptElement::insertedInto): Renamed to shouldNotifySubtreeInsertions().
* dom/ScriptElement.h:
* html/HTMLScriptElement.cpp:
(WebCore::HTMLScriptElement::insertedInto): If shouldNotifySubtreeInsertions() is true, returned InsertionShouldCallDidNotifySubtreeInsertions.
Otherwise, returned InsertionDone.
(WebCore::HTMLScriptElement::didNotifySubtreeInsertions): Called ScriptElement::didNotifySubtreeInsertions().
* html/HTMLScriptElement.h:
* svg/SVGScriptElement.cpp:
(WebCore::SVGScriptElement::insertedInto): Did the same as HTMLScriptElement::insertedInto().
(WebCore::SVGScriptElement::didNotifySubtreeInsertions): Called ScriptElement::didNotifySubtreeInsertions().
* svg/SVGScriptElement.h:
LayoutTests:
Wrote named-map-removed-while-inserting-parent-crash.html by reducing the test case attached to bug 132482.
The remaining tests were taken from blink r132482.
* fast/dom/element-removed-while-inserting-parent-crash-expected.txt: Added.
* fast/dom/element-removed-while-inserting-parent-crash.html: Added.
* fast/dom/named-map-removed-while-inserting-parent-crash-expected.txt: Added.
* fast/dom/named-map-removed-while-inserting-parent-crash.html: Added.
* fast/forms/form-control-removed-while-inserting-parent-crash-expected.txt: Added.
* fast/forms/form-control-removed-while-inserting-parent-crash.html: Added.
* svg/dom/element-removed-while-inserting-parent-crash-expected.txt: Added.
* svg/dom/element-removed-while-inserting-parent-crash.html: Added.
Commit: b0547501ab74f2060813f588469b2acdf85a2971
https://github.com/WebKit/WebKit/commit/b0547501ab74f2060813f588469b2acdf85a2971
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/yarr/YarrJIT.cpp
Log Message:
-----------
Merge r185770 - WebKit crash while loading nytimes at JavaScriptCore: JSC::ExecutableAllocator::allocate + 276
https://bugs.webkit.org/show_bug.cgi?id=146163
<rdar://problem/20392986>
Reviewed by Michael Saboff.
There's no good way to test this in our test harness because we don't
have a way to simulate executable memory pressure, and doing so would
cause the cases that still use JITCompilationMustSucceed to crash.
Instead, I tested by manually forcing all regexp JIT compilation to
fail and running the JavaScriptCore tests.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::compile): Allow compilation to fail. We can
fall back to the regexp interpreter if we need to.
Commit: 23f7d682ddefa35aa8e8064456c6d761d4250348
https://github.com/WebKit/WebKit/commit/23f7d682ddefa35aa8e8064456c6d761d4250348
Author: Joseph Pecoraro <pecoraro at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/page/PageConsoleClient.cpp
Log Message:
-----------
Merge r185781 - Crash under WebCore::PageConsoleClient::addMessage attempting to log insecure content message in ImageDocument
https://bugs.webkit.org/show_bug.cgi?id=146096
Patch by Joseph Pecoraro <pecoraro at apple.com> on 2015-06-19
Reviewed by Timothy Hatcher.
Was able to reproduce this using a user stylesheet with an http css font
on a pdf (ImageDocument) main document loaded over https. Was unable to
create a reliable test for this scenario.
* page/PageConsoleClient.cpp:
(WebCore::getParserLocationForConsoleMessage):
The scriptableDocumentParser could be null, such as in an ImageDocument.
Commit: 3d4c91b46b2a646e22cb20862bb0bd8f417d728f
https://github.com/WebKit/WebKit/commit/3d4c91b46b2a646e22cb20862bb0bd8f417d728f
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/Platform/IPC/unix/ConnectionUnix.cpp
Log Message:
-----------
Merge r185824 - [WK2] ConnectionUnix should use FastMalloc to allocate on-heap resources
https://bugs.webkit.org/show_bug.cgi?id=146143
Reviewed by Carlos Garcia Campos.
IPC handling in Unix-specific IPC::Connection implementation should use
FastMalloc to allocate on-heap resources, instead of allocating via the
system allocator.
The AttachmentInfo class is marked as allocatable through FastMalloc.
That way it can be allocated through FastMalloc while still handled
through std::unique_ptr<>.
The char[] arrays in readBytesFromSocket() and Connection::sendOutgoingMessage()
are now handled through a MallocPtr<> object.
In Connection::sendOutgoingMessage(), both the AttachmentInfo[] and char[]
arrays are now only allocated if there are actual attachments contained
in the message. The code that's conditioned with a non-empty attachments
Vector is now also grouped together, in a single branch.
* Platform/IPC/unix/ConnectionUnix.cpp:
(IPC::readBytesFromSocket):
(IPC::Connection::sendOutgoingMessage):
Commit: dab754b0190d13dfdd7451d654205ccad658ed7d
https://github.com/WebKit/WebKit/commit/dab754b0190d13dfdd7451d654205ccad658ed7d
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees-expected.txt
A LayoutTests/fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/SelectionSubtreeRoot.cpp
Log Message:
-----------
Merge r185838 - REGRESSION(r169105) Dangling renderer pointer in SelectionSubtreeRoot::SelectionSubtreeData.
https://bugs.webkit.org/show_bug.cgi?id=146116
rdar://problem/20959369
Reviewed by Brent Fulgham.
This patch ensures that we don't adjust the selection unless the visual selection still matches this subtree root.
When multiple selection roots are present we need to ensure that a RenderObject
only shows up in one of them.
RenderView::splitSelectionBetweenSubtrees(), as the name implies, splits the
selection and sets the selection range (start/end) on each selection root.
However, SelectionSubtreeRoot::adjustForVisibleSelection() later recomputes the range
based on visible selection and that could end up collecting renderers as selection start/end
from another selection subtree.
RenderObject's holds the last selection state (RenderObject::setSelectionState).
If we set a renderer first as "on selection border" and later "inside" using multiple selection roots,
we can't clean up selections properly when this object gets destroyed.
One of the roots ends up with a dangling RenderObject pointer.
Source/WebCore:
Test: fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees.html
* rendering/SelectionSubtreeRoot.cpp:
(WebCore::SelectionSubtreeRoot::adjustForVisibleSelection):
LayoutTests:
* fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees-expected.txt: Added.
* fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees.html: Added.
Commit: 80abc3167826555e121567712cb8411c663c5ec9
https://github.com/WebKit/WebKit/commit/80abc3167826555e121567712cb8411c663c5ec9
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Merge r185858 - ASSERT(!m_zOrderListsDirty) when mousing over web view with incremental rendering suppressed
https://bugs.webkit.org/show_bug.cgi?id=146225
Reviewed by Zalan Bujtas.
Update RenderLayer's z-order lists when hit testing. There's no guarantee that they've
been updated; this happens to work most of the time because painting updates them,
but if incremental rendering is suppressed, we may not have painted yet.
Easy to hit on webkit.org in MiniBrowser, but I wasn't able to make a reduced testcase.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::hitTest):
(WebCore::RenderLayer::updateLayerListsIfNeeded): Flip the order of the tests, since checking
dirty bits is cheaper than calling isStackingContext().
Commit: 8a13801ce82c830de1e27a4991069a326cf39e4e
https://github.com/WebKit/WebKit/commit/8a13801ce82c830de1e27a4991069a326cf39e4e
Author: YunQiang Su <wzssyqa at gmail.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/Platform.h
Log Message:
-----------
Merge r185863 - [WTF] Platform.h: use _ABI64 instead of _MIPS_SIM_ABI64 to determine MIPS N64
https://bugs.webkit.org/show_bug.cgi?id=145113
Patch by YunQiang Su <wzssyqa at gmail.com> on 2015-06-22
Reviewed by Csaba Osztrogonác.
* wtf/Platform.h:
Commit: daa5c808b9fe12f716259ed950588e85914a4a0f
https://github.com/WebKit/WebKit/commit/daa5c808b9fe12f716259ed950588e85914a4a0f
Author: Gyuyoung Kim <gyuyoung.kim at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/efl/ewk_context.h
M Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_context.cpp
M Source/WebKit2/UIProcess/Network/CustomProtocols/soup/WebSoupCustomProtocolRequestManager.cpp
Log Message:
-----------
Merge r185866 - [EFL][CustomProtocol] Do not add duplicated custom scheme
https://bugs.webkit.org/show_bug.cgi?id=146199
Reviewed by Carlos Garcia Campos.
WebSoupCustomProtocolRequestManager::registerSchemeForCustomProtocol generates
a crash when duplicated scheme is registered on debug mode, or just registers it on release mode.
However application can register duplicate scheme by mistake or on purpose. Thus it would be good
if we don't register it instead of registering it or generating a crash when trying to regiseter
duplicated scheme.
EFL port want to allow user to change registered callback, thus EWK2ContextTest::ewk_context_url_scheme_register()
is modified to test it.
Test: ewk_context_url_scheme_register() in test_ewk2_context.cpp.
* UIProcess/API/efl/ewk_context.h: Added a comment to replace registered callback.
* UIProcess/API/efl/tests/test_ewk2_context.cpp:
(EWK2ContextTest::schemeRequestCallback1):
(EWK2ContextTest::schemeRequestCallback2):
(TEST_F):
(EWK2ContextTest::schemeRequestCallback): Deleted.
* UIProcess/Network/CustomProtocols/soup/WebSoupCustomProtocolRequestManager.cpp:
(WebKit::WebSoupCustomProtocolRequestManager::registerSchemeForCustomProtocol):
Commit: a103bd3dff505dd10c5675230a8b7d7dd4c500eb
https://github.com/WebKit/WebKit/commit/a103bd3dff505dd10c5675230a8b7d7dd4c500eb
Author: Michael Catanzaro <mcatanzaro at gnome.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/gtk/DragAndDropHandler.cpp
Log Message:
-----------
Merge r185896 - [GTK] Crash performing drag-and-drop
https://bugs.webkit.org/show_bug.cgi?id=146267
Reviewed by Darin Adler.
Return early if gtk_get_current_event() returns null to avoid a crash. Note that this does
not fix drag-and-drop. Note also this prevents the web process from forcing the UI process
to crash by sending fake startDrag messages.
* UIProcess/gtk/DragAndDropHandler.cpp:
(WebKit::DragAndDropHandler::startDrag):
Commit: 10c85100154c57a24efeda74ee81237f107fcd2a
https://github.com/WebKit/WebKit/commit/10c85100154c57a24efeda74ee81237f107fcd2a
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/LayoutUnit.h
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebCore/LayoutUnit.cpp
Log Message:
-----------
Merge r185916 - Subpixel rendering: roundToDevicePixel() snaps to wrong value.
https://bugs.webkit.org/show_bug.cgi?id=146273
rdar://problem/18509840
Reviewed by Simon Fraser.
Due to the floating point approximate representation, we can't always produce
the correct snap value. This patch addresses the issue by removing redundant kFixedPointDenominator multiplication
and by changing the rounding in roundToDevicePixel() from float to double.
Source/WebCore:
API test is added.
* platform/LayoutUnit.h:
(WebCore::roundToDevicePixel):
Tools:
* TestWebKitAPI/Tests/WebCore/LayoutUnit.cpp:
(TestWebKitAPI::TEST):
Commit: c36bc8e3a1c053344add5a8856d27cd9a671231f
https://github.com/WebKit/WebKit/commit/c36bc8e3a1c053344add5a8856d27cd9a671231f
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Merge r185927 - Null dereference in DocumentLoader::areAllLoadersPageCacheAcceptable()
https://bugs.webkit.org/show_bug.cgi?id=146286
<rdar://problem/21523788>
Reviewed by Sam Weinig.
Add null check for the Page in areAllLoadersPageCacheAcceptable()
to fix this top crasher until I can investigate how this can happen.
* loader/DocumentLoader.cpp:
(WebCore::areAllLoadersPageCacheAcceptable):
Commit: 9404c219fc7726cea57a2c494afa2ba4c4cf61a9
https://github.com/WebKit/WebKit/commit/9404c219fc7726cea57a2c494afa2ba4c4cf61a9
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderThemeGtk.cpp
Log Message:
-----------
Merge r185948 - [GTK] Empty gtk-font-name setting causes WebProcess crash rendering pages
https://bugs.webkit.org/show_bug.cgi?id=146246
Reviewed by Sergio Villar Senin.
Return early if system font is empty.
* rendering/RenderThemeGtk.cpp:
(WebCore::RenderThemeGtk::updateCachedSystemFontDescription):
Commit: c55739bff4978b5ec67d3dd27744ae527aa65605
https://github.com/WebKit/WebKit/commit/c55739bff4978b5ec67d3dd27744ae527aa65605
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/platform/ios-simulator/ios/touch/input-range-with-thumb-display-none-crash-expected.txt
A LayoutTests/platform/ios-simulator/ios/touch/input-range-with-thumb-display-none-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/html/shadow/SliderThumbElement.cpp
Log Message:
-----------
Merge r185955 - Do not send touch events to the slider's thumb when it does not have a renderer.
https://bugs.webkit.org/show_bug.cgi?id=146307
rdar://problem/21539399
Reviewed by Simon Fraser.
Bail out early if either the touch target or the renderer() is null.
Source/WebCore:
Test: fast/events/touch/input-range-with-thumb-display-none-crash.html
* html/shadow/SliderThumbElement.cpp:
(WebCore::findTouchWithIdentifier):
(WebCore::SliderThumbElement::handleTouchStart):
(WebCore::SliderThumbElement::handleTouchMove):
(WebCore::SliderThumbElement::handleTouchEndAndCancel):
LayoutTests:
* fast/events/touch/input-range-with-thumb-display-none-crash-expected.txt: Added.
* fast/events/touch/input-range-with-thumb-display-none-crash.html: Added.
Commit: e2cf598eb0f25236306a44ce216346948381566f
https://github.com/WebKit/WebKit/commit/e2cf598eb0f25236306a44ce216346948381566f
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/navigation/page-cache-iframe-provisional-load-expected.txt
A LayoutTests/http/tests/navigation/page-cache-iframe-provisional-load.html
A LayoutTests/http/tests/navigation/resources/page-cache-helper-slow.html
M Source/WebCore/ChangeLog
M Source/WebCore/history/PageCache.cpp
M Source/WebCore/page/DiagnosticLoggingKeys.cpp
M Source/WebCore/page/DiagnosticLoggingKeys.h
Log Message:
-----------
Merge r186049 - Crash: com.apple.WebKit.WebContent at com.apple.WebCore: WebCore::CachedFrameBase::restore + 333
https://bugs.webkit.org/show_bug.cgi?id=146388
<rdar://problem/21567343>
Reviewed by Darin Adler.
Source/WebCore:
Pages that are currently loading are not supposed to go into the
PageCache. However, PageCache::canCache() only checks if the
FrameLoader's documentLoader is loading. If the subframe is in
provisional load stage, we would fail to detect that the frame is
actually loading because the FrameLoader active documentLoader would
be the provisional documentLoader, not the regular documentLoader.
Therefore, the page would get added to the PageCache and the frame
would keep loading while in the PageCache.
On http://www.audiusa.com/models, this is what was happening. It was
crashing because the subframe would finish loading while in the
PageCache, in which case we would fire the 'load' event and the
content 'load' event handler would then proceed to remove the iframe.
Upon restoring the PageCache entry, we would run into trouble as we
would have a CachedFrame whose Frame has been removed.
The solution proposed is to prevent page-caching if a subframe is in
provisional load stage.
Test: http/tests/navigation/page-cache-iframe-provisional-load.html
* history/PageCache.cpp:
(WebCore::logCanCacheFrameDecision):
(WebCore::PageCache::canCachePageContainingThisFrame):
* page/DiagnosticLoggingKeys.cpp:
(WebCore::DiagnosticLoggingKeys::provisionalLoadKey):
* page/DiagnosticLoggingKeys.h:
LayoutTests:
Add layout test to cover the case where a subframe is currently in
provisional load stage when checking if the page if page-cacheable.
The test also removes the iframe once loaded in order to cause a crash
if the frame were to finish loading while in the page cache.
* http/tests/navigation/page-cache-iframe-provisional-load-expected.txt: Added.
* http/tests/navigation/page-cache-iframe-provisional-load.html: Added.
* http/tests/navigation/resources/page-cache-helper-slow.html: Added.
Commit: d83a0d70f0f62fb19f90980fa47a65b314a9b718
https://github.com/WebKit/WebKit/commit/d83a0d70f0f62fb19f90980fa47a65b314a9b718
Author: Keith Miller <keith_miller at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WTF/ChangeLog
M Source/WTF/wtf/OSRandomSource.cpp
Log Message:
-----------
Merge r186151 - Errors in read() are not handled in WTF::cryptographicallyRandomValuesFromOS.
https://bugs.webkit.org/show_bug.cgi?id=146473
Patch by Keith Miller <keith_miller at apple.com> on 2015-06-30
Reviewed by Filip Pizlo.
We were not checking if errors occurred in WTF::cryptographicallyRandomValuesFromOS.
We now buffer the data until enough bits of entropy exist to fill the buffer
rather than crash. Additionally, added two crash functions so we can distinguish
between the two reasons why we crashed in traces.
* wtf/OSRandomSource.cpp:
(WTF::crashUnableToOpenFD):
(WTF::crashUnableToReadFromFD):
(WTF::cryptographicallyRandomValuesFromOS):
Commit: 5422ce5a33929c3d3d68efa5756cde3a016122a7
https://github.com/WebKit/WebKit/commit/5422ce5a33929c3d3d68efa5756cde3a016122a7
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/frames/flattening/hittest-iframe-while-style-changes-crash-expected.txt
A LayoutTests/fast/frames/flattening/hittest-iframe-while-style-changes-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
M Source/WebCore/rendering/RenderView.cpp
Log Message:
-----------
Merge r186165 - Frame flattening: Hit-testing an iframe could end up destroying the associated inline tree context.
https://bugs.webkit.org/show_bug.cgi?id=146447
rdar://problem/20613501
Reviewed by Simon Fraser.
This patch ensures that the render tree associated with the document on which
the hit-test is initiated does not get laid out, unless it was directly mutated prior to the hittest.
Hit-test requirements:
1. A clean the render tree before hit-testing gets propagated to the renderers.
Document::updateLayout() ensures it by calling both updateStyleIfNeeded() and layout() not only on the current tree, but also
on the ancestors if needed.
2. No render tree mutation while hit-testing the renderers.
When an iframe is being hit-tested, this hit-test could bubble down to the child frame's render view.
In order to ensure #1, we call Document::updateLayout() on the current (subframe) document.
If updateStyleIfNeeded() mutates the render tree, we mark it dirty for layout(). However frame flattening also
marks the parent renderer (RenderIFrame) dirty.
While calling layout() to clean the current render tree, we end up laying out the parent tree too.
Laying out the parent tree could end up destroying the inline tree context from where the
hittest just bubbled down. (InlineFlowBox -> RenderWidget -> RenderView).
This patch protects the render tree from such unintentional inline tree mutation during hittesting.
After the initial layout we set a layout disallow flag on the frame view to defer subsequent layouts.
This patch only changes behavior when frame flattening is enabled, but in future we may always want to enable this.
Source/WebCore:
Test: fast/frames/flattening/hittest-iframe-while-style-changes-crash.html
* page/FrameView.cpp:
(WebCore::FrameView::layout):
(WebCore::FrameView::startLayoutAtMainFrameViewIfNeeded): Deleted. -> Assertion in no longer valid.
* page/FrameView.h:
* rendering/RenderView.cpp:
(WebCore::FrameFlatteningLayoutDisallower::FrameFlatteningLayoutDisallower):
(WebCore::FrameFlatteningLayoutDisallower::~FrameFlatteningLayoutDisallower):
(WebCore::RenderView::hitTest): Protect the render tree from subsequent layouts.
LayoutTests:
* fast/frames/flattening/hittest-iframe-while-style-changes-crash-expected.txt: Added.
* fast/frames/flattening/hittest-iframe-while-style-changes-crash.html: Added.
Commit: 2f3060bada91d1e42921c71a0777f30e52348b5e
https://github.com/WebKit/WebKit/commit/2f3060bada91d1e42921c71a0777f30e52348b5e
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/misc/mask-image-accept-expected.html
A LayoutTests/http/tests/misc/mask-image-accept.html
M Source/WebCore/ChangeLog
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebCore/loader/cache/CachedResourceRequest.h
M Source/WebCore/loader/cache/CachedSVGDocumentReference.cpp
M Source/WebCore/loader/cache/CachedSVGDocumentReference.h
M Source/WebCore/platform/graphics/MaskImageOperation.cpp
Log Message:
-----------
PNG mask images are loaded with Accept:image/svg+xml
https://bugs.webkit.org/show_bug.cgi?id=146509
Source/WebCore:
rdar://problem/21584740
Reviewed by Simon Fraser.
For some strange reason MaskImageOperation code loads all mask images, including non-SVG ones
using CachedSVGDocument. Resulting bad accept header may cause server to reject the request.
This is far from ideal but as a quick fix we can override the accept header for mask images to
allow any image type.
Test: http/tests/misc/mask-image-accept.html
* loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
* loader/cache/CachedResourceRequest.h:
(WebCore::CachedResourceRequest::acceptOverride):
(WebCore::CachedResourceRequest::setAcceptOverride):
* loader/cache/CachedSVGDocumentReference.cpp:
(WebCore::CachedSVGDocumentReference::load):
* loader/cache/CachedSVGDocumentReference.h:
(WebCore::CachedSVGDocumentReference::loadRequested):
(WebCore::CachedSVGDocumentReference::setAcceptsAnyImageType):
(WebCore::CachedSVGDocumentReference::document):
* platform/graphics/MaskImageOperation.cpp:
(WebCore::MaskImageOperation::ensureCachedSVGDocumentReference):
LayoutTests:
Reviewed by Simon Fraser.
* http/tests/misc/mask-image-accept-expected.html: Added.
* http/tests/misc/mask-image-accept.html: Added.
Commit: 10660360b89c08638015449738b88914791f4d03
https://github.com/WebKit/WebKit/commit/10660360b89c08638015449738b88914791f4d03
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/editing/pasteboard/cjk-line-height-expected.txt
A LayoutTests/editing/pasteboard/cjk-line-height.html
M LayoutTests/editing/pasteboard/simplfiying-markup-should-not-strip-content-expected.txt
M Source/WebCore/ChangeLog
M Source/WebCore/editing/EditingStyle.cpp
Log Message:
-----------
Merge r186191 - REGRESSION (r179168): Characters overlap after resizing the font on the copy-pasted Japanese text
https://bugs.webkit.org/show_bug.cgi?id=146492
Reviewed by Darin Adler.
Source/WebCore:
The bug was caused by WebKit serializing the used line-height size (e.g. 18px) in the copied content
instead of string "normal" and removeStyleFromRulesAndContext failing to strip it down when text with
a font that influences the line height got pasted. This is because the used value of line-height
property of the context and the pasted content doesn't match when the context doesn't use the same font.
Fixed the bug by not considering line-height as a list of editing properties we try to preserve. This is
fine because we don't provide editing operations to directly manipulate line-height.
Test: editing/pasteboard/cjk-line-height.html
* editing/EditingStyle.cpp:
(WebCore::editingProperties): Removed CSSPropertyLineHeight.
LayoutTests:
Added a regression test. Also reverted the bad rebaseline in r179168:
http://trac.webkit.org/changeset/179168/trunk/LayoutTests/editing/pasteboard/simplfiying-markup-should-not-strip-content-expected.txt
* editing/pasteboard/cjk-line-height-expected.txt: Added.
* editing/pasteboard/cjk-line-height.html: Added.
* editing/pasteboard/simplfiying-markup-should-not-strip-content-expected.txt:
Commit: 6045adfb083cff46074b1890fbccc3e05619b225
https://github.com/WebKit/WebKit/commit/6045adfb083cff46074b1890fbccc3e05619b225
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/Allocator.cpp
Log Message:
-----------
Merge r186203 - bmalloc: realloc of an XLarge range can unmap adjacent VM ranges
https://bugs.webkit.org/show_bug.cgi?id=146535
Reviewed by Anders Carlsson.
This bug causes a crash when running fast/css/large-list-of-rules-crash.html
with the fix applied for https://bugs.webkit.org/show_bug.cgi?id=146519.
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::reallocate): Start at object + newSize since starting
at object + oldSize means deleting the adjacent VM range.
Commit: e10d746ef233a73f9f6c1393725a137f9e184879
https://github.com/WebKit/WebKit/commit/e10d746ef233a73f9f6c1393725a137f9e184879
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/PageClientImpl.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBasePrivate.h
Log Message:
-----------
Merge r186333 - [GTK] Accelerated Compositing stops working after a web process crash
https://bugs.webkit.org/show_bug.cgi?id=146508
Reviewed by Martin Robinson.
The problem is that we don't send the window ID again to the new
web process.
* UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::didRelaunchProcess): Call
webkitWebViewBaseDidRelaunchWebProcess().
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseDidRelaunchWebProcess): Set the window ID to
the new drawing area.
* UIProcess/API/gtk/WebKitWebViewBasePrivate.h:
Commit: e97b9dbb554bab9adb75d08a2232cb871c7c4b2a
https://github.com/WebKit/WebKit/commit/e97b9dbb554bab9adb75d08a2232cb871c7c4b2a
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitUIClient.cpp
M Source/WebKit2/UIProcess/gtk/WebInspectorProxyGtk.cpp
Log Message:
-----------
Merge r186225 - [GTK] WebSQL doesn't work because openDatabase always fails with DOM Exception 18
https://bugs.webkit.org/show_bug.cgi?id=146234
Reviewed by Sergio Villar Senin.
Source/WebKit2:
This is because we don't provide any quota, and 0 is used by
default, so there's never enough quota and openDatabase fails. We
should expose this in the API, but for now, we could use a default
quota of 5MB like WTR does.
* UIProcess/API/gtk/WebKitUIClient.cpp: Override
exceededDatabaseQuota and return always the default quota.
* UIProcess/gtk/WebInspectorProxyGtk.cpp:
(WebKit::exceededDatabaseQuota): Return the quota based on the
expected usage and current database usabe like mac does.
(WebKit::WebInspectorProxy::platformCreateInspectorPage): Add
custom UI client to implement exceededDatabaseQuota.
Commit: be2c7fc06df382b2685c5ecdcbe4f72bf789d975
https://github.com/WebKit/WebKit/commit/be2c7fc06df382b2685c5ecdcbe4f72bf789d975
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/SegregatedFreeList.h
M Source/bmalloc/bmalloc/Sizes.h
Log Message:
-----------
Merge r186242 - bmalloc: Shrink the super chunk size
https://bugs.webkit.org/show_bug.cgi?id=146519
Reviewed by Andreas Kling.
We have lots of reports of crashing due to failed VM allocation on iOS.
(This VM limit on iOS is usually 1GB-2GB, and has been as low as 256MB.)
Shrink the super chunk size in case fragmentation is the reason for
VM allocation failure.
This has the downside that >= 2MB allocations will now be super slow,
but they are also super rare (as in never on most websites), so this
is probably an OK tradeoff.
* bmalloc/Sizes.h:
Commit: 4d585f0a3130f2e48954c623bbd5dea2b6a975f0
https://github.com/WebKit/WebKit/commit/4d585f0a3130f2e48954c623bbd5dea2b6a975f0
Author: Mario Sanchez Prada <mario at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/CMakeLists.txt
M Source/WebCore/ChangeLog
Log Message:
-----------
Merge r186263 - Crash on xLarge memory allocation using bmalloc on 32bit systems
https://bugs.webkit.org/show_bug.cgi?id=146440
Reviewed by Gustavo Noronha Silva.
Disable the gcc's -ftree-sra optimization (automatically enabled
with -O1 and higher levels) for WebCore and 32bit Intel architectures,
as that causes the crash in bmalloc when allocating large amounts of
memory from the texture mapper's tiled backing store implementation.
* CMakeLists.txt: Pass -fno-free-sra to gcc on 32bit Intel architectures.
Commit: 6277b35dc3c81e7417348a90b68ada0d8bda1040
https://github.com/WebKit/WebKit/commit/6277b35dc3c81e7417348a90b68ada0d8bda1040
Author: Daniel Bates <dbates at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/fast/canvas/canvas-overloads-drawImage-expected.txt
M LayoutTests/fast/canvas/canvas-overloads-setFillColor-expected.txt
M LayoutTests/fast/canvas/canvas-overloads-setShadow-expected.txt
M LayoutTests/fast/canvas/canvas-overloads-setStrokeColor-expected.txt
M LayoutTests/fast/canvas/script-tests/canvas-overloads-drawImage.js
M LayoutTests/fast/canvas/script-tests/canvas-overloads-setFillColor.js
M LayoutTests/fast/canvas/script-tests/canvas-overloads-setShadow.js
M LayoutTests/fast/canvas/script-tests/canvas-overloads-setStrokeColor.js
M LayoutTests/fast/dom/HTMLSelectElement/add-expected.txt
M LayoutTests/fast/dom/HTMLSelectElement/add.html
M LayoutTests/fast/dom/HTMLSelectElement/options-collection-add-expected.txt
M LayoutTests/fast/dom/HTMLSelectElement/options-collection-add.html
A LayoutTests/fast/dom/HTMLSelectElement/resources/html-select-and-options-collection-utilities.js
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
M Source/WebCore/bindings/scripts/test/JS/JSTestObj.cpp
M Source/WebCore/bindings/scripts/test/JS/JSTestOverloadedConstructors.cpp
M Source/WebCore/bindings/scripts/test/TestObj.idl
M Source/WebCore/bindings/scripts/test/TestOverloadedConstructors.idl
Log Message:
-----------
Merge r186265 - REGRESSION (r178097): JavaScript TypeError after clicking on compose button in Yahoo Mail
https://bugs.webkit.org/show_bug.cgi?id=146515
<rdar://problem/21348421>
Reviewed by Chris Dumez.
Source/WebCore:
Fixes an issue where extra arguments passed to a Web IDL overloaded function, whose implementation
is generated by the bindings generator script, are not ignored as per the note in section "Interface object [[Call]] method"
of the Web IDL spec, <http://www.w3.org/TR/2012/CR-WebIDL-20120419/> (19 April 2012).
Currently for an overloaded function the JavaScript bindings generator script emits code to
throw a TypeError when it cannot find a candidate function that takes the same number of
arguments as passed by a caller. Prior to the change made in bug #139179 (r178097), the
bindings code for HTMLSelectElement.add() was written by hand and ignored extra arguments
that were passed to it. Following this change, the bindings code for HTMLSelectElement.add()
is generated by the bindings generator script. Therefore, we throw a TypeError when Yahoo Mail
calls HTMLSelectElement.add() with extra arguments because the code emitted by the bindings
generator script does not ignore them.
* bindings/scripts/CodeGeneratorJS.pm:
(LengthOfLongestFunctionParameterList): Added. Computes the length of longest overload parameter list.
(GenerateOverloadedFunction): Emit code that ignores more arguments than LengthOfLongestFunctionParameterList().
(GenerateOverloadedConstructorDefinition): Ditto.
* bindings/scripts/test/JS/JSTestObj.cpp:
(WebCore::jsTestObjPrototypeFunctionOverloadedMethod12): Added; expected result for an overloaded
function that takes a variadic number of Blob elements.
(WebCore::jsTestObjPrototypeFunctionOverloadedMethod): Update expected result. The added
if-conditional expression for the IDL declaration overloadedMethod(Blob... blobArgs) is empty
because we do not support overloading of functions with variadic arguments.
(WebCore::jsTestObjConstructorFunctionOverloadedMethod1):
* bindings/scripts/test/JS/JSTestOverloadedConstructors.cpp:
(WebCore::JSTestOverloadedConstructorsConstructor::constructJSTestOverloadedConstructors5): Added; expected
result for an overloaded constructors that takes a variadic number of long arguments.
(WebCore::JSTestOverloadedConstructorsConstructor::constructJSTestOverloadedConstructors): Update expected
result. The added if-conditional expression for the IDL declaration Constructor(long... longArgs) is empty
because we do not support overloading of constructors with variadic arguments.
* bindings/scripts/test/TestObj.idl: Added declaration overloadedMethod(Blob...). Also fixed
typo in license block text.
* bindings/scripts/test/TestOverloadedConstructors.idl: Added declaration Constructor(long... longArgs).
Also fixed typo in license block text.
LayoutTests:
Add new sub-tests to LayoutTests/fast/dom/HTMLSelectElement/{add, options-collection-add}.html,
simplify existing test code, share common code, and update expected results.
Additionally, update results for tests in LayoutTests/fast/canvas now that we ignore extra
arguments passed to a Web IDL overloaded function whose implementation is generated by the
bindings generator script.
* fast/canvas/canvas-overloads-drawImage-expected.txt:
* fast/canvas/canvas-overloads-setFillColor-expected.txt:
* fast/canvas/canvas-overloads-setShadow-expected.txt:
* fast/canvas/canvas-overloads-setStrokeColor-expected.txt:
* fast/canvas/script-tests/canvas-overloads-drawImage.js:
* fast/canvas/script-tests/canvas-overloads-setFillColor.js:
* fast/canvas/script-tests/canvas-overloads-setShadow.js:
* fast/canvas/script-tests/canvas-overloads-setStrokeColor.js:
* fast/dom/HTMLSelectElement/add-expected.txt:
* fast/dom/HTMLSelectElement/add.html:
* fast/dom/HTMLSelectElement/options-collection-add-expected.txt:
* fast/dom/HTMLSelectElement/options-collection-add.html:
* fast/dom/HTMLSelectElement/resources/html-select-and-options-collection-utilities.js: Added.
(createSelectElementWithTestData):
(deepCopy):
(createOption):
(createGroup):
Commit: 24cb3ff3c1754ed5fea31aaaefd91a7a2f3374fa
https://github.com/WebKit/WebKit/commit/24cb3ff3c1754ed5fea31aaaefd91a7a2f3374fa
Author: Kyounga Ra <kyounga at alticast.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ImageLoader.cpp
M Source/WebCore/loader/ImageLoader.h
Log Message:
-----------
Merge r186267 - Memory leak for a protected Element having pending events in ImageLoader.
https://bugs.webkit.org/show_bug.cgi?id=146538
Patch by Kyounga Ra <kyounga at alticast.com> on 2015-07-03
Reviewed by Brady Eidson.
If ImageLoader is destroyed before an active derefElementTimer is fired, protected element's refCount never be zero..
* loader/ImageLoader.cpp:
(WebCore::ImageLoader::~ImageLoader):
(WebCore::ImageLoader::updateFromElement):
(WebCore::ImageLoader::updateRenderer):
(WebCore::ImageLoader::updatedHasPendingEvent):
(WebCore::ImageLoader::timerFired):
* loader/ImageLoader.h:
Commit: e92b828b425a82a025a6dacd65baeaf5f7045b9e
https://github.com/WebKit/WebKit/commit/e92b828b425a82a025a6dacd65baeaf5f7045b9e
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/fast/dom/HTMLSelectElement/add-expected.txt
M LayoutTests/fast/dom/HTMLSelectElement/add.html
M LayoutTests/fast/dom/HTMLSelectElement/options-collection-add-expected.txt
M LayoutTests/fast/dom/HTMLSelectElement/options-collection-add.html
A LayoutTests/http/tests/websocket/tests/hybi/undefined-protocol-expected.txt
A LayoutTests/http/tests/websocket/tests/hybi/undefined-protocol.html
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
M Source/WebCore/bindings/scripts/test/JS/JSTestObj.cpp
M Source/WebCore/bindings/scripts/test/JS/JSTestOverloadedConstructors.cpp
M Source/WebCore/bindings/scripts/test/TestObj.idl
Log Message:
-----------
Merge r186275 - REGRESSION (r178097): HTMLSelectElement.add(option, undefined) prepends option to the list of options; should append to the end of the list of options
https://bugs.webkit.org/show_bug.cgi?id=146566
<rdar://problem/21663919>
Reviewed by Ryosuke Niwa.
Source/WebCore:
HTMLSelectElement.add(X, undefined) is supposed to be equivalent to
HTMLSelectElement.add(X) which should *append* X. The same is true
for HTMLOptionsCollection.add(X, undefined).
However, due to a bug in our bindings generator for overloaded
operations, the actual behavior was not the expected one. The
second overload would be chosen: add(X, index) and undefined would
be converted as 0-index, which would *prepend* X.
This patch fixes the bindings generator so that undefined is allowed
for optional parameters of an overload operation, when doing the
overload resolution.
Tests:
- fast/dom/HTMLSelectElement/add.html
- fast/dom/HTMLSelectElement/options-collection-add.html
- http/tests/websocket/tests/hybi/undefined-protocol.html
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateParametersCheckExpression):
Allow undefined value for optional parameters when doing the overload
resolution.
* bindings/scripts/test/JS/JSTestObj.cpp:
(WebCore::jsTestObjPrototypeFunctionOverloadedMethod):
(WebCore::jsTestObjPrototypeFunctionOverloadedMethodWithOptionalParameter1):
(WebCore::jsTestObjPrototypeFunctionOverloadedMethodWithOptionalParameter2):
(WebCore::jsTestObjPrototypeFunctionOverloadedMethodWithOptionalParameter):
* bindings/scripts/test/JS/JSTestOverloadedConstructors.cpp:
(WebCore::JSTestOverloadedConstructorsConstructor::constructJSTestOverloadedConstructors):
* bindings/scripts/test/TestObj.idl:
Add bindings tests coverage and rebaseline.
LayoutTests:
* fast/dom/HTMLSelectElement/add-expected.txt:
* fast/dom/HTMLSelectElement/add.html:
* fast/dom/HTMLSelectElement/options-collection-add-expected.txt:
* fast/dom/HTMLSelectElement/options-collection-add.html:
Update tests so that calling add(X, undefined) is expected to append X,
not prepend it.
* http/tests/websocket/tests/hybi/undefined-protocol-expected.txt: Added.
* http/tests/websocket/tests/hybi/undefined-protocol.html: Added.
Add test coverage for "new WebSocket(url, undefined)" as WebSocket is
using constructor overloads with optional parameters. Previously, calling
new WebSocket(url, undefined) was equivalent to calling
new WebSocket(url, "undefined") even though it is supposed to be
equivalent to calling new WebSocket(url).
Commit: 724ced4ac27f64f28b60b6eb7389b256dfe7eb1e
https://github.com/WebKit/WebKit/commit/724ced4ac27f64f28b60b6eb7389b256dfe7eb1e
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/history/HistoryItem.cpp
M Source/WebCore/history/HistoryItem.h
M Source/WebCore/loader/HistoryController.cpp
Log Message:
-----------
Merge r186287 - [WK2] WebBackForwardListItems' pageState is not kept up-to-date
https://bugs.webkit.org/show_bug.cgi?id=146614
<rdar://problem/21585268>
Reviewed by Gavin Barraclough.
WebBackForwardListItems' pageState on UIProcess-side were not kept
up-to-date when it was updated on WebContent process side. This meant
that we were losing the scroll position (among other things) when
transferring the session state over from one view to another.
We now call notifyHistoryItemChanged(item) after saving the scroll
position and the view state on the HistoryItem. As a result, the
WebBackForwardListProxy will send the updated pageState to the
UIProcess.
* history/HistoryItem.cpp:
(WebCore::HistoryItem::notifyChanged):
* history/HistoryItem.h:
* loader/HistoryController.cpp:
(WebCore::HistoryController::saveScrollPositionAndViewStateToItem):
Commit: 8532ea3cccbfa56ce249fb664cc734fe409300f1
https://github.com/WebKit/WebKit/commit/8532ea3cccbfa56ce249fb664cc734fe409300f1
Author: Timothy Hatcher <timothy at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/WebInspectorUI.cpp
Log Message:
-----------
Merge r186296 - Crash when closing the web inspector
https://bugs.webkit.org/show_bug.cgi?id=146620
Reviewed by Darin Adler.
* WebProcess/WebPage/WebInspectorUI.cpp:
(WebKit::WebInspectorUI::closeWindow): Null check the connection, like it is
in other places where it is used.
Commit: 341703c5446647084e34e744df241a05bb2c764d
https://github.com/WebKit/WebKit/commit/341703c5446647084e34e744df241a05bb2c764d
Author: Commit Queue <commit-queue at webkit.org>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/gtk/DragAndDropHandler.cpp
Log Message:
-----------
Merge r186360 - Unreviewed, rolling out r185896.
https://bugs.webkit.org/show_bug.cgi?id=146647
Caused by a refcounting error in GTK+; it's actually legal for
the event to be null, just the gi annotations were wrong.
(Requested by mcatanzaro on #webkit).
Reverted changeset:
"[GTK] Crash performing drag-and-drop"
https://bugs.webkit.org/show_bug.cgi?id=146267
http://trac.webkit.org/changeset/185896
Commit: 4a96d86fb289aaa9593fc4d1da7cf16d86a35a87
https://github.com/WebKit/WebKit/commit/4a96d86fb289aaa9593fc4d1da7cf16d86a35a87
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/LayoutState.cpp
M Source/WebCore/rendering/LayoutState.h
Log Message:
-----------
Merge r186366 - Crash: LayoutState root's container is nullptr when the layout root is detached.
https://bugs.webkit.org/show_bug.cgi?id=146646
rdar://problem/21371544
Reviewed by Simon Fraser.
This is a speculative fix to ensure that when the root of the LayoutState is detached
we don't try to access its container (nullptr).
This is related to trac.webkit.org/r185484.
Not reproducible.
* rendering/LayoutState.cpp:
(WebCore::LayoutState::LayoutState):
* rendering/LayoutState.h:
(WebCore::LayoutState::LayoutState): Deleted.
Commit: 82adad60f0bde276141859b9a1aba5a7a443c477
https://github.com/WebKit/WebKit/commit/82adad60f0bde276141859b9a1aba5a7a443c477
Author: Dean Jackson <dino at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
Log Message:
-----------
Merge r186380 - Memory corruption in WebGLRenderingContext::simulateVertexAttrib0
https://bugs.webkit.org/show_bug.cgi?id=146652
<rdar://problem/21567767>
Reviewed by Brent Fulgham.
The expression "(numVertex + 1) * 4 * sizeof(GC3Dfloat)" could potentially
overflow. Make it use checked arithmetic.
I couldn't make a test case that reliably exercised this.
* html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::simulateVertexAttrib0): Used Checked<GC3Dsizeiptr>
for calculating the size of the buffer.
Commit: 9bee7960e6276092ab6ced43ff47fecaef5f1614
https://github.com/WebKit/WebKit/commit/9bee7960e6276092ab6ced43ff47fecaef5f1614
Author: Dean Jackson <dino at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
Log Message:
-----------
Merge r186384 - Memory corruption in WebGLRenderingContext::simulateVertexAttrib0
https://bugs.webkit.org/show_bug.cgi?id=146652
<rdar://problem/21567767>
Follow-up fix.
* html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::simulateVertexAttrib0):
Commit: cb5d589ebbbe184b2f33b8ec590cf45ca945e410
https://github.com/WebKit/WebKit/commit/cb5d589ebbbe184b2f33b8ec590cf45ca945e410
Author: Andreas Kling <akling at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/editing/style/change-text-direction-crash-expected.txt
A LayoutTests/editing/style/change-text-direction-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/editing/ApplyStyleCommand.cpp
Log Message:
-----------
Merge r186393 - Crash when setting text direction via MakeTextWritingDirection* editing commands.
<https://webkit.org/b/146665>
<rdar://problem/20835477>
Reviewed by Ryosuke Niwa.
Source/WebCore:
Fix two buggy clients of enclosingBlock(node) that would fail if the returned
element is the same as the node passed in.
Test: editing/style/change-text-direction-crash.html
* editing/ApplyStyleCommand.cpp:
(WebCore::ApplyStyleCommand::splitAncestorsWithUnicodeBidi):
(WebCore::ApplyStyleCommand::removeEmbeddingUpToEnclosingBlock):
LayoutTests:
Add a test that covers some very simple MakeTextWritingDirection* command usage.
* editing/style/change-text-direction-crash-expected.txt: Added.
* editing/style/change-text-direction-crash.html: Added.
Commit: 0afa16c80b082f5bd649d6fd921178ca6045e343
https://github.com/WebKit/WebKit/commit/0afa16c80b082f5bd649d6fd921178ca6045e343
Author: Basile Clement <basile_clement at apple.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
A Source/JavaScriptCore/tests/stress/math-abs-positive.js
Log Message:
-----------
Merge r183692 - Math.abs() returns negative
https://bugs.webkit.org/show_bug.cgi?id=137827
Reviewed by Michael Saboff.
Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
identity function.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* tests/stress/math-abs-positive.js: Added, was previously failing.
(foo):
Commit: 51036352a2eccc0d8841be91006b815b80b2519d
https://github.com/WebKit/WebKit/commit/51036352a2eccc0d8841be91006b815b80b2519d
Author: Philip Chimento <philip.chimento at gmail.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/cairo/DrawingBufferCairo.cpp
Log Message:
-----------
[GTK] DrawingBuffer.h used outside of include guard
https://bugs.webkit.org/show_bug.cgi?id=144559
Patch by Philip Chimento <philip.chimento at gmail.com> on 2015-05-07
Reviewed by Carlos Garcia Campos.
* platform/graphics/cairo/DrawingBufferCairo.cpp: A header was
improperly included outside of an include guard, causing a build
failure with a particular combination of options.
Commit: a810bd402e6f9597b254387093730ed69c920643
https://github.com/WebKit/WebKit/commit/a810bd402e6f9597b254387093730ed69c920643
Author: Carlos Alberto Lopez Perez <clopez at igalia.com>
Date: 2015-07-07 (Tue, 07 Jul 2015)
Changed paths:
M ChangeLog
M Source/WebCore/CMakeLists.txt
M Source/WebCore/ChangeLog
M Source/WebCore/PlatformGTK.cmake
M Source/cmake/FindEGL.cmake
R Source/cmake/FindGLES.cmake
A Source/cmake/FindOpenGL.cmake
M Source/cmake/FindOpenGLES2.cmake
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r184954 - [CMake] Improve detection and usage of GL/GLES/EGL libraries.
https://bugs.webkit.org/show_bug.cgi?id=145408
Reviewed by Carlos Garcia Campos.
.:
* Source/cmake/FindEGL.cmake: Improve detection of EGL libraries.
* Source/cmake/FindGLES.cmake: Removed. It was used by the EGL port.
Remove it and make the EGL port use the improved FindOpenGLES2.cmake
instead.
* Source/cmake/FindOpenGL.cmake: Added. Add module to detect OpenGL
libraries. Detect also GLX libraries.
* Source/cmake/FindOpenGLES2.cmake: Improve detection of OpenGLES-v2
libraries. Use find_path() to get the include path.
* Source/cmake/OptionsEfl.cmake: Use now the improved FindOpenGLES2
module.
* Source/cmake/OptionsGTK.cmake: Set default value for ENABLE_GLES2
depending on the libraries found on the system.
Move the detection of GLX (and the include of CMakePushCheckState)
to FindOpenGL.cmake.
Ensure that we only define USE_GLX when we build with OpenGL
(but not with GLESv2).
Source/WebCore:
No new tests, no behavior changes.
* CMakeLists.txt: Ensure that we include the libraries and includes
for the GL/GLESv2/EGL libraries before including the ANGLE directories.
Define also any CFLAG that the system GL/GLESv2/EGL libraries may need.
* PlatformEfl.cmake: Remove some includes that are now unneeded,
because we are including now the EGL libraries on CMakeLists.txt
* PlatformGTK.cmake: Remove unneeded include (We are including the EGL
libraries now on CMakeLists.txt)
Commit: bc4b3ad0b36c7c0f397cc46a69c5082ed0396810
https://github.com/WebKit/WebKit/commit/bc4b3ad0b36c7c0f397cc46a69c5082ed0396810
Author: Andreas Kling <akling at apple.com>
Date: 2015-07-08 (Wed, 08 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dom/HTMLImageElement/remove-img-with-name-from-document-crash-expected.txt
A LayoutTests/fast/dom/HTMLImageElement/remove-img-with-name-from-document-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLImageElement.cpp
M Source/WebCore/html/HTMLImageElement.h
Log Message:
-----------
Merge r186461 - REGRESSION(r183706): HTMLImageElement sometimes fails to register as document named item.
<https://webkit.org/b/146679>
<rdar://problem/21613839>
Reviewed by Antti Koivisto.
Source/WebCore:
After r183706, Element::hasName() no longer returns outdated information when called
inside a parseAttribute() override. HTMLImageElement was relying on this to check
if it *used* to have a name attribute before the currently parsing one was set.
Since parseAttribute() only shows subclasses the new attribute value, I'm adding a
flag to HTMLImageElement that remembers whether we had a name attribute or not.
Test: fast/dom/HTMLImageElement/remove-img-with-name-from-document-crash.html
* html/HTMLImageElement.cpp:
(WebCore::HTMLImageElement::parseAttribute):
* html/HTMLImageElement.h:
LayoutTests:
Add a test that would assert when removing a named HTMLImageElement from the DOM
after having failed to register it as a document named item.
* fast/dom/HTMLImageElement/remove-img-with-name-from-document-crash-expected.txt: Added.
* fast/dom/HTMLImageElement/remove-img-with-name-from-document-crash.html: Added.
Commit: f0b4c4ad8078b2a8f9eb7d531ff373c18e027658
https://github.com/WebKit/WebKit/commit/f0b4c4ad8078b2a8f9eb7d531ff373c18e027658
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-07-08 (Wed, 08 Jul 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/frames/crash-display-none-iframe-during-onbeforeload-expected.txt
A LayoutTests/fast/frames/crash-display-none-iframe-during-onbeforeload.html
A LayoutTests/fast/frames/resources/displaynone-this-during-object-beforeload.html
M Source/WebCore/ChangeLog
M Source/WebCore/page/FrameView.cpp
Log Message:
-----------
Merge r186486 - Crash when parent iframe is set to display none and the child frame is mutated the same time.
https://bugs.webkit.org/show_bug.cgi?id=146699
rdar://problem/16207881
Reviewed by Andreas Kling.
When the parent iframe is set to display: none, we destroy the associated renderer (RenderIFrame).
However if the child frame is mutated the same time, during layout we try to access this RenderIFrame
to check whether it needs frame flattening.
This patch checks whether the parent render widget is still valid.
Source/WebCore:
Test: fast/frames/crash-display-none-iframe-during-onbeforeload.html
* page/FrameView.cpp:
(WebCore::FrameView::isInChildFrameWithFrameFlattening): rearrange early returns.
LayoutTests:
* fast/frames/crash-display-none-iframe-during-onbeforeload-expected.txt: Added.
* fast/frames/crash-display-none-iframe-during-onbeforeload.html: Added.
* fast/frames/resources/displaynone-this-during-object-beforeload.html: Added.
Commit: 4ac097f69be9072c4cac79e34fe67817bc7acf55
https://github.com/WebKit/WebKit/commit/4ac097f69be9072c4cac79e34fe67817bc7acf55
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-07-08 (Wed, 08 Jul 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.8.4 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.8.4.
Commit: 3c3a66874600c92cd808d0a3da87d77e1060bbb9
https://github.com/WebKit/WebKit/commit/3c3a66874600c92cd808d0a3da87d77e1060bbb9
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/animations/insert-animate-use-path-while-animation-expected.txt
A LayoutTests/svg/animations/insert-animate-use-path-while-animation.svg
M Source/WebCore/ChangeLog
M Source/WebCore/svg/SVGAnimatedPath.cpp
M Source/WebCore/svg/SVGAnimatedPath.h
Log Message:
-----------
Merge r186541 - Crash when appending an SVG <use> element dynamically which has animated SVG <path> element
https://bugs.webkit.org/show_bug.cgi?id=146690
<rdar://problem/20790376>
Patch by Said Abou-Hallawa <sabouhallawa at apple.com> on 2015-07-08
Reviewed by Dean Jackson.
Source/WebCore:
Test: svg/animations/insert-animate-use-path-while-animation.svg
The crashing call stack shows that
SVGAnimatedListPropertyTearOff<SVGPathSegList>::m_animVal is null when
trying to access it in synchronizeWrappersIfNeeded(). This happens because
animationStarted() was not called for this animatedType.
SVGAnimateElementBase::resetAnimatedType() calls
SVGAnimatedPathAnimator::startAnimValAnimation() at the beginning of the
animation. For the target element and all its instances, this function calls
SVGAnimatedPathSegListPropertyTearOff::animationStarted() which calls
SVGAnimatedListPropertyTearOff<SVGPathSegList>::animationStarted(). This
last function allocates the member m_animVal when calling
SVGAnimatedListPropertyTearOff<SVGPathSegList>::animVal().
When adding a new instance of the same animating target element,
SVGAnimateElementBase::resetAnimatedType() just keeps calling
SVGAnimatedPathAnimator::animValDidChange() for all the instances of the
targetElement without ensuring that all of them have started their
animations.
The fix is to make SVGAnimatedPathAnimator::resetAnimValToBaseVal() ensure
that animationStarted() is called for the targetElement and all its instances.
* svg/SVGAnimatedPath.cpp:
(WebCore::SVGAnimatedPathAnimator::startAnimValAnimation): Move resetting
the animation value and starting the animatedTypes code to a new overriding
function which is named resetAnimValToBaseVal().
(WebCore::SVGAnimatedPathAnimator::resetAnimValToBaseVal): Call the overriding
function which calls buildSVGPathByteStreamFromSVGPathSegList() as before
and ensure that all the animatedTypes have started their animations.
* svg/SVGAnimatedPath.h:
LayoutTests:
When adding dynamically a new <use> element which references an animated
SVG path after the animation starts, ensure that WebKit is not crashing.
* svg/animations/insert-animate-use-path-while-animation-expected.txt: Added.
* svg/animations/insert-animate-use-path-while-animation.svg: Added.
Commit: fcde2ceb39caf250e1c7bfcdcbe2f2ad49c2402b
https://github.com/WebKit/WebKit/commit/fcde2ceb39caf250e1c7bfcdcbe2f2ad49c2402b
Author: Hyungwook Lee <hyungwook.lee at navercorp.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2/PageLoadBasic.cpp
Log Message:
-----------
Merge r186570 - Fix ASSERTION FAILED: !m_pendingNavigationID in WebPage::reload().
https://bugs.webkit.org/show_bug.cgi?id=146546
Patch by Hyungwook Lee <hyungwook.lee at navercorp.com> on 2015-07-08
Reviewed by Darin Adler.
We did't reset pendingNavigationID value when request url is empty.
Hence we need to ignore ASSERT check in this case.
Source/WebKit2:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::reload):
Tools:
* TestWebKitAPI/Tests/WebKit2/PageLoadBasic.cpp:
(TestWebKitAPI::TEST):
Commit: e9772a42cf2807a01e28969a70ad55c9939d9758
https://github.com/WebKit/WebKit/commit/e9772a42cf2807a01e28969a70ad55c9939d9758
Author: Sungmann Cho <sungmann.cho at navercorp.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/gtk/MIMETypeRegistryGtk.cpp
Log Message:
-----------
Merge r186581 - [GTK] The "Missing Plug-in" buttons are not showing up on some flash contents.
https://bugs.webkit.org/show_bug.cgi?id=146707
Patch by Sungmann Cho <sungmann.cho at navercorp.com> on 2015-07-08
Reviewed by Martin Robinson.
Currently, WebKitGTK+ doesn't show the "Missing Plug-in" buttons if the plugin-related tags
don't have a "type" attribute. In such a case, WebCore tries to guess the MIME type from
the extensions by using MIMETypeRegistry::getMIMETypeForExtension(). For WebKitGTK+,
MIMETypeRegistry::getMIMETypeForExtension() goes through |extensionMap|, which is a simple
array of <extension, mime type>, looking for the mime type for the given extension.
But |extensionMap| in MIMETypeRegistryGtk.cpp doesn't have the information for ".swf",
so WebCore fails to guess the MIME type and regard the content type as ObjectContentFrame,
not ObjectContentNetscapePlugin.
* platform/gtk/MIMETypeRegistryGtk.cpp:
Commit: 9d4b8abedee85179ecb01e6d17ee952a1c36f837
https://github.com/WebKit/WebKit/commit/9d4b8abedee85179ecb01e6d17ee952a1c36f837
Author: Darin Adler <darin at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ThreadableLoader.cpp
M Source/WebCore/loader/ThreadableLoader.h
Log Message:
-----------
Merge r186592 - REGRESSION (r182866): repeated prompts for password on internal Apple website using workers
https://bugs.webkit.org/show_bug.cgi?id=146769
Reviewed by Sam Weinig.
Not sure how to make a regression test for this. Sure would be nice to have one though.
* loader/ThreadableLoader.cpp:
(WebCore::ThreadableLoaderOptions::ThreadableLoaderOptions): Added. Calls through to the
base class copy constructor to copy data members of the base class (the lack of this was
the bug). Also initializes all the data members of this class.
(WebCore::ThreadableLoaderOptions::isolatedCopy): Changed to call the constructor above.
* loader/ThreadableLoader.h: Added new constructor.
Commit: bf65cd3f6c83e2f6c32431a69e755152d7c245ef
https://github.com/WebKit/WebKit/commit/bf65cd3f6c83e2f6c32431a69e755152d7c245ef
Author: Michael Saboff <msaboff at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/http/tests/misc/large-js-program-expected.txt
A LayoutTests/http/tests/misc/large-js-program.php
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
Log Message:
-----------
Merge r186606 - REGRESSION (r180248): Repro Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::createRangeError + 20
https://bugs.webkit.org/show_bug.cgi?id=146767
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
If the stack check fails at the top most frame, we must use that frame to
generate the exception. Reverted the code to always use the current frame to
throw an out of stack exception.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
LayoutTests:
New test that generates a call to a function that involves creating a huge
object literal that exceeds the available stack space.
* http/tests/misc/large-js-program-expected.txt: Added.
* http/tests/misc/large-js-program.php: Added.
Commit: ded6a4f7763aaca6cd028141d878a335d6922bcb
https://github.com/WebKit/WebKit/commit/ded6a4f7763aaca6cd028141d878a335d6922bcb
Author: Brady Eidson <beidson at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/DocumentLoader.h
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Merge r186642, r186677 - DocumentLoader::detachFromFrame() is being called with no current Frame set.
<rdar://problem/21293082> and https://bugs.webkit.org/show_bug.cgi?id=146786
Reviewed by Sam Weinig.
No new tests (Unknown how to reproduce).
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::attachToFrame):
(WebCore::DocumentLoader::detachFromFrame): Null check m_frame before dereferencing it.
(WebCore::DocumentLoader::setFrame): Deleted, renamed to attachToFrame(), and take's
a Frame& instead of a Frame*.
* loader/DocumentLoader.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::initForSynthesizedDocument): setFrame is now attachToFrame.
(WebCore::FrameLoader::setPolicyDocumentLoader): Ditto.
(WebCore::FrameLoader::transitionToCommitted): Ditto.
ASSERT restoring from page cache as DocumentLoader reattaches to its Frame.
<rdar://problem/21766282> and https://bugs.webkit.org/show_bug.cgi?id=146786
Reviewed by NOBODY (Fixing obvious boneheaded mistake in r186642)
No new tests (Covered by existing)
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::attachToFrame): Bail if reattaching to the current Frame,
which happens when restoring from the page cache.
Commit: 95ed84d5ce53cf000c67918a2de2c5e157bb37d0
https://github.com/WebKit/WebKit/commit/95ed84d5ce53cf000c67918a2de2c5e157bb37d0
Author: Michael Catanzaro <mcatanzaro at gnome.org>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitContextMenuActions.cpp
Log Message:
-----------
Merge r186653 - [GTK] Crash when spell checker returns no guesses
https://bugs.webkit.org/show_bug.cgi?id=146805
Reviewed by Martin Robinson.
Properly handle ContextMenuItemTagNoGuessesFound in the switch statement.
* UIProcess/API/gtk/WebKitContextMenuActions.cpp:
(webkitContextMenuActionGetForContextMenuItem):
Commit: 689d979176e8cd91ebbecbd46797fef96893bc3d
https://github.com/WebKit/WebKit/commit/689d979176e8cd91ebbecbd46797fef96893bc3d
Author: Daniel Bates <dbates at webkit.org>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/http/tests/cookies/resources/setCookies.cgi
A LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-expected.txt
A LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-enabled-expected.txt
A LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-enabled.html
A LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-toggled-expected.txt
A LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-toggled.html
A LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies.html
A LayoutTests/http/tests/security/contentSecurityPolicy/report-same-origin-no-cookies-when-private-browsing-toggled-expected.txt
A LayoutTests/http/tests/security/contentSecurityPolicy/report-same-origin-no-cookies-when-private-browsing-toggled.html
A LayoutTests/http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-expected.txt
A LayoutTests/http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-when-private-browsing-enabled-expected.txt
A LayoutTests/http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-when-private-browsing-enabled.html
A LayoutTests/http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies.html
M LayoutTests/http/tests/security/contentSecurityPolicy/resources/save-report.php
M Source/WebCore/ChangeLog
M Source/WebCore/loader/PingLoader.cpp
Log Message:
-----------
Merge r186663 - Fetching Content Security Policy report URL should respect same origin policy
https://bugs.webkit.org/show_bug.cgi?id=146754
<rdar://problem/18860259>
Reviewed by Brady Eidson.
Inspired by Blink r149791 (by Mike West <mkwst at chromium.org>):
<https://src.chromium.org/viewvc/blink?revision=149791&view=revision>
Source/WebCore:
As per <http://www.w3.org/TR/2015/CR-CSP2-20150219/#send-violation-reports>, fetching the
Content Security Policy report URL should include cookies if and only if the origin of
the protected resource is equal to the origin of the report URL.
Tests: http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-enabled.html
http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-toggled.html
http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies.html
http/tests/security/contentSecurityPolicy/report-same-origin-no-cookies-when-private-browsing-toggled.html
http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-when-private-browsing-enabled.html
http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies.html
* loader/PingLoader.cpp:
(WebCore::PingLoader::sendViolationReport):
LayoutTests:
Added additional tests for private browsing mode.
* http/tests/cookies/resources/setCookies.cgi:
* http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-enabled-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-enabled.html: Added.
* http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-toggled-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies-when-private-browsing-toggled.html: Added.
* http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies.html: Added.
* http/tests/security/contentSecurityPolicy/report-same-origin-no-cookies-when-private-browsing-toggled-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-same-origin-no-cookies-when-private-browsing-toggled.html: Added.
* http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-when-private-browsing-enabled-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies-when-private-browsing-enabled.html: Added.
* http/tests/security/contentSecurityPolicy/report-same-origin-with-cookies.html: Added.
* http/tests/security/contentSecurityPolicy/resources/save-report.php:
* platform/wk2/TestExpectations: Skip private browsing mode tests in WebKit2 until we fix <https://bugs.webkit.org/show_bug.cgi?id=115274>.
Commit: 4bc8b5800a44297a8f0c40aa4131a508a4afdcdb
https://github.com/WebKit/WebKit/commit/4bc8b5800a44297a8f0c40aa4131a508a4afdcdb
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/SubframeLoader.cpp
Log Message:
-----------
Merge r186666 - Plugin create can end up destroying its renderer.
https://bugs.webkit.org/show_bug.cgi?id=146824
rdar://problem/18921429
Reviewed by Andreas Kling.
Plugins can run arbitrary code during initialization. If the plugin
happens to destroy the associated node, its renderer becomes invalid.
This patch checks whether the renderer survived the createPlugin() call.
(This WeakPtr pattern is also used in RenderWidget to avoid dangling pointers.)
Speculative fix. Not reproducible.
* loader/SubframeLoader.cpp:
(WebCore::SubframeLoader::loadPlugin):
Commit: 41bc8d8ad2a28282e71b9d6a8e9e40dd4056a202
https://github.com/WebKit/WebKit/commit/41bc8d8ad2a28282e71b9d6a8e9e40dd4056a202
Author: Josef Andersson <josef.andersson at fripost.org>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/platform/gtk/po/ChangeLog
M Source/WebCore/platform/gtk/po/sv.po
Log Message:
-----------
Merge r186669, r187157 - Updated Swedish translation for WebKitGTK+
https://bugs.webkit.org/show_bug.cgi?id=146596
Patch by Josef Andersson <josef.andersson at fripost.org> on 2015-07-10
Reviewed by Carlos Garcia Campos.
* sv.po:
[l10n] Updated Swedish translation
https://bugs.webkit.org/show_bug.cgi?id=147190
Patch by Josef Andersson <josef.andersson at fripost.org> on 2015-07-22
* sv.po:
Commit: 9001bdd2a89fb68b6e0cb5eb98cfa4edf15c44e7
https://github.com/WebKit/WebKit/commit/9001bdd2a89fb68b6e0cb5eb98cfa4edf15c44e7
Author: Brady Eidson <beidson at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/HistoryController.cpp
M Source/WebCore/loader/HistoryController.h
Log Message:
-----------
Merge r186683 - Crash in HistoryController::updateForCommit dereferencing a null HistoryItem.
<rdar://problem/21371589> and https://bugs.webkit.org/show_bug.cgi?id=146842
Reviewed by Chris Dumez.
No new tests (Unknown how to reproduce).
This patch basically rolls back part of http://trac.webkit.org/changeset/179472.
r179472 changed HistoryController::setCurrentItem() to take a reference instead of a pointer.
Unfortunately, we sometimes call setCurrentItem(nullptr).
We'd like to *not* do that, and there are assertions in place to try to catch when we do,
but in the meantime it is not valid to dereference nullptr.
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadSameDocumentItem):
* loader/HistoryController.cpp:
(WebCore::HistoryController::updateForCommit):
(WebCore::HistoryController::recursiveUpdateForCommit):
(WebCore::HistoryController::recursiveUpdateForSameDocumentNavigation):
(WebCore::HistoryController::setCurrentItem): Take a ptr instead of a ref.
(WebCore::HistoryController::createItem):
* loader/HistoryController.h:
Commit: b5b3d4d717b0c456f737597d583a2216af37e982
https://github.com/WebKit/WebKit/commit/b5b3d4d717b0c456f737597d583a2216af37e982
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/PageClientImpl.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
Log Message:
-----------
Merge r186761 - [GTK] Contents not correctly laid out when the web view is not realized
https://bugs.webkit.org/show_bug.cgi?id=142532
Reviewed by Darin Adler.
The problem is that we are not reporting any size until the web
view is realized, so any web view loaded in a separate tab in the
browser, will report 0x0 as the window.innerWidth,
window.innerHeight until the view is realized. Websites that use
the window.innerWidth/innerHeight during the page load to decide
how to lay out the contents will be rendered wrongly.
I haven't been able to reproduce this with unit tests, as this
requires the particular case of same window but different web
views using tabs for example.
* UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::viewSize): Always report the drawing area
size to make usre it's in sync with the WebProcess page size.
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseSizeAllocate): Remove the optimization of only
report the size when it has changed, since both the redirected
window and the drawing area already do that check. Also remove the
optimization of waiting until the view is mapped to report its
size, since that's often too late for websites using the window
size during load.
(webkitWebViewBaseMap): Never report size on map, it should have
already been reported by size-allocate.
Commit: b739af3aaa77843c76a81aeb979a78cac1f54e01
https://github.com/WebKit/WebKit/commit/b739af3aaa77843c76a81aeb979a78cac1f54e01
Author: Andreas Kling <akling at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/HistoryController.cpp
Log Message:
-----------
Merge r186828 - Don't persist history item tree for subframes across reloads.
<https://webkit.org/b/146937>
<rdar://problem/19925709>
Reviewed by Brady Eidson.
Throw away the subframe history items when reloading a page. This ensures that we
don't accumulate outdated frame metadata when subframes change name across page loads.
Since the history item tree is encoded in the UA session state and gets serialized to
disk, it's important that we don't let it grow unbounded.
* loader/HistoryController.cpp:
(WebCore::HistoryController::updateForReload):
Commit: 2fb79f1ddde56eb14aff1582ad1e2bf46c53280d
https://github.com/WebKit/WebKit/commit/2fb79f1ddde56eb14aff1582ad1e2bf46c53280d
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/compositing/fixed-with-fixed-layout-expected.txt
A LayoutTests/compositing/fixed-with-fixed-layout.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Merge r186911 - Fix disappearing position:fixed elements in fixed layout mode
https://bugs.webkit.org/show_bug.cgi?id=147019
Reviewed by Tim Horton.
Source/WebCore:
Test: compositing/fixed-with-fixed-layout.html
When in fixed layout mode, and being scaled down, viewportConstrainedVisibleContentRect() is
the wrong thing to use to determine if position:fixed elements are clipped out. In this case,
use the simpler document bounds (before scaling).
In the long term, there needs to be an equivalent of viewportConstrainedVisibleContentRect()
that gives an appropriate rect that can be used here.
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresCompositingForPosition):
LayoutTests:
Test with four fixed elements in fixed layout mode.
* compositing/fixed-with-fixed-layout-expected.txt: Added.
* compositing/fixed-with-fixed-layout.html: Added.
Commit: 73879625ae6253161ed02869d08dcffd2271e9f8
https://github.com/WebKit/WebKit/commit/73879625ae6253161ed02869d08dcffd2271e9f8
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/gtk/PasteboardGtk.cpp
M Source/WebCore/platform/gtk/PasteboardHelper.cpp
M Source/WebCore/platform/gtk/PasteboardHelper.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp
M Source/WebKit2/UIProcess/gtk/DragAndDropHandler.cpp
Log Message:
-----------
Merge r186954 - [GTK] Cleanup PasteboardHelper
https://bugs.webkit.org/show_bug.cgi?id=147035
Reviewed by Žan Doberšek.
Source/WebCore:
It's actually a singleton, but the API suggests you can create
your own or use the default one, but the default one should be the
only one. Rename PasteboardHelper::defaultPasteboardHelper() as
PasteboardHelper::singleton() and make it non-copyable and never
destroyed.
* platform/gtk/PasteboardGtk.cpp:
(WebCore::Pasteboard::writePlainText): Use PasteboardHelper::singleton().
(WebCore::Pasteboard::write): Ditto.
(WebCore::Pasteboard::writePasteboard): Ditto.
(WebCore::Pasteboard::clear): Ditto.
(WebCore::Pasteboard::canSmartReplace): Ditto.
(WebCore::Pasteboard::read): Ditto.
(WebCore::Pasteboard::hasData): Ditto.
(WebCore::Pasteboard::types): Ditto.
(WebCore::Pasteboard::readString): Ditto.
(WebCore::Pasteboard::readFilenames): Ditto.
* platform/gtk/PasteboardHelper.cpp:
(WebCore::PasteboardHelper::singleton): Renamed as singleton, also
use NeverDestroyed and return a reference instead of a pointer.
(WebCore::PasteboardHelper::PasteboardHelper): Do all
initializations here and remove the initialization static flag,
since this is a real singleton now. Also use
gdk_atom_intern_static_string() to initialize the atoms instead of
gdk_atom_intern().
(WebCore::PasteboardHelper::targetList):
(WebCore::PasteboardHelper::targetListForDataObject):
(WebCore::getClipboardContentsCallback):
* platform/gtk/PasteboardHelper.h:
Source/WebKit2:
Use PasteboardHelper::singleton() instead of
PasteboardHelper::defaultPasteboardHelper().
* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseConstructed):
* UIProcess/gtk/DragAndDropHandler.cpp:
(WebKit::DragAndDropHandler::startDrag):
(WebKit::DragAndDropHandler::fillDragData):
(WebKit::DragAndDropHandler::dataObjectForDropData):
(WebKit::DragAndDropHandler::requestDragData):
Commit: 9adfdcc9560fd679d3f3bcf09a74c2758d7baa0c
https://github.com/WebKit/WebKit/commit/9adfdcc9560fd679d3f3bcf09a74c2758d7baa0c
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/gtk/PasteboardGtk.cpp
M Source/WebCore/platform/gtk/PasteboardHelper.cpp
M Source/WebCore/platform/gtk/PasteboardHelper.h
Log Message:
-----------
Merge r187580 - [GTK] Paste data is removed from clipboard when closing browser tab
https://bugs.webkit.org/show_bug.cgi?id=144549
Reviewed by Martin Robinson.
GTK+ stores all clipboards in gtk_main or gtk_application_shutdown
when the main loop finishes. We don't use gtk_main() in the web
process, so we need to do the same and store all clipboards on
process shutdown.
* platform/gtk/PasteboardGtk.cpp:
(WebCore::Pasteboard::Pasteboard): Register the GtkClipboard.
* platform/gtk/PasteboardHelper.cpp:
(WebCore::PasteboardHelper::singleton): Make it destructible.
(WebCore::PasteboardHelper::~PasteboardHelper): Call
gtk_clipboard_store for every registered GtkClipboard.
(WebCore::PasteboardHelper::registerClipboard): Save the given
GtkClipboard.
* platform/gtk/PasteboardHelper.h:
Commit: 7c167b6bcc1a8c6282d60d07581c2e7a80796993
https://github.com/WebKit/WebKit/commit/7c167b6bcc1a8c6282d60d07581c2e7a80796993
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/text/crash-font-family-parsed-expected.txt
A LayoutTests/fast/text/crash-font-family-parsed.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/StyleResolver.cpp
Log Message:
-----------
Merge r186971 - style.fontFamily accessor crashes on unstyled node created from DOMParser().parseFromString()
https://bugs.webkit.org/show_bug.cgi?id=147026
<rdar://problem/21864487>
Reviewed by Andreas Kling.
Source/WebCore:
Font CSS properties are a little special because they are used as indices into caches.
Normally, StyleResolver gives all nodes a default font family, so our cache works correctly.
However, if the document doesn't have a Settings object, StyleResolver wasn't doing this.
Documents created from DOMParser().parseFromString() don't have a Settings object.
Test: fast/text/crash-font-family-parsed.html
* css/StyleResolver.cpp:
(WebCore::StyleResolver::defaultStyleForElement):
(WebCore::StyleResolver::initializeFontStyle): Set a font family even if we don't have a
Settings object.
LayoutTests:
* fast/text/crash-font-family-parsed-expected.txt: Added.
* fast/text/crash-font-family-parsed.html: Added.
Commit: 9b6dbb1e57c9360b5bf586f66cb39da0cc2ca2ce
https://github.com/WebKit/WebKit/commit/9b6dbb1e57c9360b5bf586f66cb39da0cc2ca2ce
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/repaint/block-inputrange-repaint-expected.txt
A LayoutTests/fast/repaint/block-inputrange-repaint.html
M Source/WebCore/ChangeLog
M Source/WebCore/html/shadow/SliderThumbElement.cpp
Log Message:
-----------
Merge r186981 - (display: block)input range's thumb disappears when moved.
https://bugs.webkit.org/show_bug.cgi?id=146896
<rdar://problem/21787807>
Reviewed by Simon Fraser.
Since the thumb is positioned after the layout for the input (shadow) subtree is finished, the repaint rects
issued during the layout will not cover the re-positioned thumb.
We need to issue a repaint soon after the thumb is re-positioned.
Source/WebCore:
Test: fast/repaint/block-inputrange-repaint.html
* html/shadow/SliderThumbElement.cpp:
(WebCore::RenderSliderContainer::layout):
LayoutTests:
* fast/repaint/block-inputrange-repaint-expected.txt: Added.
* fast/repaint/block-inputrange-repaint.html: Added.
Commit: 7bba30d37b00704137d64b51e04df372ef9ef547
https://github.com/WebKit/WebKit/commit/7bba30d37b00704137d64b51e04df372ef9ef547
Author: Alan Bujtas <zalan at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees2-expected.txt
A LayoutTests/fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees2.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderView.cpp
Log Message:
-----------
Merge r186984 - REGRESSION (r169105): Do not assign a renderer to multiple selection subtrees.
https://bugs.webkit.org/show_bug.cgi?id=147038
rdar://problem/21819351
Reviewed by David Kilzer.
A renderer should never be assigned to multiple selection subtrees. (Currently RenderObject maintains the last selection state.)
RenderView::applySubtreeSelection() loops from the start to the end of the selection to find renderers that are inside the selection.
However, in case of regions (when multiple selection roots are present) traversing the renderer tree by calling RenderObject::nextInPreOrder() could
end up going across selection roots.
This patch ensures that we assign renderers to a specific selection only when the current selection root and the renderer's selection root match.
Source/WebCore:
Test: fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees2.html
* rendering/RenderView.cpp:
(WebCore::SelectionIterator::SelectionIterator):
(WebCore::SelectionIterator::current):
(WebCore::SelectionIterator::checkForSpanner):
(WebCore::RenderView::applySubtreeSelection):
LayoutTests:
* fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees2-expected.txt: Added.
* fast/regions/crash-when-renderer-is-in-multiple-selection-subtrees2.html: Added.
Commit: d96989480e04596a8129b93c8b46f723f8b6f68b
https://github.com/WebKit/WebKit/commit/d96989480e04596a8129b93c8b46f723f8b6f68b
Author: Ting-Wei Lan <lantw44 at gmail.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M ChangeLog
M Source/cmake/OptionsCommon.cmake
Log Message:
-----------
Merge r186987 - Bring back the GNU ar check to create thin archives on non-Linux systems
https://bugs.webkit.org/show_bug.cgi?id=146681
Patch by Ting-Wei Lan <lantw44 at gmail.com> on 2015-07-17
Reviewed by Martin Robinson.
We already use GNU ar thin archive feature to save time and disk space
on creating static archives, but it is only enabled on Linux. Without
this feature, the debug build of WebCore can be larger than 4 GiB,
which can cause error because GNU ar format uses 32-bit integer to
store offsets in the symbol table. This patch is similar to
https://bugs.webkit.org/show_bug.cgi?id=128596.
* Source/cmake/OptionsCommon.cmake:
Commit: 48d47e1506d0a56be197fed4fea024b31063624f
https://github.com/WebKit/WebKit/commit/48d47e1506d0a56be197fed4fea024b31063624f
Author: Jordan Harband <ljharb at gmail.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/js/dom/JSON-stringify-expected.txt
M LayoutTests/js/resources/JSON-stringify.js
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/runtime/DatePrototype.cpp
Log Message:
-----------
Merge r187016 - new Date(NaN).toJSON() must return null instead of throwing a TypeError
https://bugs.webkit.org/show_bug.cgi?id=141115
Patch by Jordan Harband <ljharb at gmail.com> on 2015-07-19
Reviewed by Yusuke Suzuki.
Source/JavaScriptCore:
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToJSON):
LayoutTests:
* js/dom/JSON-stringify-expected.txt:
* js/resources/JSON-stringify.js:
Commit: a9df98a8cc04a0c1bcc047fa0a44097d77b3335f
https://github.com/WebKit/WebKit/commit/a9df98a8cc04a0c1bcc047fa0a44097d77b3335f
Author: Ada Chan <adachan at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/webaudio/AudioContext.cpp
Log Message:
-----------
Merge r187025 - Fix deadlock between -[AVPlayerItem currentTime] and -[AVPlayer isExternalPlaybackActive]
https://bugs.webkit.org/show_bug.cgi?id=147085
<rdar://problem/21878275>
Reviewed by Jer Noble.
* Modules/webaudio/AudioContext.cpp:
(WebCore::AudioContext::isPlayingAudioDidChange):
Call Document::updateIsPlayingMedia() on the main thread, since we could be on the audio I/O
thread here and the Document::updateIsPlayingMedia() call could block, causing a deadlock.
Commit: c45b2f71d1d1ae3154bb71366e6c5d1067031a0b
https://github.com/WebKit/WebKit/commit/c45b2f71d1d1ae3154bb71366e6c5d1067031a0b
Author: Tim Horton <thorton at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderView.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Merge r187039 - REGRESSION (r174287): Flash of black when opening a new web view or navigating to a new page
https://bugs.webkit.org/show_bug.cgi?id=147127
<rdar://problem/21474317>
Reviewed by Simon Fraser.
* rendering/RenderView.cpp:
(WebCore::RenderView::paintBoxDecorations):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::snapshotAtSize):
Avoid using an invalid documentBackgroundColor, fall back to baseBackgroundColor
like we did before r174287.
Commit: 13d234e33b8df7a8525c18d779d78f6b06761cae
https://github.com/WebKit/WebKit/commit/13d234e33b8df7a8525c18d779d78f6b06761cae
Author: Ada Chan <adachan at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/Modules/webaudio/AudioContext.cpp
Log Message:
-----------
Merge r187098 - Follow-up to my earlier fix for r147085
https://bugs.webkit.org/show_bug.cgi?id=147085
Reviewed by Eric Carlson.
* Modules/webaudio/AudioContext.cpp:
(WebCore::AudioContext::isPlayingAudioDidChange):
Null-check document() before dereferencing it in case the audio context's document is destroyed
by the time the code block is called on the main thread.
Commit: 7190549e27f9d098ecc83c6974ba97b4aa4334bd
https://github.com/WebKit/WebKit/commit/7190549e27f9d098ecc83c6974ba97b4aa4334bd
Author: Sungmann Cho <sungmann.cho at navercorp.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
R LayoutTests/platform/mac-wk2/plugins/mouse-events-expected.txt
M Source/WebKit2/ChangeLog
M Source/WebKit2/PluginProcess/PluginControllerProxy.cpp
M Source/WebKit2/PluginProcess/PluginControllerProxy.h
M Source/WebKit2/PluginProcess/PluginControllerProxy.messages.in
M Source/WebKit2/WebProcess/Plugins/PluginProxy.cpp
Log Message:
-----------
Merge r187114 - Make PluginProxy::handleMouseEvent() asynchronous.
https://bugs.webkit.org/show_bug.cgi?id=146142
Patch by Sungmann Cho <sungmann.cho at navercorp.com> on 2015-07-21
Reviewed by Anders Carlsson.
PluginProxy::handleMouseEvent() forwards the generated mouse event to PluginControllerProxy
using a synchronous message, but the recipient always reply immediately with the same value("true")
even before handling the received message. So I think PluginProxy::handleMouseEvent() is perfectly
OK to process its messages asynchronously.
Source/WebKit2:
* PluginProcess/PluginControllerProxy.cpp:
(WebKit::PluginControllerProxy::handleMouseEvent):
* PluginProcess/PluginControllerProxy.h:
* PluginProcess/PluginControllerProxy.messages.in:
* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::handleMouseEvent):
LayoutTests:
platform/mac-wk2/plugins/mouse-events-expected.txt was introduced by webkit.org/b/116665 to avoid
flakey tests, but from now on we can share the common expectations.
* platform/mac-wk2/plugins/mouse-events-expected.txt: Removed.
Commit: 5ebb5aa8beeec1b205bf67aad4fc09cfc5369374
https://github.com/WebKit/WebKit/commit/5ebb5aa8beeec1b205bf67aad4fc09cfc5369374
Author: Andreas Kling <akling at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/APISession.cpp
Log Message:
-----------
Merge r187115 - API::Session should clean up its storage in the network process when destroyed.
<https://webkit.org/b/147139>
<rdar://problem/21838764>
Reviewed by Anders Carlsson.
Have ~Session() send a DestroyPrivateBrowsingSession message to all networking processes
for ephemeral sessions. This plugs a NetworkStorageSession leak that could retain a large
CFNetwork object graph.
* UIProcess/API/APISession.cpp:
(API::Session::~Session):
Commit: 76e41278886760415d419c7ae25bf957ee4e5d33
https://github.com/WebKit/WebKit/commit/76e41278886760415d419c7ae25bf957ee4e5d33
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/animations/animation-direction-reverse-fill-mode-expected.txt
M LayoutTests/animations/animation-direction-reverse-fill-mode.html
M LayoutTests/animations/fill-mode-iteration-count-non-integer-expected.txt
M LayoutTests/animations/fill-mode-iteration-count-non-integer.html
M LayoutTests/animations/fill-mode-reverse-expected.txt
M LayoutTests/animations/fill-mode-reverse.html
M Source/WebCore/ChangeLog
M Source/WebCore/page/animation/AnimationBase.cpp
M Source/WebCore/page/animation/KeyframeAnimation.cpp
Log Message:
-----------
Merge r187121 - Safari mis-applies "animation-fill-mode: forwards" when using fractional iteration count
https://bugs.webkit.org/show_bug.cgi?id=146996
Reviewed by Dean Jackson.
Source/WebCore:
animation-fill-mode: forwards with fractional iteration counts always snapped to
1 or 0, depending on direction. Fix to compute the fill-forward state from the
correct keyframes.
If filling forwards, AnimationBase::progress() sets the elapsed time to the duration,
then uses fractionalTime() to handle animation direction mapping. If the fractionalTime
is integral, we can return early, avoiding the cost of mapping through timing functions.
Tested by existing tests.
* page/animation/AnimationBase.cpp:
(WebCore::AnimationBase::progress):
(WebCore::AnimationBase::getElapsedTime):
* page/animation/KeyframeAnimation.cpp:
(WebCore::KeyframeAnimation::fetchIntervalEndpointsForProperty): It was possible
to end up with prevIndex == nextIndex with reverse animations, which resulted
in divide-by-zero when computing scale. Fix by picking a nextIndex that is different
from prevIndex.
LayoutTests:
Progressions, improved tests.
* animations/animation-direction-reverse-fill-mode-expected.txt: New results; this is a progression.
* animations/animation-direction-reverse-fill-mode.html: Use a shorter animation. Fixed results.
* animations/fill-mode-iteration-count-non-integer-expected.txt:
* animations/fill-mode-iteration-count-non-integer.html: Use iteration counts that are not multiplies
of 0.5, so the test can differentiation between forward and backwards states. Add a non-linear timing
function to check that fill-forwards consults the timing functions. Don't print exact succeeding
results because they may have floating point values.
* animations/fill-mode-reverse-expected.txt: New results; this is a progression.
* animations/fill-mode-reverse.html: Fixed results, use gray.
Commit: 9bc33b0d3658b9820c2957e6b7964a96d6ba74ac
https://github.com/WebKit/WebKit/commit/9bc33b0d3658b9820c2957e6b7964a96d6ba74ac
Author: Tim Horton <thorton at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/editing/FrameSelection.cpp
Log Message:
-----------
Merge r187128 - Placing video in fullscreen caused WebKit crash at WebCore::Range::textQuads
https://bugs.webkit.org/show_bug.cgi?id=147166
<rdar://problem/21928558>
Reviewed by Simon Fraser.
* editing/FrameSelection.cpp:
(WebCore::FrameSelection::getClippedVisibleTextRectangles):
Check the Range, as always.
Commit: 01aadef701f07b982c3c89bd63fdc568d80a6b81
https://github.com/WebKit/WebKit/commit/01aadef701f07b982c3c89bd63fdc568d80a6b81
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/css/insert-rule-overflow-rule-data-expected.txt
A LayoutTests/fast/css/insert-rule-overflow-rule-data.html
M Source/WebCore/ChangeLog
M Source/WebCore/css/StyleSheetContents.cpp
Log Message:
-----------
Merge r187133 - StyleSheetContents::wrapperInsertRule() can create rules that overflow RuleData's selector index
https://bugs.webkit.org/show_bug.cgi?id=147144
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-07-21
Reviewed by Alex Christensen.
Source/WebCore:
RuleData identifies selectors by the index in a large array. The index only has 13 bits
so rules with more than 8192 selectors should be split.
One of the paths was not splitting the rule: StyleSheetContents::wrapperInsertRule().
When rules with too many selectors were added, the index would overflow and
some RuleData would point to selectors in the middle of selector chains. The resulting
behavior is random based on the selectors and the DOM.
We cannot easily fix that because the CSS OM API do not expect to create
several rules in response to calls to the API.
In this patch, I don't do anything fancy and just let the calls fail
if we cannot use the rules safely.
Content Extensions were also running into this problem. Large Selector lists are
pretty common, and ContentExtensionStyleSheet::addDisplayNoneSelector() was
overflowing the RuleData, creating broken page.
Unlike CSSOM, there is no problem with splitting rules coming from Content Extensions.
Instead of creating new APIs for that case, I rely on the parser to extend the StyleSheetContents.
That code already knows how to break rules correctly.
Tests: fast/css/insert-rule-overflow-rule-data.html
http/tests/contentextensions/css-display-none-overflows-rule-data-1.html
http/tests/contentextensions/css-display-none-overflows-rule-data-2.html
* contentextensions/ContentExtensionStyleSheet.cpp:
(WebCore::ContentExtensions::ContentExtensionStyleSheet::addDisplayNoneSelector):
* css/StyleSheetContents.cpp:
(WebCore::StyleSheetContents::wrapperInsertRule):
LayoutTests:
This bug was affecting two parts of WebKit:
-In CSSOM, StyleSheet.insertRule() could create bogus rules.
The new test verifies that the call fails instead of creating undefined
behaviors.
-In ContentExtensions, large selectors are now working correctly. The tests
cover the case of a default stylesheet and an dynamic stylesheet.
* fast/css/insert-rule-overflow-rule-data-expected.txt: Added.
* fast/css/insert-rule-overflow-rule-data.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-1-expected.txt: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-1.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-1.html.json: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-2-expected.txt: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-2.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-2.html.json: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-3-expected.txt: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-3.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-3.html.json: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-4-expected.txt: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-4.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-4.html.json: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-5-expected.txt: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-5.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-5.html.json: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-6-expected.txt: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-6.html: Added.
* http/tests/contentextensions/css-display-none-overflows-rule-data-6.html.json: Added.
Commit: 0eaf3c90c6ea4bb76ffacf544498bae6434fdd06
https://github.com/WebKit/WebKit/commit/0eaf3c90c6ea4bb76ffacf544498bae6434fdd06
Author: Mark Dittmer <mark.s.dittmer at gmail.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/js/property-of-window-as-prototype-expected.txt
A LayoutTests/js/property-of-window-as-prototype.html
M Source/WebCore/ChangeLog
M Source/WebCore/bindings/js/JSDOMWindowBase.cpp
Log Message:
-----------
Source/WebCore:
Fix toJSDOMWindow() in the case of an object that has the actual JS DOM window in its prototype chain.
https://bugs.webkit.org/show_bug.cgi?id=146785
Patch by Mark Dittmer <mark.s.dittmer at gmail.com> on 2015-07-22
Reviewed by Mark Lam.
* bindings/js/JSDOMWindowBase.cpp: toJSDOMWindow(): Walk the prototype chain of the given JSValue until a JSDOMWindow or JSDOMWindowShell is found.
LayoutTests:
New test: Object.create(window).location will trigger a crash when toJSDOMWindow() returns NULL on an object that have the JS DOM Window in its prototype chain.
https://bugs.webkit.org/show_bug.cgi?id=146785
Patch by Mark Dittmer <mark.s.dittmer at gmail.com> on 2015-07-22
Reviewed by Mark Lam.
* js/property-of-window-as-prototype-expected.txt:
* js/property-of-window-as-prototype.html:
Commit: 41dc66ebd412bfafe2a692462aa19685542c3b51
https://github.com/WebKit/WebKit/commit/41dc66ebd412bfafe2a692462aa19685542c3b51
Author: Jinyoung Hur <hur.ims at navercorp.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
M LayoutTests/fast/canvas/canvas-lineDash-expected.txt
M LayoutTests/fast/canvas/script-tests/canvas-lineDash.js
A LayoutTests/svg/custom/zero-dasharray-expected.html
A LayoutTests/svg/custom/zero-dasharray.html
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/cairo/GraphicsContextCairo.cpp
Log Message:
-----------
Merge r187171 - [WinCairo] SVG path not rendered with all-zero dasharray
https://bugs.webkit.org/show_bug.cgi?id=146997
Patch by Jinyoung Hur <hur.ims at navercorp.com> on 2015-07-22
Reviewed by Martin Robinson.
Source/WebCore:
All-zero dash array should not be passed to cairo_set_dash() as an argument, because it will cause an internal Cairo error.
Rather call cairo_set_dash() with num_dashes=0 to disable dash line.
Tests: fast/canvas/canvas-lineDash.html
svg/custom/zero-dasharray.html
* platform/graphics/cairo/GraphicsContextCairo.cpp:
(WebCore::GraphicsContext::setLineDash):
LayoutTests:
Canvas 2D context and SVG stroke tests with all-zero dash array are added.
* fast/canvas/canvas-lineDash-expected.txt:
* fast/canvas/script-tests/canvas-lineDash.js:
* svg/custom/zero-dasharray.html: Added
* svg/custom/zero-dasharray-expected.html: Added
Commit: e6f3a1b925af9d7b9eb752faa7b961cd42982615
https://github.com/WebKit/WebKit/commit/e6f3a1b925af9d7b9eb752faa7b961cd42982615
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitUserContentManager.cpp
Log Message:
-----------
Merge r187218 - Unregistering and re-registering a user message handler does not work
https://bugs.webkit.org/show_bug.cgi?id=138142
Reviewed by Martin Robinson.
This has probably been fixed in r184846, enable the test case
blocked on it.
* TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitUserContentManager.cpp:
(testUserContentManagerScriptMessageReceived):
Commit: e2baef6ae910084805eb43d95bc51dbdaf2d230d
https://github.com/WebKit/WebKit/commit/e2baef6ae910084805eb43d95bc51dbdaf2d230d
Author: Geoffrey Garen <ggaren at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/bmalloc/ChangeLog
M Source/bmalloc/bmalloc/SegregatedFreeList.h
M Source/bmalloc/bmalloc/Sizes.h
Log Message:
-----------
Merge r187270 - bmalloc: Shrink the super chunk size (again)
https://bugs.webkit.org/show_bug.cgi?id=147240
Reviewed by Andreas Kling.
Shrinking to 8MB reduced VM exhaustion crashes but did not eliminate them.
Let's try 4MB.
(My previous comment was that the maximum fast object was 2MB. But it
was 4MB! Now it's 2MB for realsies.)
* bmalloc/Sizes.h:
Commit: e146c2ad60756fd6bca14731fe0e7986eadcdf8e
https://github.com/WebKit/WebKit/commit/e146c2ad60756fd6bca14731fe0e7986eadcdf8e
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
A Source/WebCore/platform/graphics/gstreamer/MediaPlayerRequestInstallMissingPluginsCallback.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/PlatformEfl.cmake
M Source/WebKit2/PlatformGTK.cmake
M Source/WebKit2/UIProcess/WebPageProxy.h
M Source/WebKit2/UIProcess/WebPageProxy.messages.in
A Source/WebKit2/UIProcess/gstreamer/WebPageProxyGStreamer.cpp
M Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit2/WebProcess/WebPage/WebPage.cpp
M Source/WebKit2/WebProcess/WebPage/WebPage.h
M Source/WebKit2/WebProcess/WebPage/WebPage.messages.in
A Source/WebKit2/WebProcess/WebPage/gstreamer/WebPageGStreamer.cpp
Log Message:
-----------
Merge r187338 - [GStreamer] Crashes during plugin installation
https://bugs.webkit.org/show_bug.cgi?id=144099
Reviewed by Philippe Normand.
Source/WebCore:
Add new methods to MediaPlayerClient and ChromeClient to request
the API layer to start the installer when there are missing media
plugins.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::requestInstallMissingPlugins): Pass
the request to the ChromeClient.
* html/HTMLMediaElement.h:
* page/ChromeClient.h:
* platform/graphics/MediaPlayer.h:
(WebCore::MediaPlayerClient::requestInstallMissingPlugins):
* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::~MediaPlayerPrivateGStreamer):
Invalidate any pending request to install missing media plugins.
(WebCore::MediaPlayerPrivateGStreamer::handleMessage): In case of
missing plugins message, start a request to install them if
supported by GST.
* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
(WebCore::MediaPlayerRequestInstallMissingPluginsCallback::create):
(WebCore::MediaPlayerRequestInstallMissingPluginsCallback::MediaPlayerRequestInstallMissingPluginsCallback):
(WebCore::MediaPlayerRequestInstallMissingPluginsCallback::invalidate):
(WebCore::MediaPlayerRequestInstallMissingPluginsCallback::complete):
Source/WebKit2:
Move the missing plugins installation to the UI process, ensuring
there's a single installer running and cancelling the request when
the page is closed or the media player is deleted.
* PlatformEfl.cmake: Add new files to compilation.
* PlatformGTK.cmake: Ditto.
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in: Add
RequestInstallMissingMediaPlugins message.
* UIProcess/gstreamer/WebPageProxyGStreamer.cpp: Added.
(WebKit::WebPageProxy::requestInstallMissingMediaPlugins): Call
gst_install_plugins_async() and send
DidEndRequestInstallMissingMediaPlugins message back to the web
process when done.
* WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::requestInstallMissingMediaPlugins): Call
WebPage::requestInstallMissingMediaPlugins().
* WebProcess/WebCoreSupport/WebChromeClient.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close): Invalidate the install missing plugins
request callback.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in: Add
DidEndRequestInstallMissingMediaPlugins message.
* WebProcess/WebPage/gstreamer/WebPageGStreamer.cpp: Added.
(WebKit::WebPage::requestInstallMissingMediaPlugins): Send
RequestInstallMissingMediaPlugins to the UI process or complete
the request early if there's already a request in progress.
(WebKit::WebPage::didEndRequestInstallMissingMediaPlugins):
Complete the request.
Commit: 75f7d888c3a075589b6fe98de7292c87ba3e1637
https://github.com/WebKit/WebKit/commit/75f7d888c3a075589b6fe98de7292c87ba3e1637
Author: Anders Carlsson <andersca at apple.com>
Date: 2015-08-04 (Tue, 04 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Merge r187364 - Networking process crash in NetworkConnectionToWebProcess::convertMainResourceLoadToDownload while attempting to download a blob
https://bugs.webkit.org/show_bug.cgi?id=147276
rdar://problem/21423353
Reviewed by Andreas Kling.
We currently don't support downloading blobs, so for now just bail if we encounter a null loader inside
convertMainResourceLoadToDownload (which happens when trying to download a blob URL).
* NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::didCleanupResourceLoader):
Rewrite the assertion to be more clear - it's fine to do an extra hash lookup in debug builds.
(WebKit::NetworkConnectionToWebProcess::convertMainResourceLoadToDownload):
Bail if loader is null.
Commit: b3cc6bbfee073ba8414470be6a621ed5d6d38d6e
https://github.com/WebKit/WebKit/commit/b3cc6bbfee073ba8414470be6a621ed5d6d38d6e
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/gstreamer/GUniquePtrGStreamer.h
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/PageClientImpl.cpp
M Source/WebKit2/UIProcess/API/gtk/PageClientImpl.h
M Source/WebKit2/UIProcess/PageClient.h
M Source/WebKit2/UIProcess/gstreamer/WebPageProxyGStreamer.cpp
Log Message:
-----------
Merge r187432 - [GTK] Pass a GstInstallPluginsContext to gst_install_plugins_async
https://bugs.webkit.org/show_bug.cgi?id=147103
Reviewed by Philippe Normand.
Source/WebCore:
* platform/graphics/gstreamer/GUniquePtrGStreamer.h: Allow to use
GUniquePtr with GstInstallPluginsContext.
Source/WebKit2:
This allows PackageKit to properly position the window and make it
transient to the web view window.
* UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::setCursor): Disambiguate Cursor now that
we include gtkx.h.
(WebKit::PageClientImpl::createGstInstallPluginsContext): Create a
new GstInstallPluginsContext and set the web view window XID when
running on X11.
* UIProcess/API/gtk/PageClientImpl.h:
* UIProcess/PageClient.h:
* UIProcess/efl/WebViewEfl.h:
* UIProcess/gstreamer/WebPageProxyGStreamer.cpp:
(WebKit::WebPageProxy::requestInstallMissingMediaPlugins): Use
PageClient::createGstInstallPluginsContext() to create a new
GstInstallPluginsContext and pass it to gst_install_plugins_async().
Commit: f8b877317b117b68f9348af4a7cd0e9e016da011
https://github.com/WebKit/WebKit/commit/f8b877317b117b68f9348af4a7cd0e9e016da011
Author: Brady Eidson <beidson at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/cache/CachedResource.cpp
M Source/WebCore/loader/cache/CachedResource.h
Log Message:
-----------
Merge r187466 - Crash in WebCore::DocumentLoader::willSendRequest() with ContentFilter and AppCache.
<rdar://problem/21960398> and https://bugs.webkit.org/show_bug.cgi?id=147339
Reviewed by Alexey Proskuryakov.
No new tests (Not yet proven to be possible to test this).
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::willSendRequest): Grab the identifier from the CachedResource directly, not from the null ResourceLoader.
(WebCore::DocumentLoader::continueAfterNavigationPolicy): Null check the ResourceLoader, as it can definitely be gone by this point.
* loader/cache/CachedResource.cpp:
(WebCore::CachedResource::clearLoader): Save off the identifier for later use.
* loader/cache/CachedResource.h:
(WebCore::CachedResource::identifierForLoadWithoutResourceLoader): Expose the identifier that the ResourceLoader had when it went away.
Commit: d93deae09c3647b9d0791e90a77832aea3bc772a
https://github.com/WebKit/WebKit/commit/d93deae09c3647b9d0791e90a77832aea3bc772a
Author: Tim Horton <thorton at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Merge r187471 - First in-window viewStateChange synchronously blocks despite not previously being in-window
https://bugs.webkit.org/show_bug.cgi?id=147344
<rdar://problem/22021772>
Reviewed by Simon Fraser.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::updateViewState):
(WebKit::WebPageProxy::dispatchViewStateChange):
The whole point of m_viewWasEverInWindow was so that we would not
synchronously wait when a view was added to a window for the first time,
only all subsequent times.
However, since m_viewWasEverInWindow was being set *before* being
checked in dispatchViewStateChange, we were always blocking. This is
a huge waste of main-thread time, because there's no reason to wait
for the first paint if you've never seen the view before (and shouldn't
expect it to have content).
Instead, set the flag after dispatching a view state change, so it becomes
"have we ever sent a view state with IsInWindow set" instead.
Commit: af3bd07eecc5c0e4abb9c768f3711e265210df6c
https://github.com/WebKit/WebKit/commit/af3bd07eecc5c0e4abb9c768f3711e265210df6c
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/gstreamer/GStreamerUtilities.cpp
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/API/gtk/WebKitCredential.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitJavascriptResult.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitMimeInfo.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitNavigationAction.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitPrivate.h
M Source/WebKit2/UIProcess/API/gtk/WebKitScriptDialog.cpp
M Source/WebKit2/UIProcess/API/gtk/WebKitUserContent.cpp
Log Message:
-----------
Merge r187485 - [GTK] Use fastMalloc instead of g_slice
https://bugs.webkit.org/show_bug.cgi?id=147357
Reviewed by Sergio Villar Senin.
The use of g_slice is no longer encouraged by glib developers.
Source/WebCore:
* platform/graphics/gstreamer/GStreamerUtilities.cpp:
(WebCore::mapGstBuffer):
(WebCore::unmapGstBuffer):
Source/WebKit2:
* UIProcess/API/gtk/WebKitCredential.cpp:
(webkitCredentialCreate):
(webkit_credential_free):
* UIProcess/API/gtk/WebKitJavascriptResult.cpp:
(webkitJavascriptResultCreate):
(webkit_javascript_result_unref):
* UIProcess/API/gtk/WebKitMimeInfo.cpp:
(webkitMimeInfoCreate):
(webkit_mime_info_unref):
* UIProcess/API/gtk/WebKitNavigationAction.cpp:
(webkitNavigationActionCreate):
(webkit_navigation_action_copy):
(webkit_navigation_action_free):
* UIProcess/API/gtk/WebKitPrivate.h:
* UIProcess/API/gtk/WebKitScriptDialog.cpp:
(webkitScriptDialogCopy):
(webkitScriptDialogFree):
* UIProcess/API/gtk/WebKitUserContent.cpp:
(webkit_user_style_sheet_unref):
(webkit_user_style_sheet_new):
(webkit_user_script_unref):
(webkit_user_script_new):
Commit: 2123c93c53d18fc733211df1264798ae5e4e48f3
https://github.com/WebKit/WebKit/commit/2123c93c53d18fc733211df1264798ae5e4e48f3
Author: David Hyatt <hyatt at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/fast/dynamic/position-fixed-to-absolute-with-positioned-child-crash-expected.txt
A LayoutTests/fast/dynamic/position-fixed-to-absolute-with-positioned-child-crash.html
M Source/WebCore/ChangeLog
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/RenderBlock.h
Log Message:
-----------
Merge r187502 - ASSERTION FAILED: !currBox->needsLayout() loading bing maps (and apple.com/music and nytimes)
https://bugs.webkit.org/show_bug.cgi?id=93891
Reviewed by Simon Fraser.
Source/WebCore:
Added new tests in fast/dynamic.
Change tracking of positioned objects to always insert objects that need a layout in the
end of the ListHashMap for RenderViews. This ensures that dependencies between nested
positioned objects that both need a layout by the RenderView are resolved in the correct order.
Don't cache the end object when walking the ListHashMap to do layouts of positioned objects,
since that list is getting updated dynamically as earlier objects can mark and insert new
objects into the list during their layouts.
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::layoutPositionedObject):
(WebCore::RenderBlock::layoutPositionedObjects):
(WebCore::RenderBlock::insertIntoTrackedRendererMaps):
(WebCore::RenderBlock::insertPositionedObject):
(WebCore::RenderBlock::removePositionedObject):
* rendering/RenderBlock.h:
LayoutTests:
* fast/dynamic/position-fixed-to-absolute-with-positioned-child-crash-expected.txt: Added.
* fast/dynamic/position-fixed-to-absolute-with-positioned-child-crash.html: Added.
Commit: f87722d22895e8c7b87f09077023dc3641cd4ee2
https://github.com/WebKit/WebKit/commit/f87722d22895e8c7b87f09077023dc3641cd4ee2
Author: Said Abou-Hallawa <sabouhallawa at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/svg/custom/remove-event-listener-shadow-disallowed-element-expected.txt
A LayoutTests/svg/custom/remove-event-listener-shadow-disallowed-element.svg
M Source/WebCore/ChangeLog
M Source/WebCore/svg/SVGElement.cpp
M Source/WebCore/svg/SVGUseElement.cpp
Log Message:
-----------
Merge r187504 - Crash happens when calling removeEventListener for an SVG element which has an instance inside a <defs> element of shadow tree
https://bugs.webkit.org/show_bug.cgi?id=147290
Reviewed by Daniel Bates.
Source/WebCore:
When the shadow tree is built for a <use> element, all the SVG elements
are allowed to be cloned in the shadow tree but later some of the elements
are disallowed and removed. Make sure, when disallowing an element in the
shadow tree, to reset the correspondingElement relationship between all
the disallowed descendant SVG elements and all their original elements.
Test: svg/custom/remove-event-listener-shadow-disallowed-element.svg
*svg/SVGElement.cpp:
(WebCore::SVGElement::setCorrespondingElement)
* svg/SVGUseElement.cpp:
(WebCore::removeDisallowedElementsFromSubtree):
LayoutTests:
Make sure we do not crash when when calling removeEventListener() for an
element which is cloned under a disallowed parent inside the shadow tree
of another <use> element.
* svg/custom/remove-event-listener-shadow-disallowed-element-expected.txt: Added.
* svg/custom/remove-event-listener-shadow-disallowed-element.svg: Added.
Commit: cd10202c2440144226f2e16d969c6cfb113a4f6e
https://github.com/WebKit/WebKit/commit/cd10202c2440144226f2e16d969c6cfb113a4f6e
Author: Michael Catanzaro <mcatanzaro at gnome.org>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/platform/gtk/fonts/font-family-fallback-ignores-weak-aliases-expected.html
A LayoutTests/platform/gtk/fonts/font-family-fallback-ignores-weak-aliases.html
A LayoutTests/platform/gtk/fonts/font-family-fallback-respects-strong-aliases-expected.html
A LayoutTests/platform/gtk/fonts/font-family-fallback-respects-strong-aliases.html
M Source/WebCore/ChangeLog
M Source/WebCore/platform/graphics/cairo/RefPtrCairo.cpp
M Source/WebCore/platform/graphics/cairo/RefPtrCairo.h
A Source/WebCore/platform/graphics/freetype/FcUniquePtr.h
M Source/WebCore/platform/graphics/freetype/FontCacheFreeType.cpp
M Tools/ChangeLog
M Tools/WebKitTestRunner/gtk/fonts/fonts.conf
Log Message:
-----------
Merge r187527 - [Freetype] Always allow font matching for strong aliases
https://bugs.webkit.org/show_bug.cgi?id=147057
Reviewed by Martin Robinson.
Source/WebCore:
Tests: platform/gtk/fonts/font-family-fallback-ignores-weak-aliases.html
platform/gtk/fonts/font-family-fallback-respects-strong-aliases.html
Treat fonts that are strongly-aliased to each other as if they were identical for the
purposes of CSS font fallback. This improves the layout of many web pages by allowing
fontconfig to replace fonts with metric-compatible equivalents (e.g. Arial -> Liberation
Sans) instead of rejecting the metric-compatible font as unsuitable.
* platform/graphics/cairo/RefPtrCairo.cpp:
(WTF::refIfNotNull):
(WTF::derefIfNotNull):
* platform/graphics/cairo/RefPtrCairo.h:
* platform/graphics/freetype/FcUniquePtr.h: Added.
(WebCore::FcPtrDeleter<FcFontSet>::operator()):
(WebCore::FcPtrDeleter<FcLangSet>::operator()):
(WebCore::FcPtrDeleter<FcObjectSet>::operator()):
* platform/graphics/freetype/FontCacheFreeType.cpp:
(WebCore::strengthOfFirstAlias):
(WebCore::strongAliasesForFamily):
(WebCore::areStronglyAliased):
(WebCore::FontCache::createFontPlatformData):
Tools:
Create family aliases needed for the new layout tests.
* WebKitTestRunner/gtk/fonts/fonts.conf:
LayoutTests:
* platform/gtk/fonts/font-family-fallback-ignores-weak-aliases-expected.html: Added.
* platform/gtk/fonts/font-family-fallback-ignores-weak-aliases.html: Added.
* platform/gtk/fonts/font-family-fallback-respects-strong-aliases-expected.html: Added.
* platform/gtk/fonts/font-family-fallback-respects-strong-aliases.html: Added.
Commit: 71d7d20b83c46e83b1f9fac3a5e8fba0d1fa6eea
https://github.com/WebKit/WebKit/commit/71d7d20b83c46e83b1f9fac3a5e8fba0d1fa6eea
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/animations/remove-syncing-animation-expected.txt
A LayoutTests/animations/remove-syncing-animation.html
M Source/WebCore/ChangeLog
M Source/WebCore/page/animation/AnimationBase.h
M Source/WebCore/page/animation/AnimationController.cpp
M Source/WebCore/page/animation/CompositeAnimation.cpp
Log Message:
-----------
Merge r187535 - Animations sometimes fail to start
https://bugs.webkit.org/show_bug.cgi?id=147394
rdar://problem/21852603
Reviewed by Dean Jackson.
Source/WebCore:
When an accelerated animation or transition was started at the same time as
a non-accelerated one, and then the node for the former was removed, we could
never kick off the non-accelerated animation.
AnimationControllerPrivate has logic to synchronize the two types of animation
when they start in the same animation update, which involves setting the
m_waitingForAsyncStartNotification flag, and waiting for a notifyAnimationStarted()
to come in from the graphics system.
However, it failed to handle the case where the accelerated animation was removed
before the callback was received, which left the m_waitingForAsyncStartNotification flag
set to true, preventing the non-accelerated animation from running.
Test: animations/remove-syncing-animation.html
* page/animation/AnimationBase.h:
(WebCore::AnimationBase::isAccelerated): Make this public.
* page/animation/AnimationController.cpp:
(WebCore::AnimationControllerPrivate::clear): Add logging.
(WebCore::AnimationControllerPrivate::receivedStartTimeResponse): Add logging.
(WebCore::AnimationControllerPrivate::animationWillBeRemoved): Add logging.
After removing animations from the maps, check to see if we expect any of the
remaining animations are waiting for a notifyAnimationStarted(). If not, clear
the m_waitingForAsyncStartNotification flag.
(WebCore::AnimationController::notifyAnimationStarted): Log the renderer.
(WebCore::AnimationControllerPrivate::AnimationControllerPrivate): Remove unneeded
initializations of HashMaps.
* page/animation/CompositeAnimation.cpp:
(WebCore::CompositeAnimation::updateTransitions): Log renderers.
(WebCore::CompositeAnimation::updateKeyframeAnimations): Ditto.
LayoutTests:
Test that starts an accelerated and non-accelerated animation, then removes
the node for the accelerated one.
* animations/remove-syncing-animation-expected.txt: Added.
* animations/remove-syncing-animation.html: Added.
Commit: 8864db904bb0baf0fb8d9958f38b3183de591164
https://github.com/WebKit/WebKit/commit/8864db904bb0baf0fb8d9958f38b3183de591164
Author: Brady Eidson <beidson at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/DocumentLoader.h
Log Message:
-----------
Merge r187557 - Crash in WebCore::DocumentLoader::stopLoadingForPolicyChange.
<rdar://problem/21412186> and https://bugs.webkit.org/show_bug.cgi?id=147418
Reviewed by Chris Dumez.
No new tests (No known reproducibility)
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::responseReceived): When setting to m_waitingForContentPolicy true, make sure we have a FrameLoader.
(WebCore::DocumentLoader::detachFromFrame): Always explicitly call cancelPolicyCheckIfNeeded().
(WebCore::DocumentLoader::cancelPolicyCheckIfNeeded): Cancel the policy check if there is one.
(WebCore::DocumentLoader::cancelMainResourceLoad): Use cancelPolicyCheckIfNeeded().
* loader/DocumentLoader.h:
RELEASE_ASSERT followup to: Crash in WebCore::DocumentLoader::stopLoadingForPolicyChange.
https://bugs.webkit.org/show_bug.cgi?id=147418
Reviewed by Chris Dumez.
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::cancelPolicyCheckIfNeeded): RELEASE_ASSERT we have a FrameLoader here.
We want to know if we ever get here without one.
Review feedback followup to: Crash in WebCore::DocumentLoader::stopLoadingForPolicyChange.
https://bugs.webkit.org/show_bug.cgi?id=147418
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::cancelPolicyCheckIfNeeded):
Commit: 214c173c6fd55680ac8d5512c0a25afefbc1ad7d
https://github.com/WebKit/WebKit/commit/214c173c6fd55680ac8d5512c0a25afefbc1ad7d
Author: Michael Catanzaro <mcatanzaro at gnome.org>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/network/soup/SoupNetworkSession.cpp
M Source/WebCore/platform/network/soup/SoupNetworkSession.h
Log Message:
-----------
Merge r187586 - [GTK] Crashes when SoupSession is destroyed in exit handler
https://bugs.webkit.org/show_bug.cgi?id=145347
Reviewed by Carlos Garcia Campos.
Leak the default SoupSession with NeverDestroyed to avoid races at program exit.
* platform/network/soup/SoupNetworkSession.cpp:
(WebCore::SoupNetworkSession::defaultSession):
* platform/network/soup/SoupNetworkSession.h:
Commit: 9519baa79412bc04be2bf47ee150f1909c449928
https://github.com/WebKit/WebKit/commit/9519baa79412bc04be2bf47ee150f1909c449928
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/platform/gtk/DataObjectGtk.cpp
M Source/WebCore/platform/gtk/DataObjectGtk.h
M Source/WebCore/platform/gtk/PasteboardGtk.cpp
M Source/WebCore/platform/gtk/PasteboardHelper.cpp
Log Message:
-----------
Merge r187640 - [GTK] Have DataObjectGtk::unknownTypes() return a reference to the HashMap object
https://bugs.webkit.org/show_bug.cgi?id=147401
Reviewed by Carlos Garcia Campos.
Don't copy the DataObjectGtk::m_unknownTypes HashMap on every retrieval through
DataObjectGtk::unknownTypes(). The range-based for-loops that iterate over the
map in PasteboardGtk.cpp and PasteboardHelper.cpp are also cleaned up.
* platform/gtk/DataObjectGtk.cpp:
(WebCore::DataObjectGtk::unknownTypes):
* platform/gtk/DataObjectGtk.h:
* platform/gtk/PasteboardGtk.cpp:
(WebCore::Pasteboard::writePasteboard):
(WebCore::Pasteboard::types):
* platform/gtk/PasteboardHelper.cpp:
(WebCore::PasteboardHelper::fillSelectionData):
Commit: d74310dd5669706be3107c2062f922879668f191
https://github.com/WebKit/WebKit/commit/d74310dd5669706be3107c2062f922879668f191
Author: Benjamin Poulain <bpoulain at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/JavaScriptCore/ChangeLog
M Source/JavaScriptCore/dfg/DFGLivenessAnalysisPhase.cpp
M Source/WTF/ChangeLog
M Source/WTF/wtf/HashTable.h
M Tools/ChangeLog
M Tools/TestWebKitAPI/Tests/WTF/HashSet.cpp
Log Message:
-----------
Merge r187733 - Investigate HashTable::HashTable(const HashTable&) and HashTable::operator=(const HashTable&) performance for hash-based static analyses
https://bugs.webkit.org/show_bug.cgi?id=118455
Patch by Benjamin Poulain <bpoulain at apple.com> on 2015-08-02
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
LivenessAnalysisPhase lights up like a christmas tree in profiles.
This patch cuts its cost by 4.
About half of the gains come from removing many rehash() when copying
the HashSet.
The last quarter is achieved by having a special add() function for initializing
a HashSet.
This makes benchmarks progress by 1-2% here and there. Nothing massive.
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::process):
The m_live HashSet is only useful per block. When we are done with it,
we can transfer it to liveAtHead to avoid a copy.
Source/WTF:
Previously, when copying a HashTable, we would start from scratch
with an empty table and insert elements one by one, growing-rehashing
the table as needed.
With this patch, we have 2 improvements to remove most of the cost.
First, we compute a good size from the start. This removes all the
reallocations and rehashs.
This is where the biggest gain comes from.
The second part is a simpler version of add() when we know that
we cannot find a bucket with the same key and there cannot
be any deleted bucket.
This removes most branches from the hot loop, cutting another 25%
of the time.
* wtf/HashTable.h:
(WTF::KeyTraits>::addUniqueForInitialization):
(WTF::KeyTraits>::HashTable):
Tools:
* TestWebKitAPI/Tests/WTF/HashSet.cpp:
(TestWebKitAPI::TEST):
Commit: 2fe49af8724a15b600e8e783e04a3d810552f3db
https://github.com/WebKit/WebKit/commit/2fe49af8724a15b600e8e783e04a3d810552f3db
Author: Brady Eidson <beidson at apple.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Merge r187740 - Crash when signing into twitter calling WebCore::DocumentLoader::responseReceived(WebCore::CachedResource*, WebCore::ResourceResponse const&).
<rdar://problem/22098457> and https://bugs.webkit.org/show_bug.cgi?id=147560
Reviewed by Alexey Proskuryakov.
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::willSendRequest): Only grab identifierForLoadWithoutResourceLoader() if there's no ResourceLoader.
Commit: ddaf24724bbae3a63e09267a4dabdb90b143d1ff
https://github.com/WebKit/WebKit/commit/ddaf24724bbae3a63e09267a4dabdb90b143d1ff
Author: Philip Chimento <philip.chimento at gmail.com>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M ChangeLog
M Source/cmake/FindCairoGL.cmake
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Merge r184063 - CMake defines CAIROGL_FOUND, not CAIRO_GL_FOUND
https://bugs.webkit.org/show_bug.cgi?id=144846
Patch by Philip Chimento <philip.chimento at gmail.com> on 2015-05-10
Reviewed by Martin Robinson.
* Source/cmake/FindCairoGL.cmake: Use CAIROGL_* instead of
CAIRO_GL_* throughout, because find_package will define
CAIROGL_FOUND.
* Source/cmake/OptionsGTK.cmake: Ditto.
Commit: 79e1434b78d35b86e086082fddbac17b19fccaac
https://github.com/WebKit/WebKit/commit/79e1434b78d35b86e086082fddbac17b19fccaac
Author: Mario Sanchez Prada <mario at webkit.org>
Date: 2015-08-05 (Wed, 05 Aug 2015)
Changed paths:
M ChangeLog
M Source/cmake/FindCairoGL.cmake
Log Message:
-----------
Merge r187854 - [GTK] Accelerated 2D Canvas enabled when cairo-gl is not available
https://bugs.webkit.org/show_bug.cgi?id=147625
Reviewed by Martin Robinson.
Do not set the CAIRO_<COMPONENT>_* CMake variables for cairo-gl
components unless they were actually found, not to accidentally
enable Accelerated 2D canvas, which would cause the build to fail.
* Source/cmake/FindCairoGL.cmake: Set this variables only when
pkg_check_modules() had actually found the relevant component.
Commit: 21faa8df4b34c7ed37ba38496490ef45f3c373e0
https://github.com/WebKit/WebKit/commit/21faa8df4b34c7ed37ba38496490ef45f3c373e0
Author: Chris Dumez <cdumez at apple.com>
Date: 2015-08-06 (Thu, 06 Aug 2015)
Changed paths:
M LayoutTests/ChangeLog
A LayoutTests/mathml/maction-removeChild-expected.txt
A LayoutTests/mathml/maction-removeChild.html
M Source/WebCore/ChangeLog
M Source/WebCore/mathml/MathMLSelectElement.h
Log Message:
-----------
Merge r188014 - Crash when removing children of a MathMLSelectElement
https://bugs.webkit.org/show_bug.cgi?id=147704
<rdar://problem/21940321>
Reviewed by Ryosuke Niwa.
Source/WebCore:
When MathMLSelectElement::childrenChanged() is called after its
children have been removed, MathMLSelectElement calls
updateSelectedChild() which accesses m_selectedChild. However,
in this case, m_selectedChild is the previously selected child
and it may be destroyed as this point if it was removed. To avoid
this problem, MathMLSelectElement now keep a strong ref to the
currently selected element.
Test: mathml/maction-removeChild.html
* mathml/MathMLSelectElement.h:
LayoutTests:
Add layout test that reproduces the crash under guardmalloc.
* mathml/maction-removeChild-expected.txt: Added.
* mathml/maction-removeChild.html: Added.
Commit: 75b2386f2875aa5dd46e94ba5e529df1701a0ce3
https://github.com/WebKit/WebKit/commit/75b2386f2875aa5dd46e94ba5e529df1701a0ce3
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2015-08-06 (Thu, 06 Aug 2015)
Changed paths:
M Source/WebKit2/ChangeLog
M Source/WebKit2/UIProcess/gtk/WebContextMenuProxyGtk.cpp
M Source/WebKit2/UIProcess/gtk/WebContextMenuProxyGtk.h
Log Message:
-----------
Merge r188031 - [GTK] Crash closing a page when a context menu is open
https://bugs.webkit.org/show_bug.cgi?id=147682
Reviewed by Sergio Villar Senin.
Implement WebContextMenuProxy::cancelTracking() to clear the
internal menu when the web page is closed.
* UIProcess/gtk/WebContextMenuProxyGtk.cpp:
(WebKit::WebContextMenuProxyGtk::cancelTracking):
(WebKit::WebContextMenuProxyGtk::~WebContextMenuProxyGtk): Deleted.
* UIProcess/gtk/WebContextMenuProxyGtk.h:
Commit: 9bf1b14d82d85ffc395aee09ce3e922e7cc4c38c
https://github.com/WebKit/WebKit/commit/9bf1b14d82d85ffc395aee09ce3e922e7cc4c38c
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-08-06 (Thu, 06 Aug 2015)
Changed paths:
M Source/WebCore/ChangeLog
M Source/WebCore/loader/ThreadableLoader.h
Log Message:
-----------
Unreviewed. Fix the build with RESOURCE_TIMING disabled.
* loader/ThreadableLoader.h:
Commit: c46247240e3939fd442363c928b54434c22fbfe7
https://github.com/WebKit/WebKit/commit/c46247240e3939fd442363c928b54434c22fbfe7
Author: Carlos Garcia Campos <carlosgc at webkit.org>
Date: 2015-08-06 (Thu, 06 Aug 2015)
Changed paths:
M ChangeLog
M Source/WebKit2/ChangeLog
M Source/WebKit2/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.8.5 release.
.:
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Source/WebKit2:
* gtk/NEWS: Add release notes for 2.8.5.
Compare: https://github.com/WebKit/WebKit/compare/63f468f08bca%5E...c46247240e39
More information about the webkit-changes
mailing list