nephele
/
haikuwebkit
1
0
Fork 0
Code Issues Releases Activity
haikuwebkit/LayoutTests/accessibility/table-headers-expected.txt

16 lines
570 B
Plaintext
Raw Permalink Normal View History

[AX] Improve AccessibilityTableCell columnHeaders and rowHeaders functions. https://bugs.webkit.org/show_bug.cgi?id=136818 Patch by Andrzej Badowski <a.badowski@samsung.com> on 2014-10-14 Reviewed by Chris Fleizach. Source/WebCore: Take into account that <th> elements can be both the column headers and row headers improved the operation of two functions: columnHeaders and rowHeaders. Test: accessibility/table-headers.html * accessibility/AccessibilityTableCell.cpp: (WebCore::AccessibilityTableCell::isColumnHeaderCell): A new function that helps the main goal. (WebCore::AccessibilityTableCell::isRowHeaderCell): A new function that helps the main goal. (WebCore::AccessibilityTableCell::columnHeaders): Use isColumnHeaderCell instead of isTableHeaderCell. (WebCore::AccessibilityTableCell::rowHeaders): Use isRowHeaderCell also includes <th> row header element next to the scope attribute. * accessibility/AccessibilityTableCell.h: Adds new functions to the header file. LayoutTests: * accessibility/table-headers-expected.txt: Added. * accessibility/table-headers.html: Added. * platform/mac/accessibility/table-attributes-expected.txt: * platform/mac/accessibility/table-cells-expected.txt: * platform/mac/accessibility/table-sections-expected.txt: Canonical link: https://commits.webkit.org/155536@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@174675 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-10-14 08:18:32 +00:00
No Country Capital
1. Poland Warsaw
2. Russia Moscow
3. Ukraine Kiev
Tapping after CSS-based table casues an infinite loop in wordRangeFromPosition https://bugs.webkit.org/show_bug.cgi?id=185465 <rdar://problem/35263057> Reviewed by Antti Koivisto. LayoutTests/imported/w3c: Rebaselined the tests. h2 * web-platform-tests/dom/nodes/getElementsByClassName-30-expected.txt: table is generating a new line as expected. * web-platform-tests/html/syntax/parsing/html5lib_menuitem-element-expected.txt: h2 is generating an extra line to emulate its margin as expected. * web-platform-tests/html/syntax/parsing/html5lib_tests11-expected.txt: Ditto. * web-platform-tests/html/syntax/parsing/html5lib_tests21-expected.txt: Ditto. * web-platform-tests/html/syntax/parsing/html5lib_tests25-expected.txt: Ditto. * web-platform-tests/html/syntax/parsing/html5lib_webkit02-expected.txt: Ditto. Source/WebCore: The bug was caused by TextIterator not emitting a line break when exiting a CSS-based table when an element with `display: table-row` has an invisible text node. Specifically, TextIterator::exitNode is never called on an element with `table-cell: row` when m_node is a text node with whitespaces which appears after an element with `display: table-cell`. For example, for a tree structure like: table-row (R) table-cell (C) "text" (1) " " (2) Getting out of (C) would result in moving onto (2) without generating a line break for (R). When this happens in nextBoundary as it tries to find the end of the last word in the table cell, we end up finding the end of the document as the end of the word. As a result, nextWordBoundaryInDirection, the caller of nextBoundary, ends up infinite looping between the positon at the end of the document and the position immediately before the last word in the last table cell when it traverses words backwards. This patch fixes the hang by addressing this root cause in TextIterator. Namely, TextIterator now generates a line break when exiting a block while walking up ancestors in TextIterator::advance(). Tests: editing/selection/tapping-in-table-at-end-of-document.html editing/text-iterator/table-at-end-of-document.html * editing/TextIterator.cpp: (WebCore::TextIterator::advance): Fixed the bug. (WebCore::shouldEmitNewlineAfterNode): Do generate a new line at the end of a document when we're trying to generate every visible poitions even there are no renderers beyond this point. e.g. a position inside the last cell of a table at the end of a document hits this condition. (WebCore::shouldEmitExtraNewlineForNode): Don't emit a line break when the render box's height is 0px to avoid generating many empty lines for empty paragraph and header elements (this function is used to generate a blank line between p's and h1/h2/...'s). (WebCore::TextIterator::exitNode): LayoutTests: Rebaselined the tests. Most of these are due to new extra line breaks being generated after table and header elements as expected. See inline comments for some newly discovered bugs and rebaselines due to other non-obvious reasons. * accessibility/internal-link-anchors2-expected.txt: This test now demonstrates a bug that WebKit doesn't generate an extra line break before h3 when it has a large margin-top since an extra line break is only generated after a node at the moment. * accessibility/mac/mathml-elements-expected.txt: * accessibility/table-headers-expected.txt: * compositing/layer-creation/overlap-transformed-preserved-3d-expected.txt: * css3/flexbox/box-orient-button-expected.txt: * css3/flexbox/flexitem-expected.txt: * editing/execCommand/19087-expected.txt: The second blockquote which has the height of 0px no longer generates an extra new line. * editing/inserting/insert-list-in-table-cell-08-expected.txt: Selection is now being restored properly using TextIterator in InsertListCommand. * editing/selection/tapping-in-table-at-end-of-document-expected.txt: Added. * editing/selection/tapping-in-table-at-end-of-document.html: Added. * editing/text-iterator/table-at-end-of-document-expected.txt: Added. * editing/text-iterator/table-at-end-of-document.html: Added. * fast/block/positioning/insert-positioned-in-anonymous-crash-expected.txt: * fast/css/css3-ch-unit-expected.txt: Line breaks are generated between block & inline-block elements as expected. * fast/css/percent-min-width-img-src-change-expected.txt: * fast/css/percent-width-img-src-change-expected.txt: * fast/css/pseudo-empty-display-none-expected.txt: * fast/dom/HTMLAnchorElement/anchor-in-noscroll-iframe-crash-expected.txt: * fast/dom/HTMLDivElement/align/getset-expected.txt: * fast/dom/HTMLSelectElement/listbox-select-reset-expected.txt: * fast/dom/HTMLTableElement/table-with-invalid-border-expected.txt: * fast/forms/option-mouseevents-expected.txt: * fast/history/multiple-classes-visited-expected.txt: * fast/history/self-is-visited-expected.txt: * fast/html/marquee-reparent-check-expected.txt: * fast/inline-block/anonymous-block-crash-expected.txt: This test now demonstrates a bug that we're not generating an empty line before a block in some cases. * fast/inline/inline-position-top-align-expected.txt: * fast/invalid/test-case-tr-th-td-should-not-close-dl-list-expected.txt: * fast/overflow/scrollbar-click-retains-focus-expected.txt: * fast/parser/comments-expected.txt: * fast/parser/fragment-parser-doctype-expected.txt: * fast/ruby/ruby-base-merge-block-children-crash-2-expected.txt: * fast/spatial-navigation/snav-radio-group-expected.txt: A line break is generated after a nested table. * fast/sub-pixel/table-cells-have-stable-width-expected.txt: * fast/table/table-row-oveflow-crash-expected.txt: A line break is generated after a table as expected, which is followed by a BR which creates a blank line. * fast/table/table-with-borderattr-null-expected.txt: * fast/table/table-with-borderattr-set-to-null-expected.txt: * fast/text/international/dynamic-text-combine-crash-expected.txt: * fast/xsl/mozilla-tests-expected.txt: * http/tests/misc/large-js-program-expected.txt: * imported/blink/plugins/empty-per-context-data-expected.txt: * inspector/console/js-isLikelyStackTrace-expected.txt: * inspector/console/js-source-locations-expected.txt: * mathml/out-of-flow-in-token-crash-expected.txt: * mathml/presentation/stretchy-depth-height-expected.txt: * platform/mac/accessibility/table-cells-roles-expected.txt: Line breaks are generated after a block followed by two two consecutive BRs. * platform/mac/accessibility/table-roles-hierarchy-expected.txt: Ditto. * svg/foreignObject/fO-fixed-position-crash-expected.txt: * tiled-drawing/scrolling/non-fast-region/wheel-handler-region-basic-expected.txt: * transforms/3d/hit-testing/coplanar-with-camera-expected.txt: Canonical link: https://commits.webkit.org/201047@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231717 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-11 20:39:30 +00:00
[AX] Improve AccessibilityTableCell columnHeaders and rowHeaders functions. https://bugs.webkit.org/show_bug.cgi?id=136818 Patch by Andrzej Badowski <a.badowski@samsung.com> on 2014-10-14 Reviewed by Chris Fleizach. Source/WebCore: Take into account that <th> elements can be both the column headers and row headers improved the operation of two functions: columnHeaders and rowHeaders. Test: accessibility/table-headers.html * accessibility/AccessibilityTableCell.cpp: (WebCore::AccessibilityTableCell::isColumnHeaderCell): A new function that helps the main goal. (WebCore::AccessibilityTableCell::isRowHeaderCell): A new function that helps the main goal. (WebCore::AccessibilityTableCell::columnHeaders): Use isColumnHeaderCell instead of isTableHeaderCell. (WebCore::AccessibilityTableCell::rowHeaders): Use isRowHeaderCell also includes <th> row header element next to the scope attribute. * accessibility/AccessibilityTableCell.h: Adds new functions to the header file. LayoutTests: * accessibility/table-headers-expected.txt: Added. * accessibility/table-headers.html: Added. * platform/mac/accessibility/table-attributes-expected.txt: * platform/mac/accessibility/table-cells-expected.txt: * platform/mac/accessibility/table-sections-expected.txt: Canonical link: https://commits.webkit.org/155536@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@174675 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-10-14 08:18:32 +00:00
This tests that the columnHeaders() and rowHeaders() functions return the correct headers for a table cell.
The table cell at (0,3) should have exactly one column header, currently it has 1 column header(s).
The table cell at (0,3) should have exactly 0 row headers, currently it has 0 row header(s).
The table cell at (1,2) should have exactly one column header, currently it has 1 column header(s).
The table cell at (1,2) should have exactly one row header, currently it has 1 row header(s).