Unable to reproduce this issue on reported version 65.0.3325.181 using Mac 10.13.3. Attaching screencast for reference. Observing screen width changes according to emulated device

@Reporter: Please check the screencast and let us know if we miss anything. Also please check the issue on fresh profile which do not have any apps or extensions.

Thanks!

Deleted: 826651.mp4 2.3 MB

	826651.mp4 2.3 MB View Download

Noticed that in the screencast, the page wasn't refreshed after a device was chosen to be emulated. Changing the emulated device after the page is loaded will correctly update `screen.width`.

In other words, the issue is that `screen.width` does not reflect the emulated device after the initial page load.

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

Able to reproduce this issue on reported version 65.0.3325.181, on latest beta 66.0.3359.66 and on latest canary 67.0.3383.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04

Good Build: 65.0.3295.0
Bad Build: 65.0.3296.0

You are probably looking for a change made after 524528 (known good), but no later than 524529 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/24abf78274e01a17c4f0a4c8cc18e55720f3b3b9..3b60933b099bba43823b2c5cbdbe7c3f2e90ae68

Reviewed-on: https://chromium-review.googlesource.com/831147

Suspecting same from changelog.

@ alexmos: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-65. Please remove if not the case.

Thanks!

M65 has been out since 03/06 and we're not planning any futher M65 releases. Please target fix for M66 which is going to stable in few weeks. Pls do let me know if there is any concern here.

Looks like this is a generic problem when there are any OOPIFs on the inspected page, rather than something that regressed with sign-in isolation, which was turned on by default by the CL referenced in #6 and causes the repro page to have an OOPIF for accounts.google.com.

I can repro this on Linux ToT by starting with --site-per-process, then going to http://csreis.github.io/tests/cross-site-iframe-simple.html, opening devtools, turning on mobile device emulation, then reloading the page and checking screen.width.

Additionally, the refresh makes the OOPIF in the emulated window incorrectly scaled - the font is too large and the frame doesn't fit into the page anymore, whereas all this was fine when you select a device to emulate before refresh.

Dmitry, can you please triage from the DevTools side?

Interesting.  The workaround is to exit mobile emulation mode and then enable it again.

Some additional observations:
1) The problem will also happen if you enter mobile emulation mode and send a same-process frame to a different process.  For example, visit http://csreis.github.io/tests/cross-site-iframe.html, turn on mobile device emulation, then tap the first "Go cross-site (simple page)" button.  The screen.width will jump up to the wrong size again.

2) If a frame goes cross-process to same-process while in mobile emulation mode (e.g., by tapping on the last "Go same-site" button on the page above), the renderer crashes!  Same crash report ID is 74b5dd1430ce76a1 (blink::WindowProxy::SetGlobalProxy).

Agreed that it's too late for M65.  It might be ok to target M67 for the fix, but it does seem worth having fixed.  (If it's easy to merge to M66, that's ideal.)  Tentatively marking as launch blocker until we know more.

For reference, here's the initialization_stack_ for Charlie's SetGlobalProxy crash in #9.  Seems similar to the origin trials issue we fixed in  issue 764519 .

#1 0x00007ff989e05e8f blink::WindowProxy::InitializeIfNeeded(void), Line 156
#2 0x00007ff989e05e39 blink::Frame::GetWindowProxy(blink::DOMWrapperWorld & world), Line 163
#3 0x00007ff989e05d80 blink::ToScriptState(blink::LocalFrame * frame, blink::DOMWrapperWorld & world), Line 756
#4 0x00007ff98c207c35 blink::OriginTrialContext::InitializePendingFeatures(void), Line 198
#5 0x00007ff98c207eb6 blink::OriginTrialContext::AddFeature(const WTF::String & feature), Line 214
#6 0x00007ff989c9c9b4 blink::DocumentLoader::InstallNewDocument(const blink::KURL & url, blink::Document * owner_document, blink::WebGlobalObjectReusePolicy global_object_reuse_policy, const WTF::AtomicString & mime_type, const WTF::AtomicString & encoding, blink::DocumentLoader::InstallNewDocumentReason reason, blink::ParserSynchronizationPolicy parsing_policy, const blink::KURL & overriding_url), Line 1099
#7 0x00007ff989c9a377 blink::DocumentLoader::CommitNavigation(const WTF::AtomicString & mime_type, const blink::KURL & overriding_url), Line 709
#8 0x00007ff989c9a150 blink::DocumentLoader::CommitData(const char * bytes, unsigned __int64 length), Line 718
#9 0x00007ff989c99c95 blink::DocumentLoader::FinishedLoading(base::TimeTicks finish_time), Line 470
#10 0x00007ff989c98bc9 blink::DocumentLoader::MaybeLoadEmpty(void), Line 864
#11 0x00007ff989c986d2 blink::DocumentLoader::StartLoading(void), Line 874
#12 0x00007ff989c92973 blink::FrameLoader::Init(void), Line 289
#13 0x00007ff989c8b1cb blink::WebLocalFrameImpl::InitializeCoreFrame(blink::Page & page, blink::FrameOwner * owner, const WTF::AtomicString & name), Line 1802
#14 0x00007ff989c8a976 blink::WebLocalFrameImpl::CreateProvisional(blink::WebFrameClient * client, blink::InterfaceRegistry * interface_registry, blink::WebRemoteFrame * old_web_frame, blink::WebSandboxFlags flags, std::vector<blink::ParsedFeaturePolicyDeclaration,std::allocator<blink::ParsedFeaturePolicyDeclaration> > container_policy), Line 1712
#15 0x00007ff989c8a7ea blink::WebLocalFrame::CreateProvisional(blink::WebFrameClient * client, blink::InterfaceRegistry * interface_registry, blink::WebRemoteFrame * old_web_frame, blink::WebSandboxFlags flags, std::vector<blink::ParsedFeaturePolicyDeclaration,std::allocator<blink::ParsedFeaturePolicyDeclaration> > container_policy), Line 1651
#16 0x00007ff989c8864f content::RenderFrameImpl::CreateFrame(int routing_id, mojo::InterfacePtr<service_manager::mojom::InterfaceProvider> interface_provider, int proxy_routing_id, int opener_routing_id, int parent_routing_id, int previous_sibling_routing_id, const base::UnguessableToken & devtools_frame_token, const content::FrameReplicationState & replicated_state, content::CompositorDependencies * compositor_deps, const content::mojom::CreateFrameWidgetParams & widget_params, const content::FrameOwnerProperties & frame_owner_properties, bool has_committed_real_load), Line 1188
#17 0x00007ff989c884cf content::RenderThreadImpl::CreateFrame(mojo::StructPtr<content::mojom::CreateFrameParams> params), Line 2314
#18 0x00007ff989c121ca content::mojom::RendererStubDispatch::Accept(content::mojom::Renderer * impl, mojo::Message * message), Line 817
#19 0x00007ff98b308ec7 IPC::`anonymous namespace'::ChannelAssociatedGroupController::AcceptOnProxyThread(mojo::Message message), Line 847
#20 0x00007ff98b307256 base::internal::Invoker<base::internal::BindState<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message),scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>,base::internal::PassedWrapper<mojo::Message> >,void ()>::Run(base::internal::BindStateBase * base), Line 586
#21 0x00007ff989b97e6f base::debug::TaskAnnotator::RunTask(const char * queue_function, base::PendingTask * pending_task), Line 61

The fix ought to be to simply ALSO plumb the emulated ScreenInfo down to OOPIFs along with the original ScreenInfo and then plumb things through the child RenderWidget.

https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?q=RenderWidget::Update&sq=package:chromium&l=1924

https://cs.chromium.org/chromium/src/content/renderer/render_frame_proxy.cc?q=RenderFrameProxy::wasResiz&sq=package:chromium&l=613

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

Friendly ping to get an update on this issue as it is marked as stable blocker & M66 Stable cut is on April 12th.

Thanks..! 

dgozman@: Will you be able to help with this?  Fady left a suggestion in comment 13, so I'm curious if that approach works.

We'd like to get a fix into M66 if possible, since there will be a Site Isolation stable experiment there.  Thanks!

I am looking into this right now, but things are not clear yet.

Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4651e64a69eb454a9253963012cc10c50d0f10ae

commit 4651e64a69eb454a9253963012cc10c50d0f10ae
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Thu Apr 12 16:39:26 2018

[DevTools] Fix emulation problems with OOPIFs

- Do not mistakenly disable emulation in wrong RWHI.
  When cross-process iframe goes away, we cleanup and disable
  emulation, which did mistakenyl go to parent's RWHI.

- Include emulation agent for OOPIFs to support touch emulation.
  Otherwise Emulation.setTouchEmulatioEnabled goes nowhere.

- Prevent crash in swapping in due to early context initialization.
  With touch emulation enabled, we initialize origin trials on
  document load, which may be an initial empty load. This can trigger
  window proxy initialization and check when swapping in later.

Bug:  826651 
Change-Id: I33a9de9383810cebab449cb2d02c14c54f5980a3
Reviewed-on: https://chromium-review.googlesource.com/1003324
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550237}
[modify] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/content/browser/devtools/protocol/emulation_handler.cc
[add] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/emulation/emulation-oopifs-expected.txt
[add] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/emulation/emulation-oopifs.js
[modify] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/blink/renderer/core/exported/web_dev_tools_agent_impl.cc
[modify] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/blink/renderer/core/loader/document_loader.cc

Thanks dgozman@!  Is this one fixed after r550237?

Let's target this for M67. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4651e64a69eb454a9253963012cc10c50d0f10ae

commit 4651e64a69eb454a9253963012cc10c50d0f10ae
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Thu Apr 12 16:39:26 2018

[DevTools] Fix emulation problems with OOPIFs

- Do not mistakenly disable emulation in wrong RWHI.
  When cross-process iframe goes away, we cleanup and disable
  emulation, which did mistakenyl go to parent's RWHI.

- Include emulation agent for OOPIFs to support touch emulation.
  Otherwise Emulation.setTouchEmulatioEnabled goes nowhere.

- Prevent crash in swapping in due to early context initialization.
  With touch emulation enabled, we initialize origin trials on
  document load, which may be an initial empty load. This can trigger
  window proxy initialization and check when swapping in later.

Bug:  826651 
Change-Id: I33a9de9383810cebab449cb2d02c14c54f5980a3
Reviewed-on: https://chromium-review.googlesource.com/1003324
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550237}
[modify] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/content/browser/devtools/protocol/emulation_handler.cc
[add] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/emulation/emulation-oopifs-expected.txt
[add] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/emulation/emulation-oopifs.js
[modify] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/blink/renderer/core/exported/web_dev_tools_agent_impl.cc
[modify] https://crrev.com/4651e64a69eb454a9253963012cc10c50d0f10ae/third_party/blink/renderer/core/loader/document_loader.cc

dgozman@: Friendly ping.  Is this bug fixed now (as of r550237 in 67.0.3396.0)?

Issue 834328 has been merged into this issue.

 Issue 837652  has been merged into this issue.