plus.google.com re-layouts horizontally when the top bar shows/hides

[James Lewis]

Some sites have a menu bar at the top, which appears or disappears depending if you scroll up or down... the presence or absence of this bar causes the browser app to change it's scaling, and this means that scrolling up/down while browsing results in the device continually re-rendering as it re-scales the page...

This badly afffects google+ and presumably other google properties...

See example here:-

https://www.youtube.com/watch?v=uYhu9v4aX6w

[Olivier Tilloy (osomon)]

I can observe the same issue on my M10.

This is crazy, google plus is changing the width of the content (thus triggering a re-layout) based on the viewport *height*, not its width.
That very much looks like a bug in google plus itself.

It would be interesting to check how the site behaves on chrome on android on a similar device (10" tablet).

[Olivier Tilloy (osomon)]

Note that the browser is not "changing its scaling", all it does is show/hide the chrome based on the touch movements. The size of the webview itself remain unchanged.

[Chris Coulson (chrisccoulson)]

There's basically nothing we can do about this in Oxide - as Olivier has pointed out, this is a website bug and is specific to the desktop version of Google Plus. Oxide correctly changes the viewport height after the location bar changes position, otherwise elements fixed to the bottom of the viewport would be off the screen when the location bar is shown.

It doesn't happen on Chrome/Android because the location bar in Chrome's tablet UI doesn't hide. That's probably the only way we'd be able to prevent this in Ubuntu.

[Chris Coulson (chrisccoulson)]

I should re-phrase "website bug" as something else ("website issue", perhaps?) because it probably isn't a bug in the traditional sense - it has a responsive UI that most likely doesn't expect the viewport size to change as a result of scrolling.

[James Lewis (james-fsck)]

Could it be that the site is sending some different HTML based on the browser string on the device?... perhaps we need to alter the user agent string depending on whether the browser is operating in "mobile" format, or desktop "tabbed" format?

[Daniel Bull (ubuntu-frozenmist)]

I can understand why google is changing the width based on the viewport height, there is some logic behind it...
They want the page to render in a way that prevents posts being vertically cropped too much (which would result in the user only being able to view a small part of the post and having to scroll back and forth to read it or missing the picture or whatever). The way they are doing this is by changing the width of the contech which scales the overall page on most mobile browsers.

It looks like the issue is when you scroll down the browser automatically hides the tab and location bar which then changes the viewport size which then triggers the page to rescale. This wont only happen on G+ this will happen on lost of sites. Sites don't expect the viewport size to change unless the browser is actually being resized.

I'm not sure what the correct solution is but I would say one potential (but perhaps not very clean solution) would be not to change the viewport size when the tab/location bar is hidden if its a website which requires a vertical scroll bar. Essentially pretend the viewport stays a constant size even though in reality it has got larger. Like I said this is not an ideal solution but chances are if you are on a website with a vertical scroll bar the exact height shouldn't be hugely relevant anyway.

The other option is as was mentioned to see how Android deals with it. The location bar in Chrome on Android DOES hide but interestingly enough only under certain circumstances. I noticed when looking at Google results it didn't hide until I first tried to scroll up beyond the limit.

[James Lewis (james-fsck)]

Actually that's a good point +Daniel Bull, I guess it makes sense not to change the viewport size... the question is what should it be set to... the site looks better (no blank borders) with the viewport set to the largest size it's going to be... but by rights, if the page tries to render inside that area so that it won't be scrolled, then it should be set to the smallest size it's going to be.

[Chris Coulson (chrisccoulson)]

I already explained why the viewport size has to be changed when the location bar moves - content that's fixed to the viewport (CSS position: fixed or scrollbars) will be positioned incorrectly and could be outside of the webview if it's not. Not resizing the viewport is not going to happen.

Our browser behaves exactly the same as Chrome on Android here - in fact, we use the same code for controlling the location bar position (it's controlled by Chromium's renderer compositor, not the browser). This problem doesn't manifest on large Chrome tablets because the location bar is always displayed (at least, it is on my Nexus 10). A quick check of the source code for Chrome/Android confirms that it's always displayed on larger screens (where the smallest dimension is greater than 800 DPs

https://chromium.googlesource.com/chromium/src.git/+/6ab9853acfbfae3e598004776c1d120805956038/chrome/android/java/src/org/chromium/chrome/browser/tab/TopControlsVisibilityDelegate.java#31
https://chromium.googlesource.com/chromium/src.git/+/6ab9853acfbfae3e598004776c1d120805956038/chrome/android/java/src/org/chromium/chrome/browser/device/DeviceClassManager.java#162

On my Nexus 7, the location bar does hide but this problem doesn't manifest presumably because it gets the mobile UI which expects this behaviour.

On both my Nexus 10 and Nexus 7, Chrome gets slightly different layouts of the mobile UI for Google Plus. Our browser on the M10 gets the standard desktop UI.

[James Lewis (james-fsck)]

+Chris Coulson

I'm not disputing what you say, since I'm not in a position to fix this issue, however if the solution suggested by +Daniel Bull is not correct then can you clarify what would be the correct solution, since currently on the M10 tablet, Google+ is unusable.

If I'm reading your post correctly, you are saying that on the M10, it "gets the standard desktop UI", so since it's 1920x1200 and still hides the location bar, are you suggesting this is a bug, and the location bar should be displayed all the time?

I'm actually pretty happy with the solution of simply not hiding the location bar, as you say, this would be expected behaviour on a "desktop" browser, it would certainly also be nice to have some control over the UI scaling since in desktop mode apps are still scaled like mobile apps, but I'm sure that's coming.

I notice that part of the Google UI also auto-hides, but I guess they would cater for that.

[Daniel Bull (ubuntu-frozenmist)]

Actually I agree, it seems the correct solution is not to hide the location bar on larger screens (which would be a UI improvement anyway IMHO).

James the Google UI elements auto-hiding won't change the viewport size or the width so that won't affect the scaling so that should be fine.

[Olivier Tilloy (osomon)]

I’ve asked design to comment on the proposed solution (never auto-hide the top bar for larger screens, like the M10), which sounds reasonable to me. Let’s see what they say about it.

[James Lewis (james-fsck)]

+Olivier Tilloy Never hiding it in desktop mode should be very obvious... but this is something of a middle ground where it's being used in tablet mode. The screen is large enough to switch into the tabbed mode, but it's still using a touch interface on a small screen... I'm not sure what the best thing to do there is, I certainly enjoy the "full browser" experience on the tablet even in touch mode, so I would definitely not want to go back to the mobile interface...

Short of some other solution which does not force the viewport to change (like bringing in the url bar over the top of the rendered HTML, rather than changing the size of the viewport)... I can't see much other option, I think google does leave the URL bar there on android in this context.