I think I know what you mean. But it isn't visible in the video (I also tried to capture it, but it didn't work).
When you fling the NTP, the omnibox gets shifted for a fraction of a second multiple times. Almost looks like the omnibox is flickering. 

I saw something very similar to this, but in a steady state (i.e. not while scrolling). The omnibox is shifted downwards a couple of pixels, and rendering artifacts appear in the leftover space at the top. If I take a screenshot from the phone, the artifacts disappear (so I photographed the screen instead for the attachment).

Deleted: IMG_20160420_104852.jpg 1.1 MB

	IMG_20160420_104852.jpg 1.1 MB View Download

Tried it on a 5x and it doesn't repro at all. But it repros consistently on N5 and N6.

Grace, this is the bug you experienced with Zine today.

Yes, I saw both the original bug and #2. I am using N6p.

After comparing some screenshots, the entire area drawn by the app is scaled down, and the space remaining at the top gets filled with whatever is in the buffer. I have no idea how this can happen. 

sievers@, aelias@, do you have any pointers on what could cause that?

I don't know what rendering stack this Zine stuff uses, is it 100% View System or is a SurfaceView/TextureView involved anywhere?  I would assume it's just View System in which case it's more in Ted's area.

Right, it's NewTabPageView, which is a NativePage and AFAICT it only involves standard Views

The two things that I would be wondering about:
1.) Are you drawing the NTP as a texture at the time (i.e. entering/exiting the tab switcher), which might be a result of incorrect texture capture sizing.
2.) I believe the NTP is drawn over the surfaceview at all times, but we might have made the assumption that the NTP is opaque everywhere.  Maybe zine changed this assumption?

I would look at hierarchyviewer if you can get this into the broken state for a longer time and see if things are indeed shifted.

The cards NTP is opaque everywhere as well.

I did look at this in HierarchyViewer, and it thinks everything is absolutely fine. All the views have the correct size and look correctly from within the HierarchyViewer (e.g. when exporting the view layers as a PSD doc), but taking a photo of the actual screen shows that that is a filthy lie.

Same issue on observed on Nexus6/52.0.2736.0

Just adding - I saw the weird strip on my Nexus 5X just by opening the new tab page from the tab switcher. (see videos)

This is happening on the latest Chrome Beta release (51.0.2704.43)

Deleted: new_tab_bug_1.mp4 8.5 MB

new_tab_bug_1.mp4 8.5 MB Download

Deleted: new_tab_bug_2.mp4 7.0 MB

new_tab_bug_2.mp4 7.0 MB Download

Issue 613508 has been merged into this issue.

Issue 614669 has been merged into this issue.

Assigning to myself to keep track.

Can we get this fixed for M53? :)

This bug is reproducible on M51 stable with N6 Marshmallow, by removing the last tab and create a new tab afterwards. Screenshot won't display these misdrawn pixels but they are very visible.

Moving this nonessential bug to the next milestone.

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

If someone wants to take this on, they're more than welcome :)

I've managed to reproduce this on builds from January or so that didn't have our snippets code yet, so this doesn't look like it was introduced by that.

My next step here would be to start bisecting, because it is reproducible fairly (although not 100%) reliably with the steps in comment 22.

Thanks Bernhard! In case you don't have the cycles to bisect, would it make sense to loop in the testing team for bisection? That should help us find the person best to look into this, right?

Yes, although it might be more useful to bisect while building locally, because that will result in a single CL (as opposed to a range of CLs spanning a day).

 Issue 628937  has been merged into this issue.

While this might not be related to snippets, can we please get this addressed?  If you can't own this bauerb@, can you assign it to someone on your team to get this tracked down.

Assigning back to you so you can find it an owner.  This is a really gross bug on one of the most visible surfaces, so we should track this down and get it addressed.

Moving this back to 53 and marking RBS.  While it has existed for a while, I don't want to use that as an excuse for not addressing it.

The chromium revision that introduced this bug is crrev.com/3bc8338191cdc2369891ca26a773f91dafe77732

That's a third_party/android_tools roll.

Within that repo, the culprit is 2fd98442e4e0ced6bb30bd57abfd8a34f8142d09

That upgraded the Android Support Library from 23.0.1 to 23.2.

Ah, that should be 23.1 to 23.2

Aurimas, do you perhaps know someone who would be able to narrow down the suspects within the Android Support Library?

I filed b/30391759 for this.

You are using an ancient support library, it is version 24.1.0 now. Please update.

Nevermind, read the bug. We'll see where that goes.

Hey guys.....so whats the conclusion
Can i hope to get some reward or something of finding this small bug?😋🙈

Here's more evidence. Today in the morning on my commute I ran into this issue and took a video: https://drive.google.com/drive/folders/0B0OP7vpw4OKLQURPaXZScjY4ZXM

I got into this state by visiting content suggested by a snippet, consuming that content (incl. scrolling) and then returning to the NTP.

As you can see it seems like the omnibox is incorrectly adjusting its position during scroll.

Canary 54.0.2809.0

To prevent confusion: the position of the omnibox is correct, what is happening is that the entire visible surface gets scaled down horizontally *after* all the views have been composited (i.e. it's a visual problem, not a layout problem).

Thanks Bernhard for the clarification. I can indeed see that the entire surface incl. Omnibox seems to get re-scaled.

This now repros reliably on Canary (Bernhard is aware, just documenting it here, too):

Prerequisite:
- Current Canary 54.0.2809.0 (doesn't repro on current Dev 53.0.2785.21)
- Have content suggestions below the fold

Repro steps:
- Scroll below the fold

Just received a Dev update. This is also *not* reproducing reliably with Dev 53.0.2785.35, so needs to have regressed between 53.0.2785.35 and 54.0.2809.0

Huh, that's interesting. There have been a number of changes to the support library between those versions (https://chromium.googlesource.com/chromium/src.git/+log/53.0.2785.35..54.0.2809.0/build/secondary/third_party/android_tools/BUILD.gn): specifically, AAR support has been added to Chrome and the support library rolled to 24.1.1 (which requires AAR support), but then the support library was rolled back to 23.2.1, but the other changes stuck.

I just received the latest Canary 54.0.2810.2. This still repros 100% of the time with the prerequisites (modulo Chrome version) from Comment 50.

So, just to make things more confusing, there is indeed a bug where we position the toolbar wrongly (see https://codereview.chromium.org/2203823002/). Note that that is different from this issue though: The proper background is visible behind the toolbar, the UI does not get scaled down vertically, and the bug is visible in a screenshot. Please apply the proper differential diagnosis if you happen to reproduce either :)

In the latest Canary 54.0.2817.0 this doesn't reproduce 100% anymore with the steps in Comment 50.

Instead, it is now showing occasionally (but still frequently enough to reproduce it within 1-5 seconds) by scrolling up and down quite fast.

FWIW, that way of reproducing it has been around for a while.

But isn't it interesting that the repro steps in Comment 50
- started working somtimes between ]53.0.2785.35 and 54.0.2809.0], and
- stopped working sometimes between ]54.0.2810.2 and 54.0.2817.0] ? :)

There were a couple of rolls (forward and backwards) of the support library recently, and the first time the issue appeared was with a support library roll. So something in the support library seems to *trigger* this, although the underlying bug might be somewhere else.

I do not believe rolling the support library causes this, because this bug has been there way before. I've seen this bug for a long time (at least for more than a quater). For me the easiest steps to reproduce is removing the last tab and clicking new tab button in the empty tab switcher. IIRC this bug has been visible to me ever since newt@ left the team. The reason why I could observe this issue so early was that I needed to test the tab undo snackbar all the time.

Attached bug screenshot is taken on Nexus 6p Android 6.0 running Chrome 53. Beforehand I've seen this issue on N5 and N5x also. We did not roll support lib in 53 because of the AAR support, and only until 54 did we roll the support lib.

If I were to debug this issue, I would trace back to the very first zine CLs to see how NTPView, NTPScrollView, NTPLayout were changed, especially for onLayout() and onMeasure() methods.

Deleted: 4594634777361858832-account_id=1.jpg 56.3 KB

	4594634777361858832-account_id=1.jpg 56.3 KB View Download

Ianwen, thanks for the screenshot and the repro description. 

I can reproduce your repro case on my corp Nexus 6 (M54 Canary, M53 Dev, M53 Beta, M52 Stable) - the higher I get in channels the more often I need to repeat your steps to trigger it.

I can also reproduce on my personal Nexus 5x (M51.0.2704.81 Stable), but it's harder there, I need to be really fast in switching and try quite a few times.

So, it was definitely there as long as I can see, but has become more visible for whatever reason.

Reposting from b/30391759:

When there is a SurfaceView anywhere in the view hierarchy, the transparent region optimization is turned on, which calls gatherTransparentRegion() on all views (to remove fully transparent layers from compositing). Opaque views will remove their own bounds from the transparent region, but if a view reaches outside the bounds of its parent, it will remove the transparent region there as well. This is in fact what happens in a RecyclerView, and it's somewhat non-deterministic, because gatherTransparentRegion() is only called when layouting.

So, if it happens that gatherTransparentRegion() is called while the RecyclerView has a child starting at somewhere between 0 and 24dp (the height of the status bar), some of the transparent region _inside the status bar_ will be removed. Then when the ViewRootImpl reports the transparent region to the SurfaceFlinger, the latter calculates the visible region as the complement of that, so now it thinks the visible region extends into the area of the status bar. It then applies a source crop that is bigger than the drawn area, which has the effect of a) including some undefined pixels at the top, and b) scaling everything down to fit in the actual visible area, which explains exactly the behavior we've been seeing. It also explains why rolling the support library changed the reproducibility, as presumably there were some changes to the RecyclerView layouting in there.

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

commit 0ab0514557a8f2d7536acf6b2c13ab17e27446b6
Author: bauerb <bauerb@chromium.org>
Date: Tue Aug 09 16:39:50 2016

Only gather transparent regions inside their own view bounds in views that might have children extending beyond their bounds.

BUG= 604742 

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

[modify] https://crrev.com/0ab0514557a8f2d7536acf6b2c13ab17e27446b6/chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java
[modify] https://crrev.com/0ab0514557a8f2d7536acf6b2c13ab17e27446b6/chrome/android/java/src/org/chromium/chrome/browser/toolbar/ToolbarControlContainer.java
[modify] https://crrev.com/0ab0514557a8f2d7536acf6b2c13ab17e27446b6/chrome/android/java/src/org/chromium/chrome/browser/util/ViewUtils.java

Mega Woooot! :D Let's merge the change as soon as we've confirmed in a trunk build (assuming release managers are cool with it)

Re-oping this issue to track CL merge in M53 branch.

Hi Bernhard,

I can't see this issue on the latest Canary anymore, awesome!

Can we now merge back the change to the M53 branch?

Thanks

Patrick

That's what I was waiting for :)

Your change meets the bar and is auto-approved for M53 (branch: 2785)

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

commit 2348409f45de2eb0788d2c1bfa5332753c254508
Author: Bernhard Bauer <bauerb@chromium.org>
Date: Fri Aug 12 09:10:38 2016

Only gather transparent regions inside their own view bounds in views that might have children extending beyond their bounds.

BUG= 604742 

Review-Url: https://codereview.chromium.org/2221483002
Cr-Commit-Position: refs/heads/master@{#410701}
(cherry picked from commit 0ab0514557a8f2d7536acf6b2c13ab17e27446b6)

Review URL: https://codereview.chromium.org/2238203002 .

Cr-Commit-Position: refs/branch-heads/2785@{#576}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/2348409f45de2eb0788d2c1bfa5332753c254508/chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java
[modify] https://crrev.com/2348409f45de2eb0788d2c1bfa5332753c254508/chrome/android/java/src/org/chromium/chrome/browser/toolbar/ToolbarControlContainer.java
[modify] https://crrev.com/2348409f45de2eb0788d2c1bfa5332753c254508/chrome/android/java/src/org/chromium/chrome/browser/util/ViewUtils.java

Wooooot! Awesome PE fix! :)