I have not had any luck getting the reftest extension to register on windows mobile. I can generate the extension and put it in the profile directory, but it will not be used. When packaging up a 'make package' while having --enable-tests defined, I get a reftest.jar in the fennec/chrome folder. This is not what gets used, but I need to use the one in my profile vs the application directory. If I delete the reftest bits from the app directory, it never finds the stuff from the profile directory. I see this error while trying to debug it: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NO_NOINTERFACE)" location: "JS frame :: chrome://browser/content/browser.js :: <TOP_LEVEL> :: line 334: data: no]

Ok, I think I have this figured out after wrangling with it for most of a day. The issue here is the way the profile is being generated. The reftest extension is generated using that shortcut method where you make the extension ID be a text file pointing to the location of the extension code on the disk. If we change the way this is done (and we can change the way it is done because we can subclass whatever we need out of runreftest.py) then we can make profile/extensions/extensionID be a directory and copy the chrome/ components/ etc all into that directory. Doing that I was able to run reftests by hand on the device with these steps. 1. Build the profile directory as stated, copy the entire profile directory to device (copy to /tests/refprofile) 2. Copy over a set of tests just to make life easy (/tests/border-radius) 3. Start the SUT Agent on the phone 4. telnet into the agent and run this command: exec /tests/fennec/fennec.exe -profile /tests/refprofile -silent This registers extension, and sometimes this seems to hang and fennec has to be killed. Need to look into that next. Then run exec /tests/fennec/fennec.exe -profile /tests/refprofile -reftest /tests/border-radius/reftest.list And you won't actually see much of a UI on an HTC because the rendering happens too fast for the actual display to keep up, but you will see the titlebar count through the reftests and see the actual reftests run as the messages scroll by. Sometimes the phone slows down enough that you see the rendering taking place. I think this can be marked WFM if Joel is OK with changing runreftestremote to include these changes to the profile generation. Changing the profile this way should not affect the actual functioning of the test at all. I think that the code reading the extensionID file in fennec simply can't handle a windows mobile style path and that was what was causing this. However, I could never capture it in the debugger so I can't say for certain.

Ok, so somehow we're not correctly accessing the extension directory? Or it's not making it into the device?

(In reply to comment #2) > Ok, so somehow we're not correctly accessing the extension directory? Or it's > not making it into the device? So, my hypothesis was that the way the harness registers the extension was not working on fennec. The harness registers the reftest extension in the profile by putting a directory path in the text file: extensions/reftest@mozilla.org. I was thinking that this path might not be being interpretted correctly, because if you register the extension normally by creating extensions/reftest@mozilla.org as a directory and placing all the extension bits in it, then it worked. I tried to verify this again this morning, and I copied a new profile down and created the reftest@mozilla.org text file with a path that looked like "\tests\extensioncode" and it worked. So, what does it all mean? I think the harness is auto-generating the wrong path when it copies this file onto the device and is causing this headache. It seems to me that fennec can run the extension regardless of how it is registered, as long as the path is correct. I still think that we ought to just register the extension on the device in the standard manner using extensions/reftest@mozilla.org as a directory and copying the reftest extension code into that directory. So, it doesn't look like a problem with fennec at all at this point. Is this clear or am I not explaining it well?

Nope, that explanation does it for me. I was just trying to figure out if this was something we could more quickly code a fix for in the Fennec code-base, or in the test-rig. Looks like the test-rig is easiest. Joel, do you want to own this?

with the changes in the tree to support http reftest in the .jar file, this is not an issue. I suspect it will be an issue if we do not package reftest.jar (and related files) in the fennec.exe package.