Changing URL bar constraints only calls performResize on Hidden <-> Both

Changing URL bar constraints only calls performResize on Hidden <-> Both

With the change to the URL bar not causing a vertical resize on showing/hiding,
we keep the layout height sized "as if" the URL bar was always shown. However,
for fullscreen scenarios, since the URL bar is locked to a hidden state there's
no need to keep it static to the smaller size so we use the full viewport
height instead.

This means that when we change the URL bar constraints we may need to change
the layout height. In most cases, we can rely on a Resize event being sent to
the renderer kicking off the layout size change. The one exception here is from
a "Locked Hidden" to "Unlocked" state, or vice-versa. That's because the URL
bar's state might not change (it can remain hidden) but the layout size should
change.

Note that going from "Locked Hidden" -> "Shown" doesn't have this problem as
the URL bar state will change necessarily. Going from "Unlocked" -> "Shown" may
or may not change the URL bar state, but it will not change the layout height
since we use the "Shown" height for layout height when the URL bar is
"Unlocked".

Before this patch, we were overly-aggressive in triggering performResize which
caused us to perform extra work as the page went from "Locked Shown" to
"Unlocked", as happens when the page is navigated. This caused a minor memory
regression.  This patch performs the resize only when needed, on going from
"Locked Hidden" to "Unlocked" or vice-versa.

BUG=679546
Review-Url: https://codereview.chromium.org/2656633003
Cr-Commit-Position: refs/heads/master@{#445855}
Committed: https://chromium.googlesource.com/chromium/src/+/38992dee686ca58d5f1a61d44ef3e534b8c2967c

[bokan, 2017-01-24 20:01:37]

Description was changed from

==========
Changing URL bar constraints only calls performResize on Hidden <-> Both

With the change to the URL bar not causing a vertical resize on showing/hiding,
we keep the layout height sized "as if" the URL bar was always shown. However,
for fullscreen scenarios, since the URL bar is locked to a hidden state there's
  no need to keep it static to the smaller size so we use the full viewport
  height instead.

This means that when we change the URL bar constraints we may need to change
the layout height. In most cases, we can rely on a Resize event being sent to
the renderer kicking off the layout size change. The one exception here is from
a "Locked Hidden" to "Unlocked" state, or vice-versa. That's because the URL
bar's state might not change (it can remain hidden) but the layout size should
change.

Note that going from "Locked Hidden" -> "Shown" doesn't have this problem as
the URL bar state will change necessarily. Going from "Unlocked" -> "Shown" may
or may not change the URL bar state, but it will not change the layout height
since we use the "Shown" height for layout height when the URL bar is
"Unlocked".

Before this patch, we were overly-aggressive in triggering performResize which
caused us to perform extra work as the page went from "Locked Shown" to
"Unlocked", as happens when the page is navigated. This caused a minor memory
regression.  This patch performs the resize only when needed, on going from
"Locked Hidden" to "Unlocked" or vice-versa.

BUG=679546
==========

to

==========
Changing URL bar constraints only calls performResize on Hidden <-> Both

With the change to the URL bar not causing a vertical resize on showing/hiding,
we keep the layout height sized "as if" the URL bar was always shown. However,
for fullscreen scenarios, since the URL bar is locked to a hidden state there's
no need to keep it static to the smaller size so we use the full viewport
height instead.

This means that when we change the URL bar constraints we may need to change
the layout height. In most cases, we can rely on a Resize event being sent to
the renderer kicking off the layout size change. The one exception here is from
a "Locked Hidden" to "Unlocked" state, or vice-versa. That's because the URL
bar's state might not change (it can remain hidden) but the layout size should
change.

Note that going from "Locked Hidden" -> "Shown" doesn't have this problem as
the URL bar state will change necessarily. Going from "Unlocked" -> "Shown" may
or may not change the URL bar state, but it will not change the layout height
since we use the "Shown" height for layout height when the URL bar is
"Unlocked".

Before this patch, we were overly-aggressive in triggering performResize which
caused us to perform extra work as the page went from "Locked Shown" to
"Unlocked", as happens when the page is navigated. This caused a minor memory
regression.  This patch performs the resize only when needed, on going from
"Locked Hidden" to "Unlocked" or vice-versa.

BUG=679546
==========

[bokan, 2017-01-24 20:01:52]

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

[commit-bot: I haz the power, 2017-01-24 20:03:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-24 20:29:59]

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

[commit-bot: I haz the power, 2017-01-24 20:30:00]

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

[bokan, 2017-01-24 20:53:03]

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

[commit-bot: I haz the power, 2017-01-24 20:53:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-24 21:16:49]

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

[commit-bot: I haz the power, 2017-01-24 21:16:51]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[bokan, 2017-01-24 21:56:42]

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

[commit-bot: I haz the power, 2017-01-24 21:57:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-24 23:06:19]

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

[commit-bot: I haz the power, 2017-01-24 23:06:20]

Dry run: This issue passed the CQ dry run.

[bokan, 2017-01-24 23:06:47]

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

[aelias_OOO_until_Jul13, 2017-01-24 23:18:02]

lgtm

[bokan, 2017-01-24 23:18:25]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2017-01-24 23:19:22]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-24 23:26:30]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1485299905963840, "parent_rev":
"520f95147c821e13003362194a5de003a9f5c8f9", "commit_rev":
"38992dee686ca58d5f1a61d44ef3e534b8c2967c"}

[commit-bot: I haz the power, 2017-01-24 23:27:08]

Description was changed from

==========
Changing URL bar constraints only calls performResize on Hidden <-> Both

With the change to the URL bar not causing a vertical resize on showing/hiding,
we keep the layout height sized "as if" the URL bar was always shown. However,
for fullscreen scenarios, since the URL bar is locked to a hidden state there's
no need to keep it static to the smaller size so we use the full viewport
height instead.

This means that when we change the URL bar constraints we may need to change
the layout height. In most cases, we can rely on a Resize event being sent to
the renderer kicking off the layout size change. The one exception here is from
a "Locked Hidden" to "Unlocked" state, or vice-versa. That's because the URL
bar's state might not change (it can remain hidden) but the layout size should
change.

Note that going from "Locked Hidden" -> "Shown" doesn't have this problem as
the URL bar state will change necessarily. Going from "Unlocked" -> "Shown" may
or may not change the URL bar state, but it will not change the layout height
since we use the "Shown" height for layout height when the URL bar is
"Unlocked".

Before this patch, we were overly-aggressive in triggering performResize which
caused us to perform extra work as the page went from "Locked Shown" to
"Unlocked", as happens when the page is navigated. This caused a minor memory
regression.  This patch performs the resize only when needed, on going from
"Locked Hidden" to "Unlocked" or vice-versa.

BUG=679546
==========

to

==========
Changing URL bar constraints only calls performResize on Hidden <-> Both

With the change to the URL bar not causing a vertical resize on showing/hiding,
we keep the layout height sized "as if" the URL bar was always shown. However,
for fullscreen scenarios, since the URL bar is locked to a hidden state there's
no need to keep it static to the smaller size so we use the full viewport
height instead.

This means that when we change the URL bar constraints we may need to change
the layout height. In most cases, we can rely on a Resize event being sent to
the renderer kicking off the layout size change. The one exception here is from
a "Locked Hidden" to "Unlocked" state, or vice-versa. That's because the URL
bar's state might not change (it can remain hidden) but the layout size should
change.

Note that going from "Locked Hidden" -> "Shown" doesn't have this problem as
the URL bar state will change necessarily. Going from "Unlocked" -> "Shown" may
or may not change the URL bar state, but it will not change the layout height
since we use the "Shown" height for layout height when the URL bar is
"Unlocked".

Before this patch, we were overly-aggressive in triggering performResize which
caused us to perform extra work as the page went from "Locked Shown" to
"Unlocked", as happens when the page is navigated. This caused a minor memory
regression.  This patch performs the resize only when needed, on going from
"Locked Hidden" to "Unlocked" or vice-versa.

BUG=679546

Review-Url: https://codereview.chromium.org/2656633003
Cr-Commit-Position: refs/heads/master@{#445855}
Committed:
https://chromium.googlesource.com/chromium/src/+/38992dee686ca58d5f1a61d44ef3...
==========

[commit-bot: I haz the power, 2017-01-24 23:27:09]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/38992dee686ca58d5f1a61d44ef3...

[bokan, 2017-01-26 15:55:31]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/2659483003/ by bokan@chromium.org.

The reason for reverting is: Didn't help on the perf bots. Temporarily reverting
along with orignial patch to investigate..