1

This had been logged as a bug in sourceforge though now deleted.

I'm using FireFox 3.6 with associated jssh.

I can see in Firebug that the Event Properties are not being set. I'm trying to drag and drop with code below

var mouseDownEvent = new NameValueCollection 
                         {{"button", "1"}, {"clientX", "0"}, {"clientY", "0"}};
firstStoryRow.FireEventNoWait("onmousedown", mouseDownEvent);

There are workarounds for passing these properties but not they're not nice.

Does anyone know if this is an genuine limitation within WatiN or something I'm doing wrong?

Community
  • 1
  • 1
dove
  • 20,469
  • 14
  • 82
  • 108

1 Answers1

3

This is indeed a shortcoming in the FireFox implementation. All the given parameters/values are ignored for mouse events. This should be fixed and is not that hard. I will reopen the issue on SourceForge.

To make this work you could run this code, which is what WatiN is actually doing for you:

var jscriptref = firstStoryRow.GetJavascriptElementReference();

var fireeventcode = string.Format("var event = {0}.ownerDocument.createEvent('MouseEvents');",jscriptref);

// Params for the initMouseEvent:
// 'type', bubbles, cancelable, windowObject, detail, screenX, screenY, clientX, clientY, ctrlKey, altKey, shiftKey, metaKey, button, relatedTarget )
fireeventcode += "event.initMouseEvent('mousedown', true, true, null, 0, 0, 0, 0, 0, false, false, false, false, 1, null);";
fireeventcode += string.Format("var res = {0}.dispatchEvent(event);", jscriptref);
fireeventcode += "if(res){true;}else{false;};";

// make it a NoWait call by wrapping it in a timer call.
fireeventcode = JSUtils.WrapCommandInTimer(fireeventcode);

var result = browser.Eval(fireeventcode);

If result == 'true' all went well. Hope this will help for now, but this needs to be fixed in the next release.

Jeroen

Jeroen van Menen
  • 2,418
  • 1
  • 15
  • 11
  • this works a treat, though the result is a number (assume this is because we are not calling ClientPort.WriteAndReadAsBool(command) like WatiN would). On another note, might spin into separate question, but do you know of any limitation of reading Dom properties with GetAttributeValue in FireFox. I'm taking a look at the source and only see IE specific tests that access things like offset and clientWidth. – dove Feb 15 '11 at 12:21
  • This (= original) issue is fixed in development code. Will be part of the next WatiN 2.0+ release. Regarding FF limitations. I had to balance reading attribute values and property values from DOM elements. Might be this is what makes you to wonder. – Jeroen van Menen Feb 27 '11 at 21:37