Road to Mouse Lock: Part 3

As mentioned in the previous post, we were not able to get a nsIWidget reference which made it impossible to use the widget’s setcursor method. After discussing this with Diogo in person and using him as a sound board I decided to go back to my earlier abandoned project, using nsEventStateManager to call SetCursor. I can honestly say I made zero head way in the three or so hours I spent looking for a way. It wasn’t until Jesse started analyzing our earlier problem (missing widget) and mentioned nsGlobalWindow on IRC that I had my eureka moment. It was a moment of pure luck, at the time I was looking into methods that allowed me to gain access to the EventStateManager and was in the nsGlobalWindow.cpp. Everything just clicked after that.

Using this as reference, after a little copy and pasting I got a small prototype of what I had hoped to work. My main aim was not so much to get the mouse to disappear, this would come later because I had to pass a proper widget… which I’m not too sure how to get. The aim was to make sure I can actually call SetCursor. The end product for the lock method looks something like this:

    bool isFullScreen;
        mIsLocked = PR_TRUE;

        nsCOMPtr domWindow( do_QueryInterface( mWindow ) );
        if (!domWindow)
            return NULL;

        nsRefPtr presContext;
        presContext->EventStateManager()->SetCursor(NS_STYLE_CURSOR_NONE, nsnull, false, 0.0f, 0.0f, nsnull, true);
    return NS_OK;

For some reason when I compiled this code, the moz build looked like it did a full rebuild. It took over 30 minutes to build this time, which was significantly higher than normal. I think I might have messed up my .mozconfig at some point or something (my .mozconfig disappears when I hop branches on git). I was actually REALLY worried whether or not this code would work. When I first executed this code in VS, I didn’t even get to bring out the Web Console. VS actually crashed my whole computer to the point where I had to do a hard reset. After rebooting and testing, the code does exactly what I had hoped. It does go into SetCursor, and will use the mLockCursor which should keep the cursor at none until we unset it. I guess this is another case of the dangers of doing development on Windows. -_-

Upon looking at the code I copied, it seems that the code is used for resizing the chrome window (i.e., when we hold our mouse over the edges, get the resize cursor and perform the drag). This will serve our purpose well I think. The next thing will be to find a proper widget to put in, because right now I’ve sent in a null value. For those interested, the branch I’ve created is here on my github. I know I have way too many libraries and a bunch of unnecessary commented out code at the bottom of the lock method. The mess is the result of a bunch of things I’ve tried and have forgotten to fully clean up. Too bad programmers don’t have automatic garbage collection in real life. They’ll be cleaned up for sure, but I just wanted to put this up there and get some sleep. Yesterday’s excitement on IRC had me stay up until 3am and I had to wake up not long after.


2 thoughts on “Road to Mouse Lock: Part 3

  1. […] on the code (limited to the MouseLockable class) and encouraged by the progress made by Diogo and Raymond in implementing some of the tasks required for the Mouse Lock implementation, I decided to jump […]

  2. […] (see Diogo’s and Jacky’s posts), how to hide the mouse cursor when locked (see Raymond’s posts as well as Anurag’s), how to deal with complex UI cases in Mochitests, how to exit […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: