Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get navigator.webdriver? #1755

Closed
Elufimov opened this issue Sep 6, 2019 · 4 comments
Closed

How to get navigator.webdriver? #1755

Elufimov opened this issue Sep 6, 2019 · 4 comments
Labels

Comments

@Elufimov
Copy link

Elufimov commented Sep 6, 2019

Summary

Webdriver getter exists in NavigatorAutomationInformation https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.NavigatorAutomationInformation.html#method.webdriver and obviously this code

 let window = window().expect("no global `window` exists");
 let navigator = window.navigator();
 let webdriver = navigator.webdriver();

will result to error

error[E0599]: no method named `webdriver` found for type `web_sys::Navigator` in the current scope
  --> src\lib.rs:27:32
   |
27 |     let webdriver = navigator.webdriver();
   |                                ^^^^^^^^^

And I cant cast Navigator to NavigatorAutomationInformation.

@Pauan
Copy link
Contributor

Pauan commented Sep 6, 2019

@Elufimov navigator.webdriver is an experimental API which has not been standardized yet. We only support standardized APIs.

We've discussed adding in support for unstable APIs, with the caveat that they can break at any time, so you can't rely upon them.

On the other hand, perhaps we can make an exception here, since it seems to be supported in all browsers, and it's just a simple bool, nothing complex.

@Elufimov
Copy link
Author

Elufimov commented Sep 6, 2019

Supporting only stable set of api is completely reasonable.

On the other hand, perhaps we can make an exception here, since it seems to be supported in all browsers, and it's just a simple bool, nothing complex.

If this is possible it would be great.

@alexcrichton
Copy link
Contributor

Seems reasonable to me to add if everything already supports it!

@alexcrichton
Copy link
Contributor

I'm going to close this in favor of #1950 which tracks how we'll be handling unstable web features (or at least not yet standardized)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants