This should be already fixed in HtmlUnit-1.14 which is contained in recent builds. Please reopen with additional information if this is not the case.

I cannot reopen this ticket; apparently I don't have permission.

This is not fixed. If you try the test I attached you'll see - sorry I didn't clarify. With the OLD HTMLUnit, you get a ClassCastException. With the NEW HTMLUnit jar (and I grabbed the latest build of WebTest just to be sure), you get no exception at all until the failed assertion.

You can see what looks to be the proper current response come over the wire (it looks like interacting with the components works), but it doesn't seem to be handled or processed in any way - just ignored.

And so, the assertion fails.

Reopening as requested by user.

I've investigated it a bit. It appears that the AJAX request is correctly performed but that the response can't be correctly handled due lack of support for XMLDocument.getElementById when namespace specifies html. I guess that it would be ~1/2 day work to implement it therefore if you (or your developers) have time, it would be welcome.

Can you give us an idea of where in the code we might even begin to start looking?

In com.gargoylesoftware.htmlunit.javascript.host.XMLDocument#jsxFunction_getElementById

I just wanted to give you a *sort of* update - no real news to report; I created an Eclipse project with HtmlUnit but am having problems getting down to where the actual problem is. Even when debugging, I can only get execution into XMLDocument (after, say, clicking the AJAX button that should generate my new response) perhaps 1 time out of 10. Execution will just "drop off" before then, regardless of where I break, etc. Will keep playing with it in my spare time - am certainly learning a lot about the code in the process - but if you have any tips for accessing these methods via Eclipse, I'd appreciate it.

I am also very interested in getting this issue fixed. I tried the following code but I always see an "undefined" in the HTML page where the content updated by the AJAX response should appear. I used the method jsxFunction_getElementById from Document as a guideline for implementing this method but I am not sure if this is correct. What type is expected be to returned by this method?

    public Object jsxFunction_getElementById(final String id) {
     final XmlPage xmlPage = (XmlPage) getDomNodeOrDie();
     final Object xmlElement = xmlPage.getFirstByXPath("//*[@id=\"" + id + "\"]");
     if (xmlElement == null) {
     return null;
     }
     final SimpleScriptable jsElement = getScriptableFor(xmlElement);
     if (jsElement == NOT_FOUND) {
            getLog().debug("getElementById(" + id
                + ") cannot return a result as there isn't a JavaScript object for the XML element "
                + xmlElement.getClass().getName());
            return null;
        }
        return jsElement;
    }

The function should return a Scriptable and therefore this code looks ok.

Which HtmlUnit version did you patch?

I am using the latest version from SVN trunk. I just re-tested it with revision 2907.

My implementation of the method returns an object of type com.gargoylesoftware.htmlunit.javascript.host.XMLElement which contains an com.gargoylesoftware.htmlunit.xml.XmlElement in domNode. As the result of the AJAX request the com.gargoylesoftware.htmlunit.html.HtmlElement with the id matching the id of domNode will be replaced by domNode. From this it follows that for instance a HtmlSelect object (or any subtype of HtmlElement) will be replaced by a XmlElement object! It think this is not correct and will result in problems when using the HtmlPage for assertions.

My question is now what concrete subtype of SimpleScriptable the method should return?
Is it possible to "convert" from XmlElement to HtmlElement or doing some type of update writing the values from the XmlElement to the old HtmlElement?

Just for information: I solved the problem with the "undefined" in the resulting page by using BrowserVersion.FIREFOX_2.

I can't tell much without investigating myself on this issue. XmlElement can't be converted to HtmlElement. It makes sense for me when this method returns an XMLElement.

I just noticed that there is an issue for this topic also in the HtmlUnit tracker (#1854975). I think this ticket should be closed and the other one opened. I will deliver a patch which contains my implementation and an adjusted test case.

Cool, great news!

I´ve attached a patch with the implemented method jsxFunction_getElementById and the adjusted test method testResponseXML_getElementById_FF.

Perhaps the test method testResponseXML_getElementById should also be adjusted and included in the test run, but currently the first part using IE7 fails at all and the second part using FF returns a Document as the ownerDocument (line 1069) of the HTMLSpanElement instead of the expected XMLDocument. I don´t see a possibiliy to emulate FF behaviour because a HtmlPage is expected when creating a HtmlElement.

Maybe this patch should be better attached to issue #1854975 of HtmlUnit.

Thanks for the patch. It would be better to attach it to an HtmlUnit issue as this would allow other committers to review and to apply it.

I believe that some refactoring will be required to fully handle this kind of namespace correctly in xml documents without duplicating nodes.

For the Webtest library

For the htmlunit library

The patch helped, but I still couldn't get an updated response page returned. I've hacked up two patches that work - one for HtmlUnit's ClickableElement and one for Webtest's VerifyText. Both basically force the current window's enclosed page to be returned, and fix my problems. I'm submitting in case it helps anyone else, and in the hopes that you may have time one day to apply a more elegant solution than mine. :)

The issue has now been fixed in HtmlUnit. See https://sourceforge.net/tracker/?func=detail&atid=448266&aid=1964731&group_id=47038

@Suzanne:
can you open a new issue explaining your problem with verifyText? Optimal would be to have a simple example.

Done - WT-440 - in both instances, I'm getting the current window and forcing a getEnclosedPage(). It doesn't seem to adversely affect anything else.

Sorry it took me so long to get back to these, thanks for all the great work.