2010-06-28  Adam Barth  <abarth@webkit.org>

        Reviewed by Eric Seidel.

        The new tree builder needs to call attach() on elements it attaches to
        the DOM
        https://bugs.webkit.org/show_bug.cgi?id=41293

        Update expected results to show that the contents of the iframe
        actually get created.  This only gets us a few lines down the test
        harness before erroring out again, but I'll take it.

        * html5lib/runner-expected-html5.txt:
        * html5lib/webkit-resumer-expected-html5.txt:
2010-06-28  Adam Barth  <abarth@webkit.org>

        Reviewed by Eric Seidel.

        The new tree builder needs to call attach() on elements it attaches to
        the DOM
        https://bugs.webkit.org/show_bug.cgi?id=41293

        Apparently Nodes expect to have their attach() method called when they
        are attached to the DOM.  The new tree builder is happy to oblige.
        Making this call requires some fancy footwork with RefPtr/PassRefPtr to
        avoid extra ref churn while keeping each function small.

        * html/HTMLTreeBuilder.cpp:
        (WebCore::HTMLTreeBuilder::insertHTMLStartTagBeforeHTML):
        (WebCore::HTMLTreeBuilder::processCharacter):
        (WebCore::HTMLTreeBuilder::insertDoctype):
        (WebCore::HTMLTreeBuilder::insertComment):
        (WebCore::HTMLTreeBuilder::insertCommentOnDocument):
        (WebCore::HTMLTreeBuilder::insertElement):
        (WebCore::HTMLTreeBuilder::insertSelfClosingElement):
        (WebCore::HTMLTreeBuilder::insertScriptElement):
        * html/HTMLTreeBuilder.h:
        (WebCore::HTMLTreeBuilder::attach):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62028 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  James Robinson  <jamesr@chromium.org>

        Reviewed by Darin Adler.

        REGRESSION(53790): Neopets page with mismatched elements misrenders
        https://bugs.webkit.org/show_bug.cgi?id=41181

        Misnested formatting tags require fixup in order to create a valid DOM.  Because this takes
        O(N^2) time in some cases, http://trac.webkit.org/changeset/53790 added an iteration limit
        of 5 to this algorithm to avoid hangs.  This limit is too low for neopets, but a limit of
        7 is sufficient.  This raises the limit to 10 to have a bit of breathing room.  HTML5
        defines the fixup algorithm http://www.whatwg.org/specs/web-apps/current-work/#adoptionAgency
        but doesn't specify any particular iteration limit.

        * html/LegacyHTMLTreeBuilder.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62029 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Eric Carlson  <eric.carlson@apple.com>

        Reviewed by Sam Weinig.

        MediaPlayerPrivate::getSupportedTypes does not return "modern" MIME types
        https://bugs.webkit.org/show_bug.cgi?id=41287
        <rdar://problem/8137402>

        No new test because getSupportedTypes is used privately by MediaPlayer.

        * platform/graphics/mac/MediaPlayerPrivateQTKit.mm:
        (WebCore::MediaPlayerPrivate::getSupportedTypes): Build hash set with both common and
        modern types.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62030 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Only one character lookahead should be enough for the lexer
https://bugs.webkit.org/show_bug.cgi?id=41213

Reviewed by Oliver Hunt.

The lexer had 4 character lookahead before, which required
a complex shifting mechanism. This can be improved by using
only one character lookahead for most decisions, and a
peek() function as a fallback when it is absolutely necessary.

* parser/Lexer.cpp:
(JSC::Lexer::currentCharacter):
(JSC::Lexer::currentOffset):
(JSC::Lexer::setCode):
(JSC::Lexer::shift):
(JSC::Lexer::peek):
(JSC::Lexer::getUnicodeCharacter):
(JSC::Lexer::shiftLineTerminator):
(JSC::Lexer::lastTokenWasRestrKeyword):
(JSC::Lexer::lex):
(JSC::Lexer::scanRegExp):
(JSC::Lexer::skipRegExp):
* parser/Lexer.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62031 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Patch for https://bugs.webkit.org/show_bug.cgi?id=41299
Build up WebKitTestRunner output in the InjectedBundle

Reviewed by Anders Carlsson.

Simplify WebKitTestRunner by building up the output in the InjectedBundle
and sending it over postMessage when done, instead of using the async
WKPageRenderTreeExternalRepresentation.

* WebKitTestRunner/InjectedBundle/InjectedBundle.cpp:
(WTR::InjectedBundle::done):
(WTR::InjectedBundle::didRecieveMessage):
* WebKitTestRunner/InjectedBundle/InjectedBundle.h:
(WTR::InjectedBundle::os):
* WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp:
(WTR::WKStringToUTF8):
(WTR::InjectedBundlePage::didFinishLoadForFrame):
(WTR::InjectedBundlePage::didFailLoadWithErrorForFrame):
* WebKitTestRunner/TestInvocation.cpp:
(WTR::WKStringToUTF8):
(WTR::TestInvocation::TestInvocation):
(WTR::TestInvocation::invoke):
(WTR::TestInvocation::initializeMainWebView):
(WTR::TestInvocation::_didRecieveMessageFromInjectedBundle):
(WTR::TestInvocation::didRecieveMessageFromInjectedBundle):
* WebKitTestRunner/TestInvocation.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62032 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Adam Barth  <abarth@webkit.org>

        Reviewed by Eric Seidel.

        HTML5 Regression: Crash in insert()
        https://bugs.webkit.org/show_bug.cgi?id=41281

        We need to call endIfDelayed() outside of the script nesting block
        because endIfDelayed() might call end(), which deletes the
        HTMLDocumentParser.  If we try to exit the script nesting block after
        the HTMLDocumentParser has been deleted, we'll decrement unallocated
        memory, which is bad times.

        Moving endIfDelayed outside of the script nesting block also lets us
        avoid ending if inWrite() is true.  If we're inWrite(), then there's
        folks above us on the stack who will crash of the HTMLDocumentParser is
        deallocated.  Adding this check matches the LegacyHTMLDocumentParser
        and the logic in attemptToEnd, facilitating a small refactoring of the
        common logic for improved readability.

        I don't know of any test case that changes in behavior because of this
        patch, but this bug exists on the same line of code that the reliablity
        tests crashed.  I'm not sure whether this patch will fix that crash,
        but removing bugs (even theoretical ones) seems like a good idea.

        * html/HTMLDocumentParser.cpp:
        (WebCore::HTMLDocumentParser::insert):
        (WebCore::HTMLDocumentParser::append):
        (WebCore::HTMLDocumentParser::attemptToEnd):
        (WebCore::HTMLDocumentParser::endIfDelayed):
        (WebCore::HTMLDocumentParser::resumeParsingAfterScriptExecution):
        * html/HTMLDocumentParser.h:
        (WebCore::HTMLDocumentParser::shouldDelayEnd):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62033 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Add support for the progress bar tag
https://bugs.webkit.org/show_bug.cgi?id=41014

Reviewed by Xan Lopez.

WebCore:

Add support for rendering the progress tag for WebKit GTK+.

* GNUmakefile.am:
* platform/gtk/RenderThemeGtk.cpp:
(WebCore::RenderThemeGtk::animationRepeatIntervalForProgressBar):
Added. Currently progress bar animations are disabled. As it looks like
there may not be a good way to support this with Mozilla's theme drawing code.
(WebCore::RenderThemeGtk::animationDurationForProgressBar): Ditto.
(WebCore::RenderThemeGtk::adjustProgressBarStyle): Added.
(WebCore::RenderThemeGtk::paintProgressBar): Added.
* platform/gtk/RenderThemeGtk.h: Add declarations for new methods.
* platform/gtk/gtk2drawing.c:
(moz_gtk_get_progress_widget): Expose the progress widget so that the chunk can be positioned properly.
* platform/gtk/gtkdrawing.h: Added declaration for moz_gtk_get_progress_widget.

LayoutTests:

Unskip tests which are now passing after adding support for rendering the progress tag.

* platform/gtk/Skipped:
* platform/gtk/fast/dom/HTMLProgressElement/progress-bar-value-pseudo-element-expected.txt: Copied from LayoutTests/platform/mac/fast/dom/HTMLProgressElement/progress-bar-value-pseudo-element-expected.txt.
* platform/gtk/fast/dom/HTMLProgressElement/progress-element-expected.txt: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62034 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebCore: Fix for https://bugs.webkit.org/show_bug.cgi?id=9197 CSS3: Borders 
with border-radius and double, groove, or ridge styles should look 
better

Reviewed by Sam Weinig.

This patch re-works border radius painting to stroke paths instead 
of arcs. 

Added new function clipConvexPolygon(). Added static 
addConvexPolygonToContext so that code can be shared between 
drawConvexPolygon() and clipConvexPolygon().
* platform/graphics/GraphicsContext.h:
* platform/graphics/cg/GraphicsContextCG.cpp:
(WebCore::addConvexPolygonToContext):
(WebCore::GraphicsContext::drawConvexPolygon):
(WebCore::GraphicsContext::clipConvexPolygon):

Shells of implementations on non-CG platforms.
* platform/graphics/cairo/GraphicsContextCairo.cpp:
(WebCore::GraphicsContext::clipConvexPolygon):
* platform/graphics/haiku/GraphicsContextHaiku.cpp:
(WebCore::GraphicsContext::clipConvexPolygon):
* platform/graphics/qt/GraphicsContextQt.cpp:
(WebCore::GraphicsContext::clipConvexPolygon):
* platform/graphics/skia/GraphicsContextSkia.cpp:
(WebCore::GraphicsContext::clipConvexPolygon):
* platform/graphics/wince/GraphicsContextWince.cpp:
(WebCore::GraphicsContext::clipConvexPolygon):
* platform/graphics/wx/GraphicsContextWx.cpp:
(WebCore::GraphicsContext::clipConvexPolygon):

This new helper function determines if the inner corners of the 
border will arch in or meet at a right angle. 
* rendering/RenderBoxModelObject.cpp:
(WebCore::borderWillArcInnerEdge):

This function is re-written so that, for each side of the border, 
if borderWillArcInnerEdge() is true, we go down a brand new code 
path of clipping to a convex polygon for the border side and then 
we paint the side using the new function drawBoxSideFromPath(). If 
borderWillArcInnerEdge() is false, then we call into the old 
familiar drawLineForBoxSide() which relies on the rounder clip 
rects we have set up to arch the outer edge of the border.
(WebCore::RenderBoxModelObject::paintBorder):

This new function does the math to figure out the convex polygon 
to clip to in the case where we need to arch the inner edge of the 
border. This calls into a new GraphicsContext function that is only 
implemented on CG at this time. This is the reason we are keeping 
around an old version of paintBorder() for now.
(WebCore::RenderBoxModelObject::clipBorderSidePolygon):
* rendering/RenderBoxModelObject.h:

borderInnerRect() is a new convenience function called from 
RenderObject and RenderBoxModelObject to determine the rect of the 
inside edge of the border.
* rendering/RenderObject.cpp:
(WebCore::RenderObject::borderInnerRect):

This new function re-works drawArcForBoxSide to draw from Paths 
when appropriate instead of stroking arcs. 
(WebCore::RenderObject::drawBoxSideFromPath):

Keep this around for that do not HAVE(PATH_BASED_BORDER_RADIUS_DRAWING) until 
GraphicsContext::clipConvexPolygon() is implemented.
(WebCore::RenderObject::drawArcForBoxSide):
* rendering/RenderObject.h:

New function 
RenderStyle::getInnerBorderRadiiForRectWithBorderWidths() gets the 
inner radius values for a rect. It takes border widths a parameters 
rather than using the style's border widths so that it can be used 
in inner radius calculations for double and groove/ridge 
calculations. The W3C corner constraining rules were moved to a 
static function that can be called from both getBorderRadiiForRect
() and getInnerBorderRadiiForRectWithBorderWidths().
* rendering/style/RenderStyle.cpp:
(WebCore::constrainCornerRadiiForRect):
(WebCore::RenderStyle::getBorderRadiiForRect):
(WebCore::RenderStyle::getInnerBorderRadiiForRectWithBorderWidths):
* rendering/style/RenderStyle.h:

LayoutTests: Tests with new results after 
https://bugs.webkit.org/show_bug.cgi?id=9197 CSS3: Borders 
with border-radius and double, groove, or ridge styles should look 
better

Reviewed by Sam Weinig.

* platform/mac/fast/borders/borderRadiusAllStylesAllCorners-expected.checksum:
* platform/mac/fast/borders/borderRadiusAllStylesAllCorners-expected.png:
* platform/mac/fast/borders/borderRadiusDashed01-expected.checksum:
* platform/mac/fast/borders/borderRadiusDashed01-expected.png:
* platform/mac/fast/borders/borderRadiusDashed02-expected.checksum:
* platform/mac/fast/borders/borderRadiusDashed02-expected.png:
* platform/mac/fast/borders/borderRadiusDashed03-expected.checksum:
* platform/mac/fast/borders/borderRadiusDashed03-expected.png:
* platform/mac/fast/borders/borderRadiusDotted01-expected.checksum:
* platform/mac/fast/borders/borderRadiusDotted01-expected.png:
* platform/mac/fast/borders/borderRadiusDotted02-expected.checksum:
* platform/mac/fast/borders/borderRadiusDotted02-expected.png:
* platform/mac/fast/borders/borderRadiusDotted03-expected.checksum:
* platform/mac/fast/borders/borderRadiusDotted03-expected.png:
* platform/mac/fast/borders/borderRadiusDouble01-expected.checksum:
* platform/mac/fast/borders/borderRadiusDouble01-expected.png:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62035 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-27  John Abd-El-Malek  <jam@chromium.org>

        Reviewed by Darin Fisher.

        [chromium] Get the selected text from plugins for right click menu
        https://bugs.webkit.org/show_bug.cgi?id=41242

        * public/WebContextMenuData.h:
        (WebKit::WebContextMenuData::):
        * public/WebPlugin.h:
        (WebKit::WebPlugin::selectedText):
        * src/ContextMenuClientImpl.cpp:
        (WebKit::ContextMenuClientImpl::getCustomMenuFromDefaultItems):
        * src/WebPluginContainerImpl.cpp:
        (WebKit::WebPluginContainerImpl::selectedText):
        * src/WebPluginContainerImpl.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62036 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Andreas Kling  <andreas.kling@nokia.com>

        Reviewed by Kenneth Rohde Christiansen.

        [Qt] Use HTML5-conformant gradient interpolation mode
        https://bugs.webkit.org/show_bug.cgi?id=41298

        Unskip now working test:
        - canvas/philip/tests/2d.gradient.interpolate.colouralpha.html

        Spec link:
        http://www.whatwg.org/specs/web-apps/current-work/#colors-and-styles

        * platform/qt/Skipped:
2010-06-28  Andreas Kling  <andreas.kling@nokia.com>

        Reviewed by Kenneth Rohde Christiansen.

        [Qt] Use HTML5-conformant gradient interpolation mode
        https://bugs.webkit.org/show_bug.cgi?id=41298

        Change the Qt Gradient implementation to use ComponentInterpolation mode.

        Spec link:
        http://www.whatwg.org/specs/web-apps/current-work/#colors-and-styles

        * platform/graphics/qt/GradientQt.cpp:
        (WebCore::Gradient::platformGradient):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62037 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Laszlo Gombos  <laszlo.1.gombos@nokia.com>

        Unreviewed Symbian build fix.

        [Qt] Update the def file after r61879.

        * symbian/eabi/QtWebKitu.def:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62038 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Zhe Su  <suzhe@chromium.org>

        Reviewed by Jian Li.

        [chromium]Remove deprecated code related to input method.
        https://bugs.webkit.org/show_bug.cgi?id=41244

        Also update TestWebWidget in tests/PopupMenuTest.cpp to add missing implementations.

        * WebKit.gyp:
        * public/WebCompositionCommand.h: Removed.
        * public/WebViewClient.h:
        * public/WebWidget.h:
        * src/EditorClientImpl.cpp:
        (WebKit::EditorClientImpl::setInputMethodState):
        * src/WebPopupMenuImpl.cpp:
        * src/WebPopupMenuImpl.h:
        * src/WebViewImpl.cpp:
        * src/WebViewImpl.h:
        * tests/PopupMenuTest.cpp:
        (WebKit::TestWebWidget::setComposition):
        (WebKit::TestWebWidget::confirmComposition):
        (WebKit::TestWebWidget::textInputType):
        (WebKit::TestWebWidget::caretOrSelectionBounds):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62039 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Build fix for non-PATH_BASED_BORDER_RADIUS_DRAWING platforms.

* rendering/RenderBoxModelObject.cpp:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62040 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Adam Barth  <abarth@webkit.org>

        Reviewed by Eric Seidel.

        Add text nodes to the DOM
        https://bugs.webkit.org/show_bug.cgi?id=41306

        Actually add some text nodes to the DOM when parsing a document.  We're
        going to need to do something fancier here eventually, but this gets us
        past the error we're seeing currently in runner.html.

        Unfortunately, this patch "regresses" runner.html in the sense that we
        now hit an assert, but it's still an improvement...  I'll update the
        HTML5 expectations once we get past the assert.

        * html/HTMLTreeBuilder.cpp:
        (WebCore::HTMLTreeBuilder::processCharacter):
        (WebCore::HTMLTreeBuilder::insertTextNode):
        * html/HTMLTreeBuilder.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix a race condition that can happen when using DBs in workers.
https://bugs.webkit.org/show_bug.cgi?id=41105

Reviewed by Eric Seidel.

* storage/DatabaseTracker.cpp:
(WebCore::DatabaseTracker::addOpenDatabase):
* storage/DatabaseTracker.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62043 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Xan Lopez  <xlopez@igalia.com>

        Revert to build jsc, since the tests expect this.

        * GNUmakefile.am:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62044 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Adam Barth  <abarth@webkit.org>

        Reviewed by Eric Seidel.

        The new tree builder should actually finish building the tree
        https://bugs.webkit.org/show_bug.cgi?id=41314

        Again, this patch makes progress on runner.html, but I haven't removed
        the ASSERT yet.

        * html/HTMLTreeBuilder.cpp:
        (WebCore::HTMLTreeBuilder::HTMLTreeBuilder):
        (WebCore::HTMLTreeBuilder::finished):
        * html/HTMLTreeBuilder.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62045 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Martin Robinson  <mrobinson@igalia.com>

        Unreviewed.

        Update baselines after r62034.

        * platform/gtk/fast/dom/HTMLProgressElement/progress-bar-value-pseudo-element-expected.txt:
        * platform/gtk/fast/dom/HTMLProgressElement/progress-element-expected.txt:
        * platform/gtk/fast/dom/Window/window-property-descriptors-expected.txt:
        * platform/gtk/fast/dom/prototype-inheritance-expected.txt:
        * platform/gtk/fast/js/global-constructors-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62046 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Adam Barth  <abarth@webkit.org>

        Reviewed by Eric Seidel.

        Don't use the new tree builder for fragments
        https://bugs.webkit.org/show_bug.cgi?id=41316

        We need to walk before we can run.  After this change, we can run the
        runner.html tests (with the ASSERT caveat).

        * html/HTMLTreeBuilder.cpp:
        (WebCore::HTMLTreeBuilder::HTMLTreeBuilder):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@62047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2010-06-28  Gustavo Noronha Silva  <gns@gnome.org>

        Rubber-stamped by Xan Lopez.

        Update webkitdirs's knowledge of our library's name.

        * Scripts/webkitdirs.pm:

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