Hide Forgot
Issue 1694: Add support for registering namespace prefixes for XPath locators in WebDriver http://code.google.com/p/selenium/issues/detail?id=1694
I have done some investigation and testing. I discovered that with our content type of application/xhtml+xml that the doctype and xml namespace declaration is correct. I did test with the selenium IDE and noted that it would not record any sessions for cumin pages with that content type and doctype. Then I changed my local cumin instance to use a content type of text/html with a doctype of <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">. Using that combination, the Selenium IDE did record sessions against my local cumin instance. A quick glance through the UI did not yield any obvious differences is firefox 10. I still need to grab the python package for selenium and give that a try. Although changing our content type and doctype might work to get selenium working, it seems like a large and potentially risky change to make for the sake of working around what I consider to be a flaw with selenium. We could make cumin so that you can run it in either mode (choose content type/doctype at startup/config), but any selenium testing that is done that way wouldn't catch any flaws that may be related to the rendering of a page that is content type/doctype related (and could even give false positives). I can't say if there are any issues that would fall into that category, but I can say that changing the content-type and doctype definitely can affect the rendering of a page. Not sure how much we would gain by doing that.
(In reply to comment #3) > We could make cumin so that you can run it in either mode (choose content > type/doctype at startup/config), but any selenium testing that is done that way > wouldn't catch any flaws that may be related to the rendering of a page that is > content type/doctype related (and could even give false positives). I can't > say if there are any issues that would fall into that category, but I can say > that changing the content-type and doctype definitely can affect the rendering > of a page. Not sure how much we would gain by doing that. This solution: - using cumin.conf with some option to chane content type/doctype would be OK. We can then test/harvest structure and information that cumin provides. However we would still perform manual verification with this option disabled. This verification will confirm that cumin is usable for our customers.
Hi, Thank you for this change. I can: - browse cumin web: Overview/Messaging/Grid/Inventory - dump tables - submit job (browse widget) I'm happy with this change and we can make it permanent (triggered by cumin.conf?) Can you make then scratch/proper build with this patch for me? Thanks
(In reply to comment #7) > I think this may be a good candidate for a "hidden" config option. ie: I don't > think we want to leave it in the config with all sorts of comments. No actual > users should ever use this option. Is that reasonable? I agree.
Making this BZ public for the benefit of Open Source developers. Comments containing machine hostnames, etc, have been left private. Original report deals with the inability to use Selenium to do automated testing of Cumin. The trouble is related to doctype. Below is a portion of the original report. Note, the solution to this RFE is an unsupported, undocumented feature (except as mentioned in this BZ). It is not intended for end users in general, rather it is targeted to developers extending Cumin. ---- <snip discussion of internal wiki and cumin instance where Selenium succeeds with the wiki and fails with cumin> And the same method works. What is the difference? Headers: cumin: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US"> <head> ... wiki: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> ... I believe, that this bug in selenium is preventing us from browsing cumin: Issue 1694: Add support for registering namespace prefixes for XPath locators in WebDriver As you can see it is possible to click on elements by "name" or "id", but it's not possible to use xpath or find element by link text. Version-Release number of selected component (if applicable): cumin-0.1.5098-2.el5 How reproducible: 100% Steps to Reproduce: 1. Try to browse cumin web page with Python bindings for Selenium 2. Try to browse non-xhtml web page with Python bindings for Selenium Actual results: Cumin web page isn't browsable by selenium. Expected results: Cumin web page is browsable by selenium. Additional info:
This is addressed in revision 5232 on trunk. The undocumented, unsupported config for cumin.conf [web] section is: force-html-doctype: true Adding this will force a content type of text/html and will use the HTML doctype.
Verified on RHEL5, RHEL6, both i386 and x86_64, with cumin-0.1.5648-1