Issue metadata
Sign in to add a comment
|
gapi.auth2.init stop DeviceMode form working when refresh
Reported by
farhio...@gmail.com,
Apr 27 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Steps to reproduce the problem: 1. open https://oauth.googleusercontent.com/robots.txt 2. open devtools 3. switch Device Mode On ( command + shift + M) 4. choose a desktop resolution (1200x800) - if not exist in dropdown - create one 5. paste this code (from the github issue https://github.com/google/google-api-javascript-client/issues/392#issuecomment-366363420) CODE ========== const client_id = '359269480423-chvhi5jr4a5379f4id4cta0sd1gueqg2.apps.googleusercontent.com'; await new Promise(api_ready => document.head.append(Object.assign( document.createElement('script'), { src: 'https://apis.google.com/js/api.js', onload: api_ready, }))); await new Promise(auth2_ready => gapi.load('auth2', auth2_ready)); const googleAuth = await new Promise(init_done => gapi.auth2.init({ client_id: client_id, scope: 'openid', }).then(googleAuthWithThen => init_done(Object.assign(googleAuthWithThen, { then: undefined, })))); console.log('googleAuth =', googleAuth); ========= END Of CODE 6. press enter key to execute the code What is the expected behavior? the emulated device mode still shows the same resolution. my inspection shows that gapi.auth2.init use "document.head.insertBefore" to inject scripts - which in turn, causes the issue. What went wrong? the emulate device mode is disregarded and chrome treats the emulated screen area as a small screen without the emulated resolution . google-content-example demonstrates the above issue. echoes-player-example demonstrates the same issue with my open source project - http://echoesplayer.com (no need to execute any code) - open devtools, pick a resolution and refresh the app to see the bug. Did this work before? Yes 63 Chrome version: 66.0.3359.117 Channel: stable OS Version: OS X 10.13.4 Flash Version: toggling the device mode on/off resets to the expected behavior.
,
Apr 30 2018
Thanks for filing the issue! Tried checking the issue on reported chrome version 66.0.3359.117 and on M60(60.0.3112.0) using Mac 10.13.1 with the below mentioned steps. 1. Launched chrome 2. Navigated to https://oauth.googleusercontent.com/robots.txt 3. Inspected the page. 4. Switched Dev mode on by hitting command + shift + M. 5. Made sure the resolution is 1200*800 6. Copied/pasted the code given in command#0 in console. We observed similar behaviour i.e., the resolution didn't change in reported chrome version and on above mentioned M60 build. Attaching the screen cast from M60 for reference. @Reporter: Could you please have a look at the screen cast and give us a confirmation if the issue is there in M60 too. Please let us know if we have missed anything in the process. Any further inputs from your end may be helpful.
,
Apr 30 2018
hi. The screencast you attached doesn't show the problem. the bug is reproduced with version 66.0.3359.117 or greater. i was able to reproduce it with all extensions disabled as well as with other chrome profiles. if you record another screencase, please use these steps as it will be much clearer: 1. open http://echoesplayer.com 2. open devtools 3. switch Device Mode On ( command + shift + M) 4. choose a desktop resolution (1200x800) - if not exist in dropdown - create one 5. refresh the page expected behavior: the app should render with 1200x800 resolution actual behavior: the app renders as if it is loading in small screen device
,
Apr 30 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 2 2018
Unable to reproduce the issue on chrome version 66.0.3359.139(...as per line-3, comment#3) and on the latest canary 68.0.3415.0 using Mac 10.13.1 with the below mentioned steps. 1. Launched chrome 2. navigated to http://echoesplayer.com 3. Inspected the page. 4. switched to Device Mode 5. the screen resolution was (1200x800). 6. Refreshed the page. Even after refreshing the page we observed the screen resolution was (1200x800). We didn't observe any small screen device loading. Attaching the screen casts of both M66 and M68 for reference. @Reporter: Could you please have a look at the screen cast and let us know if anything missed from our end. A screen cast explaining the issue would help us understanding it in a better way. Thanks!
,
May 2 2018
hi. the bug is clearly shown in 837652-M66 (1).mp4 notice how the resolution is applied correctly in time 0:29 BUT after refreshing the page the resolution is applied correctly at 0:36 In the canary version this bug seems to be fixed.
,
May 2 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 3 2018
As per comment#6 checked video given in comment#5 and didn't find any difference 0:29 and 0:36. @Reporter: Please provide us a screencast from your end and please mark where the issue is seen. In above screenshot both the resolution are 1200x800 on both cases. Please help in triaging this issue further. Thanks!
,
May 3 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 3 2018
I attached a screencase. you can clearly see that after i refresh the page, while the devtools is opened and with device mode on, the 1280x800 resolution is not applied. toggling off and on the device mode fixes the issue (also demoed in this screencast).
,
May 4 2018
As per comment#9 and #11 checked the issue and able to reproduce this issue on reported version 66.0.3359.117, and latest stable 66.0.3359.139 using Windows 10, Mac 10.12.6 and Ubuntu 17.10. But issue is not reproducible on latest beta 67.0.3396.30 and latest canary 68.0.3419.0. Hence providing reverse bisect info. Last Bad Build: 67.0.3395.0 First Good Build: 67.0.3396.0 You are probably looking for a change made after 550236 (known good), but no later than 550237 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/269e6c87f284d12c2084f3185c980f0a0c0f8dab..4651e64a69eb454a9253963012cc10c50d0f10ae Probably fixed by https://chromium-review.googlesource.com/1003324. @dgozman: Please merge this to M-66 if required. Adding RB-Stable for M-66. Please remove if not the case. Thanks!
,
May 7 2018
This is due to google oauth going out of process interoperating badly with Device Mode. Unfortunately, the fix was not merged to 66 due to complexity. Could you please check this in Chrome Canary, until next version (67) comes out?
,
May 7 2018
,
Jun 3 2018
i just confirmed this bug has been fixed with v67 (chrome). thanks. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Apr 30 2018