Road to Mouse Lock: Reflections

A couple of days ago (Friday to be exact) Dave wrapped up our work on mouse lock and a couple of tests we have done and put it up for review. Of course this doesn’t mean we’re done. Aside from getting our work reviewed (which Dave has told us will undoubtedly fail), there are still implementations specified on the w3 specs that we haven’t taken care of or are piggybacking off Mozilla’s Full Screen API. There are also a few tests that we’ve left out because they either just hang or don’t do what they need to do, so as anyone can see there’s still a lot left to do. Luckily there are several people who seem to still be interested in working on mouse lock despite the course being over, myself being one of them.

What’s left to do:

• Finish off the rest of the tests. Should mention that some of these tests may be impossible, we’ve been having trouble getting focus switching to work nicely with all full screen, mouse lock, and mochitest.
• Write Litmus tests for the tests that aren’t possible for mochitests (determining if the mouse disappears upon successful mouse lock)
• Start uncoupling from full screen API so we don’t rely on full screen API to work for mouse lock to work.
• Incorporate the changes we get back from the review

For most of my classmates, this marks the end of having to work on mouse lock, so I want to take this time to reflect on what I’ve done and my thoughts on working on mouse lock. Working of Firefox is incredibly difficult. Just finding the correct place to insert code can be a real challenge. I remember when I wanted to build on top of what’s been done and to make the mouse cursor disappear, it took many hours of looking at a call stack and doing minor manipulations just to see if I’m in the right area. Of course it won’t seem that way when you look at the code… it’s easy to look at the code and say, “Yep, it makes sense to put it there.” For me when I was starting, finding the proverbial sweet spot was quite difficult. Especially before I hooked Firefox up to Visual Studio to debug. Even then, it took me a while of looking at the stack call to figure out where to edit. Aside from finding where to put the code, another area that was incredibly confusing was learning when I could get what objects and what interface I had access to. Perhaps I missed a MDN document regarding how we can tell easily, but I’ve always had trouble figuring out whether or not I can convert one object into another or if my function call to get an object returned the actual object I wanted. However, despite the hardships, I always felt compelled to continue working because what I was doing was something no one else has done, no amount of Googling was going to ever yield an answer to my question. In a way, I felt like I was an explorer searching an unexplored world.

After large parts of the implementations were complete, our class was given a more test oriented task. We needed tests to accompany our patch to ensure we didn’t break anything and that future additions didn’t break our implementations. At this point, because I had inadvertently updated the wiki the day before, I was automatically nominated with making sure all the tests were assigned to a classmate to do. A side effect of this was that I was also put in charge with managing the branch where all the tests will be stored and tested prior to our submission for review. At first I thought the task was going to be easy, because prior to this, I’ve been doing a lot of merge work from Dave, Jesse, and Diogo. So I thought this was going to be similar… boy was I wrong. Initially things started off easy as only three or four people were actually doing their tests and they were, for the most part, available on IRC. Managing the pull requests from them were simple and easy. When everyone else in the class began participating a few problems popped up:

1. Because IRC was only suggested and not required, when a pull request needed a fix, the main way to contact them was to use github’s pull request comment system. It’s fine for what it is, but unlike messengers, people usually don’t idle on github for very long.
2. Although information being up on the wiki or on a FAQ, not everyone (in fact it was the majority) reads it, so they make their own templates despite one given to them, and they make pull requests to the wrong repository.
3. Some people don’t update their repository prior to their pull request despite being told to, which meant that they coded their work based on Firefox code that was many revisions behind.
4. A side effect from the above is that they had merge conflicts with other people because everyone had to modify the makefile.in in order for the build tool to incorporate the test.
5. A lot of people didn’t actually RUN their code before submitting the pull request.

Regrading which of the 5 problems I had the biggest issue with, number 5 beats out all the others by a wide margin. I had thought that it would be standard practice to make sure what you do doesn’t break everybody’s work. It was often not the case. Unfortunately, due to time constraints I usually accepted a pull request if github said it was okay to merge in without looking at the code too closely. In hindsight I should’ve given all the code a quick glance to see if it works, but I had my own test I had to do at the time. Imagine my surprise when upon finishing my test, I update my local repository and find that I can no longer build. Thankfully because we were working only on tests, it was only the makefile that needed to be fixed.

As with most things done for the first time, some tests were not written properly or simply did not test what they were supposed to do. A few of the tests were written in vacuum where the test writer had not come on IRC to discuss the details of their test, so they did not do what was expected of them. This lead to a peer review of the tests which also included the need for a harness for tests that needed full screen. By Friday morning, 4:30am to be exact, about half the tests were converted to the proper harness format and tested what they should be testing. The last two weeks were incredibly exhausting. For the two weeks, I slept around 3-4am in the morning and depending on the day I had to wake up between 7-9am to make it to class. I assume this is how it feels to be in crunch time at a large software company just prior to release.

I’ve learned so much working on mouse lock so far, I’m sure I’ll continue to learn from it as mouse lock implementation gets for fleshed out. The experience I got from working on mouse lock is so uniquely different from anything I’ve experienced before, if I were an RPG character, I can safely say I leveled up.

——

This week is exam week, and there are still some tests that need to be done. Hopefully, I’ll find the time to take a more in-depth look at one or two tests that don’t have a primary reviewer sometime this week. Otherwise, I think I’ll be spending my free time between semesters mapping out various parts of Firefox, particularly parts that might influence mouse lock implementation.

Advertisements

Road to Mouse Lock: Part 8

It’s been almost a week and a ton of things have happened since the last time I posted. The biggest change is that our tests were more or less assigned to students, which was fine because most if not all the implementation has been done. Incidentally, I was asked to be in charge of consolidating the mochitests. The tests are stored in my github branch mouselock-tests. I was pleasantly surprised by the number of people who managed to complete their tests by Saturday night.

That said, I’ve been only doing quick looks at the code and accepting them, going with the honour system until now. I’m aiming to run through all the tests as well as looking at the code to remove the use of setTimeouts and tests that aren’t quite working.Of course, I’ve had my own tests to write, number 17 and 18.

The Problem:

Writing a mochitest that checked for various mouse events like mousedown, mouseup, mouseover, mouseenter, mouseleave, mouseout, and click. For mouseover, mouseenter, mouseleave, and mouseout, we need to make sure that these events are no longer triggered when we are in mouselock. For mouseup, mousedown, and click, we want to make sure that only the element that is locked can receive these events.

What I’ve Tried:

So for the mouse position related events, I created a div within a div. I full screened and locked the mouse to the larger container div and moved the mouse around the contained div to check the values.

For the mouse click events, again I created a div within a div, but this time the inside div is places right in the middle of the div that is mouse locked. The idea is that when I do any mousedown, mouseup, mouseclick event, only the div that we locked our mouse to catches the event. The inner div that is placed in the middle shouldn’t.

As originally mentioned I tried the createEvent javascript method. However, doing this skips over the event system totally which means that it won’t serve our purposes. So a quick search via mxr yielded a method called synthesizeMouse that served our purpose. While working on this Saturday night, Tentacle and I  (reads so wrong…), found that trying to use synthesizeMouse with the click mouse event would cause an error. The error being that the DOMWindow’s sendmousevent did not support click. The work-around I found was to call sendMouseEvent to handle the click. After that was basically figuring out the workflow of the test (where to add what event listener ) to get the test running.

The Solution:

It works! Compared to many of the tests so far that’s just 1 or 2 tests per file, mine is something like 24 tests. It seems so deceptively simple when you look at the original description but every mousedown and mouseup require a check for left, middle, and right mouse clicks, and having to keep track of the numbers can get really messy.

What’s Next:

The final stretch is here now. The first implementation (where mouselock requires full screen) is almost complete, just one or two dangling things. I plan to look at how mozilla’s full screen api handles focus lost and seeing how we can implement that for mouse lock. As well, there are still some tests remaining that need to be done and I might help do some of those as well.

Road to Mouse Lock: Part 7

So it’s been a while since my last post, work hasn’t stopped, just slowed. My other courses have large assignments that are due coming up so I’ve been focusing getting those done ahead of doing things to implement mouse lock. During the hour of spare time in between my study for a BTP500 test, I whipped up a really quick demo of how mouse lock would work on a canvas. Unfortunately there’s a stretching issue that I haven’t resolved yet, but the basic idea is there. Luckily not long after, during the recent weekend, Jesse made an incredible demo (he added in mouse lock to an existing fps browser demo). I ran it with a debug build, but I don’t think that’s the cause of my problems, but clipping seems to not work as it should at times and the mouse tracking seems to occur even when mouse lock is off, but those are minor details considering the first actual prototype with mouse lock has been implemented. Aside from that I have 2 other things I’m going to talk about…View post

The Problem:

1. When working on a dual screen monitor, I get odd behaviours from both mouse lock and full screen. When I’m in full screen and mouse locked mode, I’m able to (if I’m fast enough) take focus away from the browser by clicking (usually the right mouse button) on my second monitor and get results that look something like the following:
   
   Currently, my mouse is on my second monitor, unfortunately the results I get vary a lot when I try to replicate this behaviour. Sometimes everything will work exactly as it should, other times mouse lock and full screen stays turned on, other times it’s just full screen that sticks. I suppose part of the problem with mouse lock staying on despite focus being taken off is partly due to us piggy-backing a lot of our mouse lock exit strategies on full screen. I haven’t really debugged the issue to find out what’s been happening, so the focus of this post is with problem 2 below.
2. The other problem I’ve been working on is hiding certain mouse events like mouseover, mouseexit, and other non-user generated events. Eventually I’m assuming that suppressing the context menu for the right mouse click will be required as well, but for now the obvious non-user generated mouse events are my target. The code to do this is actually just a simple if check to see if mouse lock is on. The problem is writing the tests for it.

What I’ve tried:

I was able to do a simple in-person test to see if the events were properly hidden, and for the most part, I was successful (I need to track down other non-user generated mouse events).The problem is when I needed to write code that would used for the mochitest framework. Originally I had thought of using the JavaScript createEvent method on the document. However, when I actually tested this out all the events went through even though they should’ve been blocked. At first I thought it was because I didn’t insert my if checks at the right level and that the JS events were somehow being fired further in. So I spent 3 hours looking through nsEventStateManager.cpp looking for where I was going wrong. It seems that wasn’t actually the problem. Had I looked at the JavaScript implementation more closely, I would’ve noticed that the event is attached to the element and the element dispatches the event by itself. This to me, seems like it circumvents the whole event chain that is what normally occurs when you interact with the mouse (and probably why when I created a context menu event, a context menu didn’t pop up).

The Solution:

It would seem I’ll have to look elsewhere for my solution to this problem. I haven’t fully explored what other events I can create, perhaps there is one that exists that would allow me to do this, otherwise, maybe a content script will be necessary (I assume it will work since content scripts are powerful enough for me to check the current cursor’s image). This will going to require a bit more tinkering…

Road to Mouse Lock: Part 6

So after today’s class, the work I’ve been doing has been pulled into the main repository, which means that my work will be tested by all my peers! Hopefully it all works well, if not, I’m here to fix those problems. I’m not totally satisfied with my code just yet, at the moment I do a simple check to see if the browser is in full screen mode. The specs and how it should work in real life is that I would check to make sure the element that I’m locking to is actually the element that’s in full screen. I’m not the only one trying to get at this element, in fact my friend, James Boelen, tried this and has little success. Also, I’ve decided to structure my posts a bit differently (copying Diogo’s style) because I think it’ll help my posts be more to the point and less all-over-the-place.

The Problem:

We want to check to make sure that the element that is in full screen is actually the element that called mouse lock. We have ready for access, the element that calls the lock method of mouse lock and a reference to a nsIDOMWindow object that initiated mouse lock object. Having done much of the code to actually get the mouse cursor to disappear, we also have the following at our disposal,

• nsIDOMWindow
• nsPIDOMWindow
• nsPresContext
• nsPresShell
• nsIWidget

After a bit of searching, I found a way to call GetFullScreenElement() what I wanted from the nsPresContext by doing:

nsCOMPtr<nsIDocument> nDoc = presContext->Document();
nsIDocument::Element* check = nDoc->GetFullScreenElement();

As you can see, while I am able to call the method, the result is an nsIDocument::Element. I took this into debug mode in VS and to my relief, if I poke around inside, I see that the element from the method GetFullScreenElement() matches the one passed in from the argument. The problem was how to compare the two, especially since one of them is a nsIDOMElement while the other is a nsIDocument::Element.

What I’ve tried:

I can honestly say that I know very little of the Mozilla code. I’m not sure when it’s appropriate to use do_QueryInterface, or do_GetInterface, or if I should do some sort of casting. So in hopes of hammering this nsIDocument::Element into something more useful, I’ve tried all permutations of do_QueryInterface, do_GetInterface,  and static_cast<>. The types I tried to get it into were Element *, nsGenericHTMLElement, nsIDOMHTMLElement, etc. I can’t really say any more because I must’ve been at this for hours and I would only get errors upon errors. It was interesting because I tried to store GetFullScreenElement in a simple Element *, but the compiler would tell me to use a nsIDocument::Element *. It drove me INSANE because I would open up the object and see nsGenericHTMLElement. It taunts me! It helps having a buddy, James, who suffers the same problem. =)

Solution:

Don’t have one yet. I believe on Thursday’s class we’ll be talking about this subject and hopefully cracking this case wide open. It’s just as likely that I’m going about this the wrong way, in which case, whoops! Live and learn.

UPDATE: It seems diogo was able to find the answer! Clearly I didn’t dig far enough, didn’t think about using mozilla::dom::Element … rather I saw that once during one of my compile attempts, but didn’t click for me. But that’s one less thing to do for mouse lock!

What’s next:

The obvious thing is to write tests to check the cursor’s current image(?). By image I mean what cursor representation is it. Is it a text, resize, arrow, hand, wait, etc. Most of the stuff online deals with getting that information from using element.style.cursor, the problem is we aren’t setting the element’s style. So that route is a bust, I took to IRC (more of our classmates need to use this) and asked Dave for some guidance. He pointed me to content scripts and said that it should have everything I need to do this. I’m new to content scripts, so I’ll be learning it for the first time, hopefully it won’t be too hard.

Another area that needs to be done is, according to the spec under the lock method, restricting the mouse events that are allowed to dispatch. We need to allow only user generated events such as: mousemove, mousedown, mouseup, click, wheel, etc. while suppressing the others. I think we’re at the right level now with nsEventStateManager to do this. I’ll hope to tackle this problem before the week is done, perhaps by Thursday if I finish my other course work early enough.

Finally something more long term is working on a demo. I think I’ll do something like an image viewer. Use processing.js or something to draw a large picture on a canvas, make it full screen and allow the user to “navigate” across the picture. As for the picture, maybe I’ll do a panoramic picture 360º so that they can spin horizontally forever.

Road to Mouse Lock: Part 5

So I read Diogo’s post regarding the mouselocklost event as well as a bunch of tests he wrote. I thought it would be prudent to add his stuff into my branch and made sure my stuff worked since the stuff he’s working on will impact my code. For the most part there weren’t too many conflicts, just one dealing with the nsDOMMouseLockable.cpp where there was a conflict with the lock method. After a bit of copy and pasting I was able to get everything to build and work properly, the tests had the same results as Diogo’s earlier attempt, which is fine. As long as I don’t have fewer tests passed, I’m happy. I was going to move on but on a whim I created a new page and then called the unlock method without calling the lock method first. This caused my browser to just vanish. I opened up Visual Studio and started to poke around at what was going wrong with the unlock method. The problem was that because we didn’t have a check to see if we even needed to do the unlock method, we tried to QI a nsIDOMElement that doesn’t exist which caused the crash.

Adding an if check prevented this behaviour and while I was there, I added the steps necessary to bring the mouse back when unlock was called. I’ve also merged this back with my main mouselock branch so if anyone wants to see the code, the commit is here and my branch is now here. I’ve “decommissioned” my mouselock-MouseBeGone branch since unless there needs to be more work done on making the mouse disappear and reappear that’s drastically different, there’s no need to work on it anymore.

UPDATE: I’ve also looked at Anurag’s post regarding ESC key handling. It’s similar to how a mouselocklost event will call the unlock method. Actually, I was thinking that since the ESC key caused full screen mode to exit, which in turn will fire an event, to have that trigger mouselocklost which would call unlock. The question is how do I go about doing it.

UPDATE #2:  So there’s still more to come with regards to doing the lock method and getting the mouse to disappear. It was brought up by Anurag’s post noted above. Currently the lock method does not distinguish between full screen achieved from the menu/F11 versus full screen of an element. To remedy this, I was thinking of comparing the full screen element against the element that’s passed into the lock element. I’ve made a push to the mouselock branch with 2 lines of change that allow us to get at the element based on the document supplied during init. The problem is that the addresses are different, but the nsGenericHTMLElement is the same. I just need to figure out how to compare those two things.

On a side note, it seems the majority of my “breakthroughs” happen really late at night. It’s killing my sleeping hours.

Road to Mouse Lock: Part 4

Success! Last night I was able to access the SetCursor function and the next step was to find a widget to pass in. I was reading the blog post by Anurag, he was looking into how FF handled CSS and look for a way through there. In his post he had a snippet regarding where the cursor for a Windows system (I am also on a Windows system) would actually set the cursor to None. This part gave me the perfect place to put a breakpoint and see how to get a widget. All I needed to do was back trace the call stack far enough and I should theoretically find out where I can get a proper widget from. Looking up the stack, I traced things up to nsPresShell.cpp. I recall reading the layout introduction on the MDN yesterday when I used PresContext to get the EventStateManager. PresContext and PresShell were connected which meant that I should be able to get the shell from the context and from there get access to a proper widget to pass in.

The result was a success, I know screenshots don’t show cursors typically, but it really is missing, seriously! (Even Drake is astonished)

So basically the code goes something like this. From the PresContext, I get the PresShell, which contains a nsIFrame that contains widgets. I’m using a widget from that frame and passing that into SetCursor. Doing it this way allows me to avoid touching operating system specific code which could be a huge pain since that would mean three implementations one for each of the three major operating systems (Windows, Linux, OSX). I started looking at whether or not I could get access to this from a nsIDOMElement because when our code is ready, our lock method will be taking in an element. When I look at the code, I don’t really think I need to use the nsIDOMElement since the element should be incorporated in the nsIDOMWindow that was passed in during the init step and the result should be the same thing… but we shall see when that part gets implemented.

When the mouse cursor disappears, I think the lock method will also have to do something with the mouse’s right button click. Perhaps I’m thinking for gaming purposes, but I would assume for applications that require mouselock, the developer would also like to have specific functions for the right mouse click. I’m not too sure about this, I’ll have to speak to Dave and the other people about it. If it does turn out to be the case, then this is probably what I’ll focus on next. If not, I might hop over to take a look at the mouselocklost event and do a bit of hacking there. =)

There are two things in my code I would like to talk about and it’s this:

nsRefPtr<nsPresContext> presContext;

and this:

nsCOMPtr<nsIWidget> widget = shell->GetRootFrame()->GetNearestWidget();

So the first one is that I used nsRefPtr. I’m not really too sure what the difference is between nsRefPtr and nsCOMPtr, but when I used mxr to look for nsPresContext casting, I saw nsRefPtr used so I thought better safe than sorry. The other line of code deals with me skipping the nsCOMPtr<nsIFrame> variable declaration and directly calling the GetNearestWidget method. I know I should probably create a variable for it, but I’m guessing it’s not nsCOMPtr<nsIFrame> because I get a  ‘Release’ is not a member of ‘nsIFrame’ error. From the other pieces of code that use nsIFrame it seems they just do a simple pointer without nsCOMPtr. I might do this later, but for now, it works. =)

tl;dr

I got the mouse to disappear when lock occurs, which only happens when the window is in fullscreen mode. I’ve also cleaned up my code a bit, and for all those interested, the github branch is here and my commit is here. I’m hesitant to merge it into my main mouselock branch mainly because I might have done the implementation wrong, so I’ll wait till I get some input from my colleagues before doing the big merge.

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;
    mWindow->GetFullScreen(&isFullScreen);
    if(isFullScreen)
    {
        mIsLocked = PR_TRUE;

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

        nsRefPtr presContext;
        domWindow->GetDocShell()->GetPresContext(getter_AddRefs(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.

The Road to Mouse Lock — Part 2: Lessons Learned

In class we were able to proceed forward and nail down some more things that we should get started working on which helped provide direction to our class. For me, I had hoped to be able to implement the part of mouse lock where once mouse lock has been initiated, the mouse cursor will disappear until the mouse is unlocked either by a method call or some other approach. My initial thought was to look at how FF implements their CSS cursor style since there already is a CSS style. Unfortunately being as inexperienced as I am with using dxr and mxr I spent large amounts of time looking here and there.

It’s hard to gauge whether or not I’m doing these searches right. My thoughts are usually that I’m doing it wrong because until recently, searching for answers never took very long. I got used to the belief that somewhere out there on the internet, someone will have had the same problem as you and will have posted the answer somewhere. Of course one of the unique things about this course is that many of the things being done now are not easily accessible on the web and perhaps does not exist at all. Keeping that in mind, it’s easier to be less judgmental, but my inefficiency still bugs me. Anyway, after ditching the CSS path, I decided that I would just debug my way to the core event so that I can gain access and change things as directly as possible. That, too, was a new lesson for me. Until now debuggers were the best tools ever, in many ways they still are, just not as important in my eyes anymore. They go to the problem I have right away, it stops where I need it to, and I can inspect every little thing until I felt ready to move on. In this case, it did allow me to go to the problem areas right away, stop where I needed it to stop, but the problem was inspecting the variables until I understood what was going on. I’ve spent so much time looking at variable names, not understanding many of the types and then searching them via mxr that I developed something like tunnel vision. I was so obsessed with the SetCursor located in nsEventStateManager and getting to know it fully that I didn’t bother looking for other options. I feel that I’ll need some time to get really used to dxr and mxr and learn how to use them effectively.

Moving on to things that I actually did, I’ve made a new branch for this particular issue and here’s the commit to that. On the push, I said it was an error with the SetCursor.

This is in fact NOT the case. The issue is actually in the line before that.

baseWindow->GetMainWidget(getter_AddRefs(widget));

For the most part, these lines of code were taken from another file although the specific section of the code was posted up on the FAQ. The problem with this line (I found this out after I pushed it to my github) is that widget ends up getting a null pointer, which then screws up when it tries to dereference it. Jesse has also taken an interest with this, and I’m pretty sure between the two of us (and all the other Windows FF hackers in our class who just haven’t really said anything or come onto IRC) will be able to solve this problem fairly quickly.

I should also mention that I’ve gotten another warning while working with this build:

I haven’t really analyzed this one yet, but it doesn’t really occur on my normal test page. This will be something I’ll look into later, but my priority I think will be getting the mouse cursor to go away (and with luck this one will go too).

————-

I mentioned in my previous post about my change in attitude with regards to IRC. After the talk Dave gave in class, I’ve noticed a significant increase in the amount of talk in #seneca. I’m really happy with the change and it’s really encouraging especially when you get stuck that you know you can ask your peers and get feedback. I hope more students will do the same. There’s definitely synergy between the people who talk on IRC, and in a way, talking on IRC is infectious.

Hopefully by tomorrow, the cause will be narrowed down and solved, if not by me, by someone else.

————-

UPDATE: So taking a further look into why we’re getting a null for the widget, I found this while debugging:

It seems that when we pass in the nsIDOMWindow *, the main widget isn’t set. I’ll probably traverse the call stack in hopes of finding out why this has happened, that or ask why this was happening on IRC.