Exit fullscreen resizing bug?

One way to find the preferences for an app is run it, move its window then quit and run:

ls -ltr ~/Library/Preferences

The preferences for your app should be at the bottom of the listing because they were recently modified.  Remove the .plist from the end of the name and use that with the defaults command.

Does the CoronaSDK sample Interface/DesktopWindow exhibit the same issues you see with your own app?

Thanks for getting back to me so quickly Perry. I did what you suggested and got the following entry for my app:

uk.co.keystagefun.osx.testApp.plist

I removed the .plist and ran the following:

defaults delete uk.co.keystagefun.osx.testApp

But I still get the message:

Domain (uk.co.keystagefun.osx.testApp) not found. Defaults have not been changed.

I’ve triple checked it and it definitely doesn’t seem to run…

If anyone has any ideas they’d be much appreciated.

Thanks.

Paste the line from the ls -ltr command you ran that has your app’s id on it.

It was uk.co.keystagefun.osx.testApp.plist

Does the CoronaSDK sample  Interface/DesktopWindow  exhibit the same issues you see with your own app?

Okay - I’ve done some testing.

When I set “resizable” to false in the sample app then yes, exactly the same thing happens.

And if I set resizable to true in my app then it works okay.

So basically, with resizable set to false, any app seems to exhibit the same behaviour, namely that when in full screen mode, if I hover my mouse top left and then tap the green button that appears, the entire window shifts up and right so it’s partly off the screen (about 30% - 40% of the window is off screen). There is then no way to get it back on the screen as the green maximise button is no longer available as that presumably is also off screen. So I have to choose to Exit from the Mac menu and then relaunch.

BUT…

Interestingly, if I open the sample app full screen and then click the button you’ve included within the actual app to “maximise” I can then use the green Apple maximise button no problem and the window doesn’t move off screen. I can flick between full screen and maximised window and everything works perfectly, but only after I’ve manually clicked the button you included in the app.

Obviously I don’t really want to include a maximise button within the app myself. I could code it do this automatically the first time the app runs but I would prefer the user to start in full screen.

Is this a general bug or is it only happening to me?

Thanks.

@keystagefun

I am seing the same thing as you.

Even after succesfully running the defaults delete command.

Daily Build 2810 and higher implements the resetting of the remembered window position if Shift is held down while app starts.  This will provide a way to reset things if you can’t find the app’s preferences.

I’m having some trouble reproducing the issue you describe with the DesktopWindow sample. I made it not resizable but everything still worked as I expected it to.  One thing that is a little confusing from your description is that you seem to be using “fullscreen” and “maximize” interchangeably when they are distinct concepts.  “Maximize” means “make the window the size of the screen”, “fullscreen” means “enter a non-windowed special mode that occupies the whole screen” (these are OS X concepts which we implement).

 Can you list the steps I should take with the sample and what I should see?

Hi Perry.

Sorry for the confusion.

Okay - in the top left of any Mac window there are 3 buttons - a red one to close, a yellow one to minimise and a green one that toggles between full screen and window mode.

It’s this green one I’m referring to.

If I launch my app in full screen mode by setting that as the default launch mode in my build.settings file and then hover my mouse top left of the screen, I see these 3 buttons appear. If I press the green one I find my app shifts upwards and to the right so that around 30% - 40% of the app is off screen.

The 3 buttons are then not available so I can only close the app via the menu bar at the top.

The same thing happens with your example app and it happened the first time I ran it.

So it should just be a 3 step process to recreate it:

  • Launch the sample app (it launches in full screen mode by default)

  • Hover your mouse top left of your screen

  • Then press the green button that appears in the menu bar (next to the red close button)

The app should then move partially off screen.

Sounds like @ojnab is seeing the same thing.

Thanks,

Ian

Yes it is exactly what I am seeing.

Thanks for the details … they help a lot.

That doesn’t happen for me.  What version of OS X are you running?

El Capitan - 10.11.1

Thanks.

I am on El Capitan - 10.11.1 too.

 

I investigated this a bit further. The issue doesn’t appear when I build the samplecode DesktopWindow project, but it still happens when building my own project. 

 

So I decided to attach a sample project showing the bug. You can find it here:

http://www.shakebrowser.net/ResizeBug.zip

 

In the screenshots folder you will find screenshots showing how the bug looks on my computer.

 

Hope this will help tracking it down.

Thanks.

How does your sample project differ from the DesktopWindow project?  I ask because that seems to be the crux of the matter :slight_smile:

I have the issue with both my project and the DesktopWindow project. Exactly the same thing happens, the window moves to the precise same position off screen to the upper right.

It differs in the build.settings resizable property. If I set resizable to false in the DesktopWindow example. The issue appears when exiting fullscreen in this project too.

Yes you’re absolutely right. Good spot.

Perry - if you set resizable to false are you seeing this too?

Yes, it’s an issue on 10.11 but not 10.10.  I’m looking into it.

I can confirm this. The blue band in full screen mode ends up using up more game space than when it’s not in full screen mode. This happens in either game full screen mode or browser full screen mode. Pega training in Chennai   |   Pega Training in Chennai

Hi Perry. Thanks for looking into it. Did you get anywhere with the issue? Cheers. Ian

This is fixed in Daily Builds after 2813