I'm suspecting a blink bug:

* Inconsistent reproduction
* Suddenly works when properties are toggled in Dev Console

Will try to bisect.

Confirmed that the regression happened with 95c34ae (r419271): "    availableLogicalHeightUsing needs to take flexbox stretched heights into account" reviewed at https://codereview.chromium.org/2349803002.

cbiesinger: Could you explain what that CL changed from a CSS author's point of view? Is it possible your fix uncovered a bug in our implementation (or vice versa)?

 Issue 648186  has been merged into this issue.

In theory, what the change did was correct the position of a relative-positioned box within a flex item, where the relpos item uses a percentage value for the "top" property.

It may have affected some other things that depend on the height -- in theory, making them more correct (=actually using the real size of the flex item).

What does your code do to trigger this animation when going back from the dialog?

#4: It's a complicated effect.... If you'd like to play with it yourself, you can adjust the animation timings by setting |settings.animation.Timing.DURATION| (in ms).

The TL;DR is that we make the card position: absolute, position it to the scroll top, and animate it to the target height and location. Then we make it position: relative, which is when it disappears.


The expanded element (0:02 in the video) is a:

    <settings-section class="expanded">

where the (relevant) applied styles are:

    display: flex;
    flex-direction: column;
    min-height: 100%;
    position: relative;

The shadow root of the <settings-section> includes a:

    <div id="card">

with the styles:

    flex: 1;
    overflow: hidden;
    z-index: 0;



Preparing for the animation that shrinks the settings-section:

    1. Set div#card's inline width, height, top styles to current computed values
    2. Set div#card's inline position to "fixed"
    3. Change settings-section's class from "expanded" to "collapsing"
    4. Set settings-section's inline height to its original non-expanded height (the ending state)

The styles for <settings-section class="collapsing">, in addition to the inline height, become:

    display: flex;
    flex-direction: column;
    position: relative;
    z-index: 1;

The styles for <div id="card">, in addition to the inline styles, become:

    flex: 1;
    overflow: hidden;
    position: relative; (overridden by inline "fixed")
    z-index: 0;




Playing the animation that shrinks the settings-section:

    1. Unset div#card inline position.
    2. Play a web animation:
           start frame: [position: absolute,
                         width: 600px,
                         top: -65px, (to match the card's location when it was position: fixed)
                         height: 800px] (to match the card's expanded height)
             end frame: [position: absolute,
                         width: 600px,
                         top: 48px, (to match the card's location when it becomes position: relative)
                         height: 353px] (to match the card's collapsed height)
    3. Unset div#card's remaining inline styles (width, height, top).

During the animation, the style for <settings-section class="collapsing"> is:

    display: flex;
    height: 400px (the space it should occupy in the page, since the card is now position: absolute)
    position: relative;
    z-index: 1

and the <div#card> is:

    flex: 1;
    overflow: hidden;
    position: relative; (overridden by animation "absolute")
    z-index: 0;



Upon the animation completing, the styles are the same as above, but the <div#card> is now position: relative since the animation's "absolute" no longer applies. We then:

    1. Unset settings-section inline height (no longer necessary, since div#card is position: relative)
    2. Remove settings-section "collapsing" class

At the end:

* The settings-section has a computed height of 48px (just the section title).
  [[See: d1.png]]
* The div#card has a computed height of 0px according to the Inspector and **is not visible**.
  [[See: d2.png]]
* The :content of the div#card has the expected computed height, but is not visible, presumably because of an overflow or z-index (if it were visible, it would overlap other content since the section has the wrong height.
  [[See: d3.png]]


Toggling a style off and on, or resizing the page, fixes the glitch: the div#card and settings-section get their correct computed heights, and everything displays as it was in the beginning of the video.

If the bug **doesn't** repro, the computed styles are **still wrong** in the inspector even though everything is the correct height; again, toggling a style off and on fixes the computed height.

The above two paragraphs convince me it's a Blink bug.

Deleted: d1.png 291 KB

	d1.png 291 KB View Download

Deleted: d2.png 295 KB

	d2.png 295 KB View Download

Deleted: d3.png 297 KB

	d3.png 297 KB View Download

 Issue 651583  has been merged into this issue.

Hm... so this is a matter of the wrong size, not the wrong position?

To clarify:
- The flexbox has the right size
- The flex item has the wrong size (and has position: relative)

Is that right?

If so, that would be rather unexpected!

Yes, I think that's accurate. The div#card flex item has 0 height for no reason that I can discern (and gets corrected on toggling unrelated styles).

You can inspect things by visiting chrome://md-settings and finding a section that includes <settings-animated-pages>, which most of them do.

 Issue 655515  has been merged into this issue.

cbiesinger@: this issue is blocking md-settings' ability to launch to the dev channel.  any ETA on the fix?

Sorry, I'll look tomorrow. Is there an easy way to get the settings page to stay in the state where the flex item has the zero height? Or, maybe I just couldn't quite follow your suggestion from comment 8 :)

May not be reproducible in every environment, but here's an interesting hack to make the hidden state persist without changing the code:

1. load a fresh chrome://md-settings
2. tap Search engine > Manage search engines
3. add two breakpoints:

   - settings_section.js:204:
             this.animateCard_('absolute',....
   - settings_section.js:209
         animation.finished.then(function() {

4. press the back arrow
5. hits bp at line 204. hit resume (F8). animation plays.
6. hits bp at line 209. hit resume (F8). section disappears forever!

You can examine the problematic tree with:
    s = document.querySelector('* /deep/ settings-section[section=search]')

In particular, s.root.querySelector('#card').offsetHeight == 0.

If you toggle a style on an element (pretty much anywhere), the card re-appears. Also, resizing the page horizontally can make the card re-appear.

==========================================

I'm not sure whether the debugger simply triggers some kinda race condition, or if it's really the "same" problem we see without the debugger. Note that the web-animations-js polyfill adds noise to the debugging process; if you like you can disable it with hacks: http://pastebin.com/Fw7NT603

 Issue 656934  has been merged into this issue.

For some reason we compute the 0% flex basis as 0 instead of auto, even though I don't currently see why this would be considered definite. That's weird.

what's the status on this?  it's blocking the new Material Design settings page launch (to dev channel)

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

commit 8c4965f69d6de2d3c4ed9c6cd5b2ccbee1667cad
Author: dpapad <dpapad@chromium.org>
Date: Wed Nov 09 01:47:10 2016

MD Settings: Fix clipping of search bubbles by card boundary.

This patch also seems to address the case where a settings card is briefly
animated to a 0px height after exiting an animation.

BUG= 647487 , 649174 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/8c4965f69d6de2d3c4ed9c6cd5b2ccbee1667cad/chrome/browser/resources/settings/settings_main/settings_main.html
[modify] https://crrev.com/8c4965f69d6de2d3c4ed9c6cd5b2ccbee1667cad/chrome/browser/resources/settings/settings_main/settings_main.js
[modify] https://crrev.com/8c4965f69d6de2d3c4ed9c6cd5b2ccbee1667cad/chrome/browser/resources/settings/settings_page/settings_section.html

As of r430816, the repro steps at comment #1 are not sufficient to reproduce the issue. Please use a revision before that for further investigation.

Leaving this open since per comment #15 there is an underlying blink issue that caused it.

It is possible that https://codereview.chromium.org/2571893002/ will fix this as well

Yeah that fixed it. Testing steps:

$ git checkout 8c4965f69d6de2d3c4ed9c6cd5b2ccbee1667cad^
$ gclient sync
compile
run, make sure the flicker reproduces
$ git cherry-pick b313bcac825d7be7741d7923e9074a93a42f72d7
compile
run, bug does not reproduce anymore. So, same as bug 669714