haikuwebkit/LayoutTests/highlight/highlight-world-leak.html

50 lines
1.6 KiB
HTML
Raw Permalink Normal View History

Paint highlights specified in CSS Highlight API https://bugs.webkit.org/show_bug.cgi?id=205318 Reviewed by Ryosuke Niwa. LayoutTests/imported/w3c: * web-platform-tests/css/css-highlight-api/highlight-text-across-elements-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text.html: Added. Source/WebCore: Render highlights when present, similar to the way we render selection. Tests: imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text.html * Modules/highlight/HighlightMap.h: (WebCore::HighlightMap::map const): Add a getter for the internal HashMap. * rendering/InlineTextBox.cpp: (WebCore::InlineTextBox::selectionState): (WebCore::InlineTextBox::verifySelectionState const): (WebCore::InlineTextBox::paint): (WebCore::InlineTextBox::clampedStartEndForState const): (WebCore::InlineTextBox::selectionStartEnd const): (WebCore::InlineTextBox::highlightStartEnd const): (WebCore::InlineTextBox::resolveStyleForMarkedText): Use the highlight name from the HighlightRangeGroup to obtain the style from the renderer. (WebCore::InlineTextBox::collectMarkedTextsForHighlights const): Render the highlights when painting text. Determine if a highlight is present in the current RenderObject, and add additional MarkedText to be rendered when painting * rendering/InlineTextBox.h: * rendering/MarkedText.cpp: (WebCore::subdivide): * rendering/MarkedText.h: (WebCore::MarkedText::operator== const): Expand MarkedText to take a style name. * rendering/SelectionRangeData.cpp: (WebCore::SelectionRangeData::setContext): (WebCore::SelectionRangeData::selectionStateForRenderer): (WebCore::SelectionRangeData::set): * rendering/SelectionRangeData.h: Leverage SelectionRangeData for highlights. Tools: Expand MarkedText to take a style name. * TestWebKitAPI/Tests/WebCore/MarkedText.cpp: (WebCore::operator<<): Canonical link: https://commits.webkit.org/218737@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@253857 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-12-21 01:33:10 +00:00
<!DOCTYPE html>
<html>
<body>
<script src="../resources/js-test-pre.js"></script>
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
<script src="../resources/gc.js"></script>
Paint highlights specified in CSS Highlight API https://bugs.webkit.org/show_bug.cgi?id=205318 Reviewed by Ryosuke Niwa. LayoutTests/imported/w3c: * web-platform-tests/css/css-highlight-api/highlight-text-across-elements-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text.html: Added. Source/WebCore: Render highlights when present, similar to the way we render selection. Tests: imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text.html * Modules/highlight/HighlightMap.h: (WebCore::HighlightMap::map const): Add a getter for the internal HashMap. * rendering/InlineTextBox.cpp: (WebCore::InlineTextBox::selectionState): (WebCore::InlineTextBox::verifySelectionState const): (WebCore::InlineTextBox::paint): (WebCore::InlineTextBox::clampedStartEndForState const): (WebCore::InlineTextBox::selectionStartEnd const): (WebCore::InlineTextBox::highlightStartEnd const): (WebCore::InlineTextBox::resolveStyleForMarkedText): Use the highlight name from the HighlightRangeGroup to obtain the style from the renderer. (WebCore::InlineTextBox::collectMarkedTextsForHighlights const): Render the highlights when painting text. Determine if a highlight is present in the current RenderObject, and add additional MarkedText to be rendered when painting * rendering/InlineTextBox.h: * rendering/MarkedText.cpp: (WebCore::subdivide): * rendering/MarkedText.h: (WebCore::MarkedText::operator== const): Expand MarkedText to take a style name. * rendering/SelectionRangeData.cpp: (WebCore::SelectionRangeData::setContext): (WebCore::SelectionRangeData::selectionStateForRenderer): (WebCore::SelectionRangeData::set): * rendering/SelectionRangeData.h: Leverage SelectionRangeData for highlights. Tools: Expand MarkedText to take a style name. * TestWebKitAPI/Tests/WebCore/MarkedText.cpp: (WebCore::operator<<): Canonical link: https://commits.webkit.org/218737@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@253857 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-12-21 01:33:10 +00:00
<script>
description("Tests that using Highlight does not cause the document to get leaked.");
window.jsTestIsAsync = true;
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
window.onload = function () {
testDocumentIsNotLeaked(
async function initAndRemove(frameCount)
{
let frames = await new Promise((resolve, reject) => {
let frames = [];
let counter = 0;
function onLoad() {
counter++;
if (counter == frameCount)
resolve(frames);
}
for (let i = 0; i < frameCount; ++i) {
let frame = document.createElement('iframe');
frame.src = "resources/highlight-frame.html";
frame.onload = onLoad;
document.body.appendChild(frame);
frames.push(frame);
}
});
let frameIdentifiers = [];
for (let i = 0; i < frameCount; ++i) {
let frame = frames[i];
frameIdentifiers.push(internals.documentIdentifier(frame.contentDocument));
frame.remove();
Paint highlights specified in CSS Highlight API https://bugs.webkit.org/show_bug.cgi?id=205318 Reviewed by Ryosuke Niwa. LayoutTests/imported/w3c: * web-platform-tests/css/css-highlight-api/highlight-text-across-elements-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text.html: Added. Source/WebCore: Render highlights when present, similar to the way we render selection. Tests: imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text.html * Modules/highlight/HighlightMap.h: (WebCore::HighlightMap::map const): Add a getter for the internal HashMap. * rendering/InlineTextBox.cpp: (WebCore::InlineTextBox::selectionState): (WebCore::InlineTextBox::verifySelectionState const): (WebCore::InlineTextBox::paint): (WebCore::InlineTextBox::clampedStartEndForState const): (WebCore::InlineTextBox::selectionStartEnd const): (WebCore::InlineTextBox::highlightStartEnd const): (WebCore::InlineTextBox::resolveStyleForMarkedText): Use the highlight name from the HighlightRangeGroup to obtain the style from the renderer. (WebCore::InlineTextBox::collectMarkedTextsForHighlights const): Render the highlights when painting text. Determine if a highlight is present in the current RenderObject, and add additional MarkedText to be rendered when painting * rendering/InlineTextBox.h: * rendering/MarkedText.cpp: (WebCore::subdivide): * rendering/MarkedText.h: (WebCore::MarkedText::operator== const): Expand MarkedText to take a style name. * rendering/SelectionRangeData.cpp: (WebCore::SelectionRangeData::setContext): (WebCore::SelectionRangeData::selectionStateForRenderer): (WebCore::SelectionRangeData::set): * rendering/SelectionRangeData.h: Leverage SelectionRangeData for highlights. Tools: Expand MarkedText to take a style name. * TestWebKitAPI/Tests/WebCore/MarkedText.cpp: (WebCore::operator<<): Canonical link: https://commits.webkit.org/218737@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@253857 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-12-21 01:33:10 +00:00
}
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
nukeArray(frames);
frames = null;
return frameIdentifiers;
}
).then(
() => testPassed("Document did not leak"),
(error) => testFailed(error.message)
).finally(finishJSTest);
Paint highlights specified in CSS Highlight API https://bugs.webkit.org/show_bug.cgi?id=205318 Reviewed by Ryosuke Niwa. LayoutTests/imported/w3c: * web-platform-tests/css/css-highlight-api/highlight-text-across-elements-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text.html: Added. Source/WebCore: Render highlights when present, similar to the way we render selection. Tests: imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text.html * Modules/highlight/HighlightMap.h: (WebCore::HighlightMap::map const): Add a getter for the internal HashMap. * rendering/InlineTextBox.cpp: (WebCore::InlineTextBox::selectionState): (WebCore::InlineTextBox::verifySelectionState const): (WebCore::InlineTextBox::paint): (WebCore::InlineTextBox::clampedStartEndForState const): (WebCore::InlineTextBox::selectionStartEnd const): (WebCore::InlineTextBox::highlightStartEnd const): (WebCore::InlineTextBox::resolveStyleForMarkedText): Use the highlight name from the HighlightRangeGroup to obtain the style from the renderer. (WebCore::InlineTextBox::collectMarkedTextsForHighlights const): Render the highlights when painting text. Determine if a highlight is present in the current RenderObject, and add additional MarkedText to be rendered when painting * rendering/InlineTextBox.h: * rendering/MarkedText.cpp: (WebCore::subdivide): * rendering/MarkedText.h: (WebCore::MarkedText::operator== const): Expand MarkedText to take a style name. * rendering/SelectionRangeData.cpp: (WebCore::SelectionRangeData::setContext): (WebCore::SelectionRangeData::selectionStateForRenderer): (WebCore::SelectionRangeData::set): * rendering/SelectionRangeData.h: Leverage SelectionRangeData for highlights. Tools: Expand MarkedText to take a style name. * TestWebKitAPI/Tests/WebCore/MarkedText.cpp: (WebCore::operator<<): Canonical link: https://commits.webkit.org/218737@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@253857 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-12-21 01:33:10 +00:00
};
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
Paint highlights specified in CSS Highlight API https://bugs.webkit.org/show_bug.cgi?id=205318 Reviewed by Ryosuke Niwa. LayoutTests/imported/w3c: * web-platform-tests/css/css-highlight-api/highlight-text-across-elements-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text-expected.html: Added. * web-platform-tests/css/css-highlight-api/highlight-text.html: Added. Source/WebCore: Render highlights when present, similar to the way we render selection. Tests: imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text-across-elements.html imported/w3c/web-platform-tests/css/css-highlight-api/highlight-text.html * Modules/highlight/HighlightMap.h: (WebCore::HighlightMap::map const): Add a getter for the internal HashMap. * rendering/InlineTextBox.cpp: (WebCore::InlineTextBox::selectionState): (WebCore::InlineTextBox::verifySelectionState const): (WebCore::InlineTextBox::paint): (WebCore::InlineTextBox::clampedStartEndForState const): (WebCore::InlineTextBox::selectionStartEnd const): (WebCore::InlineTextBox::highlightStartEnd const): (WebCore::InlineTextBox::resolveStyleForMarkedText): Use the highlight name from the HighlightRangeGroup to obtain the style from the renderer. (WebCore::InlineTextBox::collectMarkedTextsForHighlights const): Render the highlights when painting text. Determine if a highlight is present in the current RenderObject, and add additional MarkedText to be rendered when painting * rendering/InlineTextBox.h: * rendering/MarkedText.cpp: (WebCore::subdivide): * rendering/MarkedText.h: (WebCore::MarkedText::operator== const): Expand MarkedText to take a style name. * rendering/SelectionRangeData.cpp: (WebCore::SelectionRangeData::setContext): (WebCore::SelectionRangeData::selectionStateForRenderer): (WebCore::SelectionRangeData::set): * rendering/SelectionRangeData.h: Leverage SelectionRangeData for highlights. Tools: Expand MarkedText to take a style name. * TestWebKitAPI/Tests/WebCore/MarkedText.cpp: (WebCore::operator<<): Canonical link: https://commits.webkit.org/218737@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@253857 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-12-21 01:33:10 +00:00
</script>
<script src="../resources/js-test-post.js"></script>
</body>
</html>