Test case: `data:text/html,<button style="display: contents;" role="none" aria-label="test">` This gets a role of nothing, which is all kinds of wrong. It should get a role of button. This works correctly if you remove display: contents. [Here's how we do this correctly for elements that aren't display: contents](https://searchfox.org/firefox-main/rev/c8c933829aec7786146f4dc5a11c575d9dcda258/accessible/base/nsAccessibilityService.cpp#1473). However, [display: contents Accessible creation has a completely different code path](https://searchfox.org/firefox-main/rev/c8c933829aec7786146f4dc5a11c575d9dcda258/accessible/base/nsAccessibilityService.cpp#1312), a fact that has always bothered me due to the potential for disparities like this. While it's a bit heavy handed for this single bug, I think we should consider removing that block and instead handling these Accessibles in the same code path as everything else. This will probably require some tweaks to various things which expect a frame and won't get one. However, I think it will ultimately make display: contents a lot easier to follow and avoid additional problems like this.
Bug 2047063 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Test case: `data:text/html,<button style="display: contents;" role="none" aria-label="test">` This gets a role of nothing, which is all kinds of wrong. It should get a role of button. This works correctly if you remove display: contents. [Here's how we do this correctly for elements that aren't display: contents](https://searchfox.org/firefox-main/rev/c8c933829aec7786146f4dc5a11c575d9dcda258/accessible/base/nsAccessibilityService.cpp#1473). However, [display: contents Accessible creation has a completely different code path](https://searchfox.org/firefox-main/rev/c8c933829aec7786146f4dc5a11c575d9dcda258/accessible/base/nsAccessibilityService.cpp#1312), a fact that has always bothered me due to the potential for disparities like this. While it's a bit heavy handed for this single bug, I think we should consider removing that block for display: contents/frameless Accessibles and instead handling these frameless Accessibles in the same code path as everything else. This will probably require some tweaks to various things which expect a frame and won't get one. However, I think it will ultimately make display: contents a lot easier to follow and avoid additional problems like this.