Yes, and, yes, I would hope that this would go into a spec of some sort (perhaps Ecmascript would be a better place than a w3c spec)
Cheers, Simon On Thu, Apr 4, 2013 at 2:16 PM, Alex Rodionov <p0d...@gmail.com> wrote: > So it should be supported by vendor, correct? > > If yes, is there any chance that this would be taken care of in W3C spec? > > -- > Cheerz, > Alex Rodionov > > On Thursday, April 4, 2013 at 19:44 , Simon Stewart wrote: > > This feels like something at the level of the WebTiming APIs: it's > information that the browser should be exposing in manner that can read by > watir-webdriver via execute_script. > > Simon > > > On Thu, Apr 4, 2013 at 12:23 PM, Jari Bakken <notificati...@github.com>wrote: > > selenium-webdriver does not provide any hooks for a client library to > inject code at specific points in the loading process. I think an > implementation using execute_script for this will always be > unsatisifying, as a lot of errors would go unnoticed. Because of this, I > would prefer to have it as a third-party gem and not part of > watir-webdriver itself. > > Another approach that is worth exploring is the various Remote Debugger > protocols, see e.g. 1 <https://wiki.mozilla.org/Remote_Debugging_Protocol>, > 2<https://developers.google.com/chrome-developer-tools/docs/debugger-protocol>and > 3<https://www.webkit.org/blog/1875/announcing-remote-debugging-protocol-v1-0/>. > Of course this doesn't help with IE at the moment (although one can hope > that the protocol will be standardised in the future). > > A few other comments: > > - execute_async_script is not faster, it blocks until the specified > callback is invoked. I don't think the performance overhead of this will be > significant. > - The API should not be global (Watir.errors) but on the browser > instance (Watir::Browser#javascript_errors would be my preference). > > — > Reply to this email directly or view it on > GitHub<https://github.com/watir/watir-webdriver/issues/191#issuecomment-15891929> > . > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list Wtr-development@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development
