Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2375113003:
Allow Desktop Canvas to be scrolled out from under System UI. (Closed)
DescriptionAllow Desktop Canvas to be scrolled out from under System UI.
This change adds the ability to scroll the desktop canvas out from under
any visible System UI.
When System UI is displayed (for Kitkat and higher) the
TouchInputHandler instance is called with the state/sizes of the System
UI per edge of the screen. These values are passed to the DesktopCanvas
instance which uses them for determining whether the System UI overlaps
with the remote image content. If there is overlap then it adjusts
the region of valid cursor and viewport positions which then allows
the user to pan the content out from 'under' the System UI which is
obscuring it.allowable position of the viewport.
When the System UI disappears (or changes size), the current amount of
padding, if any, is used as the new boundary. This prevents a jarring
translation from occuring when the System UI changes size.
BUG=621633
Committed: https://crrev.com/b2fd3d47699032e7d52a4ac2317135e444bbea6f
Cr-Commit-Position: refs/heads/master@{#423004}
Patch Set 1 #Patch Set 2 : Pre-CR tweaks #
Total comments: 16
Patch Set 3 : Adding comment block and addressing feedback #
Total comments: 12
Patch Set 4 : Cleaning up some of the previous code. #
Total comments: 10
Patch Set 5 : Addressing CR feedback #Messages
Total messages: 33 (21 generated)
The CQ bit was checked by joedow@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by joedow@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
joedow@chromium.org changed reviewers: + lambroslambrou@chromium.org
PTAL!
Ping!
I think we need better documentation to help the reader understand the concepts. I'm having problems understanding the abstractions in this CL. For example, you have the sequence: getImageBounds() calls getMaxPadding() calls getAdjustedSystemUiOffsets() calls getLetterboxPadding() I can just about grasp what the bottom method represents, but I'm struggling to understand the abstractions higher up the chain. Various members are mixed in throughout this calling chain, so that the end result, getImageBounds(), is unfathomably complex - I don't see any connection between it and "allowed cursor positions", whatever that means. Is it possible to change the set of abstractions to ones that are easier to understand? Do we have any unittests for this class? It looks like it would be easy to write tests, because the only dependencies are RenderStub (easy interface to mock) and RenderData (plain old data). You can add tests in a separate CL. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... File remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java (right): https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:22: * Used to smoothly reduce the amount of padding whle the user is zooming. s/whle/while/ https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:51: * positioning the desktop canvas to allow the user to scroll it below any visible System UI. Is this in screen or image coordinates? Can you explain in more detail what this padding represents? For example: Is the padding conceptually added to, or subtracted from, the image? How does it interact with the positioning algorithms? (How does the presence of padding affect the result?) How is it calculated? When is it re-calculated and why? What happens if these values are zero? Non-zero? Maybe explain with an example - for example, if the toolbar appears/disappears at the top of the screen, what effect does it have on mImagePadding.top ? Feel free to write a very long comment if necessary :) https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:222: // Remove or add image padding based on the new position. How is padding based on position? https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:251: return new RectF(-maxPadding[0], -maxPadding[1], mRenderData.imageWidth + maxPadding[2], If my reading is correct, this is the full image rectangle, inflated outwards by the maxPadding amount. What has this got to do with allowed cursor values? Maybe call this getMaxPaddedImageRect() or getMaxPaddedImageBounds() ? I don't conceptually understand what maxPadding is, so I also don't get the concept of this method. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:269: return new RectF(imageBounds.left + screenCenterX, imageBounds.top + screenCenterY, return imageBounds.inset(screenCenterX, screenCenterY); https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:287: /** Returns the letter box padding needed in each dimension (x and y) in screen coordinates. */ Maybe explain in a little more detail: This is the amount of unused screen space if the desktop image were positioned perfectly in the center of the screen. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:288: private float[] getLetterboxPadding() { Maybe return PointF ? https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:333: * Update the current edge padding based on the current System UI and image postion state. s/postion/position/
The CQ bit was checked by joedow@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Added a chunk of text explaining each of the concepts and expected behaviors. Also addressed other feedback. Will look at adding unit tests in a separate CL. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... File remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java (right): https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:22: * Used to smoothly reduce the amount of padding whle the user is zooming. On 2016/09/30 01:59:37, Lambros wrote: > s/whle/while/ Done. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:51: * positioning the desktop canvas to allow the user to scroll it below any visible System UI. On 2016/09/30 01:59:36, Lambros wrote: > Is this in screen or image coordinates? > Can you explain in more detail what this padding represents? > For example: > Is the padding conceptually added to, or subtracted from, the image? > How does it interact with the positioning algorithms? (How does the presence of > padding affect the result?) > How is it calculated? > When is it re-calculated and why? > What happens if these values are zero? Non-zero? > Maybe explain with an example - for example, if the toolbar appears/disappears > at the top of the screen, what effect does it have on mImagePadding.top ? > > Feel free to write a very long comment if necessary :) Added a block of text at the top of the class giving in depth details on everything. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:222: // Remove or add image padding based on the new position. On 2016/09/30 01:59:37, Lambros wrote: > How is padding based on position? Removed comment since it wan't useful. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:251: return new RectF(-maxPadding[0], -maxPadding[1], mRenderData.imageWidth + maxPadding[2], On 2016/09/30 01:59:36, Lambros wrote: > If my reading is correct, this is the full image rectangle, inflated outwards by > the maxPadding amount. > What has this got to do with allowed cursor values? > Maybe call this getMaxPaddedImageRect() or getMaxPaddedImageBounds() ? > > I don't conceptually understand what maxPadding is, so I also don't get the > concept of this method. I'll remove the maxPadding method since it is confusing and add comments here. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:269: return new RectF(imageBounds.left + screenCenterX, imageBounds.top + screenCenterY, On 2016/09/30 01:59:36, Lambros wrote: > return imageBounds.inset(screenCenterX, screenCenterY); Done. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:287: /** Returns the letter box padding needed in each dimension (x and y) in screen coordinates. */ On 2016/09/30 01:59:37, Lambros wrote: > Maybe explain in a little more detail: > This is the amount of unused screen space if the desktop image were positioned > perfectly in the center of the screen. Explained in detail at the top of the class. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:288: private float[] getLetterboxPadding() { On 2016/09/30 01:59:36, Lambros wrote: > Maybe return PointF ? I had originally left this as a float [] to make transforms simpler but I use it in an unmodified form more frequently so this change seems fine. https://codereview.chromium.org/2375113003/diff/20001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:333: * Update the current edge padding based on the current System UI and image postion state. On 2016/09/30 01:59:36, Lambros wrote: > s/postion/position/ Done.
Ping!
https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... File remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java (right): https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:71: * zoom out once the second image dimension matches the screen dimension. I'm still struggling to understand this exact concept. It sounds like "letterbox padding" is an artificial extension of the bounds of the image, to prevent excessive movement of the image when it is (fully or nearly) zoomed out. It completely "locks" movement in, say, the vertical direction if the vertical image size is smaller than the screen. When System UI appears, the "padding" is maybe adjusted. How? I can see 3 distinct schemes: * Reduced equally at top and bottom, because the viewable area is reduced by the system UI. Padding is always symmetrically applied. * Reduced at the side where System UI appears, down to a minimum of zero (padding is never negative). Maybe if you hit zero, you start taking away padding from the opposite side? Padding is always applied in such a way that Padding+SystemUI+Image == Screen (except when this would make padding negative). * Letterbox padding is not affected by system UI at all. There is a separate concept of "adjusted padding" that takes System UI into account. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:136: * We subtract the padding (100px) from the allowable range and end up with 400px - 700px. The Shouldn't this be 500px - 700px ? https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:137: * image is fully visible and no letterbox padding is displayed. But the image isn't fully visible? It's 600px tall but the viewable area is only 400px. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:149: * normal position or allow the viewport to remain until the extra padding is no longer required. "extra padding"? The amount of padding is *less* when there is System UI. So when System UI is dismissed, there is no "extra padding" to remove. Instead, there is a possibility of adding some new padding, now there is more screen space to put the image in. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:158: * at the adjusted System UI padding, current image padding, and the number of visible pixels. I don't understand "visible pixels" or the different types of padding. You have lots of different kinds of padding: "letterbox padding" "adjusted System UI padding" "current image padding" I understand the first of these. I sort-of get what "adjusted system UI padding" is trying to do, but not quite fully. I don't know what its definition is, or what properties it has, or what invariants it satisfies, so it's basically impossible for me to conceptualize or reason about it. I have no idea what "current image padding" is. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:162: * otherwise there is no need for padding. The System UI for this example has already been adjusted "otherwise there is no need for padding" But letterbox padding is still applied when there is no System UI at all. You probably don't mean "letterbox padding", but there are so many different kinds of padding now :)
Description was changed from ========== Allow Desktop Canvas to be scrolled out from under System UI. This change adds the ability to scroll the desktop canvas out from under any visible System UI. We also want to reduce the amount of screen 'bounce' and other jarring position translations. When System UI is displayed (for Kitkat and higher) the TouchInputHandler instance is called with the state/sizes of the System UI per edge of the screen. These values are passed to the DesktopCanvas instance. The DesktopCanvas instance uses these values for determining the allowable position of the viewport. As the canvas is repositioned, the amount of padding used is tracked per edge (calculated based on System UI size, current amount of padding, and the number of visible pixels around the image border). When the System UI disappears (or changes size), this information is eventually received by the DesktopCanvas instance. It uses current amount of padding for positioning. As the canvas is translated or scaled, this visible padding is reduced (it cannot be increased) so the padding decreases to 0 and then all functionality acts as it would have before. BUG=621633 ========== to ========== Allow Desktop Canvas to be scrolled out from under System UI. This change adds the ability to scroll the desktop canvas out from under any visible System UI. When System UI is displayed (for Kitkat and higher) the TouchInputHandler instance is called with the state/sizes of the System UI per edge of the screen. These values are passed to the DesktopCanvas instance which uses them for determining whether the System UI overlaps with the remote image content. If there is overlap then it adjusts the region of valid cursor and viewport positions which then allows the user to pan the content out from 'under' the System UI which is obscuring it.allowable position of the viewport. When the System UI disappears (or changes size), the current amount of padding, if any, is used as the new boundary. This prevents a jarring translation from occuring when the System UI changes size. BUG=621633 ==========
The CQ bit was checked by joedow@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
I've simplified the padding calculations quite a bit as I realized that a bunch of that code was only useful with the old positioning code (where we used to center the image and then re-position it). Since I ripped that old code out and replaced it with bounding regions instead, the padding calcs are much simpler. Due to the simplification, I don't think the block comments at the top of the class are needed anymore either so I removed those. PTAL! Joe https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... File remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java (right): https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:71: * zoom out once the second image dimension matches the screen dimension. On 2016/10/03 23:04:10, Lambros wrote: > I'm still struggling to understand this exact concept. > It sounds like "letterbox padding" is an artificial extension of the bounds of > the image, to prevent excessive movement of the image when it is (fully or > nearly) zoomed out. It completely "locks" movement in, say, the vertical > direction if the vertical image size is smaller than the screen. > When System UI appears, the "padding" is maybe adjusted. How? I can see 3 > distinct schemes: > * Reduced equally at top and bottom, because the viewable area is reduced by the > system UI. Padding is always symmetrically applied. > * Reduced at the side where System UI appears, down to a minimum of zero > (padding is never negative). Maybe if you hit zero, you start taking away > padding from the opposite side? Padding is always applied in such a way that > Padding+SystemUI+Image == Screen (except when this would make padding negative). > * Letterbox padding is not affected by system UI at all. There is a separate > concept of "adjusted padding" that takes System UI into account. Discussed offline. I've simplifed the code a bit and removed this text (since I don't think it provides value anymore). https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:136: * We subtract the padding (100px) from the allowable range and end up with 400px - 700px. The On 2016/10/03 23:04:10, Lambros wrote: > Shouldn't this be 500px - 700px ? Comment block removed. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:137: * image is fully visible and no letterbox padding is displayed. On 2016/10/03 23:04:10, Lambros wrote: > But the image isn't fully visible? It's 600px tall but the viewable area is only > 400px. Comment block removed. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:149: * normal position or allow the viewport to remain until the extra padding is no longer required. On 2016/10/03 23:04:10, Lambros wrote: > "extra padding"? The amount of padding is *less* when there is System UI. So > when System UI is dismissed, there is no "extra padding" to remove. Instead, > there is a possibility of adding some new padding, now there is more screen > space to put the image in. N/A Comment block removed. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:158: * at the adjusted System UI padding, current image padding, and the number of visible pixels. On 2016/10/03 23:04:10, Lambros wrote: > I don't understand "visible pixels" or the different types of padding. > You have lots of different kinds of padding: > "letterbox padding" > "adjusted System UI padding" > "current image padding" > > I understand the first of these. I sort-of get what "adjusted system UI padding" > is trying to do, but not quite fully. I don't know what its definition is, or > what properties it has, or what invariants it satisfies, so it's basically > impossible for me to conceptualize or reason about it. > I have no idea what "current image padding" is. Comment block removed. https://codereview.chromium.org/2375113003/diff/40001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:162: * otherwise there is no need for padding. The System UI for this example has already been adjusted On 2016/10/03 23:04:10, Lambros wrote: > "otherwise there is no need for padding" > But letterbox padding is still applied when there is no System UI at all. > You probably don't mean "letterbox padding", but there are so many different > kinds of padding now :) > Comment block removed.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
This is much easier to follow, thanks for simplifying! I would still prefer to use true Rect()s instead of offset/padding values, but this is fine as it is now. lgtm https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... File remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java (right): https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:34: private PointF mViewportPosition = new PointF(); Optional, not really part of this CL: Is there any reason we need to store this? Can't it always be calculated from mCursorPosition? https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:37: * Represents the desired center of the viewport in image space. This value may not represent Clarify that this position may extend beyond the boundary of the image, even though the injected cursor position is restricted to the image rectangle. https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:47: private Rect mSystemUiScreenSize = new Rect(); Now you've renamed this to remove 'offset', maybe clarify that this is not a true rectangle? https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:54: private RectF mVisibleImagePadding = new RectF(); optional: Would be nice if you could remove this member. It's currently circular: it is determined by reality, and also updates reality. You could just calculate it from reality everywhere, and then have a method, reduceVisibleImagePadding() that figures out how to change reality to reduce the padding by PADDING_REDUCTION_FACTOR. https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:275: // viewport itself. This prevent over and under panning of the viewport while still prevents
Thanks for the suggestions and review! https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... File remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java (right): https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:34: private PointF mViewportPosition = new PointF(); On 2016/10/04 22:06:35, Lambros wrote: > Optional, not really part of this CL: > Is there any reason we need to store this? Can't it always be calculated from > mCursorPosition? This was more important before I rewrote the positioning code. I will follow up and see if I can remove it in a later CL. https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:37: * Represents the desired center of the viewport in image space. This value may not represent On 2016/10/04 22:06:35, Lambros wrote: > Clarify that this position may extend beyond the boundary of the image, even > though the injected cursor position is restricted to the image rectangle. Done. https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:47: private Rect mSystemUiScreenSize = new Rect(); On 2016/10/04 22:06:35, Lambros wrote: > Now you've renamed this to remove 'offset', maybe clarify that this is not a > true rectangle? Acknowledged. Added TODO. https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:54: private RectF mVisibleImagePadding = new RectF(); On 2016/10/04 22:06:35, Lambros wrote: > optional: > Would be nice if you could remove this member. > It's currently circular: it is determined by reality, and also updates reality. > You could just calculate it from reality everywhere, and then have a method, > reduceVisibleImagePadding() that figures out how to change reality to reduce the > padding by PADDING_REDUCTION_FACTOR. Acknowledged. https://codereview.chromium.org/2375113003/diff/60001/remoting/android/java/s... remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java:275: // viewport itself. This prevent over and under panning of the viewport while still On 2016/10/04 22:06:35, Lambros wrote: > prevents Done.
The CQ bit was checked by joedow@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from lambroslambrou@chromium.org Link to the patchset: https://codereview.chromium.org/2375113003/#ps80001 (title: "Addressing CR feedback")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #5 (id:80001)
Message was sent while issue was closed.
Description was changed from ========== Allow Desktop Canvas to be scrolled out from under System UI. This change adds the ability to scroll the desktop canvas out from under any visible System UI. When System UI is displayed (for Kitkat and higher) the TouchInputHandler instance is called with the state/sizes of the System UI per edge of the screen. These values are passed to the DesktopCanvas instance which uses them for determining whether the System UI overlaps with the remote image content. If there is overlap then it adjusts the region of valid cursor and viewport positions which then allows the user to pan the content out from 'under' the System UI which is obscuring it.allowable position of the viewport. When the System UI disappears (or changes size), the current amount of padding, if any, is used as the new boundary. This prevents a jarring translation from occuring when the System UI changes size. BUG=621633 ========== to ========== Allow Desktop Canvas to be scrolled out from under System UI. This change adds the ability to scroll the desktop canvas out from under any visible System UI. When System UI is displayed (for Kitkat and higher) the TouchInputHandler instance is called with the state/sizes of the System UI per edge of the screen. These values are passed to the DesktopCanvas instance which uses them for determining whether the System UI overlaps with the remote image content. If there is overlap then it adjusts the region of valid cursor and viewport positions which then allows the user to pan the content out from 'under' the System UI which is obscuring it.allowable position of the viewport. When the System UI disappears (or changes size), the current amount of padding, if any, is used as the new boundary. This prevents a jarring translation from occuring when the System UI changes size. BUG=621633 Committed: https://crrev.com/b2fd3d47699032e7d52a4ac2317135e444bbea6f Cr-Commit-Position: refs/heads/master@{#423004} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/b2fd3d47699032e7d52a4ac2317135e444bbea6f Cr-Commit-Position: refs/heads/master@{#423004} |
