Crash due to floats not removed from first-letter element.
https://bugs.webkit.org/show_bug.cgi?id=86019

Reviewed by Julien Chaffraix.

Source/WebCore:

Move clearing logic of a floating/positioned object from removeChild
to removeChildNode. There are lot of places which use removeChildNode
directly and hence the object is not removed from the floating or
positioned objects list.

Test: fast/block/float/float-not-removed-from-first-letter.html

* rendering/RenderObject.cpp:
(WebCore::RenderObject::removeChild):
* rendering/RenderObjectChildList.cpp:
(WebCore::RenderObjectChildList::removeChildNode):

LayoutTests:

* fast/block/float/float-not-removed-from-first-letter-expected.txt: Added.
* fast/block/float/float-not-removed-from-first-letter.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Caret node boundary should be adjusted to account for the visible region.
https://bugs.webkit.org/show_bug.cgi?id=86116

Reviewed by Antonio Gomes.

PR 138988.

Update the node bounding box to be clipped and adjusted
for the visible region of the frame.

Reviewed Internally by Gen Mak.

* WebKitSupport/SelectionHandler.cpp:
(BlackBerry::WebKit::SelectionHandler::caretPositionChanged):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116684 268f45cc-cd09-0410-ab3c-d52691b4dbfc
<rdar://problem/10972577> and https://bugs.webkit.org/show_bug.cgi?id=80170
Contents of noscript elements turned into strings in WebArchives

Source/WebCore:

Reviewed by Andy Estes.

There's a much deeper question about how innerHTML of <noscript> is expected to work in
both a scripting and non-scripting environment that we should pursue separately.

But for webarchives, we can solve this by filtering out the <noscript> elements completely
if scripting is enabled.

Test: webarchive/ignore-noscript-if-scripting-enabled.html

* WebCore.exp.in:

Add arguments to createMarkup and MarkupAccumulator methods to pass a Vector of QualifiedNames
that should be filtered from the resulting markup:
* editing/MarkupAccumulator.cpp:
(WebCore::MarkupAccumulator::serializeNodes):
(WebCore::MarkupAccumulator::serializeNodesWithNamespaces):
* editing/MarkupAccumulator.h:
* editing/markup.cpp:
(WebCore::createMarkup):
* editing/markup.h:

If scripting is enabled, add the noscriptTag to the tag names to filter:
* loader/archive/cf/LegacyWebArchive.cpp:
(WebCore::LegacyWebArchive::create):

LayoutTests:

Reviewed by Andy Estes.

* webarchive/ignore-noscript-if-scripting-enabled-expected.txt: Added.
* webarchive/ignore-noscript-if-scripting-enabled.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116685 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] WebFrameTest.ChromePageNoJavascript isn't catching regressions
https://bugs.webkit.org/show_bug.cgi?id=86046

Reviewed by Adam Barth.

Test both cases for registerURLSchemeAsNotAllowingJavascriptURLs.  Also add
a call to layout() to ensure the javascript result is seen.

* tests/WebFrameTest.cpp:
(WebKit::TEST_F):
(WebKit):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116686 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rename the missing plug-in indicator to the unavailable plug-in indicator
https://bugs.webkit.org/show_bug.cgi?id=86136

Reviewed by Sam Weinig.

Source/WebCore:

Since the indicator is shown for more than just missing plug-ins, generalize it and use a plug-in unavailability
reason enum to make it easier to extend. Also, pass the unavailability reason to the ChromeClient member functions.

* WebCore.exp.in:
* html/HTMLEmbedElement.cpp:
(WebCore::HTMLEmbedElement::updateWidget):
* html/HTMLObjectElement.cpp:
(WebCore::HTMLObjectElement::updateWidget):
* html/HTMLPlugInElement.cpp:
(WebCore::HTMLPlugInElement::defaultEventHandler):
* html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::updateWidgetIfNecessary):
* loader/SubframeLoader.cpp:
(WebCore::SubframeLoader::loadPlugin):
* page/ChromeClient.h:
(WebCore::ChromeClient::shouldUnavailablePluginMessageBeButton):
(WebCore::ChromeClient::unavailablePluginButtonClicked):
* page/FrameView.cpp:
(WebCore::FrameView::updateWidget):
* rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::RenderEmbeddedObject):
(WebCore::RenderEmbeddedObject::setPluginUnavailabilityReason):
(WebCore::RenderEmbeddedObject::showsUnavailablePluginIndicator):
(WebCore::RenderEmbeddedObject::setUnavailablePluginIndicatorIsPressed):
(WebCore::RenderEmbeddedObject::paint):
(WebCore::RenderEmbeddedObject::paintReplaced):
(WebCore::RenderEmbeddedObject::getReplacementTextGeometry):
(WebCore::RenderEmbeddedObject::unavailablePluginReplacementText):
(WebCore):
(WebCore::RenderEmbeddedObject::isInUnavailablePluginIndicator):
(WebCore::shouldUnavailablePluginMessageBeButton):
(WebCore::RenderEmbeddedObject::handleUnavailablePluginIndicatorEvent):
(WebCore::RenderEmbeddedObject::getCursor):
* rendering/RenderEmbeddedObject.h:
(RenderEmbeddedObject):

Source/WebKit/mac:

* Plugins/Hosted/WebHostedNetscapePluginView.mm:
(-[WebHostedNetscapePluginView pluginHostDied]):
* WebCoreSupport/WebChromeClient.h:
* WebCoreSupport/WebChromeClient.mm:
(WebChromeClient::shouldUnavailablePluginMessageBeButton):
(WebChromeClient::unavailablePluginButtonClicked):

Source/WebKit/win:

* WebCoreSupport/WebChromeClient.cpp:
(WebChromeClient::shouldUnavailablePluginMessageBeButton):
(WebChromeClient::unavailablePluginButtonClicked):
* WebCoreSupport/WebChromeClient.h:
(WebChromeClient):

Source/WebKit2:

Update for WebCore changes.

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::pluginProcessCrashed):
* WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::shouldUnavailablePluginMessageBeButton):
(WebKit::WebChromeClient::unavailablePluginButtonClicked):
* WebProcess/WebCoreSupport/WebChromeClient.h:
(WebChromeClient):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116687 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ScrollView::fixedVisibleContentRect should be public
https://bugs.webkit.org/show_bug.cgi?id=86147

Reviewed by Eric Seidel.

Some code in the WebKit layer of OS(ANDROID) uses this function. That
could will be upstreamed in a later patch. For now, this patch just
makes this function public so that we remove the diff to this file.

* platform/ScrollView.h:
(WebCore::ScrollView::fixedVisibleContentRect):
(WebCore::ScrollView::delegatesScrollingDidChange):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116688 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Remove WEBKIT_USING_SKIA ifdefs that are always true
https://bugs.webkit.org/show_bug.cgi?id=86121

Reviewed by Adam Barth.

Chromium always uses Skia now, so this just removes the barriers
around code that was previously #if'd.

Source/Platform:

* chromium/public/WebCanvas.h:
(WebKit):
* chromium/public/WebGraphicsContext3D.h:
(WebGraphicsContext3D):
(WebKit::WebGraphicsContext3D::onCreateGrGLInterface):
* chromium/public/WebImage.h:
(WebImage):

Source/WebKit/chromium:

* README:
* src/DragClientImpl.cpp:
(WebKit::DragClientImpl::startDrag):
* src/PageOverlay.cpp:
* src/PlatformSupport.cpp:
(WebCore::PlatformSupport::clipboardWriteImage):
(WebCore::PlatformSupport::paintScrollbarThumb):
* src/WebContentLayerImpl.cpp:
(WebKit::WebContentLayerImpl::paintContents):
* src/WebFontImpl.cpp:
(WebKit::WebFontImpl::drawText):
* src/WebFrameImpl.cpp:
(WebKit::WebFrameImpl::printPage):
(WebKit::WebFrameImpl::printPagesWithBoundaries):
* src/WebGraphicsContext3D.cpp:
(WebKit::WebGraphicsContext3D::createGrGLInterface):
* src/WebImageDecoder.cpp:
(WebKit::WebImageDecoder::getFrameAtIndex):
* src/WebPluginContainerImpl.cpp:
(WebKit::WebPluginContainerImpl::paint):
(WebKit::WebPluginContainerImpl::printPage):
* src/painting/GraphicsContextBuilder.h:
(WebKit):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116689 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Call addTraceEvent and getTraceCategoryEnabledFlag directly
https://bugs.webkit.org/show_bug.cgi?id=85399

Reviewed by Adam Barth.

Part of a refactoring series. See tracking bug 82948.

Source/WebCore:

* CMakeLists.txt:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* platform/EventTracer.cpp: Added.
(WebCore):
(WebCore::EventTracer::getTraceCategoryEnabledFlag):
(WebCore::EventTracer::addTraceEvent):
* platform/EventTracer.h: Added.
(WebCore):
(EventTracer):
* platform/chromium/EventTracerChromium.cpp: Added.
(WebCore):
(WebCore::EventTracer::getTraceCategoryEnabledFlag):
(WebCore::EventTracer::addTraceEvent):
* platform/chromium/PlatformSupport.h:
* platform/chromium/TraceEvent.h:

Source/WebKit/chromium:

* src/PlatformSupport.cpp:
(WebCore):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116690 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ASSERT in BidiResolver<Iterator, Run>::commitExplicitEmbedding makes running debug builds annoying
https://bugs.webkit.org/show_bug.cgi?id=86140

Reviewed by Eric Seidel.

The correct fix here is to resolve
https://bugs.webkit.org/show_bug.cgi?id=76574, but in the mean time,
this ASSERT is annoying.

* platform/text/BidiResolver.h:
(WebCore::::commitExplicitEmbedding):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116691 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[webkitpy][EFL] It should be possible to use a wrapper command for ImageDiff.
https://bugs.webkit.org/show_bug.cgi?id=86145

Reviewed by Dirk Pranke.

The GTK+ and EFL ports use jhbuild to build a few base libraries
which are then used when building the port itself. Programs such
as DRT and ImageDiff are then supposed to be run with the
`run-with-jhbuild' wrapper so that the libraries are properly
found and loaded.

This was already the case for DumpRenderTree (EflPort defines the
'wrapper' option for that), but it was not possible to do the same
with ImageDiff so far.

The code which created the ImageDiff command-line call has been
moved to a separate method, _image_diff_command, which is then
overridden by EflPort to add the jhbuild wrapper.

* Scripts/webkitpy/layout_tests/port/efl.py:
(EflPort.__init__):
(EflPort._image_diff_command):
* Scripts/webkitpy/layout_tests/port/webkit.py:
(WebKitPort):
(WebKitPort._image_diff_command):
(WebKitPort._start_image_diff_process):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116692 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash in computedCSSPadding* functions due to RenderImage::imageDimensionsChanged called during attachment
https://bugs.webkit.org/show_bug.cgi?id=85912

Reviewed by Eric Seidel.

Source/WebCore:

Tests: fast/images/link-body-content-imageDimensionChanged-crash.html
       fast/images/script-counter-imageDimensionChanged-crash.html

The bug comes from CSS generated images that could end up calling imageDimensionsChanged during attachment. As the
rest of the code (e.g. computedCSSPadding*) would assumes that we are already inserted in the tree, we would crash.

The solution is to bail out in this case as newly inserted RenderObject will trigger layout later on and properly
handle what we would be doing as part of imageDimensionChanged (the only exception being updating our intrinsic
size which should be done as part of imageDimensionsChanged).

* rendering/RenderImage.cpp:
(WebCore::RenderImage::imageDimensionsChanged):

LayoutTests:

* fast/images/link-body-content-imageDimensionChanged-crash-expected.txt: Added.
* fast/images/link-body-content-imageDimensionChanged-crash.html: Added.
* fast/images/script-counter-imageDimensionChanged-crash-expected.txt: Added.
* fast/images/script-counter-imageDimensionChanged-crash.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116693 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make IFRAME_SEAMLESS child documents inherit styles from their parent iframe element
https://bugs.webkit.org/show_bug.cgi?id=85940

Reviewed by Ojan Vafai.

Source/WebCore:

The HTML5 <iframe seamless> spec says:
In a CSS-supporting user agent: the user agent must, for the purpose of CSS property
inheritance only, treat the root element of the active document of the iframe
element's nested browsing context as being a child of the iframe element.
(Thus inherited properties on the root element of the document in the
iframe will inherit the computed values of those properties on the iframe
element instead of taking their initial values.)

Initially I implemented this support to the letter of the spec. However, doing so I learned
that WebKit has a RenderStyle for the Document Node, not just the root element of the document.
In this RenderStyle on the Document, we add a bunch of per-document styles from settings
including designMode.

This change makes StyleResolver::styleForDocument inherit style from the parent iframe's
style, before applying any of these per-document styles.  This may or may not be correct
depending on what behavior we want for rtl-ordering, page-zoom, locale, design mode, etc.
For now, we continue to treat the iframe's document as independent in these regards, and
the settings on that document override those inherited from the iframe.

Also, intially when making this work, I added redirects in recalcStyle and scheduleStyleRecalc
from the child document to the parent document in the case of seamless (since the parent
document effectively manages the style resolve and layout of the child in seamless mode).
However, I was not able to find a test which depended on this code change, so in this final patch
I have removed both of these modifications and replaced them with FIXMEs.  Based on discussions
with Ojan and James Robinson, I believe both of those changes may eventually be wanted.

This change basically does 3 things:
1.  Makes StyleResolver::styleForDocument inherit from the parent iframe.
2.  Makes any recalcStyle calls on the iframe propogate down into the child document (HTMLIFrameElement::didRecalcStyle).
3.  Makes Document::recalcStyle aware of the fact that the Document's style *can* change
    for reasons other than recalcStyle(Force).

I'm open to more testing suggestions, if reviewers have settings on the Document's style
that you want to make sure we inherit from the parent iframe, or don't inherit, etc.
I view this as a complete solution to this aspect of the current <iframe seamless> spec,
but likely not the last code we will write for this aspect of the seamless feature. :)

Tested by fast/frames/seamlesss/seamless-css-cascade.html and seamless-designMode.html

* css/StyleResolver.cpp:
(WebCore::StyleResolver::collectMatchingRulesForList):
* dom/Document.cpp:
(WebCore::Document::scheduleStyleRecalc):
(WebCore::Document::recalcStyle):
* html/HTMLIFrameElement.cpp:
(WebCore::HTMLIFrameElement::HTMLIFrameElement):
(WebCore::HTMLIFrameElement::didRecalcStyle):
(WebCore):
* html/HTMLIFrameElement.h:
(HTMLIFrameElement):

LayoutTests:

This single pass is deceptive.  seamless-designMode exists
to make sure that we do not regress application of Document-level
styles in the child document.

* fast/frames/seamless/seamless-css-cascade-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116694 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebKit1: Add a way to blacklist specific plug-ins/plug-in versions
https://bugs.webkit.org/show_bug.cgi?id=86150
<rdar://problem/9551196>

Reviewed by Sam Weinig.

Source/WebCore:

* English.lproj/Localizable.strings:
Update.

* loader/SubframeLoader.cpp:
(WebCore::SubframeLoader::loadPlugin):
It is possible that the client has already set the unavailability reason so don't try to set it twice.

* platform/LocalizedStrings.cpp:
(WebCore::insecurePluginVersionText):
* platform/LocalizedStrings.h:
Add insecure plug-in version text.

* rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::unavailablePluginReplacementText):
* rendering/RenderEmbeddedObject.h:
Add InsecurePluginVersion unavailability reason.

Source/WebKit/mac:

* Misc/WebKitErrors.h:
Add WebKitErrorInsecurePlugInVersion enum.

* Plugins/WebBasePluginPackage.h:
* Plugins/WebBasePluginPackage.mm:
(-[WebBasePluginPackage bundleIdentifier]):
(-[WebBasePluginPackage bundleVersion]):
Add bundleIdentifier and bundleVersion getters.

* WebCoreSupport/WebFrameLoaderClient.mm:
(WebFrameLoaderClient::createPlugin):
Check if the plug-in is blocked. If it is, set the unavailability reason and the error code.

WebKitLibraries:

Add WKShouldBlockPlugin.

* WebKitSystemInterface.h:
* libWebKitSystemInterfaceLion.a:
* libWebKitSystemInterfaceSnowLeopard.a:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116695 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=82131
[Mac] REGRESSION (r110480): Text field that specifies background-color 
(or is auto-filled) gets un-themed border
-and corresponding-
<rdar://problem/11115221>

Reviewed by Maciej Stachowiak.

This change rolls out r110480 which is what caused styled text fields 
to get the un-themed border, and it does a bunch of work to make sure 
we get the pretty, new version of the NSTextField art whenever 
possible. We do this differently for post-Lion OS's since there is now 
a way to opt into it all the time. Lion and SnowLeopard can only use 
the new art in HiDPI mode when the background color of the text field 
is just white.

RenderThemeMac::textField() takes a boolean paramter used to determine 
if the new gradient will be used.
* rendering/RenderThemeMac.h:
(RenderThemeMac):
        
This is the post-Lion workaround. This code has no effect on Lion and 
SnowLeopard. This allows up to opt into a version of [NSTextField drawWithFrame:] that will only draw the frame of the text field; without this, it will draw the frame and the background, which creates a number of problems with styled text fields and text fields in HiDPI. There is a less comprehesive workaround for Lion and SnowLeopard in place in RenderThemeMac::textField().
* rendering/RenderThemeMac.mm:
(-[WebCoreTextFieldCell _coreUIDrawOptionsWithFrame:inView:includeFocus:]):
        
This is the roll-out of r110480.
(WebCore::RenderThemeMac::isControlStyled):
        
See the comments for a full explanation, but this is mostly code for 
Lion and SnowLeopard to determine if we can opt into the new artwork.
(WebCore::RenderThemeMac::paintTextField):
(WebCore::RenderThemeMac::textField):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116697 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash in FontCache::releaseFontData due to infinite float size.
https://bugs.webkit.org/show_bug.cgi?id=86110

Reviewed by Andreas Kling.

Source/WebCore:

New callers always forget to clamp the font size, which overflows
to infinity on multiplication. It is best to clamp it at the end
to avoid getting greater than std::numeric_limits<float>::max().

Test: fast/css/large-font-size-crash.html

* platform/graphics/FontDescription.h:
(WebCore::FontDescription::setComputedSize):
(WebCore::FontDescription::setSpecifiedSize):

LayoutTests:

* fast/css/large-font-size-crash-expected.txt: Added.
* fast/css/large-font-size-crash.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116698 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Set Valgrind environment variables for layout tests.
https://bugs.webkit.org/show_bug.cgi?id=86156

Patch by Lei Zhang <thestig@chromium.org> on 2012-05-10
Reviewed by Dirk Pranke.

* Scripts/webkitpy/layout_tests/port/chromium.py:
(ChromiumPort.setup_environ_for_server):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116703 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r116677.
http://trac.webkit.org/changeset/116677
https://bugs.webkit.org/show_bug.cgi?id=86159

This patch causes linker error to some mac bots (Requested by
jianli_ on #webkit).

Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-05-10

* WebCore.exp.in:
* dom/ContainerNode.h:
* dom/Node.cpp:
(WebCore::Node::traverseNextNode):
(WebCore::Node::traverseNextSibling):
* dom/Node.h:
(Node):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116705 268f45cc-cd09-0410-ab3c-d52691b4dbfc
nrwt: [chromium] fix path to asan symbolize script
https://bugs.webkit.org/show_bug.cgi?id=86161

Reviewed by Abhishek Arya.

* Scripts/webkitpy/layout_tests/port/chromium.py:
(ChromiumPort._get_crash_log):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116707 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add insecurePluginVersionText stubs.

* platform/blackberry/LocalizedStringsBlackBerry.cpp:
(WebCore::insecurePluginVersionText):
(WebCore):
* platform/efl/LocalizedStringsEfl.cpp:
(WebCore::insecurePluginVersionText):
(WebCore):
* platform/qt/LocalizedStringsQt.cpp:
(WebCore::insecurePluginVersionText):
(WebCore):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116708 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add insecurePluginVersionText stub here too.

* src/LocalizedStrings.cpp:

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