Don't change layout size due to top control show/hide

Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
Committed: https://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40
Cr-Commit-Position: refs/heads/master@{#370425}

[bokan, 2016-01-11 20:40:03]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-11 20:42:23]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1573283002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1573283002/1

[commit-bot: I haz the power, 2016-01-11 21:49:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-11 21:49:37]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[bokan, 2016-01-12 19:00:40]

Description was changed from

==========
<WIP> Don't resize initial containing block from top control show/hide.

BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden. Instead the
ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
BUG=428132
==========

[bokan, 2016-01-15 16:58:06]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-15 16:58:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1573283002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1573283002/80001

[bokan, 2016-01-15 16:58:47]

bokan@chromium.org changed reviewers:
+ aelias@chromium.org

[bokan, 2016-01-15 16:59:29]

Alexandre, PTAL. I'll send out an intent-to-ship to #blink-dev when/if you're
happy with this.

[commit-bot: I haz the power, 2016-01-15 17:15:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-15 17:15:23]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[bokan, 2016-01-15 17:28:56]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-15 17:29:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1573283002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1573283002/100001

[commit-bot: I haz the power, 2016-01-15 17:41:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-15 17:41:09]

Dry run: Try jobs failed on following builders:
  cast_shell_android on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[bokan, 2016-01-15 18:23:07]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-15 18:24:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1573283002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1573283002/120001

[commit-bot: I haz the power, 2016-01-15 21:42:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-15 21:42:40]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[aelias_OOO_until_Jul13, 2016-01-16 04:17:38]

Sounds good to send the intent-to-ship.

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.cpp:1130: float pageScale =
m_frame->host()->pageScaleConstraintsSet().finalConstraints().minimumScale;
This is because of how minimum-scale is also used in mainFrameSize, I assume?

The impact of scale on this stuff is a bit subtle, could you write a unit test
checking geometry sizes in the presence of an unusual min-scale?

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebViewImpl.cpp:1844: if
(!topControls().shrinkViewport())
TopControls::layoutHeight() already includes this branch.

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebViewImpl.cpp:3335:
document->notifyResizeForViewportUnits();
Likewise a test that fails if this isn't called.

[bokan, 2016-01-19 00:05:31]

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.cpp:1130: float pageScale =
m_frame->host()->pageScaleConstraintsSet().finalConstraints().minimumScale;
On 2016/01/16 04:17:38, aelias wrote:
> This is because of how minimum-scale is also used in mainFrameSize, I assume?

We say 100vh is the viewport size when top controls are hidden. When the page is
pinch-zoomable we have to also choose the scale at which we want 100vh to fill
the viewport (and use that to scale the top controls addition). I've actually
made a change here and use the scale at which viewport width == layout width. In
the common case, this will be the minimum scale. The difference is that I think
this behaves more sanely if the user specifies an explicit minimum-scale or has
a spurious "extra-wide" element on the page that implicitly increases the
minimum scale.

> 
> The impact of scale on this stuff is a bit subtle, could you write a unit test
> checking geometry sizes in the presence of an unusual min-scale?

Done, added two for scaled page and for a minimum-scale that's smaller than the
layout width scale.

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebViewImpl.cpp:1844: if
(!topControls().shrinkViewport())
On 2016/01/16 04:17:38, aelias wrote:
> TopControls::layoutHeight() already includes this branch.

It's actually the converse. When the top controls are hidden layoutHeight() will
be 0 but in this case we want to subtract their height from the WebView size to
keep the ICB from changing size.

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebViewImpl.cpp:3335:
document->notifyResizeForViewportUnits();
On 2016/01/16 04:17:38, aelias wrote:
> Likewise a test that fails if this isn't called.

This is no longer needed now that I use the layout width scale rather than
minimum scale.

[aelias_OOO_until_Jul13, 2016-01-19 20:26:32]

lgtm

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/1573283002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.cpp:1130: float pageScale =
m_frame->host()->pageScaleConstraintsSet().finalConstraints().minimumScale;
On 2016/01/19 at 00:05:31, bokan wrote:
> On 2016/01/16 04:17:38, aelias wrote:
> > This is because of how minimum-scale is also used in mainFrameSize, I
assume?
> 
> We say 100vh is the viewport size when top controls are hidden. When the page
is pinch-zoomable we have to also choose the scale at which we want 100vh to
fill the viewport (and use that to scale the top controls addition). I've
actually made a change here and use the scale at which viewport width == layout
width. In the common case, this will be the minimum scale. The difference is
that I think this behaves more sanely if the user specifies an explicit
minimum-scale or has a spurious "extra-wide" element on the page that implicitly
increases the minimum scale.

Sounds good, I was going to suggest the same thing.

[bokan, 2016-01-20 15:25:22]

Description was changed from

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden. Instead the
ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden. Instead the
ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
BUG=428132
==========

[bokan, 2016-01-20 15:26:18]

bokan@chromium.org changed reviewers:
+ jbroman@chromium.org

[bokan, 2016-01-20 15:26:19]

+jbroman@ for Source/core/layout and Source/core/css

[bokan, 2016-01-20 15:26:52]

Description was changed from

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden. Instead the
ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
BUG=428132
==========

[bokan, 2016-01-20 15:27:16]

Description was changed from

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
==========

[bokan, 2016-01-20 15:27:25]

Description was changed from

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.
Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
==========

[jbroman, 2016-01-20 15:44:28]

lgtm with a few suggestions

I'm probably not the best reviewer for core/css/ and core/layout/ changes
(someone like esprehn might be better), but this is straightforward enough that
I won't delay you much further.

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp (right):

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp:71: :
m_width(layoutView ? layoutView->viewportSizeForViewportUnits().width() : 0)
viewportSizeForViewportUnits seems not free to do twice. Why not store a
DoubleSize internally, and then construct it as:

: m_size(layoutView ? layoutView->viewportSizeForViewportUnits() : 0)

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp
(right):

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp:205: float
width = view ? view->viewportSizeForViewportUnits().width() : 0;
This seems to be the same logic that's in ViewportSize(const LayoutView*). Why
not just change the constructor call below to:

CSSToLengthConversionData::ViewportSize viewportSize(m_document->layoutView())

If you do, you probably also won't need the new include.

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutView.cpp (left):

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutView.cpp:967: float scale =
m_frameView ? m_frameView->frame().pageZoomFactor() : 1;
Do you know why this null check was here before? Is it possible for frameView()
to be null?

[bokan, 2016-01-20 16:41:10]

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp (right):

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp:71: :
m_width(layoutView ? layoutView->viewportSizeForViewportUnits().width() : 0)
On 2016/01/20 15:44:28, jbroman wrote:
> viewportSizeForViewportUnits seems not free to do twice. Why not store a
> DoubleSize internally, and then construct it as:
> 
> : m_size(layoutView ? layoutView->viewportSizeForViewportUnits() : 0)

Done.

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp
(right):

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp:205: float
width = view ? view->viewportSizeForViewportUnits().width() : 0;
On 2016/01/20 15:44:28, jbroman wrote:
> This seems to be the same logic that's in ViewportSize(const LayoutView*). Why
> not just change the constructor call below to:
> 
> CSSToLengthConversionData::ViewportSize viewportSize(m_document->layoutView())
> 
> If you do, you probably also won't need the new include.

Done.

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutView.cpp (left):

https://codereview.chromium.org/1573283002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutView.cpp:967: float scale =
m_frameView ? m_frameView->frame().pageZoomFactor() : 1;
On 2016/01/20 15:44:28, jbroman wrote:
> Do you know why this null check was here before? Is it possible for
frameView()
> to be null?

I removed it since lots of surrounding code wasn't checking and assumed it is
set. Looking through how m_frameView is initialized, it looks like in the common
case it should be non-null but I now see some XSLT path that may not have a
frame? Anyway, I put the check back in, just in case.

[bokan, 2016-01-20 16:43:43]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-01-20 16:43:44]

The patchset sent to the CQ was uploaded after l-g-t-m from aelias@chromium.org,
jbroman@chromium.org
Link to the patchset: https://codereview.chromium.org/1573283002/#ps220001
(title: "jbroman@ review")

[commit-bot: I haz the power, 2016-01-20 16:44:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1573283002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1573283002/220001

[jbroman, 2016-01-20 16:50:25]

https://codereview.chromium.org/1573283002/diff/220001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp (right):

https://codereview.chromium.org/1573283002/diff/220001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp:71: : m_size(
DoubleSize can be constructed from the FloatSize, avoiding the redundant call to
viewportSizeForViewportUnits.

m_size(layoutView ? layoutView->viewportSizeForViewportUnits() : DoubleSize())

[bokan, 2016-01-20 16:51:21]

https://codereview.chromium.org/1573283002/diff/220001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp (right):

https://codereview.chromium.org/1573283002/diff/220001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp:71: : m_size(
On 2016/01/20 16:50:25, jbroman wrote:
> DoubleSize can be constructed from the FloatSize, avoiding the redundant call
to
> viewportSizeForViewportUnits.
> 
> m_size(layoutView ? layoutView->viewportSizeForViewportUnits() : DoubleSize())

Ack, you're right. I'll up a new patch.

[bokan, 2016-01-20 16:51:26]

The CQ bit was unchecked by bokan@chromium.org

[bokan, 2016-01-20 16:53:47]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-01-20 16:53:47]

The patchset sent to the CQ was uploaded after l-g-t-m from aelias@chromium.org,
jbroman@chromium.org
Link to the patchset: https://codereview.chromium.org/1573283002/#ps240001
(title: "Remove redundant call to viewportSizeForViewportUnits")

[commit-bot: I haz the power, 2016-01-20 16:53:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1573283002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1573283002/240001

[commit-bot: I haz the power, 2016-01-20 17:56:47]

Description was changed from

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
==========

[commit-bot: I haz the power, 2016-01-20 17:56:48]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-01-20 17:57:47]

Description was changed from

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132
==========

to

==========
Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132

Committed: https://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40
Cr-Commit-Position: refs/heads/master@{#370425}
==========

[commit-bot: I haz the power, 2016-01-20 17:57:47]

Patchset 13 (id:??) landed as
https://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40
Cr-Commit-Position: refs/heads/master@{#370425}

[sgurun-gerrit only, 2016-01-20 20:59:05]

A revert of this CL (patchset #13 id:240001) has been created in
https://codereview.chromium.org/1611693002/ by sgurun@chromium.org.

The reason for reverting is: speculative reverts for
https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%2...

see crbug/579666


.