26295 2014-07-09 08:37:08 +0000 Page source not defined 2015-03-31 15:12:37 +0000 1 1 1 Unclassified Browser Test/Tools WG WebDriver unspecified PC All RESOLVED WONTFIX P2 normal --- 20860 1 ato public-browser-tools-testing ato dburns mike public-browser-tools-testing oldest_to_newest 108817 0 ato 2014-07-09 08:37:08 +0000 The command to get page source is not yet defined in the specification. The DOM Parsing specification mentions an XMLSerializer interface which barancev says FirefoxDriver is already using: http://domparsing.spec.whatwg.org/#xmlserializer The algorithm they use for XML serialization is here: http://domparsing.spec.whatwg.org/#concept-serialize-xml It should be made clear in a note or something that the stringified DOM we return doesn't necessarily correctly reflect the active DOM as it would've been seen if inspecting the DOM through a debugger. With more tactful prose. 108820 1 1491 ato 2014-07-09 13:18:43 +0000 Created attachment 1491 Example After having examined this closer I think what we want is to call outerHTML on the documentElement instead, which “[…] represents the markup of the Element and its contents”: http://domparsing.spec.whatwg.org/#outerhtml This seems to be closer to the intended behaviour of getting the current DOM and will work on both HTML and XHTML type documents. So the spec should simply refer to the DOM Parsing spec's definition of outerHTML without making any special guarantees or promises. We should however add a note saying something along the lines of this: “Note: The details of the outerHTML serialization may be subject to user agent details. For example the sequence order of attributes on DOM nodes is unspecified.” There are also the following provisions in the spec about error handling: * Throws InvalidStateError if element in an XML document cannot be serialized to XML * Throws SyntaxError if the given string is not well-formed * Throws NoModificationAllowedError if the parent of the element is a document node The two first are theoretical in our case as there's a limited number of XHTML documents out there that are both ill-formed /and/ which modify the DOM to become invalid at runtime. The third is irrelevant in our case as we will always be calling this at the document.documentElement. We could raise an "invalid element state" in this case. 119150 2 dburns 2015-03-31 15:12:37 +0000 it was decided not to add pageSource to the spefication so closing. To get the same result the local end can do > driver.executeScript("return document.querySelector(':root').outerHTML") 1491 2014-07-09 13:18:43 +0000 2014-07-09 13:18:43 +0000 Example page_source.py text/x-python-script 857 ato ZnJvbSBzZWxlbml1bSBpbXBvcnQgd2ViZHJpdmVyCgpkcml2ZXIgPSB3ZWJkcml2ZXIuRmlyZWZv eCgpCmRyaXZlci5nZXQoImh0dHA6Ly9zbnkubm8vIikKYm9keSA9IGRyaXZlci5maW5kX2VsZW1l bnRfYnlfY3NzX3NlbGVjdG9yKCI6cm9vdCIpCgpzb3VyY2Vfd2ViZHJpdmVyID0gZHJpdmVyLnBh Z2Vfc291cmNlCnNvdXJjZV94bWxzZXJpYWxpemVyID0gZHJpdmVyLmV4ZWN1dGVfc2NyaXB0KCIi IgoJdmFyIGJvZHkgPSBhcmd1bWVudHNbMF07Cgl2YXIgc3JsID0gbmV3IFhNTFNlcmlhbGl6ZXIo KTsKCXJldHVybiBzcmwuc2VyaWFsaXplVG9TdHJpbmcoYm9keSkiIiIsIGJvZHkpCnNvdXJjZV9v dXRlcmh0bWwgPSBkcml2ZXIuZXhlY3V0ZV9zY3JpcHQoIiIiCgl2YXIgYm9keSA9IGFyZ3VtZW50 c1swXTsKCXJldHVybiBib2R5Lm91dGVySFRNTDsiIiIsIGJvZHkpCgpwcmludCAid2ViZHJpdmVy LnBhZ2Vfc291cmNlOiAlaSIgJSBsZW4oc291cmNlX3dlYmRyaXZlcikKcHJpbnQgImVsZW1lbnQu b3V0ZXJIVE1MOiAlaSIgJSBsZW4oc291cmNlX291dGVyaHRtbCkKcHJpbnQgInhtbHNlcmlhbGl6 ZXI6ICVpIiAlIGxlbihzb3VyY2VfeG1sc2VyaWFsaXplcikKCndpdGggb3Blbigic291cmNlX3dl YmRyaXZlci5odG1sIiwgInciKSBhcyBmaDoKCWZoLndyaXRlKHNvdXJjZV93ZWJkcml2ZXIpCgp3 aXRoIG9wZW4oInNvdXJjZV9vdXRlcmh0bWwuaHRtbCIsICJ3IikgYXMgZmg6CglmaC53cml0ZShz b3VyY2Vfb3V0ZXJodG1sKQoKd2l0aCBvcGVuKCJzb3VyY2VfeG1sc2VyaWFsaXplci5odG1sIiwg InciKSBhcyBmaDoKCWZoLndyaXRlKHNvdXJjZV94bWxzZXJpYWxpemVyKQoKZHJpdmVyLnF1aXQo KQo=