[otnt]

I am using MSPro (3.0.6) on Google's Pixel Slate (ChromeOS with Android layer).
Since Google introduced "gestures" in ChromeOS tablet mode (last year) it broke MSPro ability to maintain Fullscreen Mode.

When the "Performance Mode" is enabled return to library would bring blue bar (with mouse pointer) on top of the screen with window controls (one of them would completely shut down MSPro)
No mouse or keyboard is connected to Pixel Slate tablet:



For some of my colleagues the cross on the top right (for closing) was very tempting to get rid of the blue bar but unfortunately this action would shut down MS and also disconnect Leader/Follower conection.
To avoid this disaster during the performance the workaround for me is to disable the "Performance Mode" and to enable "Long Press" in Touch & Pedal Settings in "Overlay Toggle Mode" section in case someone needs to edit the song.

When the "Performance Mode" is disabled return to library would not bring up the blue bar with controls.
Please see my video screen capture on YouTube:

https://youtu.be/NSFArFnudkk

Is this a bug or am I missing some setting to toggle?

[otnt]

I updated my Pixel Slate (ChromeOS tablet) to latest version version 89.0.4389.82 and also updated MSPro to 3.0.9.
Unfortunately that annoying bug which breaks full screen mode is still there.

Am I the only one here using Pixel Slate? After month of this thread there is zero reply.
Can anybody try tablet mode on any other Chromebook and see if that blue navigation would pop out with performance mode enabled?

Many thanks.

[Harry777]

Sorry to hear you're having a problem, I'd love to help but I jut don't have a Pixel Slate. Just wanted you to know at least I see your problem and that you aren't going unheard!

[Zubersoft]

Sorry otnt - I must have missed that original post. I have a Google Pixel Slate. I'll update it tomorrow and run some tests to see if I also encounter what you've described. If so, I'll see if there is anything I can do about it. As a side note, my Pixel Slate is on the beta channel - I'm not sure what channel you are on, but hopefully this won't matter.

Mike

[otnt]

Sorry otnt - I must have missed that original post. I have a Google Pixel Slate. I'll update it tomorrow and run some tests to see if I also encounter what you've described. If so, I'll see if there is anything I can do about it. As a side note, my Pixel Slate is on the beta channel - I'm not sure what channel you are on, but hopefully this won't matter.

Mike

I'm using ordinary stable channel.
I can't experiment because it's used for performing.

[Zubersoft]

otnt - I was actually on 89.0.4389 previously and did not see that issue, but I just updated to version 90.0.4430.19, so I will not be able to easily test this on the stable channel version now. Having said that, how exactly am I supposed to reproduce this issue? I enabled performance mode, and under Settings->Display Settings I have both fullscreen mode and hide the navigation bar enabled. I loaded a song, and I don't see the blue bar at the top (the application is using the full screen). I can turn pages and everything works fine. I can't seem to get that blue bar at the top to come down when I don't have the keyboard and touchpad connected. If I attach the keyboard and touchpad, I can move the mouse to the top and bring down the blue bar and click the arrow at the far left, but once I'm on the library screen, the bar goes away and everything still seems to be perfectly fine. So I'm going to need more information on the steps required to see what you are seeing along with either screenshots or a video of some kind so I can see the problem in real time.

As a side note, being on the beta channel is not really experimenting - it just means you'll get all the latest changes for Chrome OS sooner. The development channel is the risky one. Beta really has never been a problem for me, and it ensures that I am able to take advantage of the latest Chrome OS changes much sooner.

Thanks,
Mike

[otnt]

otnt - I was actually on 89.0.4389 previously and did not see that issue, but I just updated to version 90.0.4430.19, so I will not be able to easily test this on the stable channel version now. Having said that, how exactly am I supposed to reproduce this issue? I enabled performance mode, and under Settings->Display Settings I have both fullscreen mode and hide the navigation bar enabled. I loaded a song, and I don't see the blue bar at the top (the application is using the full screen). I can turn pages and everything works fine. I can't seem to get that blue bar at the top to come down when I don't have the keyboard and touchpad connected. If I attach the keyboard and touchpad, I can move the mouse to the top and bring down the blue bar and click the arrow at the far left, but once I'm on the library screen, the bar goes away and everything still seems to be perfectly fine. So I'm going to need more information on the steps required to see what you are seeing along with either screenshots or a video of some kind so I can see the problem in real time.

As a side note, being on the beta channel is not really experimenting - it just means you'll get all the latest changes for Chrome OS sooner. The development channel is the risky one. Beta really has never been a problem for me, and it ensures that I am able to take advantage of the latest Chrome OS changes much sooner.

Thanks,
Mike

I just uploaded video to YouTube https://youtu.be/tIIK0-xVohw where you can see 4 Pixel Slates behaving same way.
All four tablets were never connected to keyboard, touchpad or a mouse. They were only connected to each other or Google's Pixelbook Pen or master (no.1) to AirTurn's BT-105 page turner.
I use all four tablets solely only for displaying the sheet music (in PDF).

The behavior shown in the video persist for at least last 6 month.
That blue overlay (with back arrow on the left & closing cross on the right) covering very top of the screen is showing up ONLY in the performance mode.
At the end of the video I confirm when the performance mode is disabled the issue goes away and full screen works as it should.

How to reproduce this issue is the question. All four tables have the same MSPro settings.
AirTurn page turner was only connected to tablet no.1 (master). I can confirm the issue is persistent no matter if AirTurn is connected or not.

Should I take screenshots of the MSPro settings?

[Zubersoft]

I've reverted my device back to the stable channel, I'm testing with the same settings as you (as far as I can tell from the video), but I'm still not seeing the problem. So I'm going to need you to either share a library backup file, or capture all of the settings across library settings, display settings, the display mode dialog, and the page scaling dialog, and I will see if something is different between how we've configured the app (I'm using almost all the defaults except for changing the display mode to vertical scrolling to match you and switching the few settings under Display Settings to match what was shown in your video). 

If I'm still unable to reproduce the problem after this, then I will start to think you've modified some kind of setting in ChromeOS itself that is responsible for this issue, as I now have a completely clean device on the stable channel. You didn't modify any of the OS settings related to the gestures by chance, did you? On my device, I can't even bring that blue bar down at the top of the screen unless I have a mouse attached. If I drag down with my finger, it switches between apps.

Also, please try testing one of the devices without the protective case on it. Those can sometimes trigger odd gestures on devices, so I just want to rule that out as a possibility.

Thanks,
Mike

[otnt]

I've reverted my device back to the stable channel, I'm testing with the same settings as you (as far as I can tell from the video), but I'm still not seeing the problem. So I'm going to need you to either share a library backup file, or capture all of the settings across library settings, display settings, the display mode dialog, and the page scaling dialog, and I will see if something is different between how we've configured the app (I'm using almost all the defaults except for changing the display mode to vertical scrolling to match you and switching the few settings under Display Settings to match what was shown in your video). 

If I'm still unable to reproduce the problem after this, then I will start to think you've modified some kind of setting in ChromeOS itself that is responsible for this issue, as I now have a completely clean device on the stable channel. You didn't modify any of the OS settings related to the gestures by chance, did you? On my device, I can't even bring that blue bar down at the top of the screen unless I have a mouse attached. If I drag down with my finger, it switches between apps.

Also, please try testing one of the devices without the protective case on it. Those can sometimes trigger odd gestures on devices, so I just want to rule that out as a possibility.

Thanks,
Mike

So I really sat down today and to toggle every MSPro settings.
Until I came to "Other Settings": "Disable Mouse Cursor in Performance Mode" is what brings up the issue. I was tempted to select and tick this setting on.
It suggests that it "disables and hides the mouse cursor" but the opposite is true.

And I never use the mouse or touchpad or keyboard with these tablets. As I don't need metronome, audio, page turn animation I was disabling what I could and that is why I ticked also to disable the mouse cursor.

Anyway I was also trying different settings in ChromeOS settings: Device: Displays: I was changing resolution under "Built-in display"
Findings are that:
- if 115%, 130% and 150% are selected the blue bar would show up just briefly.
- if 100% (is what I use), 90%, 80%, 70%, and 60% are selected the blue bar would stay on.

As I mentioned before there was never real problem because there was the workaround to use this fantastic piece of software anyway.

[Zubersoft]

I'm glad you figured that out. To hide the cursor in performance mode, I call a method called "requestPointerCapture" which basically locks the mouse movement and hides the cursor. To release it, I call "releasePointerCapture" which I do when you return to the library screen. The behavior you see with the blue bar coming down and not being released is how Google is responding to my request. I would definitely avoid using that setting unless you are actually using a mouse with the device. Having said that, I've done a little research and it may be possible for me to determine when a mouse is actually present, and ignore that setting if there is no mouse. I will test with this to see if it works.

UPDATE:
It appears I cannot accurately determine if a mouse is connected using Google's API. So I have no choice but to always call requestPointerCapture and releasePointerCapture and hope the OS responds appropriately. As you have found, this does not work well if you don't actually have a mouse connected. I will add a comment in the details of that setting to not enable it if a mouse isn't connected.

Thanks,
Mike

[Geoff Bacon]

Mike

How about, when MSP starts or is reopened, asking the user whether a mouse is connected ?  i.e. a single prompt but only if the option is enabled.
As mice are PnP, you would also have to detect if a mouse is subsequently connected/disconnected (but I suspect the API might have an event for this).

Alternatively ignore the option if there has been no mouse movement since the program started (possibly attempt to move mouse offscreen when MSP starts so that you get an early indication if user has a mouse).
(Might not be possible if the mouse is treated as a "touch" or vv)

Can the mouse be made transparent?

These are just thoughts and I've no idea how they could fit into your framework or whether they would introduce issues on other devices. It also adds more complexity to cover the inadequacies of the API and could cause you support problems as that changes.

Keep up the good work and Stay Safe

Geoff

[Zubersoft]

I would venture that 99% of Android tablet users do not have a mouse attached. The majority of Chromebooks don't have a detachable screen, but do have a touchpad and wouldn't use a mouse.  I don't think there is any point in prompting users every time the app is opened, as it applies to so few (and this would just annoy a lot of people). This seems like such a minor thing as well, as most users won't need to disable the mouse cursor. I think having a warning on the setting is probably good enough as most people don't venture into the "Other Settings" section anyways.

Thanks,
Mike

[otnt]

I would venture that 99% of Android tablet users do not have a mouse attached. The majority of Chromebooks don't have a detachable screen, but do have a touchpad and wouldn't use a mouse.  I don't think there is any point in prompting users every time the app is opened, as it applies to so few (and this would just annoy a lot of people). This seems like such a minor thing as well, as most users won't need to disable the mouse cursor. I think having a warning on the setting is probably good enough as most people don't venture into the "Other Settings" section anyways.

Thanks,
Mike

Exactly my words. Warning at the settings is more than enough.

I also tested Nexus 7 with 6.0.1 Android and the mouse setting is not showing up (great).
I also tested a phone with LineageOS 8.1.0 Android where the setting is visible but even when "Disable Mouse Cursor" is enabled and ticked the app would not show that blue bar or the mouse cursor (great).
So it probably is only Chrome OS behaviour.

Have you ever thought about creating special ChromeOS forum section?

[Zubersoft]

I've created a subforum for ChromeOS discussion. Thanks for the suggestion.

Mike