Some CSS transitionend events don't fire on Android devices without displays |
||||||
Issue descriptionInternal bug with some more context: b/65674713 On Cast for Android Things, we don't always have a display and an implementation of OpenGL, so we use flags like kDisableGpu and kDisableGpuCompositing to ignore this issue. Evidently this setup prevents frames from beginning (presumably because they can't be drawn), which means animations and transitions don't make progress. This becomes an issue when apps rely on JavaScript events like "transitionend" to activate important behavior. I thought I fixed this by using kDisableGpuVsync, which fixed some types of transitions (I was testing on the 'width' property), but it's still a problem for transitions on other properties (specifically 'opacity' for the internal bug). I'm guessing this is a compositor issue. Any help on this would be greatly appreciated.
,
Nov 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bef7d9d8f813ab9a81c913dab21d565d7b8b8af4 commit bef7d9d8f813ab9a81c913dab21d565d7b8b8af4 Author: Thoren Paulson <thoren@chromium.org> Date: Tue Nov 07 01:11:05 2017 [Chromecast] Use kDisableThreadedAnimation on AT. Since some Android Things devices don't have a display, compositor-based animations weren't moving, preventing JS events for them not to be fired. Turns out there's a compositor flag that fixes this called kDisableThreadedAnimation. Bug: 781924 , internal b/65674713 Test: Fling a test page, CQ Change-Id: Ie8abe2dd49ee0fe5ea97aa9a98961c248033668a Reviewed-on: https://chromium-review.googlesource.com/755933 Reviewed-by: Luke Halliwell <halliwell@chromium.org> Commit-Queue: Thoren Paulson <thoren@chromium.org> Cr-Commit-Position: refs/heads/master@{#514327} [modify] https://crrev.com/bef7d9d8f813ab9a81c913dab21d565d7b8b8af4/chromecast/browser/cast_browser_main_parts.cc
,
Nov 7 2017
It looks like this is being worked on, going to assign it :)
,
Nov 7 2017
oops, I meant to cc flackr@, got some wires crossed...
,
Nov 7 2017
,
Jan 11 2018
With the change in comment #2, it sounds like the immediate issue is resolved. Is there further work here? If so, can we drop the priority? If not, can we close this out.
,
Feb 7 2018
,
Jun 18 2018
I don't think we will ever 'fix' this; there's a strong expectation in the browser that if the threaded compositor is being used then impl frames will happen. flackr@ - please re-open and prioritize accordingly if you think I'm wrong. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ajuma@chromium.org
, Nov 6 2017