[GTK] Does not regenerate CSS-related sources when configuration changes
https://bugs.webkit.org/show_bug.cgi?id=94927

Reviewed by Eric Seidel.

In bug 94094 the gtk EWS consistently failed to build the patch. The
reason that happens is the .in files have not been touched, so the CSS
property names and value keywords sources are not regenerated. By
adding an explicit dependency on configure.ac and GNUmakefile.am the
problem is fixed (see bug 82465, attachment 160265).

* GNUmakefile.am: add explicit dependency from the CSS-related .in files
on configure.ac and WebCore's GNUmakefile.am

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126891 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Report frame bytes by platform ImageDecoder
https://bugs.webkit.org/show_bug.cgi?id=94241

Reviewed by James Robinson.

Decoded frame bytes should be reported by the platform ImageSource and
ImageDecoder. BitmapImage used to guess system memory used by a frame
but this is no longer true if a frame is backed by an accelerated
surface or defer-decoded.

Adds ImageSource::frameBytesAtIndex and ImageDecoder::frameBytesAtIndex
such that platform can report memory usage correctly.

No new tests. Refactoring without change of behavior.
Tested on Chromium port with pixel tests without any crash or failure.

* platform/graphics/BitmapImage.cpp:
(WebCore::BitmapImage::destroyDecodedData):
(WebCore::BitmapImage::destroyDecodedDataIfNecessary):
(WebCore::BitmapImage::destroyMetadataAndNotify):
(WebCore::BitmapImage::cacheFrame):
(WebCore::BitmapImage::dataChanged):
* platform/graphics/BitmapImage.h:
(WebCore::FrameData::FrameData):
(FrameData):
(BitmapImage):
* platform/graphics/ImageSource.cpp:
(WebCore::ImageSource::frameBytesAtIndex):
(WebCore):
* platform/graphics/ImageSource.h:
* platform/graphics/cg/ImageSourceCG.cpp:
(WebCore::ImageSource::frameBytesAtIndex):
(WebCore):
* platform/image-decoders/ImageDecoder.cpp:
(WebCore::ImageDecoder::frameBytesAtIndex):
(WebCore):
* platform/image-decoders/ImageDecoder.h:
(ImageDecoder):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126892 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Refactored and consolidated variable resolution functions
https://bugs.webkit.org/show_bug.cgi?id=95166

Reviewed by Filip Pizlo.

This patch does a few things:

(1) Introduces a new class, JSScope, which is the base class for all
objects that represent a scope in the scope chain.

(2) Refactors and consolidates duplicate implementations of variable
resolution into the JSScope class.

(3) Renames JSStaticScopeObject to JSNameScope because, as distinct from
something like a 'let' scope, JSStaticScopeObject only has storage for a
single name.

These changes makes logical sense to me as-is. I will also use them in an
upcoming optimization.

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri: Build!

* bytecode/CodeBlock.cpp:
(JSC): Build fix for LLInt-only builds.

* bytecode/GlobalResolveInfo.h:
(GlobalResolveInfo): Use PropertyOffset to be consistent with other parts
of the engine.

* bytecompiler/NodesCodegen.cpp:
* dfg/DFGOperations.cpp: Use the shared code in JSScope instead of rolling
our own.

* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::createExceptionScope):
(JSC::Interpreter::privateExecute):
* interpreter/Interpreter.h: Use the shared code in JSScope instead of rolling
our own.

* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION): Use the shared code in JSScope instead of rolling
our own.

* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(LLInt): Use the shared code in JSScope instead of rolling our own. Note
that one of these slow paths calls the wrong helper function. I left it
that way to avoid a behavior change in a refactoring patch.

* parser/Nodes.cpp: Updated for rename.

* runtime/CommonSlowPaths.h:
(CommonSlowPaths): Removed resolve slow paths because were duplicative.

* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::JSGlobalData):
* runtime/JSGlobalData.h:
(JSGlobalData): Updated for renames.

* runtime/JSNameScope.cpp: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.cpp.
(JSC):
(JSC::JSNameScope::visitChildren):
(JSC::JSNameScope::toThisObject):
(JSC::JSNameScope::put):
(JSC::JSNameScope::getOwnPropertySlot):
* runtime/JSNameScope.h: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.h.
(JSC):
(JSC::JSNameScope::create):
(JSC::JSNameScope::createStructure):
(JSNameScope):
(JSC::JSNameScope::JSNameScope):
(JSC::JSNameScope::isDynamicScope): Used do-webcore-rename script here.
It is fabulous!

* runtime/JSObject.h:
(JSObject):
(JSC::JSObject::isNameScopeObject): More rename.

* runtime/JSScope.cpp: Added.
(JSC):
(JSC::JSScope::isDynamicScope):
(JSC::JSScope::resolve):
(JSC::JSScope::resolveSkip):
(JSC::JSScope::resolveGlobal):
(JSC::JSScope::resolveGlobalDynamic):
(JSC::JSScope::resolveBase):
(JSC::JSScope::resolveWithBase):
(JSC::JSScope::resolveWithThis):
* runtime/JSScope.h: Added.
(JSC):
(JSScope):
(JSC::JSScope::JSScope): All the code here is a port from the
Interpreter.cpp implementations of this functionality.

* runtime/JSStaticScopeObject.cpp: Removed.
* runtime/JSStaticScopeObject.h: Removed.

* runtime/JSSymbolTableObject.cpp:
(JSC):
* runtime/JSSymbolTableObject.h:
(JSSymbolTableObject):
* runtime/JSType.h: Updated for rename.

* runtime/Operations.h:
(JSC::resolveBase): Removed because it was duplicative.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126893 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Update the TestExpectations to match what the cr-linux-ews
bot sees.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126894 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[New Multicolumn] Rename some flow thread methods and region methods/members to make them
more accurate and also change some function signatures so they can be used by RenderMultiColumnSet.
https://bugs.webkit.org/show_bug.cgi?id=95213
        
Reviewed by Simon Fraser.

Rename regionRect()/setRegionRect()/m_regionRect on RenderRegion to be flowThreadPortionRect instead.
The term regionRect() makes it sound like you're painting a rect in the region's coordinate space,
but regionRect() actually represents the portion of the flow thread in the flow thread's coordinate space
that this region "owns."
        
Also fix paintIntoRegion and hitTestRegion to take specific flow thread portion rects to paint. This
allows a region set to paint a portion of a portion, i.e., if a multicolumn set owns part of the flow thread
it has to be able to further break up that part into individual columns and issue multiple paint calls, one
for each column.

* rendering/RenderFlowThread.cpp:
(WebCore::RenderFlowThread::layout):
(WebCore::RenderFlowThread::paintFlowThreadPortionInRegion):
(WebCore::RenderFlowThread::hitTestFlowThreadPortionInRegion):
(WebCore::RenderFlowThread::repaintRectangleInRegions):
(WebCore::RenderFlowThread::renderRegionForLine):
(WebCore::RenderFlowThread::regionLogicalTopForLine):
(WebCore::RenderFlowThread::regionLogicalWidthForLine):
(WebCore::RenderFlowThread::regionLogicalHeightForLine):
(WebCore::RenderFlowThread::regionRemainingLogicalHeightForLine):
(WebCore::RenderFlowThread::mapFromFlowToRegion):
(WebCore::RenderFlowThread::contentLogicalLeftOfFirstRegion):
(WebCore::RenderFlowThread::computeOverflowStateForRegions):
* rendering/RenderFlowThread.h:
* rendering/RenderMultiColumnSet.cpp:
(WebCore::RenderMultiColumnSet::columnCount):
(WebCore::RenderMultiColumnSet::paintColumnContents):
* rendering/RenderRegion.cpp:
(WebCore::RenderRegion::flowThreadPortionOverflowRect):
(WebCore::RenderRegion::paintReplaced):
(WebCore::RenderRegion::nodeAtPoint):
(WebCore::RenderRegion::layout):
(WebCore::RenderRegion::offsetFromLogicalTopOfFirstPage):
* rendering/RenderRegion.h:
(WebCore::RenderRegion::setFlowThreadPortionRect):
(WebCore::RenderRegion::flowThreadPortionRect):
(RenderRegion):
* rendering/RenderRegionSet.cpp:
(WebCore::RenderRegionSet::expandToEncompassFlowThreadContentsIfNeeded):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126895 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Gardening of the WK2 Debug Bot failing tests
https://bugs.webkit.org/show_bug.cgi?id=95210

Unreviewed gardening.

Patch by Thiago Marcos P. Santos <thiago.santos@intel.com> on 2012-08-28

* platform/efl-wk2/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126896 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2012-08-28  Geoffrey Garen  <ggaren@apple.com>

        Build fix: svn add two files I forgot in my last patch.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126897 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove Windows specific object-sizing test results.
https://bugs.webkit.org/show_bug.cgi?id=95160

Reviewed by NOBODY (OOPS!).

These test results now match the general LayoutTest results, removing failing platform specific results.

* platform/win/svg/custom/object-sizing-width-50p-height-75p-on-target-svg-absolute-expected.txt: Removed.
* platform/win/svg/custom/object-sizing-width-50p-height-75p-on-target-svg-expected.txt: Removed.
* platform/win/svg/custom/object-sizing-width-75p-height-50p-on-target-svg-absolute-expected.txt: Removed.
* platform/win/svg/custom/object-sizing-width-75p-height-50p-on-target-svg-expected.txt: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126898 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Add SPI for injected bundle to manually set permissions
https://bugs.webkit.org/show_bug.cgi?id=95127
<rdar://problem/12182635>

Reviewed by Jessie Berlin.

This is work toward providing Mac support for web notifications in DRT and WTR (77969).

Add support functions to WebKit2 which maintain the map of permissions to origins for web notifications.
For WebKit1 the map is managed by DumpRenderTree.

* WebProcess/InjectedBundle/InjectedBundle.h: Add TestRunner SPI.
* WebProcess/InjectedBundle/InjectedBundle.cpp:
(WebKit::InjectedBundle::setWebNotificationPermission):
(WebKit::InjectedBundle::removeAllWebNotificationPermissions):

* WebProcess/InjectedBundle/API/c/WKBundlePrivate.h: Expose as WK API. Also, rearrange the ordering of the
functions so that it reflects the same order found in InjectedBundle.h.
* WebProcess/InjectedBundle/API/c/WKBundle.cpp:

* WebProcess/Notifications/NotificationPermissionRequestManager.cpp:
(WebKit::NotificationPermissionRequestManager::setPermissionLevelForTesting): Manually set the permission
level for an origin.
(WebKit::NotificationPermissionRequestManager::removeAllPermissionsForTesting):
* WebProcess/Notifications/NotificationPermissionRequestManager.h:
(NotificationPermissionRequestManager):
* WebProcess/Notifications/WebNotificationManager.cpp:
(WebKit::WebNotificationManager::removeAllPermissionsForTesting): Clear the permission map.
* WebProcess/Notifications/WebNotificationManager.h: Promote didUpdateNotificationDecision message as public
function, so that NotificationPermissionRequestManager can update the permission map.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126899 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaselining chromium-mac test results with scrollbars.

Unreviewed update of test results.

* platform/chromium-mac/platform/chromium/virtual/gpu/fast/canvas/image-object-in-canvas-expected.png:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126900 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Be robust to WebCore popping an empty GraphicsContext stack
https://bugs.webkit.org/show_bug.cgi?id=95152

Reviewed by James Robinson.

* platform/graphics/skia/OpaqueRegionSkia.cpp:
(WebCore::OpaqueRegionSkia::popCanvasLayer):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126901 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add header guards to WebTileCacheLayer.h.
https://bugs.webkit.org/show_bug.cgi?id=95171

Reviewed by Simon Hausmann.

Headers love include guards.

* platform/graphics/ca/mac/WebTileCacheLayer.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126902 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Bugs in maintenance of internal state when user decides whether to grant notification permissions
https://bugs.webkit.org/show_bug.cgi?id=95220
<rdar://problem/12189895>

Reviewed by Jessie Berlin.

A couple of the maps maintained by the request manager should have been cleaned up when the user decided on
whether to grant a website permission to post notifications.

Also, the web process' copy of the permissions was not updated appropriately. This meant that in the
permission callback, Notification.permission was not the same value as the permission value included as
the first parameter of the callback.

This first surfaced as part of the work to bring Mac support for web notifications. I have a test that
will check for regressions in this area, once all of that has been checked in (bug 77969).

* WebProcess/Notifications/NotificationPermissionRequestManager.cpp:
(WebKit::NotificationPermissionRequestManager::didReceiveNotificationPermissionDecision):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126903 268f45cc-cd09-0410-ab3c-d52691b4dbfc