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

Issue 691968 link

Starred by 4 users
Status: WontFix
Owner:
█ robhogan@chromium.org
Use other robhogan account instead.
Closed: Feb 2017
Cc:
█ robhogan@chromium.org
ajha@chromium.org
█ msten...@opera.com
█ kavvaru@chromium.org
nyerramilli@chromium.org
rbasuvula@chromium.org
█ brajkumar@chromium.org
█ msrchandra@chromium.org
█ ranjitkan@chromium.org
█ durga.behera@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Unwanted scrollbar is observed in 'Memory' section of devtools.

Reported by yfulgaon...@etouch.net, Feb 14 2017 
Chrome Version : 58.0.3012.0 (Official Build) 66847e854d3acd13965764bcbc72d38f455c463c-refs/heads/master@{#450199} 32/64 bit
OS : Windows (7,8,10), Mac(10.12.1, 10.11.6, 10.12), Linux(14.04 LTS)

What steps will reproduce the problem?
1. Launch chrome and open devtools on NTP.
2. Navigate to 'Memory' tab, select 'Record Allocation Profile' option and click on 'Start' button.
3. Now click on 'Stop' button and observe the vertical scrollbar at the RHS of devtools window.

Actual : Vertical scrollbar is observed in 'Memory' section, even when there is no recorded summary present.
Expected : Scrollbar should not appear when summary is not present.

This is a regression issue broken in ‘M-58’, below is the Manual Regression range and will soon update other info.
Good build : 58.0.3006.0
Bad build : 58.0.3007.0
Act_Exp_scrollbar.png
37.5 KB View Download
Actual_Result.mp4
895 KB View Download
Expected_Result.mp4
788 KB View Download

Comment 1 by rbasuvula@chromium.org, Feb 14 2017

Cc: rbasuvula@chromium.org
Labels: hasbisect-per-revision ReleaseBlock-Stable
Owner: robhogan@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build: 58.0.3006.0 (Revision: 448862).
Bad build: 58.0.3007.0 (Revision: 449173).

You are probably looking for a change made after 449100 (known good), but no later than 449101 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/1dfa16b2126e9776a3e26f00b4c767b83f2645b5..d3ceb0147ad9f4d4a9b41cea0362d6221cb72302

From the CL above, assigning the issue to the concern owner

@robhogan:Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url:  https://codereview.chromium.org/2670603002
Note:1.Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.2 and able to reproduce in latest canary #58.0.3012.0
2.Adding Release Block-Stable for this issue.Please remove if not the case.

Comment 2 by robhogan@chromium.org, Feb 14 2017

Cc: msten...@opera.com
Reduction attached. mstensho@ - I need your thoughts here. When the table's container reduces in height I need to ensure calcRowLogicalHeight() gets called. Maybe it's late in the evening, but I'm drawing a blank on the right way of solving this.
691968.html
513 bytes View Download

Comment 3 by msten...@opera.com, Feb 15 2017 

So... conditioning calcRowLogicalHeight() on the section needing layout was wrong, since the section may be resized by its containing block. Attaching an even simpler test case. No need for percentage heights to reproduce this, luckily.

I suppose we need to be able to detect that the height of the table changes, and when it has changed, we need to lay out sections.

There's already m_columnLogicalWidthChanged for widths. BTW: this one is actually set to true more often than it should, which is why I had to set border-spacing:0 in my test. Otherwise the bug would be hidden.
tc.html
304 bytes View Download

Comment 4 by robhogan@chromium.org, Feb 15 2017

Cc: durga.behera@chromium.org robhogan@chromium.org ajha@chromium.org kavvaru@chromium.org brajkumar@chromium.org
 Issue 691916  has been merged into this issue.

Comment 5 by robhogan@chromium.org, Feb 18 2017

Status: WontFix (was: Assigned)
Fixed by reverting: https://codereview.chromium.org/2700183003
►

Sign in to add a comment