How do I make the quit button work for WebGL?

[Brady_Eatherton]

I used Bert_Berrevoets code to stop the Editor from playing, but is there a way to have a working ‘Quit’ button for WebGL? Is there any way to do this on Game Bucket?

Also, is there a way to keep Bert_Berrevoets code in and still publish with WebGL without getting an error? Maybe an ‘if’ statement?

[Rob]

Hi Brady,

From within your game you are not able to call a Windows method to close the browser. What you could do, which I have seen another student do, is instead wire the Quit functionality to a URL, so that instead, when quit is called the user is redirected to another web page. This could be your own website, or a page to request some feedback, a portfolio website and so on. Quite a nice way to get around the issue.

Regarding “Bert_Berrevoets code” - can you be a little more specific, what is this? What does it do?

[Brady_Eatherton]

It won’t ever shut the game down in Unity though, right?

[Rob]

How to quit the game is going to depend on the platform you are targeting.

If you create a standalone/PC/Mac build then you could have a quit button and use the following;

public void Quit()
{
    Application.Quit();
}

The above would cause the running application to close, just as if you were using an application like Microsoft Word and went to File -> Exit, or, click on the X icon in the top corner.

If you just want to have a quit button which stops the game from within the editor, returning you to Unity, but, in a build as above actually closes the application, you could use the following;

 public void Quit()
 {
     #if UNITY_EDITOR
         UnityEditor.EditorApplication.isPlaying = false;
     #else
         Application.Quit();
     #endif
 }

The above will stop the game from playing within the Unity editor if the Quit() method is called, or, if the game is running outside of Unity it will close.

For mobile devices, both Apple and Google will have specifications on whether you should quit the application or not. I believe, certainly in the case of iOS, that the memory is managed and apps are closed only if more memory needs to be freed up. Thus, a user would use the Home button, which effectively sends the app to the background.

Android devices have the back button and I would expect them to behave in a similar fashion.

In order to determine which platform the game is actually running on, you can use Application.platform, this would allow you to create a reasonably generic Quit() method, which could handle running within the Unity editor, a standalone build, Android, iOS or WebGL builds - and effectively do something different (or nothing) for each case.

Hope this helps.

---

See also;

Unity - Scripting API : Application.platform

---

Updated Tue Sep 26 2017 12:13

Can we mark this topic as solved now @Brady_Eatherton?

[mortepcandvr]

All credit to @Rob here, I use similar technique for Unity standalone vs Editor, and have expanded it for WebGL thus:

public void Quit() {
#if (UNITY_EDITOR || DEVELOPMENT_BUILD)
    Debug.Log(this.name+" : "+this.GetType()+" : "+System.Reflection.MethodBase.GetCurrentMethod().Name); 
#endif
#if (UNITY_EDITOR)
    UnityEditor.EditorApplication.isPlaying = false;
#elif (UNITY_STANDALONE) 
    Application.Quit();
#elif (UNITY_WEBGL)
    Application.OpenURL("about:blank");
#endif
  }

That works nicely for those three environments at least.
As for what happens to the WebGL environment when you call Application.OpenURL, the javascript does stop running, so CPU drops, but the browser memory remains cached so until garbage collection time, the committed memory will just sit there:
For instance, I captured these Mem & CPU figures from windows perf monitor before, during, and after Quit(),
These were screencapped on two repeat runs (hence PID 4236 for mem, PID 4192 for CPU)

after starting a blank Firefox:


.
.
after starting The Unity WebGL code from index.htm in the built subdir:


.
.
after clicking a UI button to call Quit() :


.
.
Note that Windows perf monitor does not see or show the subthreads running the javascript as separately measured process entities, only as an aggregated threadcount for the umbrella Firefox app.

[Rob]

That’s an excellent post @mortepcandvr, thank you for this, some really good detail and information there.

[Pat_V]

Hi, mortepcandvr.

First, thank you for that post. Secondly, just to be clear, is “Application.OpenURL(“about:blank”);” is actually closing the current tab or is it just invoking a blank page in the current unity screen?

Thank you.

[Alex_Stusse]

Nice Solution i was looking for somethign like that

[Rob]

is “Application.OpenURL(“about:blank”);” is actually closing the current tab or if it’s just invoking a blank page in the current unity screen?

It would do the latter, replacing the Unity game with a blank page.

You could consider alternatives for the URL though, perhaps your website displaying other games, or a portfolio of other work, or perhaps a page asking the user to feedback their experience of your game.

[Pat_V]

Ok, thank you, that was what I was thinking. I just wanted to be sure.

[Rob]

No worries