Pass the XSSAuditor's report URL to the XSSAuditorDelegate on the main thread.
https://bugs.webkit.org/show_bug.cgi?id=112179

Reviewed by Adam Barth.

Rather than relying on XSSInfo objects to move the XSSAuditor's report
URL into the XSSAuditorDelegate for reporting, we should be able to grab
the URL directly from XSSAuditor before it moves off the main thread,
and store it on the delegate.

This will enable us to drop the report URL properties from both
XSSAuditor and XSSInfo. Oh, happy day!

* html/parser/BackgroundHTMLParser.cpp:
(WebCore::BackgroundHTMLParser::sendTokensToMainThread):
    We no longer need to check whether XSSInfo objects are thread safe,
    as we've dropped the only problematic bit.
* html/parser/HTMLDocumentParser.cpp:
(WebCore::HTMLDocumentParser::pumpTokenizer):
(WebCore::HTMLDocumentParser::startBackgroundParser):
* html/parser/XSSAuditor.cpp:
(WebCore::XSSAuditor::init):
    When initializing the XSSAuditor, pass in an XSSAuditorDelegate*
    and assign the report URL directly onto that object.
(WebCore::XSSAuditor::filterToken):
    Drop the report URL parameter from XSSInfo objects we create in the
    Auditor, as they're now handled directly from the delegate.
(WebCore::XSSAuditor::isSafeToSendToAnotherThread):
    Drop the report URL property from XSSAuditor's threadsafeness check,
    as properties that do not exist are automatically thread-safe.
* html/parser/XSSAuditorDelegate.cpp:
(WebCore::XSSAuditorDelegate::didBlockScript):
    Use the delegate's own report URL rather than the XSSInfo objects'.
* html/parser/XSSAuditorDelegate.h:
(WebCore::XSSInfo::create):
(WebCore::XSSInfo::XSSInfo):
    Drop the report URL property from XSSInfo.
(WebCore::XSSAuditorDelegate::setReportURL):
(XSSAuditorDelegate):
    Provide a public API for setting a delegate's report URL.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@145695 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Layout Test fast/repaint/japanese-rl-selection-repaint-in-regions.html is failing
https://bugs.webkit.org/show_bug.cgi?id=106097

Reviewed by Tony Chang.

After http://trac.webkit.org/changeset/138785, the content overflowing the last region in chain is
displayed properly in vertical-rl writing mode. This determined the failure of japanese-rl-selection-repaint-in-regions.html
test due to the overflowing content that now appears when rendered.

I modified the original test by decreasing the font size so that the content is not overflowing, because the purpose
of the original test was not to check the overflowed content anyway. I have generated new expected results for mac and chromium
and unskipped the test on chromium and mac.

* fast/repaint/japanese-rl-selection-repaint-in-regions.html:
* platform/chromium-linux/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.png:
* platform/chromium-linux/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.txt: Added.
* platform/chromium-mac-lion/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.png: Removed.
* platform/chromium-mac/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.png:
* platform/chromium-mac/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.txt: Added.
* platform/chromium/TestExpectations:
* platform/chromium/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.txt: Removed.
* platform/gtk/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.png:
* platform/gtk/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.txt:
* platform/mac-lion/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.png: Added.
* platform/mac-lion/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.txt: Added.
* platform/mac/TestExpectations:
* platform/mac/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.png:
* platform/mac/fast/repaint/japanese-rl-selection-repaint-in-regions-expected.txt:


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