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

Issue 615373 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: Unwanted white line is seen on cast overlay after setting 'Page zoom' to 150%-250%

Reported by jshan...@etouch.net, May 27 2016

Issue description

Chrome Version:52.0.2743.11 (Official Build)Revision 6b8610b195ce50e14827e3db8198dde414366705-refs/branch-heads/2743@{#96} (64-bit)
OS: Windows(7,8,8.1,10), Linux (ubuntu 14.04 LTS), Mac (10.10.5)(10.11.4)

Steps:
1. Launch Chrome, navigate to chrome://settings and set 'Page zoom' to 150%-200%.
2. Go to NTP and select Cast open from context menu and observe.

Actual: Unwanted white line is seen on cast overlay after setting 'Page zoom' to 150%-200%.

Expected: No white line should be seen on cast overlay after setting 'Page zoom' to 150%-200%.

This is a regression issue broken in M-50, below is bisect info.

Good build: 50.0.2637.0
Bad build: 50.02638.0

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/50ac11db71e0311d95d6bfd5a4912bf98cebe64c..eec02e1394905a98671bc640cd05504698dccc8f?pretty=fuller&n=30

Suspecting: r372809 ?

Please help to re-assign if your change is not the cause for this issue



 
Actual_Expected.jpg
122 KB View Download
Labels: -Pri-1 -M-52 M-53 Pri-2

Comment 2 by sko...@chromium.org, May 27 2016

Labels: -Pri-2 Pri-3

Comment 3 by sko...@chromium.org, May 27 2016

Labels: -M-53

Comment 4 by takumif@google.com, Jun 21 2016

The problem is that the we use the offsetHeight of the upper div (#first-run-flow) as the margin-top of the lower div (#container-header), and the offsetHeight attribute returns a rounded-up integer value, even if the actual height has decimals. So that fractional difference sometimes results in a 1px-wide space between the two divs. 

When you get the offsetHeight attribute in media_router_container.js (line 2322, this.$$('#first-run-flow').offsetHeight), you can subtract 1 to solve the issue, but that might not be a clean solution... I suppose another solution is to ensure that the actual height of #first-run-flow is always an integer.

Comment 5 by sko...@chromium.org, Jun 22 2016

Labels: Hotlist-Fixit-PE2016
Owner: ----
Status: Untriaged (was: Assigned)
-owner as I'm not actively looking into this.

Related: amp@ brought up handling zoom/larger text in another thread.

Comment 7 by sko...@chromium.org, Aug 17 2016

Cc: taku...@chromium.org
Labels: -Hotlist-Fixit-PE2016 Hotlist-Fixit
Status: Available (was: Untriaged)
Owner: taku...@chromium.org
Status: Assigned (was: Available)
Project Member

Comment 9 by bugdroid1@chromium.org, Sep 16 2016

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

commit 99ee961ad19a96ba4fa47a92130aee1e3f0dc0db
Author: takumif <takumif@chromium.org>
Date: Fri Sep 16 18:04:50 2016

[MR UI] Handle fractional height for first-run-flow element

The first run flow div, whose height is not hard-coded, has a fractional height value, which is also used as the top margin size for the header below it. By keeping it fractional rather than rounding by using offsetHeight, we avoid rounding errors.

BUG= 615373 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/99ee961ad19a96ba4fa47a92130aee1e3f0dc0db/chrome/browser/resources/media_router/elements/media_router_container/media_router_container.js

Status: Fixed (was: Assigned)

Sign in to add a comment