Re: [WebDriver] getPageSource - Does it need to be a remote end call?

getPageSource is quite popular API method, and I think it is important to
make sure it is present in (at least) the local end implementations.

Current implementations are inconsistent, and selenium documentation for
the API method includes sentence "Think of it as an artist's impression." I
think it would be an improvement to be more specific, e.g. require
implementations return document.documentElement.outerHTML.

If it *is* in the scope and within the authority of the spec to require
(MUST) that local ends implement certain functionality, then I think
specifying that local end MUST implement [get]PageSource API method would
suffice.

If otherwise it is beyond the authority/outside of the scope, then I think
keeping the remote end endpoint would help insure the functionality is
preserved. (still more specification than "artist's impression" would help)

Using the same endpoint/API method for non-web mobile case could contribute
to the "artist's impression" vision of it; for that reason I don't
necessarily think it is a good idea.

Seva

On Mon, Mar 9, 2015 at 9:01 AM, Luke Inman-Semerau <luke.semerau@gmail.com>
wrote:

> I know mobile isn't explicitly in the first draft of the spec, but
> it's slightly more complicated for the current ios and android
> implementations that I know about. There is no equivalent trivial
> execute script method that could generate the 'Native' source / tree.
>
> Although since it's not really a Page, I could see the addition of a
> new end point to handle mobile's case.
>
> On Mon, Mar 9, 2015 at 7:11 AM, David Burns <dburns@mozilla.com> wrote:
> > Hi All,
> >
> > Do we want to keep getPageSource a server side call or are we ok with
> moving
> > this into the client. The JS required to create it is rather trivial[1].
> > This could easily be moved into the local end with little disruption to
> > people's tests.
> >
> > David
> >
> > [1] driver.execute_script('return document.documentElement.outerHTML')
> >
> >
>
>

Received on Thursday, 9 April 2015 23:22:53 UTC