Also sprach Martin Thomson:
> On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen <a...@sny.no> wrote:
>> Motivation:
>> To give web authors a way to infer if user agent is controlled by
>> automation, so the document can take alternate code paths when under
>> test.
>
> Can you speak more about why this is a good idea? I've poor
> experience with "this code is now under test" in the past. You
> create the risk that code becomes split into two: code that works
> as tested, and code that doesn't work because it isn't tested.
>
> (Not an objection, there's definitely value in consistency between
> implementations.)
As far as I’m aware the interface was added to the spec at the
explicit request of web authors.
I share your concern of code that gets written for “test only”
environments and that later fails to work in reality. Another
aspect is that it is also important for test environments to induce
reproducibility.
One part to mitigating instability in tests is to eliminate sources
of indeterministic variance. For example it might be reasonable
to want to replace Math.random with a PRNG with a fixed seed during
testing.
The most important characteristic of navigator.webdriver is that
it provides consistency. With navigator.webdriver there’s _one
way_ to indicate to a document that it is under test, and you no
longer need an in-house standard on how to do that.
Sufficiently advanced test environments typically have the ability
to serve entirely custom versions of web apps, but as more application
code lives in the browser (in JS), it becomes vital to have a good
standard for testing also in the web platform layer.
Without exposing this attribute on the navigator object, it becomes
hard to make decisions about code that executes before the document
finishes loading. By the point WebDriver returns control to the
user after loading a document, it may be too late to invoke
executeScript("window.isTest = true").
Whatever the web author uses navigator.webdriver for, if their test
strategy to begin with is not sound, then there is little we can
do to protect them from using the attribute as a foot-gun. They
might want to test that their site still works in production before
publishing.
In the Blink intent-to-ship thread [1] they cite anti-abuse use
cases for navigator.webdriver, where a foreign website you don’t
own could use it to block unsolicited bots/crawlers. As I also
mention in the commit message [2], this is not what the attribute
is designed for.
For better or worse (though probably the better!) the source code
of all the major browser engines are available for anyone to
scrutinise, and given the ability to compile custom browsers it is
not really a technically sound argument to make that navigator.webdriver
can realistically be used as an anti-abuse measure.
[1]
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/6GysDZCWwB8/rXbGoRohBgAJ
[2] https://reviewboard.mozilla.org/r/216250/diff/4#index_header
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
