Mouse Lock API Test Tracker

From CDOT Wiki
Revision as of 23:21, 14 February 2012 by Cwtseng (talk | contribs)
Jump to: navigation, search

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:

Review Issues

  • 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