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

Issue 627191 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jul 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

[Android] Remote desktop is not displayed when device's orientation changes

Project Member Reported by joedow@chromium.org, Jul 11 2016

Issue description

I no longer see my remote desktop when rotating my device (switching from portrait to landscape or vice versa) until I touch the screen or cause an animation to be displayed.

This is a regression from the previous behavior.  The current suspect is a change from yuweih@ last week.  If so, then this is not a problem in the M52 release candidate.

When rotating the client device we destroy and recreate the desktop activity so I'm assuming somethjing doesn't get hooked back up when this occurs so no paint action is invoked.

 

Comment 1 by yuweih@chromium.org, Jul 11 2016

Labels: -M-53 M-54
Actually M53 has been branched a week before last Thursday... I think this fix is for M54 and the bug doesn't affect M53.
Project Member

Comment 2 by bugdroid1@chromium.org, Jul 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/856d9fb7b4fa883fc66ec27ec3901b3b3683875a

commit 856d9fb7b4fa883fc66ec27ec3901b3b3683875a
Author: yuweih <yuweih@chromium.org>
Date: Mon Jul 11 21:20:57 2016

[Remoting Android] Fix Painting After Rotation Bug

Previous CL 2132883002 removed the attachRedrawCallback() call in
Desktop.onStart() since it will be called in DesktopView.surfaceChanged().
This introduces a bug that if requestRepaint() is called before
surfaceChanged(), then mRepaintPending will be set to true and
mDisplay.redrawGraphics() will do nothing. paint() will not be called since
the redraw callback is not set, and mRepaintPending will not be set back to
false, making it skip all future render requests until paint() is triggered
by JniVideoRenderer in C++.

This CL fixes this problem by moving attachRedrawCallback() to the ctor
of DesktopView. paint() already has checks to prevent rendering happens if
the DesktopView is not ready yet.

BUG= 627191 

Review-Url: https://codereview.chromium.org/2136233002
Cr-Commit-Position: refs/heads/master@{#404732}

[modify] https://crrev.com/856d9fb7b4fa883fc66ec27ec3901b3b3683875a/remoting/android/java/src/org/chromium/chromoting/DesktopView.java

Comment 3 by yuweih@chromium.org, Jul 12 2016

Status: Fixed (was: Assigned)

Comment 4 by joedow@chromium.org, Jul 12 2016

Owner: ajnolley@chromium.org
Assigning to AJ to validate.

Thanks for updating the milestone as well!
Status: Verified (was: Fixed)
I confirmed the issue in a build from last week and have verified the issue is fixed in 54.0.2794.0. Changing Orientation works correctly and the desktop remains visible

Sign in to add a comment