Collapse OS(UNIX)||OS(ANDROID) to OS(UNIX)
https://bugs.webkit.org/show_bug.cgi?id=108091

Patch by Laszlo Gombos <l.gombos@samsung.com> on 2013-01-28
Reviewed by Adam Barth.

OS(UNIX) is defined when OS(ANDROID) is defined.

* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::handleMouseDown):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140989 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Quit debug build without -DSHARED_CORE=ON
https://bugs.webkit.org/show_bug.cgi?id=104773

Patch by Halton Huo <halton.huo@intel.com> on 2013-01-28
Reviewed by Laszlo Gombos.

Debug build without -DSHARED_CORE=ON will fail because libwebcore_efl.a
is too big (>4G) to archive. The solution is simply to abort cmake in
this condition and notify developer.

* CMakeLists.txt:
* Source/cmake/OptionsEfl.cmake:
* Source/cmake/OptionsCommon.cmake:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140990 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening.

Adding a failure expectation for a User Timing test added in r140882.

* platform/gtk/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140991 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't use threaded HTML parser for data: URLs
https://bugs.webkit.org/show_bug.cgi?id=108096

Reviewed by Eric Seidel.

data: URLs are currently loaded synchronously. Using the main thread parser for them preserves this behavior.
This fixes fast/dom/HTMLDocument/document-open-return-value.html and probably others.

No new tests because covered by existing tests.

* html/parser/HTMLParserOptions.cpp:
(WebCore::HTMLParserOptions::HTMLParserOptions):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140992 268f45cc-cd09-0410-ab3c-d52691b4dbfc
getComputedStyle returns "left" instead of "none" for "float" on abspos elements
https://bugs.webkit.org/show_bug.cgi?id=105836

Patch by Uday Kiran <udaykiran@motorola.com> on 2013-01-28
Reviewed by Tony Chang.

If 'position' has the value absolute, page or fixed, and the value of float is
left or right, the box is absolutely positioned and the computed value of float is none.
http://www.w3.org/TR/css3-positioning/#dis-pos-flo
This matches behavior of Firefox 18, Opera 12 and IE9.

Source/WebCore:

Test: fast/css/position-absolute-float.html

* css/CSSComputedStyleDeclaration.cpp:
(WebCore::CSSComputedStyleDeclaration::getPropertyCSSValue):

LayoutTests:

* fast/css/position-absolute-float-expected.txt: Added.
* fast/css/position-absolute-float.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140993 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Correct auto-zoom when using compositor scaling
https://bugs.webkit.org/show_bug.cgi?id=107592

Reviewed by Adam Barth.

1. The scale of auto-zoom should exclude deviceScaleFactor because the compositor will handle the scaling;
2. Scroll location needs to be calculated differently when pageScaleFactor is handled by the compositor.

* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::computeScaleAndScrollForHitRect):
* tests/WebFrameTest.cpp: Updated tests DivAutoZoomParamsTest, DivAutoZoomMultipleDivsTest, DivAutoZoomScaleBoundsTest and DivAutoZoomScaleFontScaleFactorTest, to make two versions of them (WebKitScaling and CompositorScaling).


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140994 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add StorageStrategy member functions to WebKit2
https://bugs.webkit.org/show_bug.cgi?id=108105

Reviewed by Tim Horton.

Source/WebCore:

StorageStrategy::sessionStorageNamespace should be virtual, not static...

* WebCore.exp.in:
* storage/StorageStrategy.h:
(StorageStrategy):

Source/WebKit2:

Add default implementations that just chain up to the base class for now.

* WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:
(WebKit::WebPlatformStrategies::localStorageNamespace):
(WebKit::WebPlatformStrategies::sessionStorageNamespace):
* WebProcess/WebCoreSupport/WebPlatformStrategies.h:
(WebPlatformStrategies):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140995 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Revert 130950
BUG=163593

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140996 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders] Parse @-webkit-filter
https://bugs.webkit.org/show_bug.cgi?id=106837

Reviewed by Dean Jackson.

Source/WebCore:

The new CSS Custom Filters syntax includes an @filter rule:
@filter IDENT { <custom-filter-description> }

IDENT is the filter name. For example:
@filter my-filter { ... }

<custom-filter-description> is a set of CSS properties, which are still under discussion in
the CSSWG.

This patch adds parsing and JS bindings for the prefixed at-rule. It does not add parsing
for any of the at-rule's internal properties.

Spec: https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#the-atfilter-rule

Tests: css3/filters/custom/custom-filter-parsing-at-rule-invalid.html
       css3/filters/custom/custom-filter-parsing-at-rule-valid.html

* CMakeLists.txt:
* DerivedSources.cpp:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/JSCSSRuleCustom.cpp:
(WebCore::toJS):
* bindings/objc/DOMCSS.mm:
(kitClass):
* bindings/v8/custom/V8CSSRuleCustom.cpp:
(WebCore::wrap):
* css/CSSGrammar.y.in:
* css/CSSParser.cpp:
(WebCore::CSSParser::createFilterRule):
(WebCore::CSSParser::detectAtToken):
* css/CSSParser.h:
* css/CSSPropertySourceData.h:
* css/CSSRule.h:
* css/CSSRule.idl:
    Only contains a CSSStyleDeclaration "style" property, like the other at-rules that are
    supposed to contain properties (e.g. CSSStyleRule, CSSFontFaceRule, CSSPageRule).
    Eventually, when it's specified, we should expose the filter name as well.
    Other at-rules IDL Spec: http://www.w3.org/TR/DOM-Level-2-Style/idl-definitions.html
* css/StyleRule.cpp:
(WebCore::StyleRuleBase::reportMemoryUsage):
(WebCore::StyleRuleBase::destroy):
(WebCore::StyleRuleBase::copy):
(WebCore::StyleRuleBase::createCSSOMWrapper):
(WebCore::StyleRuleFilter::StyleRuleFilter):
(WebCore::StyleRuleFilter::~StyleRuleFilter):
(WebCore::StyleRuleFilter::mutableProperties):
(WebCore::StyleRuleFilter::setProperties):
(WebCore::StyleRuleFilter::reportDescendantMemoryUsage):
* css/StyleRule.h:
(StyleRuleBase):
(WebCore::StyleRuleBase::isFilterRule):
(StyleRuleFilter):
(WebCore::StyleRuleFilter::create):
(WebCore::StyleRuleFilter::filterName):
(WebCore::StyleRuleFilter::properties):
(WebCore::StyleRuleFilter::copy):
* css/StyleSheetContents.cpp:
(WebCore::childRulesHaveFailedOrCanceledSubresources):
* css/WebKitCSSFilterRule.cpp: Added.
    WebKitCSSFilterRule is implemented similar to CSSFontFaceRule.
(WebCore::WebKitCSSFilterRule::WebKitCSSFilterRule):
(WebCore::WebKitCSSFilterRule::~WebKitCSSFilterRule):
(WebCore::WebKitCSSFilterRule::style):
(WebCore::WebKitCSSFilterRule::cssText):
    The CSS text implementation for WebKitCSSFilterRule is almost the same as
    CSSFontFaceRule. WebKitCSSFilterRule additionally needs to output the filter name in its
    syntax (e.g. @-webkit-filter my-filter { }).
(WebCore::WebKitCSSFilterRule::reattach):
(WebCore::WebKitCSSFilterRule::reportMemoryUsage):
* css/WebKitCSSFilterRule.h: Added.
(WebKitCSSFilterRule):
(WebCore::WebKitCSSFilterRule::create):
* css/WebKitCSSFilterRule.idl: Added.

LayoutTests:

Add positive and negative tests for parsing the @-webkit-filter rule.

Factored out common helper functions between the existing CSS Custom Filters parsing tests
and the new tests into custom-filter-parsing-common.js.

* css3/filters/custom/custom-filter-parsing-at-rule-invalid-expected.txt: Added.
* css3/filters/custom/custom-filter-parsing-at-rule-invalid.html: Added.
* css3/filters/custom/custom-filter-parsing-at-rule-valid-expected.txt: Added.
* css3/filters/custom/custom-filter-parsing-at-rule-valid.html: Added.
* css3/filters/custom/custom-filter-property-parsing-invalid.html:
* css3/filters/custom/custom-filter-property-parsing.html:
* css3/filters/script-tests/custom-filter-parsing-at-rule-invalid.js: Added.
(testInvalidFilterAtRule):
* css3/filters/script-tests/custom-filter-parsing-at-rule-valid.js: Added.
(testFilterAtRule):
    Tests @-webkit-filter rule parsing and its ability to hold CSS properties.
(testNestedRules):
    Tests nesting between at-rules, involving @-webkit-filter rules.
(checkRule):
    Factor out common rule checking functionality into its own helper function, so it can be
    reused.
* css3/filters/script-tests/custom-filter-parsing-common.js: Added.
(jsWrapperClass):
    Moved.
(shouldBeType):
    Moved.
* css3/filters/script-tests/custom-filter-property-parsing-invalid.js:
* css3/filters/script-tests/custom-filter-property-parsing.js:
* platform/chromium/css3/filters/custom/custom-filter-parsing-at-rule-valid-expected.txt:
    V8 represents WebKitCSSFilterRule a little differently.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140997 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Revert 140996
> Revert 130950
> BUG=163593

TBR=cevans@google.com

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Promote composited-scrolling layers to stacking containers.
https://bugs.webkit.org/show_bug.cgi?id=106142

Reviewed by Simon Fraser.

With this patch, RenderLayers that use composited scrolling are
treated as stacking contexts. Since isStackingContainer now depends on
the value of m_needsCompositedScrolling, special care needed to be
taken to ensure that the value of isStackingContainer is not used when
updating m_needsCompositedScrolling. In particular, the code for
rebuilding the layer lists needed to be generalized so that we could
build the layer lists using the value of isStackingContext rather than
isStackingContainer when building the layer lists used to determine if
the descendants are contiguous in stacking order. Also, updating
m_needsCompositedScrolling can now affect stacking container status
and can therefore dirty layer lists.

Source/WebCore:

Test: compositing/overflow/composited-scrolling-creates-a-stacking-container.html

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateDescendantsAreContiguousInStackingOrder):
  Modified to use layer lists built based on isStackingContext rather
  than isStackingContainer.
(WebCore::RenderLayer::updateNeedsCompositedScrolling):
  This function can now affect stacking container status and layer
  lists.
(WebCore::RenderLayer::rebuildZOrderLists):
  Refactored to generalize layer list building.
(WebCore::RenderLayer::collectLayers):
  This function can now stop at either stacking containers or
  contexts.
(WebCore::RenderLayer::updateLayerListsIfNeeded):
  Layer lists may need to be built a 2nd time if we opt into
  composited scrolling.
* rendering/RenderLayer.h:
(RenderLayer):
(WebCore::RenderLayer::isStackingContainer):
  Returns true if we use composited scrolling.

LayoutTests:

* compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt: Added.
* compositing/overflow/composited-scrolling-creates-a-stacking-container.html: Added.
* platform/chromium/TestExpectations:
* platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140999 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Revert 130950
BUG=163593

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141000 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move ensureUserAgentShadowRoot to Element
https://bugs.webkit.org/show_bug.cgi?id=108070

Reviewed by Dimitri Glazkov.

Move ensureUserAgentShadowRoot to Element where the other
methods related to shadow roots are and get rid of the
unnecessarily specific cast to HTMLElement.

No new tests, just refactoring.

* dom/Element.cpp:
(WebCore::Element::ensureUserAgentShadowRoot): Moved from FormAssociatedElement.
* dom/Element.h:
(Element):
* html/FormAssociatedElement.cpp:
* html/FormAssociatedElement.h:
(FormAssociatedElement):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141002 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[wk2] WKView's intrinsicContentSize should only report a flexible width if the content width is less than the minimum width
https://bugs.webkit.org/show_bug.cgi?id=108056

Reviewed by Simon Fraser.

We're currently reporting a flexible width if the intrinsic
content size is less than *or equal* to the minimum layout
width. This is wrong and causes ping-ponging between flexible
and inflexible width in cases where autolayout fits our
view to exactly the intrinsic content size. It should be strictly
less than instead.

* UIProcess/API/mac/WKView.mm:
(-[WKView _setIntrinsicContentSize:]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141003 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin: getMainResourceDataOfFrame should return PDFPlugin's data so that Save... works
https://bugs.webkit.org/show_bug.cgi?id=108060
<rdar://problem/13075454>

Reviewed by Sam Weinig.

* WebProcess/Plugins/Netscape/NetscapePlugin.h: Implement getResourceData.
* WebProcess/Plugins/PDF/SimplePDFPlugin.h:
* WebProcess/Plugins/PDF/SimplePDFPlugin.mm: Implement getResourceData, returning the accumulated
data if it exists and has finished loading.
(WebKit::SimplePDFPlugin::getResourceData):
* WebProcess/Plugins/Plugin.h: Add getResourceData, which hands out a raw pointer/size pair
to the plugin's "main resource" data.
* WebProcess/Plugins/PluginProxy.h: Implement getResourceData.
* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::getResourceData): Forward getResourceData through to the plugin.
* WebProcess/Plugins/PluginView.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::getMainResourceDataOfFrame): If the requested frame is backed by a PluginDocument,
attempt to ask the PluginView for its resource data.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141004 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move hasAuthorShadowRoot to Element
https://bugs.webkit.org/show_bug.cgi?id=108071

Reviewed by Dimitri Glazkov.

Move hasAuthorShadowRoot to Element and get rid of unneccesary booleans
in HTMLProgressElement and HTMLMeterElement. Also get rid of
ShadowRoot::isAccessible since it obfuscates what's actually happening
inside of Element::shadowRoot().

No new tests, just refactoring.

* dom/Element.cpp:
(WebCore::Element::shadowRoot):
(WebCore::Element::hasAuthorShadowRoot):
* dom/Element.h:
(Element):
* dom/ShadowRoot.h:
* html/HTMLMeterElement.cpp:
(WebCore::HTMLMeterElement::HTMLMeterElement):
* html/HTMLMeterElement.h:
(HTMLMeterElement):
* html/HTMLProgressElement.cpp:
(WebCore::HTMLProgressElement::HTMLProgressElement):
* html/HTMLProgressElement.h:
(HTMLProgressElement):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141005 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] WebConsoleMessage is missing LevelDebug (chromium bug 172416)
https://bugs.webkit.org/show_bug.cgi?id=108004
http://code.google.com/p/chromium/issues/detail?id=172416

console.debug triggers a NOTREACHED() assertation in Chromium. This
is because WebCore::MessageLevel contains 5 levels, including debug,
where WebConsoleMessage::Level is missing a "debug" level. Add a
WebConsoleMessage::LevelDebug so that it can get passed up to the
renderer even if it doesn't make use of that now.

Requires another patch to chromium itself to fix chromium bug 172416
but this is a prerequisite.

Also add an enum compile time check to AssertMatchingEnums.cpp,

Patch by Kevin Day <kevinday@gmail.com> on 2013-01-28
Reviewed by Jochen Eisinger.

* public/WebConsoleMessage.h:
* src/AssertMatchingEnums.cpp:
* src/WebFrameImpl.cpp:
(WebKit::WebFrameImpl::addMessageToConsole):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141006 268f45cc-cd09-0410-ab3c-d52691b4dbfc
"clang: warning: not using the clang compiler for C++ inputs" due to hard-coding of /usr/bin/clang in WebCore.gyp
https://bugs.webkit.org/show_bug.cgi?id=108089

Reviewed by Ojan Vafai.

Use gcc since older versions of clang (with Xcode 3.2) warn that they are going to use gcc anyway.
These warnings are showing up on the main Chromium waterfall too:
http://build.chromium.org/p/chromium/builders/Mac/builds/19113/steps/compile/logs/stdio

No new tests, this is a build change.

* WebCore.gyp/WebCore.gyp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141007 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL][WK2] Use C API inside ewk_download_job
https://bugs.webkit.org/show_bug.cgi?id=107810

Reviewed by Anders Carlsson.

Use C API inside ewk_download_job instead of accessing internal C++
classes directly, to avoid violating API layering.

* UIProcess/API/C/WKDownload.cpp:
(WKDownloadGetID): Add C API to get the download ID as we need it to
support our public API and it seems like a useful addition.
* UIProcess/API/C/WKDownload.h:
* UIProcess/API/efl/ewk_download_job.cpp:
(EwkDownloadJob::EwkDownloadJob):
(EwkDownloadJob::id):
(EwkDownloadJob::request):
(EwkDownloadJob::cancel):
* UIProcess/API/efl/ewk_download_job_private.h:
(EwkDownloadJob::create):
(EwkDownloadJob):
* UIProcess/efl/DownloadManagerEfl.cpp:
(WebKit::DownloadManagerEfl::decideDestinationWithSuggestedFilename):
(WebKit::DownloadManagerEfl::didReceiveResponse):
(WebKit::DownloadManagerEfl::didCreateDestination):
(WebKit::DownloadManagerEfl::didReceiveData):
(WebKit::DownloadManagerEfl::didFail):
(WebKit::DownloadManagerEfl::didCancel):
(WebKit::DownloadManagerEfl::didFinish):
(WebKit::DownloadManagerEfl::registerDownloadJob): Rename
registerDownload() to registerDownloadJob() for consistency with
unregisterDownloadJob().
(WebKit::DownloadManagerEfl::ewkDownloadJob): Rename downloadJob() to
ewkDownloadJob() for clarity since it returns a EwkDownload object.
Also take a WKDownloadRef in argument instead of an identifier since
all the callers have a WKDownloadRef and it makes their code simpler.
Finally, make the getter non-const since it returns a non-const pointer.
(WebKit::DownloadManagerEfl::unregisterDownloadJob): Take a
WKDownloadRef in argument instead of an identifier since all the
callers have a WKDownloadRef and it makes their code simpler.
* UIProcess/efl/DownloadManagerEfl.h:
(DownloadManagerEfl):
* UIProcess/efl/PageClientBase.cpp:
(WebKit::PageClientBase::handleDownloadRequest):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141008 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash inside RenderBlock::layoutRunsAndFloatsInRange in the widow code
https://bugs.webkit.org/show_bug.cgi?id=108084

Reviewed by Dean Jackson.

This is a blind fix based on the code and Chromium's stack-traces.

Unfortunately no new test as I couldn't get a local reproduction.

* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::layoutRunsAndFloatsInRange):
Added a missing NULL-check: the previous 'while' finish if |lineBox|
is NULL and we don't want to crash in this case.


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