Use-after-free in CompositeEditCommand::cloneParagraphUnderNewElement
https://bugs.webkit.org/show_bug.cgi?id=114911

Reviewed by Oliver Hunt.

Back ported https://src.chromium.org/viewvc/blink?revision=148680&view=revision.

* editing/CompositeEditCommand.cpp:
(WebCore::CompositeEditCommand::cloneParagraphUnderNewElement):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148908 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Update about:config lists
https://bugs.webkit.org/show_bug.cgi?id=114967

Patch by Eli Fidler <efidler@blackberry.com> on 2013-04-22
Reviewed by Rob Buis.

* WebCoreSupport/AboutDataEnableFeatures.in:
* WebCoreSupport/AboutDataHaveFeatures.in:
* WebCoreSupport/AboutDataUseFeatures.in:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148909 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        <rdar://problem/13334446> [Mac] Tweak sandbox profiles.

        Reviewed by Sam Weinig.

        * NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:
        * WebProcess/com.apple.WebProcess.sb.in:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148910 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Slow/beachballing when using the find bar on a page with plug-ins
https://bugs.webkit.org/show_bug.cgi?id=114990
<rdar://problem/12832313>

Reviewed by Tim Horton.

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::notifyWidget):
Call shouldCreateTransientPaintingSnapshot().

(WebKit::PluginView::shouldCreateTransientPaintingSnapshot):
Don't create a painting snapshot if we're asked to paint the find indicator.

* WebProcess/Plugins/PluginView.h:
Add new member function.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148911 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin: Support unlocking encrypted PDFs
https://bugs.webkit.org/show_bug.cgi?id=114938
<rdar://problem/12872888>

Reviewed by Alexey Proskuryakov and Oliver Hunt.

If we try to load an encrypted PDF, we need to provide a sane mechanism
through which the user can provide the password. Add a slightly-below-center
password field to match PDFKit's normal behavior.

* WebKit2.xcodeproj/project.pbxproj: Add PDFPluginPasswordField.{h,mm}
* WebProcess/Plugins/PDF/PDFLayerControllerDetails.h: Add attemptToUnlockWithPassword:
* WebProcess/Plugins/PDF/PDFPlugin.h:
Add createPasswordEntryForm, attemptToUnlockPDF, m_passwordField.
* WebProcess/Plugins/PDF/PDFPlugin.mm:
(annotationStyle): Make #annotationContainer a flexbox that centers its contents.
This won't affect the normal absolutely-positioned form fields, but the inline
password field will be centered vertically and horizontally.

(WebKit::PDFPlugin::pdfDocumentDidLoad):
If the document is locked when loaded, create a password field.

(WebKit::PDFPlugin::createPasswordEntryForm):
Create a PDFPluginPasswordField and attach it to the document.

(WebKit::PDFPlugin::attemptToUnlockPDF):
Try to unlock the PDF with the given password. If this succeeds, remove
the password field and relayout the scroll view.

(WebKit::PDFPlugin::calculateSizes):
Make the document 0x0 if it is locked, preventing scrolling.

(WebKit::PDFPlugin::handleMouseEvent):
Don't pass mouse events to PDFLayerController while it is locked,
as it has no useful events to provide, and will try to present a
dialog asking for the password if we let a click through.

* WebProcess/Plugins/PDF/PDFPluginAnnotation.h:
(WebKit::PDFPluginAnnotation::eventListener): Added.
* WebProcess/Plugins/PDF/PDFPluginAnnotation.mm:
(WebKit::PDFPluginAnnotation::handleEvent):
Move event-handling code here from PDFPluginAnnotationEventListener::handleEvent
so that subclasses can override this instead of having to have their own
event listeners (this is also why we now expose eventListener()).

(WebKit::PDFPluginAnnotation::PDFPluginAnnotationEventListener::handleEvent):
Forward the event to our owning PDFPluginAnnotation.

* WebProcess/Plugins/PDF/PDFPluginPasswordField.h: Added.
(WebKit::PDFPluginPasswordField::PDFPluginPasswordField):
* WebProcess/Plugins/PDF/PDFPluginPasswordField.mm: Added.
(WebKit::PDFPluginPasswordField::create):
(WebKit::PDFPluginPasswordField::~PDFPluginPasswordField):
Unregister for keyup.

(WebKit::PDFPluginPasswordField::createAnnotationElement):
Register for keyup, and set our element's class to "password".

(WebKit::PDFPluginPasswordField::updateGeometry):
Added. Override updateGeometry and do nothing, as the password field
has a geometry defined by CSS instead of by the PDF content.

(WebKit::PDFPluginPasswordField::handleEvent):
If the enter/return key is pressed, attempt to unlock the PDF. Also,
we do not call either of our superclass' implementations of handleEvent,
because blurring the password field should not destroy it, and tabbing
between fields has no relevance when there can only be one field.

* WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:
(WebKit::PDFPluginTextAnnotation::PDFPluginTextAnnotationEventListener):
Removed. We now share our superclass' event listener.

(WebKit::PDFPluginTextAnnotation::textAnnotation): Const.
* WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:
(WebKit::PDFPluginTextAnnotation::~PDFPluginTextAnnotation):
PDFPluginTextAnnotation no longer has its own event listener,
so there's nothing left to clear here. Just make sure to unregister
our event from PDFPluginAnnotation's shared event listener!

(WebKit::PDFPluginTextAnnotation::createAnnotationElement):
Ensure that we can create a PDFPluginTextAnnotation with a null annotation.

(WebKit::PDFPluginTextAnnotation::commit): Use value().
(WebKit::PDFPluginTextAnnotation::value):
Factor retrieving the value of the form control out of commit().

(WebKit::PDFPluginTextAnnotation::handleEvent):
Call up to PDFPluginAnnotation's handler so that defocus destroys the annotation.

Export HTMLNames::typeAttr.

* WebCore.exp.in:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148912 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make it easier to extend NetworkResourceLoadParameters
https://bugs.webkit.org/show_bug.cgi?id=114992

Reviewed by Sam Weinig.

Turn NetworkResourceLoadParameters into a struct which matches all our other parameter classes in WebKit2. Fill in the struct manually
instead of having a constructor with 9 parameters.

* NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::performSynchronousLoad):
* NetworkProcess/SchedulableLoader.cpp:
(WebKit::SchedulableLoader::SchedulableLoader):
* Shared/Network/NetworkResourceLoadParameters.cpp:
(WebKit::NetworkResourceLoadParameters::NetworkResourceLoadParameters):
(WebKit::NetworkResourceLoadParameters::encode):
(WebKit::NetworkResourceLoadParameters::decode):
* Shared/Network/NetworkResourceLoadParameters.h:
(NetworkResourceLoadParameters):
* WebProcess/Network/WebResourceLoadScheduler.cpp:
(WebKit::WebResourceLoadScheduler::scheduleLoad):
* WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:
(WebKit::WebPlatformStrategies::loadResourceSynchronously):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148913 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Fix remaining introspection warnings
https://bugs.webkit.org/show_bug.cgi?id=114980

Reviewed by Gustavo Noronha Silva.

Source/WebCore:

* bindings/gobject/WebKitDOMCustom.h: Add scope and transfer annotations and flesh
out gtkdoc for completeness.
* bindings/gobject/WebKitDOMEventTarget.h:
(_WebKitDOMEventTargetIface): Ditto and also align virtual method names with those used
for the concrete ones.

Source/WebKit/gtk:

* webkit/webkitspellchecker.h:
(_WebKitSpellCheckerInterface): Align the name of the check_spelling_of_string virtual
method with the concrete method to avoid a g-ir-scanner warning.
* webkit/webkitversion.h.in: Skip WEBKITGTK_API_VERSION for introspection because it
doesn't follow the appropriate namespace name.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148914 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[css exclusions] shape-inside-recursive-layout.html should not yet test display: inline-grid
https://bugs.webkit.org/show_bug.cgi?id=114986

Reviewed by Dirk Schulze.

Because the inline-grid value is not yet supported, the test case is falling back to
display: block. This causes an incorrect layout, as block and inline content react to
shape-inside differently.

* fast/exclusions/shape-inside/shape-inside-recursive-layout-expected.html:
* fast/exclusions/shape-inside/shape-inside-recursive-layout.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148915 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Enable introspection always for developer builds
https://bugs.webkit.org/show_bug.cgi?id=114983

Reviewed by Gustavo Noronha Silva.

.:

* Source/autotools/SetupAutoconfHeader.m4: No longer expose the ENABLE_INTROSPECTION
autoconf header variable. It isn't used and it means that when introspection is enabled
or disabled, there is an unnecessary full rebuild.

Source/WebKit/gtk:

* GNUmakefile.am: Make warnings during gir scanning cause the build to fail. Eliminate
warnings about deprecated API that the g-ir-scanner uses when generating
the scanner program. Use --quiet to avoid printing lots of output to
non-verbose builds.

Source/WebKit2:

* GNUmakefile.am: Make warnings during gir scanning cause the build to fail. Eliminate
warnings about deprecated API that the g-ir-scanner uses when generating
the scanner program. Use --quiet.

Tools:

* Scripts/webkitdirs.pm:
(runAutogenForAutotoolsProjectIfNecessary): Always enable introspection
when using build-webkit.
* gtk/jhbuildrc: Enable documentation for all jhbuild modules and explicitly
choose the memory gsettings backend while in the jhbuild. This eliminates
warnings from programs that fall back to the memory backend.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148916 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        <rdar://problem/13334446> [Mac] Tweak sandbox profiles.

        Reviewed by Anders Carlsson.

        Unbreak Lion, which doesn't provide detailed control over IPC.

        * WebProcess/com.apple.WebProcess.sb.in:



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

* platform/mac-lion/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148918 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Plugin Snapshotting: Don't consume insane amounts of time detecting the primary plugin
https://bugs.webkit.org/show_bug.cgi?id=114994
<rdar://problem/13696269>

Reviewed by Anders Carlsson.

On some pages, we currently waste a lot of time on every subframe load
and every addPluginView doing primary plugin detection. This patch
attempts to address this via a few minor changes:

- Only allow detection after the main frame's didFinishLoad comes, instead of the first subframe.

- Only explicitly detect on the main frame's didFinishLoad (not subframes).

- Coalesce calls to determinePrimarySnapshottedPlugIn from both addPluginView
(in case JS is adding lots of plugins in a loop) and didFinishLoad.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::addPluginView): Coalesce calls to determinePrimarySnapshottedPlugIn.
(WebKit::WebPage::didFinishLoad):
Coalesce calls to determinePrimarySnapshottedPlugIn.
Bail on subframe loads, we're only interested in the main frame being complete.
(WebKit::WebPage::determinePrimarySnapshottedPlugInTimerFired):
Call determinePrimarySnapshottedPlugIn.
* WebProcess/WebPage/WebPage.h:
Add m_determinePrimarySnapshottedPlugInTimer and determinePrimarySnapshottedPlugInTimerFired


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148919 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Do not reuse ExclusionShapeInsideInfo in a recursive region layout
https://bugs.webkit.org/show_bug.cgi?id=114467

Reviewed by David Hyatt.

Source/WebCore:

Elements that respect shape-inside that have inline children should not reuse an
ExclusionShapeInsideInfo for their children's layout. This patch adds the test
for regions. See the details for non-region layout in bug 104582.
https://bugs.webkit.org/show_bug.cgi?id=104582

Test: fast/regions/shape-inside/shape-inside-recursive-layout.html

* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::layoutExclusionShapeInsideInfo): Do not look up a region's
ExclusionShapeInsideInfo if a block is already respecting shape-inside.

LayoutTests:

Test that for various types of inline containers do not reuse
ExclusionShapeInsideInfo when laying out their children.

* fast/regions/shape-inside/shape-inside-recursive-layout-expected.html: Added.
* fast/regions/shape-inside/shape-inside-recursive-layout.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148920 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove the memory instrumentation code
https://bugs.webkit.org/show_bug.cgi?id=114931

Reviewed by Andreas Kling.

.: 

* Source/autotools/symbols.filter:

Source/JavaScriptCore: 

* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

Source/WebCore: 

The Memory Instrumentation code is unfinished and has already
become out of sync the objects it is supposed to represent.

The current approach does not seem maintainable, it is better to
remove it before someone gets hurt.

By removing the code, the binary become 1240976 bytes smaller.
Yep, almost 1 Mb, bringing WebCore to the size it has 5 months ago :)

* MostWebCoreFiles: remove the support for memory instrumentation.

Source/WebKit: 

* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:

Source/WebKit/mac: 

* WebView/WebRenderLayer.mm:

Source/WebKit/win: 

* WebKit.vcproj/WebKitExports.def.in:

Source/WTF: 

On Mac x86_64, the code removal cause the binary to be
9224 bytes smaller.

* GNUmakefile.list.am:
* WTF.pro:
* WTF.vcproj/WTF.vcproj:
* WTF.vcxproj/WTF.vcxproj:
* WTF.vcxproj/WTF.vcxproj.filters:
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/Forward.h:
* wtf/ListHashSet.h:
(ListHashSet):
(ListHashSetNodeAllocator):
(WTF::ListHashSetNodeAllocator::pool):
(WTF::ListHashSetNodeAllocator::pastPool):
* wtf/MemoryInstrumentation.cpp: Removed.
* wtf/MemoryInstrumentation.h: Removed.
* wtf/MemoryInstrumentationArrayBufferView.h: Removed.
* wtf/MemoryInstrumentationHashCountedSet.h: Removed.
* wtf/MemoryInstrumentationHashMap.h: Removed.
* wtf/MemoryInstrumentationHashSet.h: Removed.
* wtf/MemoryInstrumentationListHashSet.h: Removed.
* wtf/MemoryInstrumentationSequence.h: Removed.
* wtf/MemoryInstrumentationString.h: Removed.
* wtf/MemoryInstrumentationVector.h: Removed.
* wtf/MemoryObjectInfo.h: Removed.
* wtf/text/AtomicString.h:
* wtf/text/StringImpl.h:
(WTF::StringImpl::isASCIILiteral):
* wtf/text/WTFString.h:

Tools: 

* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MemoryInstrumentationTest.cpp: Removed.

LayoutTests: 

* inspector/profiler/memory-instrumentation-cached-images-expected.txt: Removed.
* inspector/profiler/memory-instrumentation-cached-images.html: Removed.
* inspector/profiler/memory-instrumentation-canvas-expected.txt: Removed.
* inspector/profiler/memory-instrumentation-canvas.html: Removed.
* inspector/profiler/memory-instrumentation-external-array-expected.txt: Removed.
* inspector/profiler/memory-instrumentation-external-array.html: Removed.
* inspector/profiler/memory-instrumentation-external-string-expected.txt: Removed.
* inspector/profiler/memory-instrumentation-external-string.html: Removed.
* inspector/profiler/memory-instrumentation-test.js: Removed.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148921 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web process should decide when to continue main resource loads
https://bugs.webkit.org/show_bug.cgi?id=114995

Reviewed by Sam Weinig.

Main resource loads can be converted to downloads, so we need the ability to let the web process decide when
to continue loading after a response has been received.

* NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didReceiveResponseAsync):
For non-main resources, just call continueDidReceiveResponse directly; there's no need to ping-pong to the web process in that case.

(WebKit::NetworkResourceLoader::continueDidReceiveResponse):
Just call ResourceHandle::continueDidReceiveResponse.

* NetworkProcess/NetworkResourceLoader.messages.in:
Add ContinueDidReceiveResponse message.

* NetworkProcess/SchedulableLoader.cpp:
(WebKit::SchedulableLoader::SchedulableLoader):
Initialize m_isLoadingMainResource.

* NetworkProcess/SchedulableLoader.h:
(WebKit::SchedulableLoader::isLoadingMainResource):
Add getter.

(SchedulableLoader):
Move m_shouldClearReferrerOnHTTPSToHTTPRedirect next to the rest of the booleans.

* Shared/Network/NetworkResourceLoadParameters.cpp:
(WebKit::NetworkResourceLoadParameters::NetworkResourceLoadParameters):
(WebKit::NetworkResourceLoadParameters::encode):
(WebKit::NetworkResourceLoadParameters::decode):
* Shared/Network/NetworkResourceLoadParameters.h:
(NetworkResourceLoadParameters):
Add isMainResource flag.

* WebProcess/Network/WebResourceLoadScheduler.cpp:
(WebKit::WebResourceLoadScheduler::scheduleSubresourceLoad):
Pass the cached resource to scheduleLoad.

(WebKit::WebResourceLoadScheduler::schedulePluginStreamLoad):
Pass null to scheduleLoad.

(WebKit::WebResourceLoadScheduler::scheduleLoad):
Initialize isMainResource.

* WebProcess/Network/WebResourceLoader.cpp:
(WebKit::WebResourceLoader::didReceiveResponseWithCertificateInfo):
If this is a main resource load, send back a ContinueDidReceiveResponse message.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148922 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Cairo] Canvas-shadow behavior is not being as expected
https://bugs.webkit.org/show_bug.cgi?id=108897

Patch by Rashmi Shyamasundar <rashmi.s2@samsung.com> on 2013-04-22
Reviewed by Martin Robinson.

Source/WebCore:

Use the pattern-extend-mode "CAIRO_EXTEND_NONE" instead of "CAIRO_EXTEND_PAD" in
PlatformContextCairo::drawSurfaceToContext().

In the function PlatformContextCairo::drawSurfaceToContext(), a pattern is being
created from the source surface and this pattern is drawn onto the destination
context. There is no gradient involved. Hence the extend mode for filling the
pattern should be "CAIRO_EXTEND_NONE". If we use the extend mode
"CAIRO_EXTEND_PAD" in PlatformContextCairo::drawSurfaceToContext(), the original
image area is also filled with the shadow color which is not the expected behavior.

Test: fast/canvas/canvas-image-shadow.html

* platform/graphics/cairo/PlatformContextCairo.cpp:
(WebCore::PlatformContextCairo::drawSurfaceToContext):

LayoutTests:

Test to verify the shadow of an image drawn on canvas.
This test uses an image whose size is smaller than,
the size of the rectangle which should be filled with the image.

* fast/canvas/canvas-image-shadow-expected.txt: Added.
* fast/canvas/canvas-image-shadow.html: Added.
* fast/canvas/green.png: Added.
* fast/canvas/script-tests/canvas-image-shadow.js: Added.
(draw):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148923 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Windows build fix after r148921

Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-04-22

* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148924 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Mac debug build fix after r148921

Unreviewed.

Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-04-22

* page/animation/CompositeAnimation.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148925 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add branchAdd32 missing implementation in SH4 base JIT.
This should fix SH4 build, broken since r148893.
https://bugs.webkit.org/show_bug.cgi?id=114993.

Patch by Julien Brianceau <jbrianceau@nds.com> on 2013-04-22
Reviewed by Oliver Hunt.

* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchAdd32):
(MacroAssemblerSH4):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148926 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Another Windows build fix after r148921

Unreviewed.

Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-04-22

* AccessibleBase.cpp: Add missing header include.


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