HtmlUnit
The best way is to open a bug report in the sourceforge bug tracking database. Sending a bug report to the mailing list runs the risk that the bug may get lost. Putting it in the bug database guarantees that it won't. Please search the bug database to see if your bug hasn't already been reported before opening a new one.
If you know how to fix the problem then patches are gratefully accepted.
| [top] |
The best way is to open a bug report in the sourceforge bug tracking database. See the answer on bug reporting for why the database is preferred.
If you're willing to write the feature yourself, you can always send us a patch.
| [top] |
Mostly, because the main thread in HtmlUnit finishes execution before allowing background threads to run. You can do one of:
page.getEnclosingWindow().getThreadManager().joinAll(10000); just after getting the page and before manipulating it
//try 20 times to wait .5 second each for filling the page.
for (int i = 0; i < 20; i++) {
if (condition_to_happen_after_js_execution) {
break;
}
synchronized (page) {
page.wait(500);
}
}
| [top] |
Refer to "How to submit a patch"
| [top] |
HtmlUnit relies on commons-httpclient 3.1 for Cookie handling. The odds are pretty good that whatever cookie problems you're encountering already have a solution as explained in the Cookie Guide. If that doesn't help then post something to the HtmlUnit mailing list.
| [top] |
26.02.2003 16:07:05 org.apache.commons.httpclient.HttpMethodBase processRedirectResponse INFO: Redirect requested but followRedirects is disabled
It's an annoyance that I haven't figured out how to fix yet.
For a variety of reasons, I handle the redirection logic inside HtmlUnit rather than letting commons-httpclient handle it for me. It's commons-httpclient that is displaying that message because I have explicitly disabled its redirection support.
I'd like to filter out that warning message but haven't figured out a clean way of doing it. A number of people have pointed out that it's easy to disable a message if you know which logger is being used. The problem is that there isn't a way to disable the messages without knowing the logger in use.
| [top] |
There is no "roadmap" of releases. Features will be added as they are written.
Changes to the product (including new features) are implemented by volunteers in their spare time. If feature X is important to you and nobody seems to be working on it then perhaps you should consider writing it yourself and submitting a patch.
| [top] |
Submit a bunch of patches that improve the product and when the existing commiters are satisfied with your work, you will be given commit access.
As a rule of thumb, if your patches need to be "touched up" before they can be committed, then you won't be getting commit access. Refer to the page on submitting patches for an idea of what is expected.
| [top] |
Make sure (a) that you are using the latest version of HtmlUnit, and (b) that you are calling WebClient.closeAllWindows() when you are finished with your WebClient instance.
| [top] |