Mouse Lock API Test Tracker

Mouse Lock API Test

The Mouse Lock Test had changed considerably since the start of the MouseLock Implementation from the Fall 2011 Semester. As such, a new page is required to track the test properly. A link to the old test tracker is available here. The tests are coded by three person:

• Ching Wei Tseng (Steven)
• Raymond Hung
• Diogo Golovanevsky Monteiro

Review Issues [This list consists of older issues that were resolved]

• Rewrite DOM node removal unlocking logic to use nsIMutatationObserver humph, diogogmt
• Space, bracing, tabs, etc style nits humph
• clientX, clientY, screenX, screenY values should follow spec as per scheib's comment diogogmt
• Confirm |aEvent->lastRefPoint = nsIntPoint(bounds.width/2, bounds.height/2);| that / 2 is right diogogmt
• "nsCOMPtr<nsIContent> mMouseLockedElement; - Shouldn't this be a static member variable? Or how does the patch handle cases when the document which has iframe and mouse moves over those iframes." Probably wants a test for this case, too. diogogmt
• "nsDOMMouseLockable::ShouldLock...QI to nsINode and check IsInDoc()" diogogmt
• "nsRefPtr<nsMouseLockableRequest> request = new nsMouseLockableRequest(aSuccessCallback, aFailureCallback); -- You should store aTarget (QI'ed to nsINode or nsIContent or Element or nsIDOMEventTarget) so that when calling callback you push Cx to stack; nsCxPusher pusher: // defined in nsContentUtils.h NS_ENSURE_STATE(pusher.Push(target));" - humph
• "nsDOMMouseLockable looks like it should be cycle collectable" humph
• Break .pointer out of Navigator, and add nsIDOMMozNavigatorPointer (not sure if this name is best) as a new interface to Navigator, similar to nsIDOMMozNavigatorBattery. - humph, diogogmt
• Rename for moz* prefix. The API should be probably prefixed. So, navigator.mozPointer and all the interfaces should start with nsIDOMMoz. Similar to what webkit* is doing: - humph
  • navigator.webkitPointer.unlock();
  • navigator.webkitPointer.lock();
  • navigator.webkitPointer.isLocked();
  • document.body.addEventListener("webkitpointerlocklost", ...
  • mouseMoveEvent.webkitMovementX
  • mouseMoveEvent.webkitMovementY
• Follow discussion unfolding here for other changes: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1558.html
• Finish tests, updated to changes above.
• Update patch to trunk - humph
• Figure out why DOMMouseScroll events aren't being retargeted to the locked element

• Look into roc's suggestion from bug 722449 comment 8, namely, using getBoundingClientRect vs. GetPrimaryFrame()

• Maybe use nsStubMutationObserver instead of nsIMutationObserver?

• Extensions to the Document Interface. Add pointerLockElement attribute and exitPointerLock method - diogogmt

• Update Element interface to have requestPointerLock - diogogmt

• Dispatch pointerlockchange or pointerlockerror events instead of firing a callback when pointer gets locked - diogogmt

• Update mochitests to use new pointerlock API

• Add expect number of tests to mochitests
• Update patch to trunk

Test [as of 31st January, 2012]

This is a new list of test. The following tests will need to confirm to the new prefixes in accordance to Patchv3 of Bug 633602. Please add your name beside each test(s) you are assessing/reviewing/fixing. Once the cause for rejection is clear, indicate it by placing an X in any of the columns and optionally filling out the comments column. Indicate the action taken to resolve the issue in the action taken column. Example actions include:

1. DELETED
2. FIXED

Other actions are also acceptable where appropriate. Once fixed, please pull request to Steven's (Anachid's mouselock) branch and indicate that you've done so in the pull requested column. Ensure that you add [POST-SUBMIT] to the name of your pull request.

Num	Name	Primary Reviewer	Timing issues?	Needs Harness?	Needs focus?	Formatting issues?	Other? (Indicate in comments)	Action Taken	Pull requested?	Updated with Patchv3	Comments
Add my repo as a "remote" and ensure you have actually tested your test before sending a pull request
1	test_FullScreenHarness.html	Anachid	X (no action)	X (no action)	X (no action)	X (no action)	-	FIXED UPLOADED	Merged	X	No issues
2	file_DOMtree.html	Anachid	X (fixed)	X (fixed)	X (fixed)	X (no action)	-	FIXED UPLOADED	Merged	X	No issues
3	file_nestedFullScreen.html	Anachid	X (fixed)	X (fixed)	X (fixed)	X (no action)	-	FIXED UPLOADED	Merged	X	Had timing issues
4	file_differentDOM.html	Anachid	X (no action)	X (no action)	X (no action)	X (no action)	-	FIXED UPLOADED	Merged	X	Removed style "display: none" as this causes a crash
5	file_fullscreen.html	Anachid	X	X	X	X	-	FIXED UPLOADED	Merged	X	Test needs to completely re-done. Cases like ok(false, "Mouse locked without fullscreen mode"); will always fail! Flow of the test will causes scope problems. Currently fixing.
6	file_doubleLockCallBack.html	Anachid	X	X	X	X	-	FIXED UPLOADED	Merged	X	Re-formatted for consistencies
7	file_unlockOnUnload.html	Anachid	X	X	X	X	-	FIXED UPLOADED	Merged	X	Fixed formatting issues
8	file_exitMouseLockOnLoseFocus.html	Anachid	X	X	X	X	-	FIXED UPLOADED	Merged	X	Re-formatted for consistencies
9	test_mousePos.html	rhung					Doesn't seem like it can be done via mochitest	REMOVED			As mentioned in the previous comments, synthesizeMouse cannot be moved beyond the browser. It might need to be a litmus test.
10	file_mouselocklost.html	Anachid	X	X	X	X	-	FIXED UPLOADED	Merged	X	Removed some test that were repeating. Otherwise, it works Renamed to file_pointerLockLost.html to adhere to specification
11	file_movementXY.html	rhung	X	X	X	X	-	Tentative Fix	Merged	X	This test have multiple parts checks for mozMovementX and mozMovementY exists and their values before and after lock - FIXED checks that repeated movement does not exceed the width/height of the screen - FAILED TO RUN PROPERLY (REMOVED TENTATIVELY)
12	file_targetOutOfFocus.html	rhung Anachid	X	X	X	X (fixed)	-	FIXED UPLOADED	Merged	X	Minor changes, mostly styling. Minor timing issues detected, fixed by Anachid
13	test_mouseLockable.html	rhung	X	X	X	X	-	FIXED & RENAMED UPLOADED	Merged	X	Updated to test_MozPointerLock.html
14	file_MouseEvents.html	rhung	X	X	X	X	Leak issue might be platform specific. no longer a platform issue as it happens on linux as well - Anachid	FIXING		X	"mouseover", "mouseout", "mouseenter", "mouseleave" have been moved to another: file_cursorPosEvents.html
15	file_cursorPosEvents.html	rhung	X	X	X	X	-	FIXED UPLOADED	Merged	X	stripped out from file_MouseEvents.html
16	file_limitlessScroll.html	rhung						MERGED WITH file_movementXY			See file_movementXY.html for comment
17	file_defaultUnlock.html	rhung Anachid	X	X	X	X	read comments	FIXED UPLOADED	Merged	X	Changed ownership to Anachid - Old version was unable to synthesize the key events and is crashing Re done the entire file to ensure the events are executed properly
18	file_userPref.html	rhung						FIXED UPLOADED	Merged	X	Anachid - Changed for inconsistent format Small minor bug fix
19	file_constantXY.html	rhung	X	X	X	X	-	FIXED UPLOADED	Merged	X	Needs proper error messages, perhaps formatting issues. Test runs fine though.
20	file_pointerLockCSSDisplay.html	Anachid	X	X	X	X	-	FIXED UPLOADED	Merged	X	New test after crash reported here check that lock cannot be enabled if styling element have "display: none" set.
21	[unknown filename]	Diogogmt						[Unknown]			Test on checking that events inside a locked element are re-targeted to the element in lock.

Possible Test Cases

New Tests (not sure if it will work on mochitest, and the test will possibly fail as dave is working on this patch)

1. When there is a parent element with multiple child element, have a test to check that all mouse events fired inside the child element are suppressed and is captured by the parent element. (this may also include the scenario where there is an iframe in the parent element) - Being worked on by Diogogmt
2. A Test to check that repeated move of the mouse to a certain direction that will exceed the screen size does not break the mouselock (this may conflict with file_movementXY.html and we may need to add more test cases) - Should be in file_movementXY.html