Manual bisect:
Good Build: 51.0.2666.0 dev
Bad Build: 51.0.2667.0 dev

Tool Bisect:
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/a9af97d82c54e699fb369db0fdc8e44923af03d7..e4dae472b2f122a5c93dc3f7338ee946eda677b1

Unable to find suspect from changelog. Please help in assigning to appropriate dev.

Able to reproduce the issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.5 using chrome latest Dev M52-52.0.2743.10. Observed a white line flickers below the video while resizing the chrome window.

Moving this nonessential bug to the next milestone.

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

sc00335628@ Please confirm whether this issue is till reproducible?

With respect to Comment#4: Checked the issue on latest linux 54.0.2825.0 and is still reproducible.

Attaching screenshot of same.

Deleted: Actual_615007.png 574 KB

	Actual_615007.png 574 KB View Download

This bug is tagged as regression.Which means that the bisects are incorrect or do not have an owner who is actively investigating.
Requesting the reporter to triage and update the behavior in all the latest chrome channels and bisect if needed.Close as WontFix if not reproducible.

Issue is still reproducible on 56.0.2920.0 dev ,Ubuntu 14.04 on resizing window.

Re-bisected an got changelog as:

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/e931e57f2587458f35852035ba7afc526989d127..40b5be7a5c1c8172109644d1317f20a857ad9617

Suspecting  https://codereview.chromium.org/1762673002 from changelog.

@kojii: Please help in re-assigning if it is not related to your change.

The bisect looks wrong, my CL is about a change in test, and others don't look related.

The issue looks like about IFRAME sizing, but is it possible to re-try the bisect and see if it results in the same range?

Rebisected this on Windows-10 and this looks to be regressed in M-53. M-52(chrome version: 52.0.2743.116) worked fine on Windows-10.

Bisect result from Windows-10.

Last good build: 53.0.2749.0
First bad build: 53.0.2750.0

Changelog: https://chromium.googlesource.com/chromium/src/+log/59d51f9a4cea0fd3d0c27eaf069442b9f556ea9a..d1b22fc961b1a2677c32f61a2a5640850b66adb9

Suspected change: https://codereview.chromium.org/2016883002

reveman@: Could you please take a look at this and confirm if the suspected change could be related to this.

Thank you!

Issue is seen in mac os 10.11.6 using chrome canary M57 #57.0.2931.0 

@reveman --could you please look into this.

Thanks!

Note, this looks like depends on window size. You may need to resize the window to see if it reproduces.

That change only effects chromeos devices and Android apps so it can't be the cause of this issue. 

Rebisected this on Windows 10 and got the same good and bad as in C#9.

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/e623eb7cd1fc6d7cef93a133c4742c42da96b76c..7b8323249aac91b1c7e51d880584fd102934cb7e

This looks to be related to  https://codereview.chromium.org/2006223006 and that's why has different regression range on Windows than on Linux as bisect result as updated in C#1.(Linux bisect includes the CL of turning on the material design on Linux https://codereview.chromium.org/1759483005 in C#1)

 

I can get a white line to appear on the right side if I resize the browser window just so --- as others have noted, the precise size of the window is important. I am pretty confident this can't be related to top chrome Material Design because it's all inside the renderer. This may bisect to that change simply because that change affects the size of the renderer (as the space used by the toolbar changes slightly).

Using the web inspector, it looks to me to be a pixel rounding error (subpixel alignment or whatever we call it). The .glue-modal class has a white background and a fractional size; the .glue-modal-content class is supposed to be 100% but doesn't seem to always get the entire size of its parent.

I'm guessing that video elements have to map to an integer number of CSS pixels while regular HTML elements do not.

Either the material design UI *or* the Media controls needs to take this into account.

I'm not sure how the top chrome UI could take this into account?

assigning to someone who can triage

Just to update, able to reproduce the issue on windows 7 using chrome version 57.0.2970.0.

dcheng@, any idea where this might belong to? Bisect doesn't seem to be helpful very much.

This issue looks like it's about IFRAME sizing, and you're the best expert on IFRAME as far as I know?

Sorry, I don't have much insight to add here - it looks like something related to styling and pixel rounding. I don't think it's iframe specific.

When bisecting, did we verify that 'good' revisions didn't reproduce this bug when the window is resized? On CrOS, it's immediately obvious when this happens (the white line flickers in and out as the window is resized)

When bisecting on Windows-10, Desktop resolution(1920*1200) without resizing the browser window. 

Chrome:
========
>Good build doesn't show any whiteline at the bottom but does show whiteline to the right.
>Bad build shows the whiteline both at the bottom and to the right.

Firefox:
========
>Doesn't show any whiteline at the bottom but shows to the right like the Good build of Chrome.

IE and Edge:
============
>Doesn't show any whiteline at the bottom or to the right. 

IFRAME is sized like 698.438 x 722.750, when its parent has "width: 76%; height: 76%".

Inside the IFRAME, <html> is 698 x 0, and <body> is 698 x 723. <video> is smaller, 698 x 393, so I guess rounding is happening at FrameView.

Also "margin: auto" looks necessary. Attaching (currently) minimum repro.

Deleted: frame-size-rounding-615007.html 492 bytes

frame-size-rounding-615007.html 492 bytes View Download

I wonder if this is a layout issue.

I see the white horizontal line *sometimes* (but not always) when the iframe has a size between N and N + .5 for some integer N.

I see another spurious horizontal line at the top of the video when using page zoom and resizing.

Talked with eae@, yeah, rounding is a layout issue, even if it's specific to FrameView.

Just To Update,Still able to reproduce the issue on Ubuntu 14.04 using latest chrome version 57.0.2986.0.

Could some one from cc people please look into this issue.

Thanks!

My instinct atm is that this isn't a regression, just flaky or bisect process not doing the same steps each time.

Let me change to pri 2 based on the suspect, if anyone thinks this is a regression, or got more accurate bisect, please change it back to pri 1.

Not happening for me on Linux, 63.0.3236.0 (Official Build) dev (64-bit).

Can you confirm if it's still happening for you?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

No longer happening.