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 <[email protected] 
> (mailto:[email protected])> 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
> > [email protected] (mailto:[email protected])
> > http://rubyforge.org/mailman/listinfo/wtr-development
>  
> _______________________________________________
> Wtr-development mailing list
> [email protected] (mailto:[email protected])
> http://rubyforge.org/mailman/listinfo/wtr-development
>  
>  


_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development

Reply via email to