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

Issue 645524 link

Starred by 3 users
Status: WontFix
Owner:
█ skuhne@chromium.org
OOO (till 1/28)
Closed: Sep 2016
Cc:
█ addison@chromium.org
█ skuhne@chromium.org
jasonwong@chromium.org
█ lpique@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Cros-ARC: Android on Chromebook UI getting cut off since dm.heightPixels wrongly includes the maximize/minimize bar only present on Chromebooks

Reported by a...@infinut.com, Sep 9 2016 
Chrome OS Version: 53.0.27.85.100 beta
Chrome OS Platform: 8530.80.0
Firmware Google_Cyan.7287.57.82
Chromebook: ACER R11

Please specify Cr-* of the system to which this bug/feature applies (add
the label below).
label:Cros-ARC

Steps To Reproduce:
(1) Run the attached android project on a Chromebook over ADB. The log 
on Chromebook Acer R11 shows,
09-08 16:58:44.960 1176-6209/com.infinut.anar.demos I/Screen: WidthPixels:960
09-08 16:58:44.960 1176-6209/com.infinut.anar.demos I/Screen: HeightPixels:600
09-08 16:58:44.959 1176-1176/com.infinut.anar.demos I/Surface: WidthPixels:960
09-08 16:58:44.959 1176-1176/com.infinut.anar.demos I/Surface: HeightPixels:568

Note that the log shows that the displayMetrics.heightPixels (Screen) are different from the surfaceHolder.OnSurfaceChanged (Surface) pixels even though the view is defined to be fullscreen and the theme is fullscreen - @android:style/Theme.Black.NoTitleBar.Fullscreen

(2) Run the same application on an Android device. Note that the displayMetrics.heightPixels (Screen) from display metrics and surfaceHolder.onSurfaceChanged (Surface) are the same.

On Nexus 7 Android tablet,
09-08 17:05:48.066 3503-3821/com.infinut.anar.demos I/Screen: WidthPixels:1920
09-08 17:05:48.066 3503-3821/com.infinut.anar.demos I/Screen: HeightPixels:1104
09-08 17:05:48.064 3503-3503/com.infinut.anar.demos I/Surface: WidthPixels:1920
09-08 17:05:48.065 3503-3503/com.infinut.anar.demos I/Surface: HeightPixels:1104


Expected Result:
The dm.heightPixels should not include the maximize/minimize bar since it is a fixed bar that cannot be removed (similar to the back/home/apps bar at the bottom of android devices).

Actual Result:
The maximize/minimize bar is included in the dm.heightPixels, but not in surfaceHolder.surfaceChanged height. The surface one is correct. 

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
Is a problem for all our apps, since we use the dm.widthPixels and dm.heightPixels extensively to determine sizing and positioning of UI elements

What is the impact to the user, and is there a workaround? If so, what is
it?
The android app does not 'just work' on Chromebooks, and will require significant rework to not have the UI cut off at the bottom few pixels. See attached image.

Please provide any additional information below. Attach a screen shot or
log if possible.
Screenshot 2016-09-05 at 1.17.28 PM.png
90.6 KB View Download

Comment 1 by dubois...@gmail.com, Sep 9 2016 

I am hit by this also, although my need is not only about the misreporting ... I'm hoping to get back those extra pixels of real-estate.  https://bugs.chromium.org/p/chromium/issues/detail?id=645282

When I maximize my app on ChromeOS using the maximize button on the toolbar it prints a warning that my app won't work that way.  It does maximize during that run but launches in the landscape layout on the next run.  For me, this makes the problem of the top-bar's presence worse.

Comment 2 by a...@infinut.com, Sep 9 2016 

Re-attaching the code to reproduce the problem. Did not attach the first time.
surfaceviewdemo.zip
15.5 MB Download

Comment 3 by jasonwong@chromium.org, Sep 12 2016

Cc: jasonwong@chromium.org addison@chromium.org
Components: Platform>ARC
Labels: Cros-ARC

Comment 4 by addison@chromium.org, Sep 27 2016

Cc: skuhne@chromium.org lpique@chromium.org
Owner: reve...@chromium.org
Status: Assigned (was: Unconfirmed)
David, could you also look into this issue, where the UI is getting cut off?

Comment 5 by reve...@chromium.org, Sep 28 2016

Owner: skuhne@chromium.org
skuhne@, can you take a look at this and assign back to me if it's a SF/HWC issue?

Comment 6 by skuhne@chromium.org, Sep 29 2016

Status: WontFix (was: Assigned)
The SurfaceView is not covering the entire window/display. It will be limited to the window without the caption. If that surface would cover everything, either the caption would be drawn over your content, hence blocking your content - OR - your content would cover the caption, hence making it impossible for the user to control the window - OR - part of the content would get cut off.

The source of this is N's decision to put the caption into the app's window in free form mode. 

Going forward we will move the caption out of the window again, but for the initial version of ARC++, we are "N freeform compatible".

So this is not a bug, it's intended.

Please re-open if you feel that the surfaceView should have the size of the window, but note that without the ability to hide the caption and / or as long as the caption is part of the window nothing can be done here.
►

Sign in to add a comment