Anurag Bhatnagar's Blog » Open Source

Processing.js Bug 1606 – Review needs work update

anurag — Wed, 14 Dec 2011 20:14:23 +0000

At the last checkpoint for this bug, my code had been reviewed by John Buckley and he had suggested some changes.

Here’s the update:

/* IE9+ Compatibility mode fix  - Bug 1606*/  

if (document.documentMode >= 9 && !document.doctype) {
  throw("DocType directive is missing. The recommended DocType in IE 9 is the HTML 5 DocType: ");
}

Tested it on IE9 to make sure it works, results below:

Update: Processing.js bugs – review needs work

anurag — Fri, 02 Dec 2011 23:03:51 +0000

Just as I was beginning to feel exceptionally lucky, my processing.js bug patches were NOT accepted in the first iteration

Check for IE9 non-HTML5 mode
filter(BLUR) issue

Their status is now changed to “review-needs-work”. And work I shall…with the benefit of comments from John Buckley I am sure it won’t take too long. Except… being only two weeks away from finals for this semester, time is of the essence, and I’m afraid work on them will be put on the back-burner for now.

I did sign up for the second part of the Open Source project though, so I’m sure I’ll get through these bugs, and adopt some more in due time

Running the Mozilla Mouse lock tests

anurag — Fri, 02 Dec 2011 22:48:14 +0000

Having written a first draft of the Mozilla mouse lock tests, I went ahead to put it all together and run them on my nightly build.

I created a new test branch on my github for the tests I had written, and added the two new files in the conventional mochi test format:

I added the two tests in the following directory: mozilla-central\dom\tests\mochitest\mouselock

Edited the Makefile.in to include my tests:

_TEST_FILES	= \
    test_isInstanceofMouselockable.html \
    test_mouseLockableHasRequiredMethods.html \

And I was ready to give them a test after merging in all the final changes from humphd.

I did a rebuild of the firefox in my new test branch after resolving merge conflicts and ran the tests:

TEST_PATH=dom/tests/mochitest/mouselock/test_isInstanceofMouselockable.html make -C ffobjdir mochitest-plain
TEST_PATH=dom/tests/mochitest/mouselock/test_mouseLockableHasRequiredMethods.html make -C ffobjdir mochitest-plain

Results are below. Final step was to send a pull request to the Mozilla MouseLock test module owner Raymond here

MouseLockable Mochi Tests – First draft of tests

anurag — Thu, 01 Dec 2011 13:03:04 +0000

Hurrah! We (mostly Prof. Humphrey) implemented Mouse Lock in Firefox! Following the specs given by W3C, we implemented Mouse Lock that will be shipped in the new version of firefox in the coming few weeks (I believe by Feb 2012).

To get a grasp what we accomplished, check out the first demos (ever, on firefox) of the mouse lock implementation:

Mouse Lock Demos

The journey lasted just a couple of weeks, but the amount of new concepts and ideas I was introduced to is amazing. This experience was the first c++ project I was a part of in a non-c++ course (of which I have had only 2). The techniques of Mozilla development, like translating specs into IDL, then coding the classes, using reference tools like MXR and DXR, and debugging in a new environment have been thrilling to learn and participate in. Of-course all of this was in concert with interacting on irc with the open source community, becoming more familiar with git and the make tool, and most of all, going through the actual process of problem solving, solo and in a team.

However, for all the work already done, about 80% of it, we have another 90% left. If the math doesn’t add up, you can take it with up Prof. Humphrey who I have quoted here.

Now the next step of writing tests begins.

I have written 3 Mochi tests for MouseLockable:

navigator.pointer (readonly) is a MouseLockable
MouseLockable has lock(), unlock(), islocked()
“The unlock method cancels the mouse lock state”

Below are the first drafts of the actual js code to test each of them, that I will refactor over the next day and push off to the MouseLockable tests module owner Raymond.

All of them passed when I tried them on Mochi Test Maker on my nightly build, after merging in the latest commits last night.

Test 1: Test to see if navigator.pointer object is of MouseLockable typ

Test 2: Test to see if MouseLockable has lock(), unlock(), islocked()

Test 3: Test to see if unlock() will cancel the lock() state in MouseLockable

Escape key event in Firefox to exit MouseLock

anurag — Sun, 20 Nov 2011 08:36:14 +0000

I’ve been working on another task in the MouseLock implementation: When ESC key is pressed, mouse lock should exit.

I’ve been going through mxr, dxr and comments in other mozilla bugs, and came up with the following code that we might need to check for the ESC key press:

nsEvent* aEvent;
  const nsKeyEvent* keyEvent = static_cast(aEvent);
  int key = keyEvent->keyCode ? keyEvent->keyCode : keyEvent->charCode;

  if (key == NS_VK_ESCAPE) {
	  fprintf(stderr, "Escape key is pressed!");
	  mIsLocked = PR_FALSE;
  }

However, it doesn’t work for now.

It builds if I insert it in the lock method for now, but I am not sure how to make it work. How will the lock/unlock method know to listen for this event? I am not sure how to implement that in c++ yet…will continue working on that.

Also, to those who need help setting up Visual Studio as their FF debugger on Windows: and https://developer.mozilla.org/en/Debugging_Mozilla_on_Windows_FAQ

—————————

Update:

Just found this piece of code:

// if we can use the keyboard (eg Ctrl+L or Ctrl+E) to open the toolbars, we
// should provide a way to collapse them too.
if (aEvent.keyCode == aEvent.DOM_VK_ESCAPE) {
   FullScreen._shouldAnimate = false;
   FullScreen.mouseoverToggle(false, true);
}

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#4027

Maybe we should also have a variable like _shouldMouseLock. On pressing ESC we can set it to false, and it could trigger the unlock() method. We could use the same variable to trigger unlock when the browser/window/tab loses focus.

Progress made on processing.js blur filter bug

anurag — Sun, 20 Nov 2011 04:28:37 +0000

It’s been a while since I reported my progress on the blur filter bug assigned to me. I made some progress last week by isolating the shifting caused in the canvas to these lines of code, using breakpoints through firebug.

After playing around for a little bit to determine the magnitude of the shift caused, I saw when I subtracted 200 from the yi and ymi values, the shifting seemed to stop. In this case, my canvas size had been (200,200). I tried changing the canvas size and the value I had to subtract from the variables to seemingly remove any shifting, and it was exactly the value of the width of the canvas. I also tried changing the height of the canvas, to not be the same as the width, and as long as I subtracted the width from those variables, the shifting seemed to be gone.

Next, I needed to find out how to refer to the width of the canvas in the code. I searched the entire processing.js file for variables containing ‘width’ and ‘canvas’, but didn’t find the correct reference. After sometime I dropped by the #processing.js channel on irc, and got my answer from pomax. I adjusted the code in the processing.js file as follows:


        // subtract canvas width to adjust for shifting canvas (bug #1392)
        yi += aImgWidth-p.externals.canvas.width;
        ymi += aImgWidth-p.externals.canvas.width;
        ym++;
      }

I ran several tests in processing js helper using different canvas values. When I was confident I had adjusted for the shifting, I started to research how to write ref tests, as pomax had suggested this should be my next step before I request a peer review.

I wound up at this page on how to write ref tests.

Step 1 – I used the following sketch to build the ref test using the generator (located in: processing-js / test / ref / ref-test-builder.html):

void setup ()
{
    size( 100, 100 );
}

void draw ()
{
    for ( int i = 0; i < 5; i++ )
    {
        fill(200);
        ellipse(25,30,35,40);
    }
    filter( BLUR );
    exit();
}

Step 2 – I put the generated code in blurFilter.pde file and in the processing-js / test / ref / directory.
Step 3 – I edited tests.js in the same directory to include the test file I just created as the first test and tagged it under ’2D’.

var tests = [
  { path: "blurFilter.pde", tags: ["2D"] },
  { path: "stretch.pde", tags: ["3D"] },
  { path: "arc-fill-crisp.pde", tags: ["2D"], epsilonOverride: 0.07 },

Step 4 – I ran index.html, selected 2D tests only, and hit start.
Step 5 – Voila! My test passed!

I also ran the test again after reverting the changes I made to adjust the shifting canvas, to make sure the test did fail before my changes. Sure enough, they did, and you can clearly see the direction in which the canvas shifted in the red pixels marking the offset in the failed test.

Committed the code here, and the final commit after all changes here. Will be requesting peer review on lighthouse next.

Screen-shots of failed and passed tests attached below:

Mine if the first test in the screenshot, check out the red mark in the failed test screenshot showing how the canvas had been shifting before.

Taking on a task in the Mouse Lock implementation

anurag — Sat, 19 Nov 2011 07:33:06 +0000

Now that I am getting a handle 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 right in as well.

One of the requirements as per the specs is that the mouse cursor not be displayed while the mouse lock is on. So clearly, this method will be called from within the lock() method which we’ve got a start on. Next idea that immediately comes to mind is to somehow use the code that implements the CSS property of ‘cursor:none’ to achieve the same goal within the window that has mouse lock enabled.

Some of my colleagues have also started on the same road and I thought I would join in and discover with them.

The first breakthrough was to stumble upon this: Bug 346690. It is the bug that implements the Cursor:None property of CSS3 in firefox. Going through the discussion in the comments of that thread gave me various clues like ‘OnHideCursor()’ method and where some of the code relating to this implementation was saved. For windows, it is found in the file: mozilla-central/widget/src/windows/nsWindow.cpp.

I found an interesting part of the code in this file here:

case eCursor_none:
      newCursor = ::LoadCursor(nsToolkit::mDllInstance, MAKEINTRESOURCE(IDC_NONE));
      break;

It seems to be the code where the properties for the cursor are set in c++. So the next step is to study it further, discuss on irc and use mxr and dxr to find more clues as to how the CSS3 cursor none property was implemented.

Finally getting down to coding the MouseLock implementation in Firefox

anurag — Sat, 19 Nov 2011 07:17:07 +0000

Continuing development on the implementation of the mouse lock bug, I’ve caught up to my fellow students and Prof. Humphrey in DPS909 by setting up the lock() method.

In my last blog post on the implementation of the MouseLock bug I mentioned I had a working build of firefox with the MouseLockable class code. Yesterday I was able to add the init() and lock() methods to the class, and re-build successfully. I also did a small test in the web console of the nightly build to test the code:

The lock() and unlock() methods are not yet implemented, but I am just changing the value of a variable to test that the code works so far, here it is:

nsresult
nsDOMMouseLockable::Init(nsIDOMWindow* aContentWindow)
{
  NS_ENSURE_ARG_POINTER(aContentWindow);
  // Hang on to the window so we can check for fullscreen
  mWindow = aContentWindow;
  return NS_OK;
}

/* void lock (); */
NS_IMETHODIMP nsDOMMouseLockable::Lock()
{
  mWindow->GetFullScreen(&mIsLocked);
  mIsLocked = PR_TRUE;
  return NS_OK;
}

/* void unlock (); */
NS_IMETHODIMP nsDOMMouseLockable::Unlock()
{
  mIsLocked = PR_FALSE;
  return NS_OK;
}

/* bool islocked (); */
NS_IMETHODIMP nsDOMMouseLockable::Islocked(bool *_retval NS_OUTPARAM)
{
  NS_ENSURE_ARG_POINTER(_retval);
  *_retval = mIsLocked;
  return NS_OK;
}

Since my last post, I pulled in code from humphd, diogogmt and rhung into my repository and merged their changes with mine.

Here is my latest commit after the merges and the lock() method code.

Tinkering with Firefox Code as a beginner – lessons learned

anurag — Wed, 09 Nov 2011 17:35:14 +0000

I was fortunate to have a good start in building firefox for the first time – except the windows style line endings error – I didn’t have any other difficulties and was able to get the build running locally quickly.

However, when I started to play around to make a change to the source code, I started getting into a lot of trouble. I have been trying to re-build firefox for about the last 4 hours, and only now got it to work again. Here’s what happened and what I learned:

For my first mod to the code, I thought I would insert a printf statement just before an error that I was getting on my build:

The error was inside a .cpp file inside my object directory. Even though it was inside my objdir, I thought it will be safe to make a change, as I was modifying a cpp file and not .obj file. I made the following change to the code, just before the line that threw the exception that I saw in my build.

if ( aInstancePtr )
      {
        nsCOMPtr factoryPtr = do_QueryInterface(aInstancePtr, &status);
        printf("My first printf! Woohoo!");
        NS_ASSERTION(factoryPtr, "Oops!  You're asking for a weak reference to an object that doesn't support that.");
        if ( factoryPtr )
          {
            status = factoryPtr->GetWeakReference(&result);
          }
        // else, |status| has already been set by |do_QueryInterface|
      }

I ran the make command again in a different objdir and waited for the new ff to build, but it kept stalling at different steps. I waited for over 30 minutes the first time, and then an hour and so on but the make command would just freeze. I tried building with slightly different config options (disabling debug and test just to build quickly), but it still kept hanging.

During this whole time that it was building and failing, I was going over the different folders and files of the source code. While the folder names and file names made some sense, opening the file and trying to understand the code made far lesser sense. Even in files I thought I will be able to follow the more code I read, I got lost very quickly.

Then, I made a small change to one of the only files I could make sense of:

\mozilla-central\browser\branding\nightly\pref\firefox-branding.js

There were no comments for the lines I changed, but they were self-explanatory – they set the default url for firefox. I changed the value of the url from about:blank to the url for Planet CDOT.

pref("startup.homepage_override_url","http://zenit.senecac.on.ca/~chris.tyler/planet/");
pref("startup.homepage_welcome_url","http://zenit.senecac.on.ca/~chris.tyler/planet/");

I made the same change in another similar file I found, but then reverted it back, because I thought this was the reason my build didn’t work (the comments had warned not to make the change):

\mozilla-central\browser\branding\nightly\locales\browserconfig.properties

# Do NOT localize or otherwise change these values
browser.startup.homepage=about:blank

I had been trying the re-build in another objdir all this while because I wanted to save the working build I had, and also preserve one of the changes I had made to a .cpp file inside it. This is when I realized how silly it is to modify a file (whichever type of file) inside the objdir – because the changes will just get overwritten with a new build. And if you don’t rebuild, the changes will never take effect. (I know….I can’t believe it took me to long to realize this )

So it was pretty straight-forward from here, I delete all the other objdirs I had created leaving the original one that worked. I ran the make command again, targeting the same objdir – the build worked, taking just 16 minutes, as most of the object files didn’t have to be compiled again.

I knew my printf change was a lost cause, but I was hoping to see if the other change I made (changing the default url) would work. I didn’t expect it to work because there was the other properties files that still clearly defined the start-up homepage as ‘about:blank’, but somehow – and you’ll just have to trust me on this (or try it for yourself) – the default url that the firefox nightly build opened with was Planet CDOT!

While going through the c++ code and the “wall” of text during the builds, I noticed a lot of interface names and class names began with the prefix ‘ns’. For example, nsIArray. I wondered if this was a remnant of the code borrowed into the Mozilla project from ‘Netscape’. I have seen the NS prefix in class names in ios code library (iPhone) too, but that was because that code was imported from NextStep, which was the second company founded by Steve Jobs after he left Apple, which was merged back into Apple when he re-joined.

So I googled to see if my assumption was right, and it turns out the stated reason for why a lot of the code has the ‘ns’ prefix is because it stands for ‘Namespace’. Strange.

Anyway, in that search I also came across this useful article:

https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide

Stay tuned for my first working printf in Mozilla code…

Making a Firefox Debug Build on Windows

anurag — Wed, 09 Nov 2011 11:51:07 +0000

As the first step towards setting up my development environment for working on the Mouse Lock Implementation on Firefox, I cloned the unofficial Mozilla Central repo, having sanitized it for windows style line-endings. I checked out a branch that I will work on for the bug.

Next step was to download the Mozilla build package for Windows, that includes most of the tools I will need to setup, configure and then debug the Mozilla code.

After installing it I ran the start-msvc10 bat file and navigated to the mozilla-central directory. I edited the .mozconfig file for the firefox debug build with the following options:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-dbg-objdir
mk_add_options MOZ_MAKE_FLAGS=-j5
ac_add_options --enable-application=browser
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-tests

The documentation I consulted for these configurations can be found here.

The next step was to just call the make command to do its thing:

time make -f client.mk build > log.txt

The log file of my make command is available here.

In an compile time of 32 minutes, my Intel i3 dual core took just 4 and a half minutes (running up to 5 processes concurrently as set in the configure options), to compile about 3680 object files (to calculate this, run this command on your objdir -> find . -name ‘*.obj’ -type f | wc -l).

I found my local firefox build in this location: \mozilla-central\ff-dbg-objdir\dist\bin

It ran with a lot of warnings, which I understand is normal, but I did get a local build of firefox in debug mode working on my machine!

Next step…diving into the code and start hacking. Stay tuned…