Issue metadata
Sign in to add a comment
|
window.screenTop reports wrong value after coming back from full-screen mode |
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: This is happening only on Mac for me: 1. Go into the JavaScript console on a page. Print the value of window.screenTop. It is typically nonzero. 2. Go into full-screen mode (Ctrl+Apple+F). 3. Print the value of window.screenTop again. It should be zero. 4. Leave full-screen mode. 5. Print the value of window.screenTop. It is still zero! 6. Switch to a different tab and go back to the original tab. Print the value of window.screenTop. It is now nonzero. What is the expected behavior? I'd expect the value of window.screenTop to be updated to a nonzero value after leaving full-screen mode (i.e. in step 5). What went wrong? The value of window.screenTop is update too late (only in step 6). Did this work before? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version:
,
Jan 20 2017
Able to reproduce the issue on mac 10.12.2 chrome version 55.0.2883.95 and beta 56.0.2924.67 but working fine on 57.0.2986.0 - coming back from full screen mode window.screenTop still shows zero Seems the issue got fixed in latest builds yori@, Could you please recheck in latest builds and update the thread. Working on
,
Jan 20 2017
,
Jan 23 2017
last bad build: 56.0.2924.73 first good build: 57.0.2925.0 Bisect Tool invoking all good builds not invoking bad build. Hence providing the manual CL CL : https://chromium.googlesource.com/chromium/src/+log/56.0.2924.0..57.0.2925.0?pretty=fuller&n=10000 Unable to find the suspect from the manual CL yori@, Could you please recheck in latest builds and update the thread.
,
Jan 24 2017
I've just checked on Chrome Canary 58.0.2991.0 and the problem is *not* fixed.
,
Jan 24 2017
Please ignore my above comments with a clean profile this is reproducible in canary as well. Issue is repro on M50 50.0.2661.37 but working fine on 40.0.2172.0 Hence this is a regression adding Needs-Bisect label
,
Jan 25 2017
Able to reproduce the issue on Mac 10.12.2 using chrome reported version #55.0.2883.95, latest dev #57.0.2987.8 and latest canary #58.0.2991.0. Issue is specific to mac OS only. Bisect Information: ===================== Good build: 49.0.2586.0 Revision(363935) Bad Build : 49.0.2588.0 Revision(364574) Note: The actual bad build was 49.0.2587.0, after running bisect script, got all the good builds. Hence, increased the bad build to 49.0.2588.0. Change Log URL: https://chromium.googlesource.com/chromium/src/+log/01749fbb1216c45883397ef4f8ae3b8e90500a24..f6bce52dc0ec0f84660aa4e62906b63366e33805 From the above change log suspecting below change Review url: https://codereview.chromium.org/1495623008 spqchan@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Jan 26 2017
,
Apr 8 2017
,
Aug 27
I cannot reproduce this on Mac Chrome 68. Is this still an issue?
,
Aug 27
,
Aug 28
Thanks; it seems fixed now. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dstockwell@chromium.org
, Jan 20 2017