Experimental viewport meta tag support for desktop

chrome/browser/chromeos/login/chrome_restart_request.cc

Index: chrome/browser/chromeos/login/chrome_restart_request.cc
diff --git a/chrome/browser/chromeos/login/chrome_restart_request.cc b/chrome/browser/chromeos/login/chrome_restart_request.cc
index e921b954097d5e3646702562bf119820fada249d..7fcdaef31ddbb7f4a8701881c53ee1ba328b89cb 100644
--- a/chrome/browser/chromeos/login/chrome_restart_request.cc
+++ b/chrome/browser/chromeos/login/chrome_restart_request.cc
@@ -106,6 +106,8 @@ std::string DeriveCommandLine(const GURL& start_url,
       ::switches::kEnableTouchEditing,
       ::switches::kEnableUniversalAcceleratedOverflowScroll,
       ::switches::kEnableViewport,
+      ::switches::kEnableViewportMeta,
+      ::switches::kScaleViewportOnResize,

[kenneth.r.christiansen, 2013/10/25 06:27:01]

It cannot always scale and will overflow. Not sure if we can find a better
wording.

Why can't this be used on desktop? I mean is it a problem when you make the view
bigger or smaller?

I think what you really want here is whether to apply the aspect-ratio scale
difference (if not restricted) between orientation changes. 

That is only related to some specific kind of resize.

kApplyViewportAspectRatioScaleDifference ?

[bokan, 2013/10/25 17:19:33]

On desktop, if viewport is enabled and we have this flag (it's currently
implicitly on), shrinking the window will resize the page so that we don't get
horizontal overflow since the page thinks we're changing orientation. This
happens even on pages without a viewport tag.

You're correct in that we're really after is to distinguish between these two
kinds of resizes. Alex suggested MainFrameResizesAreOrientationChanges. I think
it's more clear. 

       ::switches::kForceDeviceScaleFactor,
       ::switches::kGpuStartupDialog,
       ::switches::kGpuSandboxAllowSysVShm,