Closed Bug 1792603 Opened 2 years ago Closed 2 years ago

GetFramesForArea doesn't report nsTableRowFrames when partially on screen

Categories

(Core :: Layout, defect)

defect

Tracking

()

RESOLVED INVALID
Accessibility Severity s3

People

(Reporter: morgan, Assigned: morgan)

References

Details

(Keywords: access)

Attachments

(1 obsolete file)

STR:

  1. Load <table id="table" style="width:150vw;" border><tr id="row"><td id="one" style="width:50vw;">one</td><td style="width:50vw;" id="two">two</td><td id="three">three</td></tr></table>
  2. Call:
nsIScrollableFrame* sf = presShell->GetRootScrollFrameAsScrollable();
      nsRect scrollPort = sf ? sf->GetScrollPortRect() : rootFrame->GetRect();
nsLayoutUtils::GetFramesForArea(
          RelativeTo{rootFrame}, scrollPort, frames,
          {{
            nsLayoutUtils::FrameForPointOption::OnlyVisible,
            nsLayoutUtils::FrameForPointOption::IgnorePaintSuppression,
            nsLayoutUtils::FrameForPointOption::IgnoreCrossDoc
            }});

Expected: The row is reported in the returned frames array, the only thing that isn't is the offscreen "three" cell.
Actual: The table, "one" cell, and "two" cell are reported, but the row and the "three" cell are not reported.

This seems to only be an issue with table row frames. The following, for example, does not reproduce this issue.

<div id="outer" style="width:200vw; background: green; overflow:scroll;"><div id="inner"><div style="display:inline-block; width:100vw; background:red;" id="on">on screen</div><div style="background:blue; display:inline;" id="off">offscreen</div></div></div>
Blocks: 1787274
Assignee: nobody → mreschenberg
Status: NEW → ASSIGNED
Whiteboard: [access-s3]
Attachment #9296815 - Attachment is obsolete: true

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(boris.chiou)
Severity: -- → S3
Flags: needinfo?(boris.chiou)

closing invalid since based on matrix discussion this seems expected behaviour, and we'll work around it in a11y

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Accessibility Severity: --- → s3
Whiteboard: [access-s3]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: