[ 
https://issues.apache.org/jira/browse/CB-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256537#comment-13256537
 ] 

Patrick Mueller commented on CB-535:
------------------------------------

Coupla things:

1) We're including a header from Apple in this commit.  Please make sure you 
augment the relevant LICENSE and NOTICE files appropriately.  IANAL, but I 
_believe_ you will have to augment the top-level LICENSE file, the same kind of 
way I did with weinre.  See [1].

2) Do we really need to include the header file?  I don't think we do. Or could 
we create a simpler header file from scratch - if we need a header file - to 
get around the LICENSE requirement, which is a small pain in the rear.

3) The URL referenced in the description reference Mac OS X bits, not iOS bits. 
 Specifically, WebView vs UIWebView.  Does using WebView stuff just work in 
iOS, because WebView is magically mapped, or related (via subclassing, 
whatever) to UIWebView?  Something about this smells wrong, or at least ... 
just fragile and therefore stinky.  I guess I'm asking: does this code actually 
work?  Note that we've seen things like iWebInspector which work on the 
simulator, but not on real devices.  This may be one of those things.  Also, 
which versions of iOS does this actually work on?

4) We should really come up with a bullet-proof method of ensure that people 
don't accidently ship the "debug" version.  I don't have a good answer here, 
but will note that I've seen folks deploy web apps with weinre enabled - which 
is a VERY BAD THING.  It should somehow be glaringly obvious (perhaps just by 
default) that your app is running in "debug" mode.  Once we do this, BTW, we 
can start providing all kinds of other diagnostic bits, only when you're 
running in debug mode.  Perhaps we should open a new issue on "allow a 
glaringly obvious debug enablement mode" or something?

[1] https://github.com/apache/incubator-cordova-weinre/blob/master/LICENSE#L208
                
> Add a way to log JavaScript exceptions, parse errors, and get JS stack frame 
> events (with line numbers, etc)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: CB-535
>                 URL: https://issues.apache.org/jira/browse/CB-535
>             Project: Apache Callback
>          Issue Type: Bug
>          Components: iOS
>    Affects Versions: Master
>            Reporter: Shazron Abdullah
>            Assignee: Shazron Abdullah
>             Fix For: 1.7.0
>
>
> It's possible from tests I did with my proof of concept based on this header: 
> http://opensource.apple.com/source/WebKit/WebKit-6531.9/mac/WebView/WebScriptDebugDelegate.h
> You would then set the delegate on a UIWebView subclass that overrode this 
> selector:
> {code}
> - (void)webView:(id)sender didClearWindowObject:(id)windowObject 
> forFrame:(WebFrame*)frame
> {
>     [sender setScriptDebugDelegate:myWebScriptDebugDelegate]; // e.g
> }
> {code}
> webView:didClearWindowObject:forFrame: 
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Protocols/WebFrameLoadDelegate_Protocol/Reference/Reference.html
> Of course this will involve private methods (not kosher by Apple), and might 
> not be baked in (but included in the source that is installed), and we could 
> provide instructions on how to explicitly include and enable it and output 
> warnings if it is used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to