I have been able to reproduce the flickering text behavior in the editor. It is occurring when hovering the buttons in the sidebar, the buttons underneath the editor do not produce any flickering when hovered.

Here's an all-in-one test.html that contains html and css that reproduce red text flicker when the mouse cursor is moved in/out the button area.

Note: the flicker goes away if I remove "position: fixed" from the left section #header element's CSS.

Deleted: test.html 52.6 KB

test.html 52.6 KB View Download

I didn't install those extensions, but hovering over the red text in the test case from #c2 causes a very subtle change in the red text (font weight increases slightly), but definitely not a 'flicker'. This is on 64.0.3260.2 (Official Build) dev (64-bit). I assume it becomes a flicker after the extensions are installed? Could you attach a standalone test case? If the test case in #c2 is meant to be standalone, then unfortunately I cannot reproduce the issue.

Yes, the red text's font weight is changing, which creates "flicker" when the mouse is moved over the button. When there are many buttons on the left the flicker occurs more frequently. Anyway, it's a bug and shouldn't happen.

shend@, are you using a HighDPI display aka Retina? I guess the change is less drastic in this case. On a standard DPI display with ClearType enabled the difference is, well, huge. See the attached animated gif.

Deleted: flicker.gif 4.6 KB

	flicker.gif 4.6 KB View Download

We reproduced this on canary but with very little difference. Maybe the test team can reproduce it more clearly.

PLEASE USE test.html ATTACHED HERE because the regression occurred in 25.0.1326.0 which required -webkit- prefix for CSS transitions.
Bisect info: 167683 (good) - 167744 (bad)
https://chromium.googlesource.com/chromium/src/+log/e212a306..a04c9d09?pretty=fuller

Repro: move the mouse cursor in/out the button area on the left
Expected: only the button color is changed
Observed: in addition to the button color, the red text on the right changes appearance (see gif in #c7)

Cannot pinpoint any CL (a per-revision bisect is required, apparently), but if I have to guess it'd be r167707 "WebKit Roll"
Here's the webkit changelog: https://trac.webkit.org/log/webkit/?action=stop_on_copy&mode=stop_on_copy&rev=134601&stop_rev=134347&limit=255&verbose=on
In the webkit roll there are several commits related to animation e.g. https://trac.webkit.org/changeset/134532/webkit/

Deleted: test.html 52.6 KB

test.html 52.6 KB View Download

Able to reproduce this issue on Macbook air 10.12.6, Win-10 and Ubuntu 14.04 using chrome stable version #62.0.3202.94 and latest canary #64.0.3266.0.
This is a non-regression issue as it is observed from M50 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Quoting  https://crbug.com/793794#c5  schenney@chromium.org

> In that case this is very minor changes in appearance due to the text shifting to a composited layer for the transition. For good performance we composite (use the GPU to move content around) when animating transitions, but compositing is incompatible with LCD text rendering because the text is no longer integer aligned. The jump from LCD to anti-aliased text creates the appearance change.

> We will not be fixing this. On your end you could add "will-change: transform" to the element with the transition on it, and then the text will always be composited.

==========================

This workaround works for me.

It's a terrible solution. Pretty much the same as backface-visibility: hidden;. Load that html example file and use either of these "workarounds". Toggle them on and off and you'll see that it's now negatively changing font color and appearance by default, instead of only when the transition is occurring.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug is worse than ever, and I've come across instances where will-change doesn't even work. Nobody here seems to care though, so I'm not sure it matters.