Timeline

Nov 28, 2010:

10:45 PM Changeset in webkit [72783] by Dimitri Glazkov

• 7 edits in trunk

2010-11-28 Dimitri Glazkov <Dimitri Glazkov>

Reviewed by Darin Adler.

Default event handlers should also be using event retargeting.
​https://bugs.webkit.org/show_bug.cgi?id=49986

• fast/events/shadow-boundary-crossing-2.html: Added a test.
• fast/events/shadow-boundary-crossing-2-expected.txt: Modified expectations to include new test.

2010-11-28 Dimitri Glazkov <Dimitri Glazkov>

Reviewed by Darin Adler.

Default event handlers should also be using event retargeting.
​https://bugs.webkit.org/show_bug.cgi?id=49986

Test: fast/events/shadow-boundary-crossing-2.html

• dom/EventContext.cpp: (WebCore::EventContext::defaultEventHandler): Added.
• dom/EventContext.h: Added decl.
• dom/Node.cpp: (WebCore::Node::dispatchGenericEvent): Changed to use event retargeting for

default event handlers.

5:06 PM Changeset in webkit [72782] by morrita@google.com

• 7 edits in trunk

2010-11-23 MORITA Hajime <​morrita@google.com>

Reviewed by Kent Tamura.

REGRESSION: Text on <input type="search"> is not spellchecked.
​https://bugs.webkit.org/show_bug.cgi?id=49651

• editing/spelling/spellcheck-attribute.html: Added <input type="search"> cases.
• editing/spelling/spellcheck-attribute-expected.txt:

2010-11-23 MORITA Hajime <​morrita@google.com>

Reviewed by Kent Tamura.

REGRESSION: Text on <input type="search"> is not spellchecked.
​https://bugs.webkit.org/show_bug.cgi?id=49651

TextControlInnerElement::isSpellCheckingEnabled() didn't consider
non-root shadow elelements and always went false for <input type="search>.
This change unifies shadow and host handling into Element::isSpellCheckingEnabled().

Test: editing/spelling/spellcheck-attribute.html

• dom/Element.cpp: (WebCore::Element::isSpellCheckingEnabled):
• rendering/TextControlInnerElements.cpp:
• rendering/TextControlInnerElements.h:

4:45 PM Changeset in webkit [72781] by barraclough@apple.com

• 8 edits
  6 adds in trunk

Bug 48101 - Yarr gives different results for /(?:a*?){2,}/

Reviewed by Sam Weinig.

JavaScriptCore:

The test cases in the linked mozilla bug demostrate a couple of
problems in subpattern matching. These bugs lie in the optimized
cases - for matching parentheses with a quantity count of 1, and
for matching greedy quantified parentheses at the end of a regex
(which do not backtrack).

In both of these cases we are failing to correctly handle empty
matches. In the case of parenthese-single matches (quantity count
one) we are failing to test for empty matches at all. In the case
of terminal subpattern matches we do currenty check, however there
is a subtler bug here too. In the case of an empty match we will
presently immediately fall through to the next alternative (or
complete the regex match), whereas upon a failed match we should
be backtracking into the failing alternative, to give it a chance
to match further (e.g. consider /a??b?|a/.exec("ab") - upon first
attempting to match the first alternative this will match the empty
string - since a?? is non-greedy, however rather than moving on to
the second alternative we should be re-matching the first one, at
which point the non-greedy a?? will match, and as such the result
should be "ab", not "a").

Terminal sunpattern matching contains a second bug, too. The frame
location values in the subpattern should be being allocated with
the outer disjunction's frame (as we do for the parentheses-single
optimization). Consider the following three regexes:

/a*(?:b*)*c*/
/a*(?:b*)c*/
/a*(?:b*)*/

Considering only the frame location required by the atoms a,b, and
c, (ignoring space associated with the nested subpattern) the first
regex (a normal subpattern match) requires a frame size of 2 for
the outer disjunction, (to backtrack terms a & c), with each
iteration of the subpattern requiring a frame of size 1 (in order
to backtrack b). In the case of the second regex (where the
parentheses-single optimization will kick in) the outer frame must
be set up with a frame size of 3, since the outer frame will also
be used when running the nested subpattern. We will currently only
allocate a farme of size 1 for the outer disjuntion (to contain a),
howver the frame size should be 2 (since the subpattern will be
evaluated in the outer frame). In addition to failing to allocate
frame space the frame offsets are also presently invalid - in the
case of the last regex b's frame location will be set assuming it
to be the first term in the frame, whereas in this case b lies
after the term a, and should be taking a separate frame location.

In order to correctly allocate the frame for terminal subpattern
matches we must move this optimization back up from the JIT into
the compiler (and thus interpreter too), since this is where the
frame allocation takes place.

• yarr/RegexCompiler.cpp:

(JSC::Yarr::RegexPatternConstructor::setupAlternativeOffsets):
(JSC::Yarr::RegexPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::compileRegex):

• yarr/RegexInterpreter.cpp:

(JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
(JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
(JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::matchParenthesesTerminalEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::backtrackParenthesesTerminalEnd):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
(JSC::Yarr::ByteCompiler::emitDisjunction):

• yarr/RegexInterpreter.h:
• yarr/RegexJIT.cpp:

(JSC::Yarr::RegexGenerator::generateParenthesesSingle):
(JSC::Yarr::RegexGenerator::generateParenthesesGreedyNoBacktrack):
(JSC::Yarr::RegexGenerator::generateTerm):

• yarr/RegexPattern.h:

(JSC::Yarr::PatternTerm::PatternTerm):

LayoutTests:

Add layout tests for corner cases of repeat matches in regular expressions,
and of the examples documented in the ECMA-262 spec .

• fast/regex/ecma-regex-examples-expected.txt: Added.
• fast/regex/ecma-regex-examples.html: Added.
• fast/regex/repeat-match-waldemar-expected.txt: Added.
• fast/regex/repeat-match-waldemar.html: Added.
• fast/regex/script-tests/ecma-regex-examples.js: Added.
• fast/regex/script-tests/repeat-match-waldemar.js: Added.

10:51 AM Changeset in webkit [72780] by commit-queue@webkit.org

• 2 edits in trunk/WebCore

2010-11-28 Antonio Gomes <​agomes@rim.com>

Reviewed by Kenneth Rohde Christiansen.

Spatial Navigation: use isSpatialNaviagtionEnabled from SpatialNavigation.h in HTMLInputElement::defaultEventHandler
​https://bugs.webkit.org/show_bug.cgi?id=50131

For all isSpatialNavigationEnabled calls throughout WebCore, we decided to use the static method in
SpatialNavigation.h instead of directly checking from the one in Settings.h. Reason: in a soon future,
there will be a isCaretBrowsing check incorporated into this method (and probably renaming it accordingly)
to avoid feature conflicts (spatial navigation x caret browsing).

No new tests needed.

• html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::defaultEventHandler):

10:32 AM Changeset in webkit [72779] by Laszlo Gombos

• 4 edits in trunk

2010-11-28 Laszlo Gombos <Laszlo Gombos>

Reviewed by Kenneth Rohde Christiansen.

[Qt] Move some build logic from Qt to platform independent code
​https://bugs.webkit.org/show_bug.cgi?id=50134

Remove the creation of the directories under $$OUTPUT_DIR/include
as these will be handled by the fwheader_generator target.

Remove the explicit generation of $$OUTPUT_DIR/WebKit2/generated as
this is not required.

• DerivedSources.pro:

2010-11-28 Laszlo Gombos <Laszlo Gombos>

Reviewed by Kenneth Rohde Christiansen.

[Qt] Move some build logic from Qt to platform independent code
​https://bugs.webkit.org/show_bug.cgi?id=50134

Create target directories inside generate-forwarding-headers.pl.

• Scripts/generate-forwarding-headers.pl:

9:34 AM Changeset in webkit [72778] by Laszlo Gombos

• 2 edits in trunk

2010-11-28 Laszlo Gombos <Laszlo Gombos>

Reviewed by Antonio Gomes.

[Qt] Remove unused BASE_DIR from the build system
​https://bugs.webkit.org/show_bug.cgi?id=50132

• WebKit.pri:

Nov 27, 2010:

6:54 PM Changeset in webkit [72777] by commit-queue@webkit.org

• 13 edits
  1 add in trunk/WebCore

2010-11-27 Benjamin Kalman <​kalman@chromium.org>

Reviewed by Darin Adler.

Move Position::EditingBoundaryCrossingRule to a new header file
​https://bugs.webkit.org/show_bug.cgi?id=49630

• GNUmakefile.am:
• WebCore.exp.in:
• WebCore.gypi:
• WebCore.pro:
• WebCore.vcproj/WebCore.vcproj:
• WebCore.xcodeproj/project.pbxproj:
• dom/Position.cpp: (WebCore::downstreamIgnoringEditingBoundaries): (WebCore::upstreamIgnoringEditingBoundaries):
• dom/Position.h:
• editing/DeleteSelectionCommand.cpp: (WebCore::DeleteSelectionCommand::doApply):
• editing/EditingBoundary.h: Added.
• editing/visible_units.cpp: (WebCore::startOfParagraph): (WebCore::endOfParagraph): (WebCore::isStartOfParagraph): (WebCore::isEndOfParagraph):
• editing/visible_units.h:
• rendering/RenderObject.cpp: (WebCore::RenderObject::createVisiblePosition):

1:15 AM Changeset in webkit [72776] by rwlbuis@webkit.org

• 4 edits
  3 adds in trunk

2010-11-26 Rob Buis <​rwlbuis@gmail.com>

Reviewed by Simon Fraser.

Percentage z offset in transform-origin should make the property invalid
​https://bugs.webkit.org/show_bug.cgi?id=48704

Discard transform-origin property when parsing invalid Z value.

Test: fast/css/transform-origin-parsing.html

• css/CSSParser.cpp: (WebCore::CSSParser::parseTransformOriginShorthand): (WebCore::CSSParser::parseTransformOrigin):
• css/CSSParser.h: