Is this running --mustash?

sadrul@, riajang@: can you comment on this?

per IRC: this is --mash

Additionally, piece of info:

- Bug is reproducible with ozone/x11 builds of chromeos, launching with --mash.

$  out/ozone/chrome_os/chrome --mash --user-data-dir=~/tmp- --ozone-platform=x11 --window-manager=ash

OR

$  out/ozone/chrome_os/chrome --mash --user-data-dir=~/tmp- --ozone-platform=x11 --window-manager=simple_wm

- Bug is *not* reproducible when building non-ozone chromeos builds of chrome (this is only possible with ToT if commit bb77840039a03ce9e18fe5b411d5a310fcec6d78 is reverted - https://codereview.chromium.org/2555893002).

$ out/chrome_os_raw/chrome --mash --user-data-dir=~/tmp-

OR

$ out/chrome_os_raw/chrome --mash --user-data-dir=~/tmp- --window-manager=simple_wm 

"In certain machines" - what machines should I test on if I want to reproduce this bug? I can't seem to reproduce it with "out/ozone/chrome_os/chrome --mash --user-data-dir=~/tmp- --ozone-platform=x11 --window-manager=ash" or "out/ozone/chrome_os/chrome --mash --user-data-dir=~/tmp- --ozone-platform=x11 --window-manager=simple_wm". 

tonikitoo: What revision did you build at?

Another thought, what WM are you using? Is it a tiling WM? We are assuming the XWindow size matches the size we set it at. If you resize the XWindow, or use a tiling WM that resets the size there will be an offset.

@kylechar / riajiang: thanks for replying. the revision I used is efd3d8ba87ec8266ab1b5c34cfee31c1121f45ca (Jan/12):

These are some of the configurations I tested it with, and in the end, it seems related to the window manager being used, as per @kylechar comment:

1) Problem REPRODUCES

tonikitoo@ubuntu $ wmctrl -m
Name: Compiz
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: ON

2) Problem REPRODUCES

fred@debian:~$ wmctrl -m
Name: Mutter (Muffin)
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

3) Problem DOES NOT REPRODUCE

tonikitoo@ubuntu $ wmctrl -m 
Name: Xfwm4
Class: xfwm4
PID: 28768
Window manager's "showing the desktop" mode: N/A

4) Problem DOES NOT REPRODUCE

tonikitoo@fedora $ wmctrl -m
Name: GNOME Shell
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

However, even on the machines where the problem does not reproduce at first, the mouse offset issue does start to happen if I resize the outermost window (in this case the ozone window). For instance, if I resize the top level window upwards, that portion of the window is drawn black, and the offset happens by that specific amount.

Okay, that is basically expected then and my fault. For Chrome OS on a device, Chrome OS is what is controlling the displays and it makes PlatformWindow the appropriate size for the display. That gets messier when running Chrome OS on Linux where the WM can change the PlatformWindow size.

For non-mustash Chrome OS running on Linux, when you resize the PlatformWindow it changes the display resolution to match the window size. We could do something like that.

A more hacky solution is to add an offset when the window gets resized. Does https://codereview.chromium.org/2629653002 fix the problem? I'm not sure if it's landable though.

As another data source, --screen-config also allows to work arounds the problem:

$ out/ozone/chromeos_os/chrome --mash --user-data-dir=~/tmp- --ozone-platform=x11 --window-manager=simple_wm  --screen-config="800x600"

** see --screen-config="800x600"

@kylechar: https://codereview.chromium.org/2629653002 does fixes the mouse offset problem, yes.

But it does not fix the whole thing: for instance, when the host WM resizes the outermost window, the browser position seems not changed accordingly. hence chrome's tab-bar gets covered by the outermost window titlebar (see attached picture. btw, on this picture it is also possible to see that the move location and its hover effect work).

But it does get better indeed. Maybe we can fix it somehow at FakeDisplayDelegate level, since its intention is to make off-device chrome os builds run. WDYT?

Deleted: Screenshot from 2017-01-12 15-51-16.png 8.2 KB

	Screenshot from 2017-01-12 15-51-16.png 8.2 KB View Download

Deprecating Proj-Mustash-Mus-WS in favor of component Internals>Services>WindowService.

I don't believe this is an issue anymore.