Web page doesn't use full height when installed to homescreen |
||||||
Issue descriptionChrome Version: 57.0.2970.0 OS: Android What steps will reproduce the problem? (1) Go to http://webmsx.org (2) From the Chrome menu, click "Add to Homescreen" (3) Launch the newly added WebMSX homescreen icon What is the expected result? The bottom "toolbar" of the page should be flush against the Android "home button bar" What happens instead? There's 22px of gap It's a bit hard to tell because the app background is black like the Android bar but inspecting from chrome://inspect shows the issue more clearly.
,
Jan 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/18940be9f2a3912efbdbed71863a7749ed243e9a commit 18940be9f2a3912efbdbed71863a7749ed243e9a Author: bokan <bokan@chromium.org> Date: Fri Jan 06 18:53:20 2017 Use full viewport height for layout if URL bar is locked shown or hidden. With inert-top-controls turned on by default, we don't change the layout height when the top controls are normally hidden. That is, if a user hides the URL bar by scrolling, the page won't resize to use the newly available space. It'll lay out as though the URL bar was still showing. This patch makes an exception for cases where Chrome locks the URL bar in the hidden state. e.g. Fullscreen or WebApp mode. In those cases, since the URL bar can't be shown at all, there's no reason not to use the full height. BUG= 678649 Review-Url: https://codereview.chromium.org/2614993002 Cr-Commit-Position: refs/heads/master@{#441995} [modify] https://crrev.com/18940be9f2a3912efbdbed71863a7749ed243e9a/third_party/WebKit/Source/core/frame/BrowserControls.h [modify] https://crrev.com/18940be9f2a3912efbdbed71863a7749ed243e9a/third_party/WebKit/Source/web/WebViewImpl.cpp [modify] https://crrev.com/18940be9f2a3912efbdbed71863a7749ed243e9a/third_party/WebKit/Source/web/WebViewImpl.h [modify] https://crrev.com/18940be9f2a3912efbdbed71863a7749ed243e9a/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp
,
Jan 6 2017
This should be fixed in ToT now. I'll request a merge to M56 when I can confirm it in a Canary.
,
Jan 10 2017
Fix confirmed in Canary, requesting merge.
,
Jan 10 2017
Your change meets the bar and is auto-approved for M56. Please go ahead and merge the CL manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6db97b43abbc7b0fcbeae646f219836342eb9545 commit 6db97b43abbc7b0fcbeae646f219836342eb9545 Author: David Bokan <bokan@chromium.org> Date: Tue Jan 10 20:19:22 2017 Use full viewport height for layout if URL bar is locked shown or hidden. With inert-top-controls turned on by default, we don't change the layout height when the top controls are normally hidden. That is, if a user hides the URL bar by scrolling, the page won't resize to use the newly available space. It'll lay out as though the URL bar was still showing. This patch makes an exception for cases where Chrome locks the URL bar in the hidden state. e.g. Fullscreen or WebApp mode. In those cases, since the URL bar can't be shown at all, there's no reason not to use the full height. BUG= 678649 Review-Url: https://codereview.chromium.org/2614993002 Cr-Commit-Position: refs/heads/master@{#441995} (cherry picked from commit 18940be9f2a3912efbdbed71863a7749ed243e9a) Review-Url: https://codereview.chromium.org/2623933002 . Cr-Commit-Position: refs/branch-heads/2924@{#720} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [modify] https://crrev.com/6db97b43abbc7b0fcbeae646f219836342eb9545/third_party/WebKit/Source/core/frame/BrowserControls.h [modify] https://crrev.com/6db97b43abbc7b0fcbeae646f219836342eb9545/third_party/WebKit/Source/web/WebViewImpl.cpp [modify] https://crrev.com/6db97b43abbc7b0fcbeae646f219836342eb9545/third_party/WebKit/Source/web/WebViewImpl.h [modify] https://crrev.com/6db97b43abbc7b0fcbeae646f219836342eb9545/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp
,
Jan 10 2017
,
Jan 11 2017
Works fine as per expected behavior ,Verified in Latest M56 on Nexus 5x / N.
,
Jan 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe commit 01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe Author: bokan <bokan@chromium.org> Date: Fri Jan 27 17:01:54 2017 Revert of Use full viewport height for layout if URL bar is locked shown or hidden. (patchset #2 id:20001 of https://codereview.chromium.org/2614993002/ ) Reason for revert: Temporarily reverting to see if it fixes the memory regression in the linked bug. BUG= 679546 Original issue's description: > Use full viewport height for layout if URL bar is locked shown or hidden. > > With inert-top-controls turned on by default, we don't change the layout height > when the top controls are normally hidden. That is, if a user hides the URL bar > by scrolling, the page won't resize to use the newly available space. It'll lay > out as though the URL bar was still showing. > > This patch makes an exception for cases where Chrome locks the URL bar in the > hidden state. e.g. Fullscreen or WebApp mode. In those cases, since the URL bar > can't be shown at all, there's no reason not to use the full height. > > BUG= 678649 > > Review-Url: https://codereview.chromium.org/2614993002 > Cr-Commit-Position: refs/heads/master@{#441995} > Committed: https://chromium.googlesource.com/chromium/src/+/18940be9f2a3912efbdbed71863a7749ed243e9a TBR=aelias@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 678649 Review-Url: https://codereview.chromium.org/2657773005 Cr-Commit-Position: refs/heads/master@{#446693} [modify] https://crrev.com/01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe/third_party/WebKit/Source/core/frame/BrowserControls.h [modify] https://crrev.com/01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe/third_party/WebKit/Source/web/WebViewImpl.cpp [modify] https://crrev.com/01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe/third_party/WebKit/Source/web/WebViewImpl.h [modify] https://crrev.com/01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp
,
Jan 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9427bfd430073a9caa0770ab6653b040520a8aab commit 9427bfd430073a9caa0770ab6653b040520a8aab Author: bokan <bokan@chromium.org> Date: Tue Jan 31 01:37:01 2017 Reland of Use full viewport height for layout if URL bar is locked shown or hidden. (patchset #1 id:1 of https://codereview.chromium.org/2657773005/ ) Reason for revert: Relanding since the graph in the original bug didn't get any better, ruling out this CL. Original issue's description: > Revert of Use full viewport height for layout if URL bar is locked shown or hidden. (patchset #2 id:20001 of https://codereview.chromium.org/2614993002/ ) > > Reason for revert: > Temporarily reverting to see if it fixes the memory regression in the linked bug. > BUG= 679546 > > Original issue's description: > > Use full viewport height for layout if URL bar is locked shown or hidden. > > > > With inert-top-controls turned on by default, we don't change the layout height > > when the top controls are normally hidden. That is, if a user hides the URL bar > > by scrolling, the page won't resize to use the newly available space. It'll lay > > out as though the URL bar was still showing. > > > > This patch makes an exception for cases where Chrome locks the URL bar in the > > hidden state. e.g. Fullscreen or WebApp mode. In those cases, since the URL bar > > can't be shown at all, there's no reason not to use the full height. > > > > BUG= 678649 > > > > Review-Url: https://codereview.chromium.org/2614993002 > > Cr-Commit-Position: refs/heads/master@{#441995} > > Committed: https://chromium.googlesource.com/chromium/src/+/18940be9f2a3912efbdbed71863a7749ed243e9a > > TBR=aelias@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG= 678649 > > Review-Url: https://codereview.chromium.org/2657773005 > Cr-Commit-Position: refs/heads/master@{#446693} > Committed: https://chromium.googlesource.com/chromium/src/+/01f12135d93ddd4f3daf304f8a3b86c4cd7c6dbe TBR=aelias@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 679546 Review-Url: https://codereview.chromium.org/2663823002 Cr-Commit-Position: refs/heads/master@{#447155} [modify] https://crrev.com/9427bfd430073a9caa0770ab6653b040520a8aab/third_party/WebKit/Source/core/frame/BrowserControls.h [modify] https://crrev.com/9427bfd430073a9caa0770ab6653b040520a8aab/third_party/WebKit/Source/web/WebViewImpl.cpp [modify] https://crrev.com/9427bfd430073a9caa0770ab6653b040520a8aab/third_party/WebKit/Source/web/WebViewImpl.h [modify] https://crrev.com/9427bfd430073a9caa0770ab6653b040520a8aab/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by bokan@chromium.org
, Jan 5 2017