This may be a change in the underlying StreamVR that will no longer dynamically accept resolution changes.  However, it can accept resolution changes by relaunching a page within the same browser window.

Thanks for filing the issue!

As this issue is related to VR headset, which is not available at TE end to test and confirm the issue, hence adding TE-Hardware-Dependency label to it. Could someone from Blink>WebVR team to look into the issue and help in further triaging.

Thanks!

Bill, can you take a look? May be the same root cause as  issue 835888  .

I'll investigate.  Before digging in, I seem to recall that sites doing dynamic resolution tuning would have to call requestPresent multiple times.  In any case, I'll dig in to confirm.

There's two different scenarios. Calling requestPresent while presenting lets you update the layer bounds, this lets you use a smaller subset of the full drawing buffer to reduce rendering cost. This is equivalent to WebXR's XRWebGLLayer.requestViewportScaling(scaleFactor).

If you want greater-than-default resolution, you have to size the initial framebuffer since the layer bounds or viewport scale don't let you grow above size 1.0. For WebXR, this is a constructor arg for the XRWebGLLayer, for example:
  new XRWebGLLayer(xrSession, gl, { framebufferScaleFactor: 0.8 });

For WebVR 1.1, you get a recommended renderWidth/renderHeight in the eye parameters. The expectation is that you can use them as-is, or multiply them with a scaling factor to increase/decrease the framebuffer size.

WebVR 1.1 doesn't specifically say if it's OK to change the canvas size while presenting. The Android implementation supports it, though it's a somewhat expensive operation and may cause a visual glitch for a frame while applying the new size.

However, at least setting the initial canvas size has to work.

'I seem to recall that sites doing dynamic resolution tuning would have to call requestPresent multiple times'.

Yes, we have been having to do that.  In scale of preferences from our point of view;
1 best if we can just change resolution without stopping presentation
2 issue exitPresent and requestPresent in the same event handler
3 issue exitPresent, and then requestPresent in a later event handler (this is what we had been doing till recently)
4 restart application before changing resolution (needed with current bug)

After fixing  issue 835888 , this is closer to working.  However, the content was stretched instead of just blurry.  Continuing to investigate - there could be a bug with how we are handling size/rects.

https://immersive-web.github.io/webxr-samples/framebuffer-scaling.html also gives an easier way to debug the equivalent in WebXR.  I guess that uses your same underlying code; if not it needs to be fixed too.
1. enter VR
2. exit VR
3. change Framebuffer scale
4. enter VR

Proposed fix in https://chromium-review.googlesource.com/c/chromium/src/+/1144469

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

commit 606c29625e0ce93ba94e5d183942d6fb2865321e
Author: Klaus Weidner <klausw@chromium.org>
Date: Fri Jul 20 00:51:50 2018

Recreate WebXR render target view on texture resize

The render target view depends on the destination texture, but wasn't
being recreated on texture resize, resulting in broken rendering
after changing framebuffer scale (WebXR) or canvas size (WebVR 1.1)
for the OpenVR backend.

BUG= 835905 

Cq-Include-Trybots: luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I92bbcdc4f2ed4da1c248cf63132a2bc60a25a8c7
Reviewed-on: https://chromium-review.googlesource.com/1144469
Reviewed-by: Bill Orr <billorr@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576728}
[modify] https://crrev.com/606c29625e0ce93ba94e5d183942d6fb2865321e/device/vr/windows/d3d11_texture_helper.cc

According to omahaproxy the change landed before branch cut and is included in 69.0.3497.0, so there's no need for a cherry pick for M69.

https://storage.googleapis.com/chromium-find-releases-static/606.html#606c29625e0ce93ba94e5d183942d6fb2865321e

Thank you all