Bugzilla

STR:
 (1) Load testcase
 (2a) Select-all
...or:
 (2b) In layout debugger, dump the frame tree.

ACTUAL RESULTS:
For 2a: The select-all-highlighting shows a bit of extra highlighted area to the right of the character -- it looks like a whitespace character.
For 2b: The framedump shows something like this:
```
Text(0)"X\n"@...  {0,0,690,1140} vis-overflow={0,0,990,1140} ...
```
Notably, there's a bogus "\n" character shown as part of the text-run, and we think there's some visual overflow (690 width in the frame rect vs. 990 width in the visual-overflow rect).


EXPECTED RESULTS:
For 2a: The select-all highlighting should tightly wrap the X character.
For 2b: There shouldn't be a weird stray \n character, and the framedump shouldn't show any visual overflow beyond the frame rect.


Morgan discovered this issue while working on backplates (which is dependent on the visual overflow area)

STR:
 (1) Load testcase
 (2a) Select-all
...or:
 (2b) In layout debugger, dump the frame tree.

ACTUAL RESULTS:
For 2a: The select-all-highlighting shows a bit of extra highlighted area to the right of the character -- it looks like a whitespace character.
For 2b: The framedump shows something like this:
```
Text(0)"X\n"@...  {0,0,690,1140} vis-overflow={0,0,990,1140} ...
```
Notably, there's a bogus "\n" character shown as part of the text-run, and we think there's some visual overflow (690 width in the frame rect vs. 990 width in the visual-overflow rect).


EXPECTED RESULTS:
For 2a: The select-all highlighting should tightly wrap the X character.
For 2b: There shouldn't be a weird stray \n character, and the framedump shouldn't show any visual overflow beyond the frame rect.
[EDIT: Actually maybe it's correct that the \n character shows up -- but it's still quite odd that it creates 1 **horizontal** space worth of visual overflow...]


Morgan discovered this issue while working on backplates (which is dependent on the visual overflow area)

STR:
 (1) Load testcase
 (2a) Select-all
...or:
 (2b) In layout debugger, dump the frame tree.

ACTUAL RESULTS:
For 2a: The select-all-highlighting shows a bit of extra highlighted area to the right of the character -- it looks like a whitespace character.
For 2b: The framedump shows something like this:
```
Text(0)"X\n"@...  {0,0,690,1140} vis-overflow={0,0,990,1140} ...
```
Notably, there's a bogus "\n" character shown as part of the text-run, and we think there's some visual overflow (690 width in the frame rect vs. 990 width in the visual-overflow rect).


EXPECTED RESULTS:
For 2a: The select-all highlighting should tightly wrap the X character.
For 2b: There shouldn't be a weird stray \n character, and the framedump shouldn't show any visual overflow beyond the frame rect.
[EDIT: Actually maybe it's correct that the \n character shows up as part of the text node -- but it's still quite odd that it creates 1 **horizontal** space worth of visual overflow...]


Morgan discovered this issue while working on backplates (which is dependent on the visual overflow area)