Return-Path: 
 <dev-return-29323-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-dev-archive@www.apache.org
Delivered-To: apmail-cordova-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 5097C10723
	for <apmail-cordova-dev-archive@www.apache.org>;
 Fri, 10 Jan 2014 23:09:21 +0000 (UTC)
Received: (qmail 22810 invoked by uid 500); 10 Jan 2014 23:09:21 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 22787 invoked by uid 500); 10 Jan 2014 23:09:21 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 22775 invoked by uid 99); 10 Jan 2014 23:09:21 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Jan 2014 23:09:21 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of pmuellr@gmail.com designates
 209.85.128.178 as permitted sender)
Received: from [209.85.128.178] (HELO mail-ve0-f178.google.com)
 (209.85.128.178)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Jan 2014 23:09:17 +0000
Received: by mail-ve0-f178.google.com with SMTP id c14so3905365vea.23
        for <multiple recipients>; Fri, 10 Jan 2014 15:08:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=s5nGuz4pVx/XkMD6zqWP4tQukCfNTT70+ACnJH6KPn8=;
        b=JnIDb6V8dlS8ZzL1EyDwtFvJF3kD2biptKZDIQ/QfS+1GNFv/OwKPM0XlGyZE/1ecK
         WmRFVgmSAiQnYn1pIIhZyitj15tomthIiChdHdFIqM7LroK3NQPw4D1EWEzst6lBTrYW
         lSkyoyacn4DZW9PP8Ya/Zsg8g355TlM9RHvGMZ+Ys7CXM9UF0hmiQ/9zr2+vvnG/QJOe
         p+d3+izxkQGh0u/dLXCG7BY19lFWi+GBtPf9P9MXb1QNYkVAWXSTQSN5XLbbAH8iOtKh
         IPoTo/p3EX5x47dkh3T8W3Y8A/vOWDxjGqAYTnhacdF8oNj4fQpqKuynB5/P1HHdRmLC
         y9eA==
MIME-Version: 1.0
X-Received: by 10.52.165.210 with SMTP id za18mr8396956vdb.20.1389395336220;
 Fri, 10 Jan 2014 15:08:56 -0800 (PST)
Received: by 10.58.214.232 with HTTP; Fri, 10 Jan 2014 15:08:56 -0800 (PST)
In-Reply-To: <JIRA.12688188.1389330826800.77983.1389379975904@arcas>
References: <JIRA.12688188.1389330826800@arcas>
	<JIRA.12688188.1389330826800.77983.1389379975904@arcas>
Date: Fri, 10 Jan 2014 18:08:56 -0500
Message-ID: 
 <CACAoQH2CRKpxQ9dYAq5-rOY7qfghKB9VmOcaGTjB=tGkOGyQUQ@mail.gmail.com>
Subject: Re: [jira] [Commented] (CB-5759) Conflict between xhr.js from Intel
 XDK and Weinre remote hook script
From: Patrick Mueller <pmuellr@gmail.com>
To: dev <dev@cordova.apache.org>
Cc: issues@cordova.apache.org
Content-Type: multipart/alternative; boundary=001a11c2048e77d53004efa5cf1d
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c2048e77d53004efa5cf1d
Content-Type: text/plain; charset=ISO-8859-1

So, there's a list of things you can try w/weinre issues.

- is the weinre server on your whitelist (for Cordova)
- try turning using --verbose and --debug when you invoke weinre, and see
if anything appears in the terminal where you run weinre
- try running the demo apps provided with weinre (link available on your
weinre server's "home page"



On Fri, Jan 10, 2014 at 1:52 PM, Jonathan Silverman (JIRA)
<jira@apache.org>wrote:

>
>     [
> https://issues.apache.org/jira/browse/CB-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868120#comment-13868120]
>
> Jonathan Silverman commented on CB-5759:
> ----------------------------------------
>
> Update: Removing "use strict" didn't fix the combo of Wenre and xhr.js.
>
> I am working on getting the developer license but its a slow process since
> I need authorization.
>
> Haven't found a way to get my self-signed certificates trusted in
> XDK/node-webkit. Even though I trusted them in Safari like you're supposed
> to.
>
> Basically means that both Ripple+ChromeDevTools and Weinre are useless to
> me right now, and for different reasons.
>
> Ripple's useless to me right now because it won't connect to any of my
> self-signed https:// endpoints. If trust is really the issue, I just need
> to get my certs into the trust store.
>
> Weinre because it doesn't work with xhr.js and I don't want to use Intel's
> getRemoteDataExt function.
>
> > Conflict between xhr.js from Intel XDK and Weinre remote hook script
> > --------------------------------------------------------------------
> >
> >                 Key: CB-5759
> >                 URL: https://issues.apache.org/jira/browse/CB-5759
> >             Project: Apache Cordova
> >          Issue Type: Bug
> >          Components: weinre
> >    Affects Versions: 2.9.0
> >         Environment: OS X, Windows
> >            Reporter: Jonathan Silverman
> >            Assignee: Patrick Mueller
> >            Priority: Critical
> >              Labels: javascript
> >
> > I have code that proves a conflict between xhr.js and weinre.
> > Cross-post from:
> https://www.html5dev-software.intel.com/viewtopic.php?f=34&t=5024
> > Adding xhr.js causes Weinre to not work, as no connectable targets
> appear. http://cl.ly/image/1L0l060e381G
> > I can confirm that xhr.js and Weinre conflict. If they are both added,
> neither work. If one is added, and not the other, it works.
> > Example:
> > {code}
> > <script src="intelxdk.js"></script>
> >   <script src="xhr.js"></script>
> >   <script type="text/javascript">
> >    /* This code is used to run as soon as Intel activates */
> >    var onDeviceReady=function(){
> >       //hide splash screen
> >       intel.xdk.device.hideSplashScreen();
> >
> >      $.get("https://dev-1-web-geo.meteostar.local").done(function(data){
> alert(data); });
> >    };
> >
>  document.addEventListener("intel.xdk.device.ready",onDeviceReady,false);
> >   </script>
> > {code}
> > Works
> > {code}
> > <script src="intelxdk.js"></script>
> >    <script src="
> http://debug-software.intel.com/target/target-script-min.js#QhYeZC6N-jY-XBnNnuS5DqN6Ti72PEzRd1Oeu_TKT9g
> "></script>
> >   <script src="xhr.js"></script>
> >   <script type="text/javascript">
> >    /* This code is used to run as soon as Intel activates */
> >    var onDeviceReady=function(){
> >       //hide splash screen
> >       intel.xdk.device.hideSplashScreen();
> >
> >      $.get("https://dev-1-web-geo.meteostar.local").done(function(data){
> alert(data); });
> >    };
> >
>  document.addEventListener("intel.xdk.device.ready",onDeviceReady,false);
> >   </script>
> > {code}
> > Doesn't
> > It doesn't seem to matter where you put the Weinre script. No matter
> what, it breaks xhr.js. It broke when included both before and after the
> xhr.js include.
> > To me, this is critical because I would like to use Weinre to debug and
> test while using xhr.js to enable cross-origin XHRs to the app.
> > This seems to affect Weinre 2.0.0-pre-HHOSN197, if that's the correct
> version number.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1.5#6160)
>



-- 
Patrick Mueller
http://muellerware.org

--001a11c2048e77d53004efa5cf1d--