On Chrome OS, leaving fullscreen does not restore window decorations.

[gordol]

Steps to reproduce: Open any mosh-chrome window (preferences, new session, or shell). Make the window fullscreen by pressing F4. Press F4 again to leave fullscreen.

Expected behavior: Window manager controls (min, max, close buttons) should be visible.

Observed behavior: Window manager controls (min, max, close buttons) are not re-applied to the window. It's as if it's still fullscreen, just smaller than the full screen.

The window is still re-sizable when coming out of full screen, FWIW, only the controls are missing.

If you press alt-tab after coming out of full-screen, the controls do re-appear, oddly enough.

Screenshots here: https://imgur.com/a/MVg0KtB

Chrome OS Version: Version 67.0.3396.78 (Official Build) beta (64-bit)

Mosh-Chrome Version: I am using a patched build of Mosh-Chrome, based on v0.5.4, where I have embedded a Powerline font and a user CSS file, but otherwise, no code has been changed. You can see my changes here: https://github.com/rpwoodbu/mosh-chrome/compare/master...gordol:master

I have not observed this behavior with any other windows in Chrome OS.

[rpwoodbu]

That's exceedingly strange. I'm inclined to think this is a ChromeOS bug, since Mosh for Chrome does not use a custom frame (i.e., the frame is the default one provided by the platform).

I am not able to repro with "Mosh (dev)" on Chrome OS stable (Version 66.0.3359.203 (Official Build) (64-bit)). Are you able to repro with that version (sans your patches)?

[rpwoodbu]

I just tried this on Chrome OS dev (Version 68.0.3440.15 (Official Build) dev (64-bit)), and also could not repro. However, I did find some other Chrome OS window manager bugs in the process... 😉

[gordol]

Interestingly enough... I powerwashed/switched to dev and it didn't happen, and also it doesn't happen on stable.

I'm on stable now... and for some reason when I make the window full-screen, I'm unable to show the shelf by moving my cursor to the edge of the screen. This doesn't happen in other windows... For example, in Secure Shell or Crosh Window.

I'm also unable to move my cursor to the top of the screen to expose the window controls...

Is the full-screen window management code for Mosh-Chrome different in some way?

[gordol]

I have a fix!

PR incoming. :)

[gordol]

Actually it still doesn't fix it...

It just makes it work initially...

For some reason, when the window loses focus, and regains focus, the bug is triggered where the shelf and window controls are not triggered.

[gordol]

Going out of full-screen, and back to full-screen does fix it though.

Very strange...

[gordol]

So basically, when the window loses focus, and regains focus, while in full-screen, it's not possible to trigger the shelf and window controls. Leaving full-screen, and re-entering full-screen restores expected functionality. The PR above removes the functionality that defocused-refocused the window, which prevents this from triggering initially, but it still happens if you switch windows and come back.

[rpwoodbu]

Thanks for the PR! I'll try to carve out time this weekend to work on this project and get that merged.

Other than that hack, I don't think I'm doing anything special wrt window management. It's possible there's some special handling in hterm, so you might try reproducing with Secure Shell.

[gordol]

btw... updated libapps to latest, and this doesn't happen.

[gordol]

ugh... no it doesn't... sorry, it still triggers this bad behavior when the window loses and regains focus

[gordol]

The shelf issue is not happening after the latest stable update... but the window controls disappearing after coming out of fullscreen is indeed still present. So strange...

Version 67.0.3396.87 (Official Build) (64-bit)

[gordol]

The window controls are accessible while in full-screen, but it's not possible to drag the window, you can only minimize it. If you convert it back to a window from fullscreen, it won't have a titelbar or control buttons, it's just a square resizeable box.

[rpwoodbu]

I am actually able to reproduce this reliably on my Asus Chromebox (Version 67.0.3396.99 (Official Build) (64-bit)), building from master. As you suggested, your PR doesn't seem to fix the issue. I'm disinclined to merge it, as the bug it works around is still unresolved.

I will try building with a newer hterm.

[rpwoodbu]

Gah, still happens with libapps at tag hterm-1.80.

[vapier]

i'm assuming this is a bug in CrOS. not sure how hterm would be able to affect window decorations as Chrome generally doesn't allow JS to manipulate them.

[rpwoodbu]

@vapier Yes, likely a Chrome OS bug. However, it is possible, AIUI, for the app to manipulate the window decorations, at least in (Packaged?) Apps (examples available upon request). However, Mosh for Chrome is not (intentionally) doing so, and I assume hterm isn't (intentionally) doing so, either.

[vapier]

hterm shouldn't be doing this, do if it did, it's a bug. we limit chrome.xxx usage because hterm is usable outside of extensions like the open web.

[gordol]

so strange...

i can also reproduce this with the chrome os files app natively... however, when you resize the decorationless window, the decorations pop back in.

https://www.youtube.com/watch?v=25lgdxj4gAA

gonna close this as a chrome OS bug.

[gordol]

https://bugs.chromium.org/p/chromium/issues/detail?id=867566