Bug 47997

Created attachment 71314 [details] Test case

Forgot to mention that this was originally reported on the Chrome side as http://crbug.com/59962.

We should fix the rendering / layout to match Firefox given that our parsing already matches.

This only occurs in quirks mode. We've found the CSS rule in Firefox's quirks.css

Created attachment 93247 [details] speculative fix

Created attachment 93253 [details] Patch

Comment on attachment 93253 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=93253&action=review > LayoutTests/fast/lists/nested-dd-with-lists.html:4 > + <dd><li>item 1 > + <dd><li>item 2 Can you use something besides text so we don't need different image baselines for each platform?

I thought some fonts were OK to use on all platforms? I assume the default one is.

Really? I don't believe you. The number of needlessly duplicated layout test result images would be insane.

(In reply to comment #9) > Really? I don't believe you. The number of needlessly duplicated layout test result images would be insane. The number of needlessly duplicated layout test result images is insane.

Created attachment 93254 [details] Patch for landing

Created attachment 93255 [details] Patch for landing

Comment on attachment 93255 [details] Patch for landing Rejecting attachment 93255 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-3', 'build-..." exit_code: 2 Last 500 characters of output: tests/xmlhttprequest ................................................................................................................................................................................ http/tests/xmlhttprequest/web-apps ............... http/tests/xmlhttprequest/workers ........... http/tests/xmlviewer . http/tests/xmlviewer/dumpAsText ........... 748.93s total testing time 23506 test cases (99%) succeeded 1 test case (<1%) had incorrect layout 16 test cases (<1%) had stderr output Full output: http://queues.webkit.org/results/8684700

Created attachment 93267 [details] Archive of layout-test-results from cr-jail-3 The attached test failures were seen while running run-webkit-tests on the commit-queue. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.7

It appears AX code doesn't like me changing the style of these inner dds: --- /tmp/layout-test-results/platform/mac/accessibility/definition-list-term-expected.txt 2011-05-12 01:02:02.000000000 -0700 +++ /tmp/layout-test-results/platform/mac/accessibility/definition-list-term-actual.txt 2011-05-12 01:02:02.000000000 -0700 @@ -10,11 +10,11 @@ PASS obj.childAtIndex(0).subrole is "AXSubrole: AXTerm" PASS obj.childAtIndex(0).roleDescription is "AXRoleDescription: term" PASS obj.childAtIndex(1).role is 'AXRole: AXGroup' -PASS obj.childAtIndex(1).subrole is "AXSubrole: AXDefinition" -PASS obj.childAtIndex(1).roleDescription is "AXRoleDescription: definition" +FAIL obj.childAtIndex(1).subrole should be AXSubrole: AXDefinition. Was AXSubrole: . +FAIL obj.childAtIndex(1).roleDescription should be AXRoleDescription: definition. Was AXRoleDescription: group. PASS obj.childAtIndex(1).role is 'AXRole: AXGroup' -PASS obj.childAtIndex(1).subrole is "AXSubrole: AXDefinition" -PASS obj.childAtIndex(1).roleDescription is "AXRoleDescription: definition" +FAIL obj.childAtIndex(1).subrole should be AXSubrole: AXDefinition. Was AXSubrole: . +FAIL obj.childAtIndex(1).roleDescription should be AXRoleDescription: definition. Was AXRoleDescription: group. PASS successfullyParsed is true TEST COMPLETE Chris, do you have any suggestions?

It looks like the render tree changed with your change. It assumes that there will be a render object that can be identified for the <ol/dl/ul> It would appear that accessibility can no longer identify if the element is one of these. It does so in AXObjectCache I believe by looking at the tag name for the associated node with a render object

Does that mean the best path forward is to change how the AX logic finds these elements?

(In reply to comment #17) > Does that mean the best path forward is to change how the AX logic finds these elements? I don't know what changed the fact that if you ask for renderer->node()->hasTagName(dlTag) it started returning false...

(In reply to comment #18) > (In reply to comment #17) > > Does that mean the best path forward is to change how the AX logic finds these elements? > > I don't know what changed the fact that if you ask for renderer->node()->hasTagName(dlTag) it started returning false... Eric's theory is that some render objects that used to be blocks are now inlines, which might be affecting how the AX code walks the render tree.

Comment on attachment 93255 [details] Patch for landing This patch gives the wrong rendering for this document: TT <dd>Hello</dd>

Basically this bug boils down to: we're now entering into a new DOM state that the previous parser never let us get to. The old parser used to auto-close <dd> tags, but the HTML5 one doesn't. Mozilla has some magic CSS which applies a -moz-margin-start for non-nested dds, and turns that margin into a :before { content "\A "; } in the nested case. It's not entirely clear to me how that works. But I expect it makes the spaces able to colapse? And why those don't get collapsed when they're dd's are outside of dl's isn't clear to me either. Basically I don't really understand the expected rendering of dd (we don't really have enough testing yet), so I feel unclear how this should be fixed.

Attached test case seems to render same as Chrome Canary 112, Firefox Nightly 112 and STP163 and related Chromium bug (in Comment 02) is marked as "WONTFIX" with the comment 21 as reference. Do we need to do anything here or we can close this? Thanks!