New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 896985 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 892347



Sign in to add a comment

Spellcheck misspelled words have partial and/or blinking squiggle

Project Member Reported by mbarowsky@google.com, Oct 19

Issue description

Chrome Version       : 71.0.3558.0
OS Version: 11097.0.0


What steps will reproduce the problem?
1. Type a word in a text field that triggers Chrome spellcheck
2. See that the red squiggle is at first half hidden (only top half appears)
3. Upon double click selecting the misspelled word and clicking at the end of it, the red squiggle starts blinking with the cursor
4. I also had the squiggle stay where the word was after the word was deleted and continue blinking with the cursor, but I can't reproduce

What is the expected result?
Squiggle appears fully from the start and doesn't blink with the cursor.


What happens instead of that?


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (X11; CrOS x86_64 11097.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3558.0 Safari/537.36



 
Components: -Blink>Editing>Selection -Blink>Editing>Spellcheck Blink>Paint
Route to Blink>Paint for triage.
Owner: wangxianzhu@chromium.org
Status: Assigned (was: Unconfirmed)
This is a known issue with the invalidation rect for spellcheck markers and other text decorations. I think the spell check path is distinct from text decoration. The latter is non-trivial to fix due to the way decorations are painted.

Assigning to wangxianzhu@ to look at the spelling markers case. I own the other issue related to text decoration.
Cc: yosin@chromium.org kojii@chromium.org
I think the fix should be to include the pixels painted by document markers into the ink overflow (visual overflow) of line boxes.

However, if layout-ng can already calculate correct ink overflow for line boxes with document markers or decorations, I think we can just wait for launch of layout-ng without bothering the legacy layout system.
Blockedon: 892347
Currently, ink overflow is part of layout, both in legacy and in NG, so re-computing ink overflow is not easy. Chris is moving it to paint in  issue 892347 . Hopefully that makes doing this easier?
Correct that the fix is to include the decorations of various kinds into the visual overflow. Layout does not consider the decorations at all, and shouldn't as far as I know. The decoration bounds are not computed anywhere - we just paint them.
Cc: bsalomon@chromium.org chrishtr@chromium.org ericrk@chromium.org pdr@chromium.org wangxianzhu@chromium.org
 Issue 917264  has been merged into this issue.

Sign in to add a comment