The computed values of fix length padding should be subpixel precision like margin
https://bugs.webkit.org/show_bug.cgi?id=118936

Reviewed by Simon Fraser.

Source/WebCore: 

The bug was caused by ComputedStyleExtractor::propertyValue always returning the used value
for padding. Fixed the bug by returning the computed value when they're of fixed length.

This aligns the behaviors of getComputedStyle(~).padding~ with getComputedStyle(~).margin~,
which had been fixed in r102149. While the current CSSOM specification says getComputedStyle
should return the used values for margins when display property is set to anything but none,
new behavior matches that of Chrome, Firefox, and Internet Explorer.

Also extracted zoomAdjustedPaddingOrMarginPixelValue to reduce the code duplication.

Test: fast/css/getComputedStyle/getComputedStyle-padding-margin-subpixel-length.html

* css/CSSComputedStyleDeclaration.cpp:
(WebCore::zoomAdjustedPaddingOrMarginPixelValue): Extracted.
(WebCore::ComputedStyleExtractor::propertyValue):

LayoutTests: 

Add a regression test for obtaining the computed values of floating point padding and margin.
They shouldn't be rounded to whole pixels.

* fast/css/getComputedStyle/getComputedStyle-padding-margin-subpixel-length-expected.txt: Added.
* fast/css/getComputedStyle/getComputedStyle-padding-margin-subpixel-length.html: Added.
* fast/shapes/shape-inside/shape-inside-shape-logical-top-expected.html: Use a different technique to detect
the subpixel layout since paddings


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153067 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Pixel-snap the unavailable plugin indicator arrow for maximum sharpness
https://bugs.webkit.org/show_bug.cgi?id=119024
<rdar://problem/14523331>

Reviewed by Anders Carlsson.

* rendering/RenderEmbeddedObject.cpp:
(WebCore::addReplacementArrowPath):
(WebCore::RenderEmbeddedObject::getReplacementTextGeometry):
Pixel-snap the unavailable plugin indicator arrow. Snapping directions
were chosen by eye/symmetry to look best on 1x and 2x devices at
1x and 2x page scale.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153068 268f45cc-cd09-0410-ab3c-d52691b4dbfc
10.7: Java applets do not work due to sandbox violation/exception
https://bugs.webkit.org/show_bug.cgi?id=118920
<rdar://problem/14471541&12910934&14223830&14260729&14267679>

Patch by Simon Cooper <scooper@apple.com> on 2013-07-23
Reviewed by Alexey Proskuryakov.

Introduce versioning into the common profile and use it to fix
a number of issues with Java on 10.7 and 10.8. Allow writing the
com.apple.java.util.prefs preference file. This change also
introduces a "/Library/Application Support/Java/PublicFiles"
area which Java can read without any restrictions. Files written
to this location will need to be created and written to by
a privileged process.

* Resources/PlugInSandboxProfiles/com.apple.WebKit.plugin-common.sb:
* Resources/PlugInSandboxProfiles/com.oracle.java.JavaAppletPlugin.sb:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153070 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Removed unused sourceOffset from JSTokenLocation.
https://bugs.webkit.org/show_bug.cgi?id=118996.

Reviewed by Geoffrey Garen.

This also removes the assertion reported in the bug because it is now
moot, thereby resolving the assertion failure issue on Windows.

* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::toArgumentList):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
* parser/Lexer.cpp:
(JSC::::lex):
* parser/Lexer.h:
(JSC::::lexExpectIdentifier):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::::Parser):
(JSC::::parseFunctionInfo):
(JSC::::parseExpressionOrLabelStatement):
(JSC::::parseMemberExpression):
* parser/Parser.h:
(JSC::::parse):
* parser/ParserTokens.h:
(JSC::JSTokenLocation::JSTokenLocation):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153071 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(r150867): FrameView auto-sizing + delegate denied image load may cause StyleResolver to re-enter itself.
<rdar://problem/14324895>
<http://webkit.org/b/119023>

Reviewed by Simon Fraser.

Source/WebCore:

The bug happened when FrameView::autoSizeIfEnabled() was getting called below FrameLoader::checkCompleted()
triggered by an incorrect loadDone() callback originating in SubresourceLoader::didCancel().

* css/StyleResolver.cpp:
(WebCore::StyleResolver::loadPendingResources):

    Add an assertion that this function is not getting re-entered. If a similar bug occurs
    in the future, this will help the lucky person debugging.

* loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didCancel):

    Don't notifyDone() if the SubresourceLoader is in Uninitialized state.

Tools:

Add a test for this rather specific problem.

* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKit2ObjC/PreventImageLoadWithAutoResizing.mm: Added.
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKit2ObjC/PreventImageLoadWithAutoResizing_Bundle.cpp: Added.
(TestWebKitAPI::DenyWillSendRequestTest::DenyWillSendRequestTest):
(TestWebKitAPI::DenyWillSendRequestTest::willSendRequestForFrame):
(TestWebKitAPI::DenyWillSendRequestTest::didCreatePage):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153072 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Added ExpressionRangeInfo for BinaryOpNodes that can throw exceptions
due to type coersion.
https://bugs.webkit.org/show_bug.cgi?id=116853.

Reviewed by Geoffrey Garen.

Source/JavaScriptCore: 

* bytecompiler/NodesCodegen.cpp:
(JSC::BinaryOpNode::emitBytecode):
- Added expression info for the strcat and the general binary op cases.
  I did not add expression info for the "compare with null" case because
  that comparison cannot trigger type coersion, and hence it won't throw
  any exceptions and doesn't need the expression info.

LayoutTests: 

Added the test case from bugzilla which exercises the general binary op
type coersion case, plus another for exercising the strcat case.

* fast/js/line-column-numbers-expected.txt:
* fast/js/line-column-numbers.html:
* fast/js/script-tests/line-column-numbers.js:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153073 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Need ExpressionRangeInfo before ResolveForPuts in strict mode.
https://bugs.webkit.org/show_bug.cgi?id=118997.

Reviewed by Oliver Hunt.

If we add an assertion in UnlinkedCodeBlock::expressionRangeForBytecodeOffset()
to ensure that we are able to find an ExpressionRangeInfo for any given bytecode
offset, the following tests will fails:
    fast/js/basic-strict-mode.html
    fast/js/mozilla/strict/8.7.2.html
With this fix, those tests will no longer fail.

* bytecompiler/NodesCodegen.cpp:
(JSC::AssignResolveNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
- Emit expression info before calls to emitResolveBaseForPut() when in strict mode.



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