1217253 - Text repainted every time the caret blinks in Google Docs

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Visit the Google Docs URL in two browser windows. In one window select some text, then in the other window click to place the caret.

In my mozilla-central build, every time the caret blinks on or off, we repaint the text. The appearance of the text while the caret is visible is different from when it's hidden. This looks horrible.

I see this on Linux and Matt sees it on Mac.

Comment 1

[Matt Woodrow (:mattwoodrow)]

It looks like the document is manually implementing selection by drawing background colors/borders behind the text, and apply an opacity to that.

For some reason the opacity value keeps changing, so we re-layerize the selection into it's own layer (with all the text in yet another layer on top). The frequency of this is low enough that we hit our active layer timeout, so we keep toggling back and forth between layer states.

I can see the colour values changing in chrome too (using a color picker), though it seems to be at a lower frequency, not sure why yet.

Comment 2

[Matt Woodrow (:mattwoodrow)]

One (simple) option would be to stop allowing JS changes to opacity to trigger active layers. That would remove the switching between subpixel-AA and not, and reduce the invalidations to just the selected area.

A slightly more complex approach would be to increase the number of changes required before a making layers active (and require them to be in close succession?), and also increase the timeout threshold before falling back again. This should hopefully fix this case, without breaking 'true' JS based animations.

Comment 3

[Markus Stange [:mstange]]

The testcase in bug 710186 has a similar problem, but not due to JS, so I filed bug 1217748 about it.

I don't really have any good ideas on how to approach this yet.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #0)
> The appearance of the text while the caret is visible is
> different from when it's hidden. This looks horrible.

This is probably due to component alpha layers being broken with APZ (bug 1122916). Bug 1147673 will fix it.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could just stop JS changes from triggering animation and hope that authors use will-change:opacity to induce an active layer. That's the simplest and I guess it matches what other browsers do?

Comment 5

[Markus Stange [:mstange]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> We could just stop JS changes from triggering animation

For all properties, or just for opacity? If we do the same for transform and top/left, I'm concerned about pages that let you move things with the mouse, e.g. map panning - or really any "animation" that needs to react to user input in real time and thus can't use CSS animations / transitions.
Opacity usually doesn't have this problem, so I think making this change just for opacity would be totally fine.

Comment 6

[Andrew Overholt [:overholt]]

Can anyone still reproduce this?

Comment 7

[Markus Stange [:mstange]]

I can't. Maybe Google Docs has changed their caret's z order.

The problem itself is still tracked in bug 1217748 so I think we can close this bug.