[jira] [Commented] (CB-13848) Weinre: Refused to get unsafe header "Content-Length"
[
https://issues.apache.org/jira/browse/CB-13848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349854#comment-16349854
]
Patrick Mueller commented on CB-13848:
--
It looks like the code that gets the content-length could probably be wrapped
in a try/catch, seems survivable for {{expectedContentLength}} to be
{{undefined}} in the end.
Perhaps a better story would be an easy way to toggle the network tracking off,
seems like it will be a likely source of errors as the browser change things in
this area.
In any case, it's not likely I'll get around to fixing this, I don't have time
to work on weinre anymore. Best bet is to use the existing native debuggers
for your platforms. For more info on that, see the yellow box at:
https://people.apache.org/~pmuellr/weinre/docs/latest/Home.html
> Weinre: Refused to get unsafe header "Content-Length"
> -
>
> Key: CB-13848
> URL: https://issues.apache.org/jira/browse/CB-13848
> Project: Apache Cordova
> Issue Type: Bug
>Reporter: Kristoffer Lundén
>Priority: Major
> Attachments: weinre.png
>
>
> {{Weire *2.0.0-pre-I0Z7U9OV* from [https://www.npmjs.com/package/weinre.] }}
>
> {{CORS/Ajax issue, server needs to add the header:
> }}{{Access-Control-Expose-Headers, see
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Access-Control-Expose-Headers]}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12792) Concat all the js files of weinre client into one bound
[ https://issues.apache.org/jira/browse/CB-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006864#comment-16006864 ] Patrick Mueller commented on CB-12792: -- It seems like the best approach may be to put this functionality into `weinre.build/scripts/build-client-html.py`, which seems to be the code which builds the .html file in question. > Concat all the js files of weinre client into one bound > --- > > Key: CB-12792 > URL: https://issues.apache.org/jira/browse/CB-12792 > Project: Apache Cordova > Issue Type: New Feature > Components: cordova-weinre >Affects Versions: cordova@7.0.0 > Environment: ALL >Reporter: unbug >Assignee: Patrick Mueller >Priority: Blocker > Labels: build > Original Estimate: 48h > Remaining Estimate: 48h > > It's took too long to load the client with more than 140+ js files from a > remote server, and event it done loading, the socket already lost. It's > better to have a concat bound for the client. > 1. Prove a default bound. > 2. Prove a npm build task to build the bound manually. > 3. Prove a npm build task to minify the bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12792) Concat all the js files of weinre client into one bound
[ https://issues.apache.org/jira/browse/CB-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006744#comment-16006744 ] Patrick Mueller commented on CB-12792: -- This seems like something worth fixing, for any downstream uses of weinre, and especially over slow networks. Since I'm not actively working on weinre at the moment, someone will have to provide a PR. > Concat all the js files of weinre client into one bound > --- > > Key: CB-12792 > URL: https://issues.apache.org/jira/browse/CB-12792 > Project: Apache Cordova > Issue Type: New Feature > Components: cordova-weinre >Affects Versions: cordova@7.0.0 > Environment: ALL >Reporter: unbug >Assignee: Patrick Mueller >Priority: Blocker > Labels: build > Original Estimate: 48h > Remaining Estimate: 48h > > It's took too long to load the client with more than 140+ js files from a > remote server, and event it done loading, the socket already lost. It's > better to have a concat bound for the client. > 1. Prove a default bound. > 2. Prove a npm build task to build the bound manually. > 3. Prove a npm build task to minify the bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12495) [weinre] console history not working on IE
[ https://issues.apache.org/jira/browse/CB-12495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878941#comment-15878941 ] Patrick Mueller commented on CB-12495: -- Hoping this is just a simple problem like the keycodes are different or something. How to fix it is another problem. Needs some investigation: - for browsers that work, what are the events that are triggering the history mechanism - for browsers that don't work, are those same events being triggered? If not, can we make them get triggered, or is there some alternative route to get the same history traversal semantics with whatever events are being triggered in the upsupported browsers? > [weinre] console history not working on IE > -- > > Key: CB-12495 > URL: https://issues.apache.org/jira/browse/CB-12495 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller >Priority: Critical > > From a GOOG groups message: > Moving though history with arrow keys is not working in WEINRE console for > modern browsers, but working in IE. This is happening for a while now, I'm > kind of surprised that no one cares. Is there a way to fix this? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-12495) console history not working on IE
Patrick Mueller created CB-12495: Summary: console history not working on IE Key: CB-12495 URL: https://issues.apache.org/jira/browse/CB-12495 Project: Apache Cordova Issue Type: Bug Components: weinre Reporter: Patrick Mueller Assignee: Patrick Mueller Priority: Critical >From a GOOG groups message: Moving though history with arrow keys is not working in WEINRE console for modern browsers, but working in IE. This is happening for a while now, I'm kind of surprised that no one cares. Is there a way to fix this? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-12495) [weinre] console history not working on IE
[ https://issues.apache.org/jira/browse/CB-12495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller updated CB-12495: - Summary: [weinre] console history not working on IE (was: console history not working on IE) > [weinre] console history not working on IE > -- > > Key: CB-12495 > URL: https://issues.apache.org/jira/browse/CB-12495 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller >Priority: Critical > > From a GOOG groups message: > Moving though history with arrow keys is not working in WEINRE console for > modern browsers, but working in IE. This is happening for a while now, I'm > kind of surprised that no one cares. Is there a way to fix this? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12185) problem with messageParts[0] = null
[
https://issues.apache.org/jira/browse/CB-12185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696549#comment-15696549
]
Patrick Mueller commented on CB-12185:
--
In case this may be appropriate for you, instructions on debugging web pages in
Chrome on an Android device from your Windows, Mac, or Linux computer -
https://developers.google.com/web/tools/chrome-devtools/remote-debugging
> problem with messageParts[0] = null
> ---
>
> Key: CB-12185
> URL: https://issues.apache.org/jira/browse/CB-12185
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 2.0.0
> Environment: Windows7 debugging angular2 project in ipad.
>Reporter: Clara
>Assignee: Patrick Mueller
> Labels: easyfix
>
> I had a problem trying to understand why my program is failing. When weinre
> tries to show me the error it fails, because MessageParts length is 0 or
> first element is null
> Line:
> {code:javascript}
> Console.prototype._generic = function(level, messageParts) {
> var message, messagePart, parameters, payload, _i, _len;
> message = messageParts[0].toString(); //<-- length 0 I don't know why but in
> my case is 0.
> parameters = [];
> {code}
> I fixed it with a null verification (messageParts[0]==null -> "no message")
> and now I can see my real error. Here is the difference:
> [ImageLink|https://cdn.pbrd.co/images/1QiBx9nyb.jpg]
> Files where I found the code: *Console.amd.js* and *target-script-min.js*
> P.D: I hope the version is correct. I looked at package.json of weinre (I
> downloaded it via npm) and it is written:
> "_id": "weinre@2.0.0-pre-I0Z7U9OV",
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12185) problem with messageParts[0] = null
[
https://issues.apache.org/jira/browse/CB-12185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696463#comment-15696463
]
Patrick Mueller commented on CB-12185:
--
Sounds like perhaps {{Console.log()}} was invoked, but should have been
{{Console.log("")}}.
Also, I always ask folks now if they *REALLY* need to use weinre, since native
debugging is supported on so many platforms these days. Check the yellow box
on the weinre home page for other options.
https://people.apache.org/~pmuellr/weinre/docs/latest/Home.html
> problem with messageParts[0] = null
> ---
>
> Key: CB-12185
> URL: https://issues.apache.org/jira/browse/CB-12185
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 2.0.0
> Environment: Windows7 debugging angular2 project in ipad.
>Reporter: Clara
>Assignee: Patrick Mueller
> Labels: easyfix
>
> I had a problem trying to understand why my program is failing. When weinre
> tries to show me the error it fails, because MessageParts length is 0 or
> first element is null
> Line:
> {code:javascript}
> Console.prototype._generic = function(level, messageParts) {
> var message, messagePart, parameters, payload, _i, _len;
> message = messageParts[0].toString(); //<-- length 0 I don't know why but in
> my case is 0.
> parameters = [];
> {code}
> I fixed it with a null verification (messageParts[0]==null -> "no message")
> and now I can see my real error. Here is the difference:
> [ImageLink|https://cdn.pbrd.co/images/1QiBx9nyb.jpg]
> Files where I found the code: *Console.amd.js* and *target-script-min.js*
> P.D: I hope the version is correct. I looked at package.json of weinre (I
> downloaded it via npm) and it is written:
> "_id": "weinre@2.0.0-pre-I0Z7U9OV",
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-10886) add support for support IE Mobile
Patrick Mueller created CB-10886:
Summary: add support for support IE Mobile
Key: CB-10886
URL: https://issues.apache.org/jira/browse/CB-10886
Project: Apache Cordova
Issue Type: Bug
Components: weinre
Reporter: Patrick Mueller
Assignee: Patrick Mueller
Priority: Critical
see https://github.com/apache/cordova-weinre/pull/14
It appears some Windows phone are using a User Agent that weinre doesn't catch.
{{"MSIE"}} and now {{"IEMobile"}} as well.
There's a check for just {{"MSIE"}} in the file
{{weinre.web/modules/weinre/common/HookLib.coffee}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10590) Known security vulnerabilities in dependencies of current version of express: qs@0.4.x and connect@1.x
[ https://issues.apache.org/jira/browse/CB-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144541#comment-15144541 ] Patrick Mueller commented on CB-10590: -- Thanks for the report! While I don't have time to work on this now, I'm willing to take a PR/patch. Patcher may want to look at adding qs/connect - the affected packages - directly as top-level packages, which express would then pick up (maybe, if allowed for in it's package deps semvers). May be easier at upgrading express, which is currently at 2.5 - not sure how easy upgrading to something more modern would be. > Known security vulnerabilities in dependencies of current version of express: > qs@0.4.x and connect@1.x > -- > > Key: CB-10590 > URL: https://issues.apache.org/jira/browse/CB-10590 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Spencer A Claxton >Assignee: Patrick Mueller > > There are known security vulnerabilities in dependencies of current version > of express: qs@0.4.x and connect@1.x. See > https://nodesecurity.io/advisories/qs_dos_extended_event_loop_blocking and > https://nodesecurity.io/advisories/methodOverride_Middleware_Reflected_Cross-Site_Scripting > for more detail. Can we bump express so that these vulnerabilities go away? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-10358) throwing in the towel
Patrick Mueller created CB-10358: Summary: throwing in the towel Key: CB-10358 URL: https://issues.apache.org/jira/browse/CB-10358 Project: Apache Cordova Issue Type: New Feature Components: weinre Reporter: Patrick Mueller Assignee: Patrick Mueller Priority: Trivial !http://unmaintained.tech/badge.svg! It's been over a year since the last weinre release - http://people.apache.org/~pmuellr/weinre/builds/?C=M;O=D;V=0 Even before then, the bug reports have slowed down, and I don't really have time to deal with the handful that are left anyway. So, consider this my throwing the towel. My next update may just be a badge and link to http://http://unmaintained.tech/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10281) Allow CORS
[
https://issues.apache.org/jira/browse/CB-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083080#comment-15083080
]
Patrick Mueller commented on CB-10281:
--
I didn't realize that was considered an error CORS could fix. Looking at the
CORS docs at
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS , I
suppose this could be related to "enable cross-site HTTP requests for: ...
Scripts (for unmuted exceptions)", except I have no idea what "unmuted
exceptions" are.
Some further searching found this (green note):
https://w3c.github.io/webappsec-csp/#framework-directive-source-list - W3C
Content Security Policy Level 3: "Note: Though IP address do match the grammar
above, only 127.0.0.1 will actually match a URL when used in a source
expression (see §6.1.11.2 Does url match source list? for details). The
security properties of IP addresses are suspect, and authors ought to prefer
hostnames whenever possible." So, I think ip addresses will fail CSP tests.
But there's no mention there of CORS allowing the failure to permit further
processing.
I'd like to see if we can nail down that this is actually happening. Not happy
with making changes based on guesses, without knowing what's really going on.
Some questions:
* what version of the default Android browser are you using?
* are you using CSP?
* exactly what error are you seeing, and where are you seeing it?
I'm actually a bit hesitant to fix this, as this is a security consideration as
note by the CSP ref. If you REALLY REALLY want to do this, you can use
http://xip.io/ to reference a local ip address via a DNS resolvable name, which
should fix this for you.
> Allow CORS
> --
>
> Key: CB-10281
> URL: https://issues.apache.org/jira/browse/CB-10281
> Project: Apache Cordova
> Issue Type: New Feature
> Components: weinre
>Affects Versions: 3.5.0
>Reporter: Miquel
>Assignee: Patrick Mueller
>Priority: Minor
> Labels: easyfix, features, patch
> Fix For: Master
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> I've created a pull request to allow CORS:
> https://github.com/apache/cordova-weinre/pull/10:
> {noformat}
> diff --git a/weinre.server/lib/weinre.js b/weinre.server/lib/weinre.js
> index a4ca11c..036df78 100644
> --- a/weinre.server/lib/weinre.js
> +++ b/weinre.server/lib/weinre.js
> @@ -133,6 +133,11 @@ startServer = function() {
>});
>app.use(express.favicon(favIcon));
>app.use(jsonBodyParser());
> + app.use(function(req, res, next) {
> +res.header("Access-Control-Allow-Origin", "*");
> +res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With,
> Content-Type, Accept");
> +next();
> + });
>app.all(/^\/ws\/client(.*)/, function(request, response, next) {
> var uri;
> uri = request.params[0];
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10281) Allow CORS
[
https://issues.apache.org/jira/browse/CB-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076168#comment-15076168
]
Patrick Mueller commented on CB-10281:
--
I don't understand your description. What file can you not download with the
standard weinre, but can with your CORS changes? I'm trying to understand if
this is something everyone needs, if it's a safe change to make, etc.
In terms of the actual changes, I can make them, no worries. Just wanted to
point out where the actual source was.
> Allow CORS
> --
>
> Key: CB-10281
> URL: https://issues.apache.org/jira/browse/CB-10281
> Project: Apache Cordova
> Issue Type: New Feature
> Components: weinre
>Affects Versions: 3.5.0
>Reporter: Miquel
>Assignee: Patrick Mueller
>Priority: Minor
> Labels: easyfix, features, patch
> Fix For: Master
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> I've created a pull request to allow CORS:
> https://github.com/apache/cordova-weinre/pull/10:
> {noformat}
> diff --git a/weinre.server/lib/weinre.js b/weinre.server/lib/weinre.js
> index a4ca11c..036df78 100644
> --- a/weinre.server/lib/weinre.js
> +++ b/weinre.server/lib/weinre.js
> @@ -133,6 +133,11 @@ startServer = function() {
>});
>app.use(express.favicon(favIcon));
>app.use(jsonBodyParser());
> + app.use(function(req, res, next) {
> +res.header("Access-Control-Allow-Origin", "*");
> +res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With,
> Content-Type, Accept");
> +next();
> + });
>app.all(/^\/ws\/client(.*)/, function(request, response, next) {
> var uri;
> uri = request.params[0];
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10281) Allow CORS
[
https://issues.apache.org/jira/browse/CB-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075280#comment-15075280
]
Patrick Mueller commented on CB-10281:
--
Thanks for the PR. Coupla things:
* the source is CoffeeScript; the original source location of your modification
is here:
https://github.com/apache/cordova-weinre/blob/master/weinre.server/lib-src/weinre.coffee#L139
* weinre already handles CORS requests for things that CORS requests are
absolutely required for; see:
https://github.com/apache/cordova-weinre/blob/master/weinre.server/lib-src/HttpChannelHandler.coffee#L46
and
https://github.com/apache/cordova-weinre/blob/master/weinre.server/lib-src/HttpChannelHandler.coffee#L141
So, not sure what this patch would do - presumably allow downloading of the
weinre static resources via CORS - the existing code just handles XHR requests
via CORS. Is there some reason you need this?
> Allow CORS
> --
>
> Key: CB-10281
> URL: https://issues.apache.org/jira/browse/CB-10281
> Project: Apache Cordova
> Issue Type: New Feature
> Components: weinre
>Affects Versions: 3.5.0
>Reporter: Miquel
>Assignee: Patrick Mueller
>Priority: Minor
> Labels: easyfix, features, patch
> Fix For: Master
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> I've created a pull request to allow CORS:
> https://github.com/apache/cordova-weinre/pull/10:
> {noformat}
> diff --git a/weinre.server/lib/weinre.js b/weinre.server/lib/weinre.js
> index a4ca11c..036df78 100644
> --- a/weinre.server/lib/weinre.js
> +++ b/weinre.server/lib/weinre.js
> @@ -133,6 +133,11 @@ startServer = function() {
>});
>app.use(express.favicon(favIcon));
>app.use(jsonBodyParser());
> + app.use(function(req, res, next) {
> +res.header("Access-Control-Allow-Origin", "*");
> +res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With,
> Content-Type, Accept");
> +next();
> + });
>app.all(/^\/ws\/client(.*)/, function(request, response, next) {
> var uri;
> uri = request.params[0];
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-7248) weinre do not work using hash(#) in location
[ https://issues.apache.org/jira/browse/CB-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller updated CB-7248: Priority: Major (was: Blocker) > weinre do not work using hash(#) in location > > > Key: CB-7248 > URL: https://issues.apache.org/jira/browse/CB-7248 > Project: Apache Cordova > Issue Type: Bug > Components: weinre > Environment: mac，ubuntu >Reporter: Hans Chan >Assignee: Patrick Mueller > > i am using weinre (2.0.0-pre-HH0SN197)，installed by npm。 > when i open a url like "http://myip/index"; in my mobile device, it works > perfect; > but with a location "http://myip/index#hash";, the debug client can not find > the target. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9817) Referenced express version of weinre npm-package is vulnerable
[ https://issues.apache.org/jira/browse/CB-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961405#comment-14961405 ] Patrick Mueller commented on CB-9817: - I have very little time to work on weinre these days. If someone else wants to pick this up, let me know. > Referenced express version of weinre npm-package is vulnerable > -- > > Key: CB-9817 > URL: https://issues.apache.org/jira/browse/CB-9817 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Christian Kühl >Assignee: Patrick Mueller > Fix For: 2.0.0 > > > Affects weinre nom-package with version 2.0.0-pre-I0Z7U9OV. > Please update to a patched version of express if possible. > https://nodesecurity.io/advisories/express-no-charset-in-content-type-header -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9297) Cordova CLI fails silently with iojs
[ https://issues.apache.org/jira/browse/CB-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725897#comment-14725897 ] Patrick Mueller commented on CB-9297: - Added a comment to the `node-xcode` issue re: coming change to node 4 on sync/async forked `send()` callback. But I think that's a red herring in this case. Not seeing anywhere in the code I'm running for the broken example, that a `fork()` is happening. > Cordova CLI fails silently with iojs > > > Key: CB-9297 > URL: https://issues.apache.org/jira/browse/CB-9297 > Project: Apache Cordova > Issue Type: Bug > Components: CLI >Affects Versions: 5.1.2 > Environment: Cordova CLI: 5.1.1 (this isn't in your version list > above) > ios-deploy version: 1.7.0 > ios-sim version: 4.1.1 > OS: Mac OS X Yosemite > Xcode version: Xcode 6.4 Build version 6E35b > node (iojs): 1.8.1 >Reporter: Robert Churchill > > Running most build tasks (emulate, run, build) for ios when node is replaced > by iojs results in the build failing silently. Example: > $ cordova build ios > $ > $ cordova build ios --verbose > Generating config.xml from defaults for platform "ios" > Calling plugman.prepare for platform "ios" > Preparing ios project > ... > [seems to finish prepare (but without executing hooks) then exits] > ... > $ > Not sure if you plan to support iojs, but at least this report might help > someone googling. Unfamiliar with the Apache JIRA system so apologies if this > report is in the wrong place etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9297) Cordova CLI fails silently with iojs
[
https://issues.apache.org/jira/browse/CB-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725501#comment-14725501
]
Patrick Mueller commented on CB-9297:
-
Thanks Julien, was able to reproduce with your example.
Agree with Robert that lack of a {{.catch()}} at the end of the {{.then()}}
chains smells fishy. Tried instrumenting the referenced module, was unable to
see my instrumented output on the failure condition. May be being caught by
someone else and thrown away, or perhaps there's a similar problem, that's
happening earlier, dunno.
Happy to look into it more, if anyone has any more hints.
> Cordova CLI fails silently with iojs
>
>
> Key: CB-9297
> URL: https://issues.apache.org/jira/browse/CB-9297
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 5.1.2
> Environment: Cordova CLI: 5.1.1 (this isn't in your version list
> above)
> ios-deploy version: 1.7.0
> ios-sim version: 4.1.1
> OS: Mac OS X Yosemite
> Xcode version: Xcode 6.4 Build version 6E35b
> node (iojs): 1.8.1
>Reporter: Robert Churchill
>
> Running most build tasks (emulate, run, build) for ios when node is replaced
> by iojs results in the build failing silently. Example:
> $ cordova build ios
> $
> $ cordova build ios --verbose
> Generating config.xml from defaults for platform "ios"
> Calling plugman.prepare for platform "ios"
> Preparing ios project
> ...
> [seems to finish prepare (but without executing hooks) then exits]
> ...
> $
> Not sure if you plan to support iojs, but at least this report might help
> someone googling. Unfamiliar with the Apache JIRA system so apologies if this
> report is in the wrong place etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9297) Cordova CLI fails silently with iojs
[
https://issues.apache.org/jira/browse/CB-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725309#comment-14725309
]
Patrick Mueller commented on CB-9297:
-
OK, so I think I figured out the cordova hooks thing (neat!). In my default
project (hello sample), I added two hooks, for {{before_build}} and
{{after_build}}:
{noformat}
$ cat hooks/before_build/log.js
#!/usr/bin/env node
console.log(' before build')
$ cat hooks/after_build/log.js
#!/usr/bin/env node
console.log('- after build')
{noformat}
When I do a {{cordova build}}, I see the following output bracket the output of
the build:
{noformat}
Running command: /Users/pmuellr/tmp/hello/hooks/before_build/log.js
/Users/pmuellr/tmp/hello
before build
Running command: /Users/pmuellr/tmp/hello/platforms/ios/cordova/build
... many lines elided ...
** BUILD SUCCEEDED **
Running command: /Users/pmuellr/tmp/hello/hooks/after_build/log.js
/Users/pmuellr/tmp/hello
- after build
{noformat}
Works fine for me on Mac Yosemite, with io.js 2.4.0 and 3.2.0, cordova 5.2.0
Was it some code in your hook that caused the reference line in {{platform.js}}
to be executed? Could you provide an example.
> Cordova CLI fails silently with iojs
>
>
> Key: CB-9297
> URL: https://issues.apache.org/jira/browse/CB-9297
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 5.1.2
> Environment: Cordova CLI: 5.1.1 (this isn't in your version list
> above)
> ios-deploy version: 1.7.0
> ios-sim version: 4.1.1
> OS: Mac OS X Yosemite
> Xcode version: Xcode 6.4 Build version 6E35b
> node (iojs): 1.8.1
>Reporter: Robert Churchill
>
> Running most build tasks (emulate, run, build) for ios when node is replaced
> by iojs results in the build failing silently. Example:
> $ cordova build ios
> $
> $ cordova build ios --verbose
> Generating config.xml from defaults for platform "ios"
> Calling plugman.prepare for platform "ios"
> Preparing ios project
> ...
> [seems to finish prepare (but without executing hooks) then exits]
> ...
> $
> Not sure if you plan to support iojs, but at least this report might help
> someone googling. Unfamiliar with the Apache JIRA system so apologies if this
> report is in the wrong place etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9297) Cordova CLI fails silently with iojs
[ https://issues.apache.org/jira/browse/CB-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725278#comment-14725278 ] Patrick Mueller commented on CB-9297: - Sorry for being a n00b, but I'm not familiar with cordova much anymore, so need a simple example to reproduce the problem. Can I repro with the default sample? And then just add a plugin? Can you provide an example of a plugin that's not working for you? > Cordova CLI fails silently with iojs > > > Key: CB-9297 > URL: https://issues.apache.org/jira/browse/CB-9297 > Project: Apache Cordova > Issue Type: Bug > Components: CLI >Affects Versions: 5.1.2 > Environment: Cordova CLI: 5.1.1 (this isn't in your version list > above) > ios-deploy version: 1.7.0 > ios-sim version: 4.1.1 > OS: Mac OS X Yosemite > Xcode version: Xcode 6.4 Build version 6E35b > node (iojs): 1.8.1 >Reporter: Robert Churchill > > Running most build tasks (emulate, run, build) for ios when node is replaced > by iojs results in the build failing silently. Example: > $ cordova build ios > $ > $ cordova build ios --verbose > Generating config.xml from defaults for platform "ios" > Calling plugman.prepare for platform "ios" > Preparing ios project > ... > [seems to finish prepare (but without executing hooks) then exits] > ... > $ > Not sure if you plan to support iojs, but at least this report might help > someone googling. Unfamiliar with the Apache JIRA system so apologies if this > report is in the wrong place etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9297) Cordova CLI fails silently with iojs
[
https://issues.apache.org/jira/browse/CB-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14724532#comment-14724532
]
Patrick Mueller commented on CB-9297:
-
I'm not sure what "_seems to finish prepare (but without executing hooks) then
exits_" means. Could you elaborate?
I just tried running {{cordova build}} and {{cordova emulate}} with io.js 1.8.1
(originally reported version with error), and with iojs 3.2.0 (latest as of
this comment) with cordova 5.2.0, and everything appeared to run correctly, to
me. But I'm a bit rusty - perhaps I'm missing something (like, what the hooks
are).
> Cordova CLI fails silently with iojs
>
>
> Key: CB-9297
> URL: https://issues.apache.org/jira/browse/CB-9297
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 5.1.2
> Environment: Cordova CLI: 5.1.1 (this isn't in your version list
> above)
> ios-deploy version: 1.7.0
> ios-sim version: 4.1.1
> OS: Mac OS X Yosemite
> Xcode version: Xcode 6.4 Build version 6E35b
> node (iojs): 1.8.1
>Reporter: Robert Churchill
>
> Running most build tasks (emulate, run, build) for ios when node is replaced
> by iojs results in the build failing silently. Example:
> $ cordova build ios
> $
> $ cordova build ios --verbose
> Generating config.xml from defaults for platform "ios"
> Calling plugman.prepare for platform "ios"
> Preparing ios project
> ...
> [seems to finish prepare (but without executing hooks) then exits]
> ...
> $
> Not sure if you plan to support iojs, but at least this report might help
> someone googling. Unfamiliar with the Apache JIRA system so apologies if this
> report is in the wrong place etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-9377) weinre still referencing path.existsSync()
Patrick Mueller created CB-9377:
---
Summary: weinre still referencing path.existsSync()
Key: CB-9377
URL: https://issues.apache.org/jira/browse/CB-9377
Project: Apache Cordova
Issue Type: Bug
Components: weinre
Reporter: Patrick Mueller
Assignee: Patrick Mueller
User reported runtime error in weinre, presumably with a relatively new version
of node.
{noformat}
if (!path.existsSync(fileName)) return properties;
^
-
error: TypeError: undefined is not a function
-
stack:
cli.coffee:66 - getDotWeinreServerProperties()
{noformat}
References of {{path.exists*()}} will need to be changed to {{fs.exist*()}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-1797) Show URL or name of the style sheet when hovering over an HTML element
[ https://issues.apache.org/jira/browse/CB-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513897#comment-14513897 ] Patrick Mueller commented on CB-1797: - Just following the links here, not clear whether a latest dev-tools update would fix this or not. But if the href IS in the CSSOM, then it would be possible to hack it, even if dev-tools didn't do anything with it. Hacks typically cost more :-) > Show URL or name of the style sheet when hovering over an HTML element > -- > > Key: CB-1797 > URL: https://issues.apache.org/jira/browse/CB-1797 > Project: Apache Cordova > Issue Type: New Feature > Components: weinre > Environment: Mac OSX 10.7.5 >Reporter: John Fossey >Assignee: Patrick Mueller > Labels: features, stylesheet, url > > When using the elements feature of Weinre, I would like to be able to see the > URL or name of the style sheet the HTML element is using when I hover over > it. For more details and screenshots, see the "Using Elements in Weinre > Doesn't Display Stylesheets" post in the Weinre Google Group at > https://groups.google.com/forum/?fromgroups#!forum/weinre. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-91) update to latest Web Inspector
[ https://issues.apache.org/jira/browse/CB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513893#comment-14513893 ] Patrick Mueller commented on CB-91: --- Sam, Sorry to report that no, weinre is not being maintained well any more. I'm not able to provide much support any more, since weinre is no longer part of my job description. And only a few people have helped out with support issues over the years. I suspect it may be easier to update to the latest dev tools at this point - back when I was still supporting weinre it was changing frequently, but I suspect the interface changes now are rather infrequent. Pretty sure I'd go with blink over webkit, given the choice. Luckily, there's less and less need for weinre these days - I've put links in the docs to the latest great debuggers available for some of the popular mobile platforms - http://people.apache.org/~pmuellr/weinre/docs/latest/ > update to latest Web Inspector > -- > > Key: CB-91 > URL: https://issues.apache.org/jira/browse/CB-91 > Project: Apache Cordova > Issue Type: New Feature > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller > > from https://github.com/phonegap/weinre/issues/36 > The version of Web Inspector we're pulling is pretty old, prolly time to > update. Some thoughts: > * should probably figure out which revisions of Web Inspector are being used > for stable Chrome builds, and use those as potential pull targets > * the sourcemap JavaScript debug stuff seems to be coming on line right now, > might want to wait for it to be in a usable state before pulling, in case > folks want to try to hack some JavaScript debug ala > [Aardwolf|http://lexandera.com/aardwolf/] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8738) can't load weinre script dynamically
[ https://issues.apache.org/jira/browse/CB-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378494#comment-14378494 ] Patrick Mueller commented on CB-8738: - I'm going to leave this open, to add a note in the doc about overriding the server and id with globals on the `window` object. Doesn't appear to be in the doc. > can't load weinre script dynamically > > > Key: CB-8738 > URL: https://issues.apache.org/jira/browse/CB-8738 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Christian F >Assignee: Patrick Mueller >Priority: Minor > > The weinre target application is connecting nicely to the weinre-server, in > the case the script is included in the html head. > But I would like to load the script dinamically via ajax with jquery. > After loading I see the client in polling the weinre server with calls like > http://localhost:8081/ws/target/t-21. > But I cant connect to that session. I am sure, that I use the same session id > on the target client and the debuging client. > Could you please fix it, so that the weinre-library can be loaded dynamically. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-8738) can't load weinre script dynamically
[ https://issues.apache.org/jira/browse/CB-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller updated CB-8738: Priority: Minor (was: Major) > can't load weinre script dynamically > > > Key: CB-8738 > URL: https://issues.apache.org/jira/browse/CB-8738 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Christian F >Assignee: Patrick Mueller >Priority: Minor > > The weinre target application is connecting nicely to the weinre-server, in > the case the script is included in the html head. > But I would like to load the script dinamically via ajax with jquery. > After loading I see the client in polling the weinre server with calls like > http://localhost:8081/ws/target/t-21. > But I cant connect to that session. I am sure, that I use the same session id > on the target client and the debuging client. > Could you please fix it, so that the weinre-library can be loaded dynamically. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8738) can't load weinre script dynamically
[ https://issues.apache.org/jira/browse/CB-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14377974#comment-14377974 ] Patrick Mueller commented on CB-8738: - I'll need to understand what the problem is, before it can be fixed. Your issue sounds suspiciously similar to one recently reported in the weinre google group: https://groups.google.com/forum/#!topic/weinre/n5J82H6Cb3s I'm wondering if weinre isn't able to calculate the URL to the server the way it usually does. Which means you can try overriding the values, as described in the post above. > can't load weinre script dynamically > > > Key: CB-8738 > URL: https://issues.apache.org/jira/browse/CB-8738 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Christian F >Assignee: Patrick Mueller > > The weinre target application is connecting nicely to the weinre-server, in > the case the script is included in the html head. > But I would like to load the script dinamically via ajax with jquery. > After loading I see the client in polling the weinre server with calls like > http://localhost:8081/ws/target/t-21. > But I cant connect to that session. I am sure, that I use the same session id > on the target client and the debuging client. > Could you please fix it, so that the weinre-library can be loaded dynamically. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8418) Reload elements tab
[ https://issues.apache.org/jira/browse/CB-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305072#comment-14305072 ] Patrick Mueller commented on CB-8418: - >From memory, I think weinre is actually supposed to track the DOM changes. It >may be something catastrophic has occurred, and the updates didn't all make >it. Let me poke around, because I think this issue has come up before. You mention Android 4.1 specifically, so I assume you're using weinre because the real remote debug is not available to you; but just in case, I've put links to the latest built-in remote debuggers for some platforms here: http://people.apache.org/~pmuellr/weinre/docs/latest/ > Reload elements tab > --- > > Key: CB-8418 > URL: https://issues.apache.org/jira/browse/CB-8418 > Project: Apache Cordova > Issue Type: New Feature > Components: weinre >Reporter: Christopher Decoster >Assignee: Patrick Mueller >Priority: Minor > > When previewing the DOM in the elements tab there is no feature to reload the > current elements in the dom. Quite often things are added to the dom > programmatically. > The only way to see this reflected in the Elements tab is to hit remote > select toggle your target again, and then return to the elements tab. > Live reloading on changes would probably have its cost. However just having a > 'reload' button to update the elements tab would save a lot of clicking > around. > Cheers, this project has saved me many hours in debugging Android 4.1 issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8359) JavaScript errors do not show in console
[
https://issues.apache.org/jira/browse/CB-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290865#comment-14290865
]
Patrick Mueller commented on CB-8359:
-
Also, there may be some special error handling support for the callback-y
things that I hook, like timers, XHRs, etc. Because weinre is in the loop
there. ALWAYS RUN YOUR CODE IN A setTimeout(), MAYBE :-)
> JavaScript errors do not show in console
>
>
> Key: CB-8359
> URL: https://issues.apache.org/jira/browse/CB-8359
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Raymond Camden
>Assignee: Patrick Mueller
>
> Given a simple error:
> function blah() {
>doX(); // doX isn't defined
> }
> The error does not show up in the console. Other things, like basic
> console.log('foo') messages show up fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8359) JavaScript errors do not show in console
[
https://issues.apache.org/jira/browse/CB-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290856#comment-14290856
]
Patrick Mueller commented on CB-8359:
-
I think I had experimental support this at one point, via {{window.onerror}} or
some such. Some quick experiments running weinre on the built-in demo on my
laptop, and using chrome dev tools on the demo web page to monkey with things,
this no longer works. I know there were some problems with this in the past,
the support I might have had may have actually caused other issues.
Off top of my head, I don't know how to catch these kinds of things, but if you
know of a way to do that, we can wire it into a console.log invocation.
> JavaScript errors do not show in console
>
>
> Key: CB-8359
> URL: https://issues.apache.org/jira/browse/CB-8359
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Raymond Camden
>Assignee: Patrick Mueller
>
> Given a simple error:
> function blah() {
>doX(); // doX isn't defined
> }
> The error does not show up in the console. Other things, like basic
> console.log('foo') messages show up fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8315) "Object" doesn't display its attributes
[
https://issues.apache.org/jira/browse/CB-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278935#comment-14278935
]
Patrick Mueller commented on CB-8315:
-
I just tried the following, where lines prefixed with ">" are things I entered,
other lines were the output in the console.
{noformat}
> x = 1
> console.log(x)
1
> x = {a: "1"}
> console.log(x)
Object
a: "1"
__proto__: —
{noformat}
Appears to work for "basic" objects. So, still thinking that you are sending
console.log() either a native object, or perhaps an object with some properties
that are natives that the weinre code can't handle, but that can survive a
JSON.stringification().
> "Object" doesn't display its attributes
> ---
>
> Key: CB-8315
> URL: https://issues.apache.org/jira/browse/CB-8315
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Firefox nightly on MacOSX Yosemite
>Reporter: _kud
>Assignee: Patrick Mueller
>Priority: Blocker
>
> When you console.log() an object, you can see the type "Object". But when you
> click on the arrow, it doesn't display the attributes:
> ```
> 2015-01-15T14:23:53.342Z weinre:
> NetworkNotify.setInitialContent([35,"{\"channel\":{\"name\":\"Euronews\"},\"program\":{\"progress\":21.6667,\"startAt\":\"15:23\",\"endAt\":\"15:27\",\"title\":\"Le
>
> mag\",\"genre\":\"Magazine\",\"subgenre\":\"D\\u00e9couverte\"}}","XHR",null])
> 2015-01-15T14:23:53.342Z weinre:
> NetworkNotify.didFinishLoading([35,1421331832.673,null])
> 2015-01-15T14:23:53.346Z weinre:
> --
> 2015-01-15T14:23:53.346Z weinre: POST /c-48 [request]
> 2015-01-15T14:23:53.346Z weinre:WeinreClientCommands.logError(["weinre:
> invocation exception on Object.childNodeInserted(): TypeError: parent is
> undefined",null])
> 2015-01-15T14:23:53.346Z weinre: client c-48: weinre: invocation exception on
> Object.childNodeInserted(): TypeError: parent is undefined
> ```
> I had to do console.log(JSON.stringify(Object)) to get a correct display.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8313) How to know when the connection is ready?
[
https://issues.apache.org/jira/browse/CB-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278923#comment-14278923
]
Patrick Mueller commented on CB-8313:
-
One of my focus areas for weinre was how to make it easy to discover/start a
debugger session, and I think weinre does a pretty good job there.
Older versions of Safari, which required various sorts of menu clicks to
launch, closed unconnected windows, etc, did a pretty poor job of it. It was
almost not worth using, it was so painful to me. Perhaps it's fixed these
days, I dunno. If not, maybe someday.
I'm hoping the firefox "remote debugging for everything" story ends up being a
useful for users, and will perhaps even drive the vendors (Google/Apple/MS/etc)
to work together to create a nice environment for multi-platform developers.
> How to know when the connection is ready?
> -
>
> Key: CB-8313
> URL: https://issues.apache.org/jira/browse/CB-8313
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: MacOSX latest Yosemite, Firefox latest Nightly
> Weinre 2.0.0-pre-I0Z7U9OV
>Reporter: _kud
>Assignee: Patrick Mueller
>Priority: Blocker
>
> As I can see, the project redefines console. Though, when the scope is
> private or/and used with browserify, the console.log doesn't work. I have no
> return.
> Though, if I do:
> ```
> video.addEventListener( 'play', function() {
> console.log( 'hello' )
> })
> ```
> in my code, it seems to work.
> Do you have any idea why?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8315) "Object" doesn't display its attributes
[
https://issues.apache.org/jira/browse/CB-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278803#comment-14278803
]
Patrick Mueller commented on CB-8315:
-
I'm pretty sure the you posted are not relevant to the console.log() issue of
just displaying an empty Object. But thanks for posting them, sometimes such
messages are relevant!!!
Weinre runs in user-land JavaScript code, and doesn't have complete access to
all of private API that Web Inspector uses to be able to display properties of
objects. I'm guessing in this case that the object in question is some kind of
native object, which the user-land weinre introspection code can't peek into,
but it happens that it's possible to produce a JSON representation of the
object.
What object is it that you're trying to display? Is it possible to reproduce
this with just the sample/demo web page supplied by the server?
> "Object" doesn't display its attributes
> ---
>
> Key: CB-8315
> URL: https://issues.apache.org/jira/browse/CB-8315
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Firefox nightly on MacOSX Yosemite
>Reporter: _kud
>Assignee: Patrick Mueller
>Priority: Blocker
>
> When you console.log() an object, you can see the type "Object". But when you
> click on the arrow, it doesn't display the attributes:
> ```
> 2015-01-15T14:23:53.342Z weinre:
> NetworkNotify.setInitialContent([35,"{\"channel\":{\"name\":\"Euronews\"},\"program\":{\"progress\":21.6667,\"startAt\":\"15:23\",\"endAt\":\"15:27\",\"title\":\"Le
>
> mag\",\"genre\":\"Magazine\",\"subgenre\":\"D\\u00e9couverte\"}}","XHR",null])
> 2015-01-15T14:23:53.342Z weinre:
> NetworkNotify.didFinishLoading([35,1421331832.673,null])
> 2015-01-15T14:23:53.346Z weinre:
> --
> 2015-01-15T14:23:53.346Z weinre: POST /c-48 [request]
> 2015-01-15T14:23:53.346Z weinre:WeinreClientCommands.logError(["weinre:
> invocation exception on Object.childNodeInserted(): TypeError: parent is
> undefined",null])
> 2015-01-15T14:23:53.346Z weinre: client c-48: weinre: invocation exception on
> Object.childNodeInserted(): TypeError: parent is undefined
> ```
> I had to do console.log(JSON.stringify(Object)) to get a correct display.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8313) How to know when the connection is ready?
[
https://issues.apache.org/jira/browse/CB-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278789#comment-14278789
]
Patrick Mueller commented on CB-8313:
-
Sorry, I was suggesting YOU can queue up your messages, and then set a timeout
to log them to the console. You are correct that I can't really do that from
weinre, unless I provided some sort of setting for that.
It's a complex situation; you can actually connect/disconnect from your weinre
target from within the same browser client session (ie, the browser session
showing the weinre/web inspector user interface), or across multiple browser
client sessions (across multiple machines even). Ideally, you'd want to
"queue" all the messages generated while not connected, and then when
connected, display them all. Only the first connection after having no
connections would see the messages; connect with another client session a
second later, they'd see none of the queued messages.
I'm making use of the webkit web inspector protocol for generating message
events, which given the communication pattern between debug targets and
clients, means there are cases for loss. We'd need to come up with a
completely different protocol for dealing with console messages statefully.
Which is a lot of non-trivial code.
Given the current state of debuggers in iOS and Android, that can be used
instead of weinre, I can't really justify investing in this myself. If you -
or anyone else - wants to give it a go, I'm happy to work with you on the
initial design and implementation.
> How to know when the connection is ready?
> -
>
> Key: CB-8313
> URL: https://issues.apache.org/jira/browse/CB-8313
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: MacOSX latest Yosemite, Firefox latest Nightly
> Weinre 2.0.0-pre-I0Z7U9OV
>Reporter: _kud
>Assignee: Patrick Mueller
>Priority: Blocker
>
> As I can see, the project redefines console. Though, when the scope is
> private or/and used with browserify, the console.log doesn't work. I have no
> return.
> Though, if I do:
> ```
> video.addEventListener( 'play', function() {
> console.log( 'hello' )
> })
> ```
> in my code, it seems to work.
> Do you have any idea why?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8313) Add an event to say the connection to the server is ready
[
https://issues.apache.org/jira/browse/CB-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278702#comment-14278702
]
Patrick Mueller commented on CB-8313:
-
Yes, there is a timing issue, as the connection needs to be made to the server,
and then the weinre ui connected to the target being debugged, etc.
I don't have an explicit event that gets fired when weinre is connected to the
server, and in some sense, what you're really wanting is a notification that
some client has connected to the target. The target doesn't have any access to
this information - by design. It also gets complicated because multiple
clients can connect to a target simultaneously. The definition of "a good
time" for when console.log() will be visible to you is ... difficult.
My suggestion would be to add these startup messages you want to log, to an
array, and then set a timeout which will pull them out of the array and
console.log() them; and then presumably delete them from the array.
> Add an event to say the connection to the server is ready
> -
>
> Key: CB-8313
> URL: https://issues.apache.org/jira/browse/CB-8313
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: MacOSX latest Yosemite, Firefox latest Nightly
> Weinre 2.0.0-pre-I0Z7U9OV
>Reporter: _kud
>Assignee: Patrick Mueller
>Priority: Blocker
>
> As I can see, the project redefines console. Though, when the scope is
> private or/and used with browserify, the console.log doesn't work. I have no
> return.
> Though, if I do:
> ```
> video.addEventListener( 'play', function() {
> console.log( 'hello' )
> })
> ```
> in my code, it seems to work.
> Do you have any idea why?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8313) console.log doesn't work well with browserify? troubles with private scope?
[
https://issues.apache.org/jira/browse/CB-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278672#comment-14278672
]
Patrick Mueller commented on CB-8313:
-
I'll need more information. You say "console.log doesn't work. I have no
return". Not sure what that means. Can you provide more detail? I assume you
are not seeing any output in the weinre console.
I'm not sure what the video callback console.log() usage indicates. You see
the console output in weinre in ONLY the case? I don't think the fact that the
console.log() is being called from within a callback should affect the console
functionality.
If you can provide the smallest possible testcase that shows the failures, that
would be great.
> console.log doesn't work well with browserify? troubles with private scope?
> ---
>
> Key: CB-8313
> URL: https://issues.apache.org/jira/browse/CB-8313
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: MacOSX latest Yosemite, Firefox latest Nightly
> Weinre 2.0.0-pre-I0Z7U9OV
>Reporter: _kud
>Assignee: Patrick Mueller
>Priority: Blocker
>
> As I can see, the project redefines console. Though, when the scope is
> private or/and used with browserify, the console.log doesn't work. I have no
> return.
> Though, if I do:
> ```
> video.addEventListener( 'play', function() {
> console.log( 'hello' )
> })
> ```
> in my code, it seems to work.
> Do you have any idea why?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8023) weinre console.log fails when given null value
[
https://issues.apache.org/jira/browse/CB-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220250#comment-14220250
]
Patrick Mueller commented on CB-8023:
-
Ah, that makes more sense; for some reason I thought your case was calling
{{console.log()}}, but ya, it does appear to still be a problem if you also
call {{console.log(null)}}. I'm surprised no one has hit that case before!
> weinre console.log fails when given null value
> --
>
> Key: CB-8023
> URL: https://issues.apache.org/jira/browse/CB-8023
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Kevin Turner
>Assignee: Patrick Mueller
> Labels: easyfix, easytest
>
> weinre's Console._generic, through which all console.log messages go,
> contains this line:
> https://github.com/apache/cordova-weinre/blob/f8bcc48f84d9d08f04993328124a62b6bc5026c4/weinre.web/modules/weinre/target/Console.coffee#L78
> message = messageParts[0].toString()
> When messageParts[0] is null, that fails with "null is not an object" (on
> cordova on iOS, other browsers may have different messages but also may not
> have a toString on null).
> It's a small mistake but terrifically annoying to track down such a crash
> introduced by this debugging tool.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-8023) weinre console.log fails when given null value
[
https://issues.apache.org/jira/browse/CB-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213715#comment-14213715
]
Patrick Mueller commented on CB-8023:
-
Ya, in Chrome, I'm seeing {{"Uncaught TypeError: Cannot read property
'toString' of undefined"}}.
I've just pushed a fix here, on master:
https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=blobdiff;f=weinre.web/modules/weinre/target/Console.coffee;h=aec70be9b1a95191e622ad12120e705aeb958d98;hp=cf6624a7e461b873f8c1ef21157d721c2c830bcf;hb=04ba61d963c7f1774b4bff5d7eb3a5772e3f7088;hpb=707a7a1bf56269c5cd4b3fa53a3d6ab5b6ba69ab
Basically, a pre-check of the messageParts parm to make sure it's not null or
an empty array:
{{return if !messageParts?.length}}
I'll need to spin a new build, and test it, before releasing a new version.
Thanks for the report! Sorry for your troubles.
> weinre console.log fails when given null value
> --
>
> Key: CB-8023
> URL: https://issues.apache.org/jira/browse/CB-8023
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Kevin Turner
>Assignee: Patrick Mueller
> Labels: easyfix, easytest
>
> weinre's Console._generic, through which all console.log messages go,
> contains this line:
> https://github.com/apache/cordova-weinre/blob/f8bcc48f84d9d08f04993328124a62b6bc5026c4/weinre.web/modules/weinre/target/Console.coffee#L78
> message = messageParts[0].toString()
> When messageParts[0] is null, that fails with "null is not an object" (on
> cordova on iOS, other browsers may have different messages but also may not
> have a toString on null).
> It's a small mistake but terrifically annoying to track down such a crash
> introduced by this debugging tool.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-5718) Detection of HTTPS broken
[
https://issues.apache.org/jira/browse/CB-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller resolved CB-5718.
-
Resolution: Fixed
> Detection of HTTPS broken
> -
>
> Key: CB-5718
> URL: https://issues.apache.org/jira/browse/CB-5718
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 2.0.0
>Reporter: Andrew Brock
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: https
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 2 JS files don't correctly handle https:
> web/index.js(64):
> --- else if (protocol == "https:") {
> +++ else if (weinre_protocol == "https:") {
> web/target/target-script-min.js(3359):
> --- pattern = /(http:\/\/(.*?)\/)/;
> +++ pattern = /(https?:\/\/(.*?)\/)/;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-5718) Detection of HTTPS broken
[
https://issues.apache.org/jira/browse/CB-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162273#comment-14162273
]
Patrick Mueller commented on CB-5718:
-
I've commit the patch here:
https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commit;h=891a61f73f27c171f5170327c18858ccf48841d2
I've been having difficulties publishing to npm - if you'd like to try it
before I get the issue resolved, you can install from the tarball, with this
command:
sudo npm -g install
http://people.apache.org/~pmuellr/weinre/builds/2.0.0-pre-I0Z7U9OV/apache-cordova-weinre-2.0.0-pre-I0Z7U9OV-bin.tar.gz
> Detection of HTTPS broken
> -
>
> Key: CB-5718
> URL: https://issues.apache.org/jira/browse/CB-5718
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 2.0.0
>Reporter: Andrew Brock
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: https
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 2 JS files don't correctly handle https:
> web/index.js(64):
> --- else if (protocol == "https:") {
> +++ else if (weinre_protocol == "https:") {
> web/target/target-script-min.js(3359):
> --- pattern = /(http:\/\/(.*?)\/)/;
> +++ pattern = /(https?:\/\/(.*?)\/)/;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-5718) Detection of HTTPS broken
[
https://issues.apache.org/jira/browse/CB-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160276#comment-14160276
]
Patrick Mueller commented on CB-5718:
-
Andrew / James - thanks for the report and comment.
The patch here is easy enough - just the suggested fix to weinre.web/index.js -
that it's easier for me to do this myself.
Good to go after this single fix?
Andrew, had you tried picking up a new weinre release, for a fix to the second
problem?
> Detection of HTTPS broken
> -
>
> Key: CB-5718
> URL: https://issues.apache.org/jira/browse/CB-5718
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 2.0.0
>Reporter: Andrew Brock
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: https
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 2 JS files don't correctly handle https:
> web/index.js(64):
> --- else if (protocol == "https:") {
> +++ else if (weinre_protocol == "https:") {
> web/target/target-script-min.js(3359):
> --- pattern = /(http:\/\/(.*?)\/)/;
> +++ pattern = /(https?:\/\/(.*?)\/)/;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-7430) weinre does not play nice with npm dedupe
[ https://issues.apache.org/jira/browse/CB-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller resolved CB-7430. - Resolution: Fixed > weinre does not play nice with npm dedupe > - > > Key: CB-7430 > URL: https://issues.apache.org/jira/browse/CB-7430 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 2.0.0 > Environment: Ubuntu, node.js 0.10.31 >Reporter: Magnus Skog >Assignee: Patrick Mueller >Priority: Minor > Labels: node.js, npm > > Weinre breaks if you dedupe your node dependencies. This happens because > weinre assumes that coffee-script is located in the local node_modules > folder, which might not be the case after npm dedupe. > Error: Cannot find module > '/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/node_modules/coffee-script' > at Function.Module._resolveFilename (module.js:338:15) > at Function.Module._load (module.js:280:25) > at Module.require (module.js:364:17) > at require (module.js:380:17) > at Object. > (/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/weinre:34:1) > at Module._compile (module.js:456:26) > at Object.Module._extensions..js (module.js:474:10) > at Module.load (module.js:356:32) > at Function.Module._load (module.js:312:12) > at Function.Module.runMain (module.js:497:10) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7430) weinre does not play nice with npm dedupe
[ https://issues.apache.org/jira/browse/CB-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121332#comment-14121332 ] Patrick Mueller commented on CB-7430: - fixed in commit: 03084bdb6a23cc4f6085a16420df9182b2252e43 - https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commit;h=03084bdb6a23cc4f6085a16420df9182b2252e43 published in release: 2.0.0-pre-HZO3BMNG (available at npm) > weinre does not play nice with npm dedupe > - > > Key: CB-7430 > URL: https://issues.apache.org/jira/browse/CB-7430 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 2.0.0 > Environment: Ubuntu, node.js 0.10.31 >Reporter: Magnus Skog >Assignee: Patrick Mueller >Priority: Minor > Labels: node.js, npm > > Weinre breaks if you dedupe your node dependencies. This happens because > weinre assumes that coffee-script is located in the local node_modules > folder, which might not be the case after npm dedupe. > Error: Cannot find module > '/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/node_modules/coffee-script' > at Function.Module._resolveFilename (module.js:338:15) > at Function.Module._load (module.js:280:25) > at Module.require (module.js:364:17) > at require (module.js:380:17) > at Object. > (/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/weinre:34:1) > at Module._compile (module.js:456:26) > at Object.Module._extensions..js (module.js:474:10) > at Module.load (module.js:356:32) > at Function.Module._load (module.js:312:12) > at Function.Module.runMain (module.js:497:10) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CB-7437) xhr readystate event passed bad event on some platforms
[ https://issues.apache.org/jira/browse/CB-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller resolved CB-7437. - Resolution: Fixed > xhr readystate event passed bad event on some platforms > --- > > Key: CB-7437 > URL: https://issues.apache.org/jira/browse/CB-7437 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller >Priority: Minor > > description at https://github.com/apache/cordova-weinre/pull/8 > readystate change event bound in the _xhr() function in > weinre.web/modules/weinre/common/WebSocketXhr.coffee -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7437) xhr readystate event passed bad event on some platforms
[ https://issues.apache.org/jira/browse/CB-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121331#comment-14121331 ] Patrick Mueller commented on CB-7437: - fixed in commit: 34d2980aea58ddc0d62ddb3924b6c649aca03f4c - https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commit;h=34d2980aea58ddc0d62ddb3924b6c649aca03f4c published in release: 2.0.0-pre-HZO3BMNG (available at npm) > xhr readystate event passed bad event on some platforms > --- > > Key: CB-7437 > URL: https://issues.apache.org/jira/browse/CB-7437 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller >Priority: Minor > > description at https://github.com/apache/cordova-weinre/pull/8 > readystate change event bound in the _xhr() function in > weinre.web/modules/weinre/common/WebSocketXhr.coffee -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CB-7438) weinre target not setting server url when from script's src attribute for https
[ https://issues.apache.org/jira/browse/CB-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller resolved CB-7438. - Resolution: Fixed > weinre target not setting server url when from script's src attribute for > https > --- > > Key: CB-7438 > URL: https://issues.apache.org/jira/browse/CB-7438 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller > > The file weinre.web/modules/weinre/target/Target.coffee file calculates the > weinre server URL based on the script src url, but only accepts http and not > https. > Reported by Sam Placette. > PR: https://github.com/apache/cordova-weinre/pull/4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7438) weinre target not setting server url when from script's src attribute for https
[ https://issues.apache.org/jira/browse/CB-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121330#comment-14121330 ] Patrick Mueller commented on CB-7438: - fixed in commit: d1694e49d9955c8a6e821a3bafbeb489ad593441 - https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commitdiff;h=d1694e49d9955c8a6e821a3bafbeb489ad593441;hp=feb2f061d63582a2067cd1a35bddc17cc43a543b published in release: 2.0.0-pre-HZO3BMNG (available at npm) > weinre target not setting server url when from script's src attribute for > https > --- > > Key: CB-7438 > URL: https://issues.apache.org/jira/browse/CB-7438 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller > > The file weinre.web/modules/weinre/target/Target.coffee file calculates the > weinre server URL based on the script src url, but only accepts http and not > https. > Reported by Sam Placette. > PR: https://github.com/apache/cordova-weinre/pull/4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7438) weinre target not setting server url when from script's src attribute for https
[ https://issues.apache.org/jira/browse/CB-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116558#comment-14116558 ] Patrick Mueller commented on CB-7438: - This is now in master: https://github.com/apache/cordova-weinre/commit/d1694e49d9955c8a6e821a3bafbeb489ad593441 > weinre target not setting server url when from script's src attribute for > https > --- > > Key: CB-7438 > URL: https://issues.apache.org/jira/browse/CB-7438 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller > > The file weinre.web/modules/weinre/target/Target.coffee file calculates the > weinre server URL based on the script src url, but only accepts http and not > https. > Reported by Sam Placette. > PR: https://github.com/apache/cordova-weinre/pull/4 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-7438) weinre target not setting server url when from script's src attribute for https
[
https://issues.apache.org/jira/browse/CB-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116553#comment-14116553
]
Patrick Mueller edited comment on CB-7438 at 8/30/14 8:34 PM:
--
suggested fix
from:
{code}
pattern = /(http:\/\/(.*?)\/)/
{code}
to
{code}
pattern = /((https?:)?\/\/(.*?)\/)/
{code}
in the setWeinreServerURLFromScriptSrc() function in
weinre.web/modules/weinre/target/Target.coffee
was (Author: pmuellr):
suggested fix
from:
pattern = /(http:\/\/(.*?)\/)/
to
pattern = /((https?:)?\/\/(.*?)\/)/
in the setWeinreServerURLFromScriptSrc() function in
weinre.web/modules/weinre/target/Target.coffee
> weinre target not setting server url when from script's src attribute for
> https
> ---
>
> Key: CB-7438
> URL: https://issues.apache.org/jira/browse/CB-7438
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> The file weinre.web/modules/weinre/target/Target.coffee file calculates the
> weinre server URL based on the script src url, but only accepts http and not
> https.
> Reported by Sam Placette.
> PR: https://github.com/apache/cordova-weinre/pull/4
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-7438) weinre target not setting server url when from script's src attribute for https
[ https://issues.apache.org/jira/browse/CB-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116553#comment-14116553 ] Patrick Mueller commented on CB-7438: - suggested fix from: pattern = /(http:\/\/(.*?)\/)/ to pattern = /((https?:)?\/\/(.*?)\/)/ in the setWeinreServerURLFromScriptSrc() function in weinre.web/modules/weinre/target/Target.coffee > weinre target not setting server url when from script's src attribute for > https > --- > > Key: CB-7438 > URL: https://issues.apache.org/jira/browse/CB-7438 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller > > The file weinre.web/modules/weinre/target/Target.coffee file calculates the > weinre server URL based on the script src url, but only accepts http and not > https. > Reported by Sam Placette. > PR: https://github.com/apache/cordova-weinre/pull/4 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-7438) weinre target not setting server url when from script's src attribute for https
Patrick Mueller created CB-7438: --- Summary: weinre target not setting server url when from script's src attribute for https Key: CB-7438 URL: https://issues.apache.org/jira/browse/CB-7438 Project: Apache Cordova Issue Type: Bug Components: weinre Reporter: Patrick Mueller Assignee: Patrick Mueller The file weinre.web/modules/weinre/target/Target.coffee file calculates the weinre server URL based on the script src url, but only accepts http and not https. Reported by Sam Placette. PR: https://github.com/apache/cordova-weinre/pull/4 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7437) xhr readystate event passed bad event on some platforms
[ https://issues.apache.org/jira/browse/CB-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116548#comment-14116548 ] Patrick Mueller commented on CB-7437: - commit here: https://github.com/apache/cordova-weinre/commit/f6c24acb6c897de9ab2c68af41e92d8c54b5717c > xhr readystate event passed bad event on some platforms > --- > > Key: CB-7437 > URL: https://issues.apache.org/jira/browse/CB-7437 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Reporter: Patrick Mueller >Assignee: Patrick Mueller >Priority: Minor > > description at https://github.com/apache/cordova-weinre/pull/8 > readystate change event bound in the _xhr() function in > weinre.web/modules/weinre/common/WebSocketXhr.coffee -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-7437) xhr readystate event passed bad event on some platforms
Patrick Mueller created CB-7437: --- Summary: xhr readystate event passed bad event on some platforms Key: CB-7437 URL: https://issues.apache.org/jira/browse/CB-7437 Project: Apache Cordova Issue Type: Bug Components: weinre Reporter: Patrick Mueller Assignee: Patrick Mueller Priority: Minor description at https://github.com/apache/cordova-weinre/pull/8 readystate change event bound in the _xhr() function in weinre.web/modules/weinre/common/WebSocketXhr.coffee -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7430) weinre does not play nice with npm dedupe
[ https://issues.apache.org/jira/browse/CB-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116529#comment-14116529 ] Patrick Mueller commented on CB-7430: - I've decided to create a more elaborate patch to remove CoffeeScript as a runtime dependency; it's in devDependencies now, and the build script will recompile the .coffee files into .js files. One less thing to de-dupe. Also upgraded the coffee-script, nopt and underscore versions in the package.json.template file to recent versions. Express has changed so much I decided to not upgrade to it's major version - but there has been a patch version since the last release that shows up here. This is currently in a branch CB-7430, per: https://github.com/apache/cordova-weinre/tree/CB-7430 https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=shortlog;h=refs/heads/CB-7430 all in this commit: https://github.com/apache/cordova-weinre/commit/9b06777d6b23d1d2785b66a0e3f6f6c754561a08 https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commit;h=9b06777d6b23d1d2785b66a0e3f6f6c754561a08 I'll merge it in a few days, give you a chance to try it if you like. > weinre does not play nice with npm dedupe > - > > Key: CB-7430 > URL: https://issues.apache.org/jira/browse/CB-7430 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 2.0.0 > Environment: Ubuntu, node.js 0.10.31 >Reporter: Magnus Skog >Assignee: Patrick Mueller >Priority: Minor > Labels: node.js, npm > > Weinre breaks if you dedupe your node dependencies. This happens because > weinre assumes that coffee-script is located in the local node_modules > folder, which might not be the case after npm dedupe. > Error: Cannot find module > '/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/node_modules/coffee-script' > at Function.Module._resolveFilename (module.js:338:15) > at Function.Module._load (module.js:280:25) > at Module.require (module.js:364:17) > at require (module.js:380:17) > at Object. > (/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/weinre:34:1) > at Module._compile (module.js:456:26) > at Object.Module._extensions..js (module.js:474:10) > at Module.load (module.js:356:32) > at Function.Module._load (module.js:312:12) > at Function.Module.runMain (module.js:497:10) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7430) weinre does not play nice with npm dedupe
[ https://issues.apache.org/jira/browse/CB-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115521#comment-14115521 ] Patrick Mueller commented on CB-7430: - Thanks for the pull request and bug report! The PR looks good (less code). Will give it a shot this weekend. > weinre does not play nice with npm dedupe > - > > Key: CB-7430 > URL: https://issues.apache.org/jira/browse/CB-7430 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 2.0.0 > Environment: Ubuntu, node.js 0.10.31 >Reporter: Magnus Skog >Assignee: Patrick Mueller >Priority: Minor > Labels: node.js, npm > > Weinre breaks if you dedupe your node dependencies. This happens because > weinre assumes that coffee-script is located in the local node_modules > folder, which might not be the case after npm dedupe. > Error: Cannot find module > '/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/node_modules/coffee-script' > at Function.Module._resolveFilename (module.js:338:15) > at Function.Module._load (module.js:280:25) > at Module.require (module.js:364:17) > at require (module.js:380:17) > at Object. > (/Users/erikn/Code/eagle-ng/node_modules/grunt-weinre/node_modules/weinre/weinre:34:1) > at Module._compile (module.js:456:26) > at Object.Module._extensions..js (module.js:474:10) > at Module.load (module.js:356:32) > at Function.Module._load (module.js:312:12) > at Function.Module.runMain (module.js:497:10) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-7367) Allow update of weinreId without page refresh
[ https://issues.apache.org/jira/browse/CB-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller resolved CB-7367. - Resolution: Fixed commit https://github.com/apache/cordova-weinre/commit/ad3c24fe15d119b6e0a712c061e9269418382692 > Allow update of weinreId without page refresh > - > > Key: CB-7367 > URL: https://issues.apache.org/jira/browse/CB-7367 > Project: Apache Cordova > Issue Type: Wish > Components: weinre >Reporter: Stewart >Assignee: Patrick Mueller >Priority: Minor > > As the clientId is specified in the URL's fragment, browsers will not refresh > the page when changing the clientId from Weinre. > Detect changes to the fragment within Weinre to allow updating this on the > fly (no page refresh required). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7367) Allow update of weinreId without page refresh
[ https://issues.apache.org/jira/browse/CB-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108109#comment-14108109 ] Patrick Mueller commented on CB-7367: - Patch applied, weinre rebuilt. Thanks Stewart! > Allow update of weinreId without page refresh > - > > Key: CB-7367 > URL: https://issues.apache.org/jira/browse/CB-7367 > Project: Apache Cordova > Issue Type: Wish > Components: weinre >Reporter: Stewart >Assignee: Patrick Mueller >Priority: Minor > > As the clientId is specified in the URL's fragment, browsers will not refresh > the page when changing the clientId from Weinre. > Detect changes to the fragment within Weinre to allow updating this on the > fly (no page refresh required). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7367) Allow update of weinreId without page refresh
[ https://issues.apache.org/jira/browse/CB-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106844#comment-14106844 ] Patrick Mueller commented on CB-7367: - Sorry, brain fart there! Got a few things on my mind :-) Ya, don't have any tests, sorry. Will look at soon, thanks so much! > Allow update of weinreId without page refresh > - > > Key: CB-7367 > URL: https://issues.apache.org/jira/browse/CB-7367 > Project: Apache Cordova > Issue Type: Wish > Components: weinre >Reporter: Stewart >Assignee: Patrick Mueller >Priority: Minor > > As the clientId is specified in the URL's fragment, browsers will not refresh > the page when changing the clientId from Weinre. > Detect changes to the fragment within Weinre to allow updating this on the > fly (no page refresh required). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7367) Allow update of weinreId without page refresh
[ https://issues.apache.org/jira/browse/CB-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106728#comment-14106728 ] Patrick Mueller commented on CB-7367: - Did you have any interest in working on a patch? Build directions should be included in the docs. No worries, if not. I'll queue it up for sometime next week (hopefully). > Allow update of weinreId without page refresh > - > > Key: CB-7367 > URL: https://issues.apache.org/jira/browse/CB-7367 > Project: Apache Cordova > Issue Type: Wish > Components: weinre >Reporter: Stewart >Assignee: Patrick Mueller >Priority: Minor > > As the clientId is specified in the URL's fragment, browsers will not refresh > the page when changing the clientId from Weinre. > Detect changes to the fragment within Weinre to allow updating this on the > fly (no page refresh required). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-6991) Weinre fails to load in browsers without a built-in development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller resolved CB-6991.
-
Resolution: Fixed
Fixed in commit
https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commit;h=198d290b5fc0b873b67e3f6c344055a9fe5611a7
; tagged as 2.0.0-pre-HYFXM3QM
> Weinre fails to load in browsers without a built-in development console
> ---
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6991) Weinre fails to load in browsers without a built-in development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084834#comment-14084834
]
Patrick Mueller commented on CB-6991:
-
Just published 2.0.0-pre-HYFXM3QM of weinre, now available at:
https://www.npmjs.org/package/weinre
Let us know if it works out for you!
> Weinre fails to load in browsers without a built-in development console
> ---
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6991) Weinre fails to load in browsers without a built-in development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084736#comment-14084736
]
Patrick Mueller commented on CB-6991:
-
As soon as I can do a build; if you're in a pinch, and handy with git and
rebuilding weinre, you should be able to build a local copy with this fix; of
course, you've already hacked the same fix manually, so ... you shouldn't need
anything else for yourself.
> Weinre fails to load in browsers without a built-in development console
> ---
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6991) Weinre fails to load in browsers without a built-in development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084661#comment-14084661
]
Patrick Mueller commented on CB-6991:
-
Thanks the patch Sergey; surely one of the smallest patches ever!!! :-)
Will try to get this integrated today.
> Weinre fails to load in browsers without a built-in development console
> ---
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-7248) weinre do not work using hash(#) in location
[ https://issues.apache.org/jira/browse/CB-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084656#comment-14084656 ] Patrick Mueller commented on CB-7248: - Are you able to use Chrome Dev Tools instead of weinre? https://developer.chrome.com/devtools/docs/remote-debugging > weinre do not work using hash(#) in location > > > Key: CB-7248 > URL: https://issues.apache.org/jira/browse/CB-7248 > Project: Apache Cordova > Issue Type: Bug > Components: weinre > Environment: mac，ubuntu >Reporter: Hans Chan >Assignee: Patrick Mueller >Priority: Blocker > > i am using weinre (2.0.0-pre-HH0SN197)，installed by npm。 > when i open a url like "http://myip/index"; in my mobile device, it works > perfect; > but with a location "http://myip/index#hash";, the debug client can not find > the target. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7248) weinre do not work using hash(#) in location
[ https://issues.apache.org/jira/browse/CB-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084326#comment-14084326 ] Patrick Mueller commented on CB-7248: - What platform is this for? Where is the weinre server, and what version is it? Also, what URL are you using in your HTML for the weinre script, and what URL are you using to access the weinre debug client in the browser? > weinre do not work using hash(#) in location > > > Key: CB-7248 > URL: https://issues.apache.org/jira/browse/CB-7248 > Project: Apache Cordova > Issue Type: Bug > Components: weinre > Environment: mac，ubuntu >Reporter: Hans Chan >Assignee: Patrick Mueller >Priority: Blocker > > i am using weinre (2.0.0-pre-HH0SN197)，installed by npm。 > when i open a url like "http://myip/index"; in my mobile device, it works > perfect; > but with a location "http://myip/index#hash";, the debug client can not find > the target. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7248) weinre do not work using hash(#) in location
[ https://issues.apache.org/jira/browse/CB-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084259#comment-14084259 ] Patrick Mueller commented on CB-7248: - What platform is this for? Where is the weinre server, and what version is it? Are you using a multi-user id as a hash? [1] [1] http://weinre.mybluemix.net/doc/MultiUser.html > weinre do not work using hash(#) in location > > > Key: CB-7248 > URL: https://issues.apache.org/jira/browse/CB-7248 > Project: Apache Cordova > Issue Type: Bug > Components: weinre > Environment: mac，ubuntu >Reporter: Hans Chan >Assignee: Patrick Mueller >Priority: Blocker > > i am using weinre (2.0.0-pre-HH0SN197)，installed by npm。 > when i open a url like "http://myip/index"; in my mobile device, it works > perfect; > but with a location "http://myip/index#hash";, the debug client can not find > the target. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CB-6991) Weinre fails to load in browsers without a built-in development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller reassigned CB-6991:
---
Assignee: Sergey Grebnov (was: Patrick Mueller)
Sergey, can you look into this? I've seen another report of funky console
issues on windows - something must have changed recently relating to it.
> Weinre fails to load in browsers without a built-in development console
> ---
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Sergey Grebnov
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6991) Weinre fails to load in browsers without a built-in development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039324#comment-14039324
]
Patrick Mueller commented on CB-6991:
-
hmmm, last I remember, you could certainly use `console.log()` in iOS and
Android - can't remember about wp8. I do know weinre works on all those
platforms. The test you made isn't necessarily complete; the console object
may well be injected into the global scope, and not available as a property of
the "window" object.
So, still trying to figure out your root problem; why did you need to add the
code that you added. Could you only get weinre to work on iOS and Android and
wp8 by modifying that code? If so, that's a weird regression since weinre has
worked in the past on those platforms.
Also, as I noted earlier, you don't really need to use weinre for recent
Android or iOS devices anyway, since both platforms have web debugging support
available now.
> Weinre fails to load in browsers without a built-in development console
> ---
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6991) Weinre doesn't fails to load in browsers without a development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038802#comment-14038802
]
Patrick Mueller commented on CB-6991:
-
Joshua, I understood the problem, was curious about what platforms don't have a
"console" object. I'm not aware of any that don't. I'd obviously like to test
this, and if there's some device I already have or can get cheap or borrow that
exhibits this behaviour, I'd like to try.
w/r/t warning the user, I guess we'd do this in the console itself? Kinda
weird, eh? "warning: you are running on a platform without a console"
displayed in their console :-) I think we have a way of sending weinre console
messages from the debug target, but will have to check.
> Weinre doesn't fails to load in browsers without a development console
> --
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6991) Weinre doesn't fails to load in browsers without a development console
[
https://issues.apache.org/jira/browse/CB-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038758#comment-14038758
]
Patrick Mueller commented on CB-6991:
-
Thanks Joshua!
What mobile platform are you running on that doesn't support console? Of the
environments listed - wp8, iOS, Android - I thought we already had weinre
working - and recent-ish releases of iOS and Android have native debugging
stories as well.
> Weinre doesn't fails to load in browsers without a development console
> --
>
> Key: CB-6991
> URL: https://issues.apache.org/jira/browse/CB-6991
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
> Environment: Windows Phone 8.0, iOS, Android
>Reporter: Joshua Walsh
>Assignee: Patrick Mueller
>Priority: Blocker
> Labels: easyfix, javascript
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I couldn't work out where to submit a pull request, so I'm doing an issue
> report instead. Additionally, this issue applies to version
> 2.0.0-pre-HH0SN197 of Weinre, but I don't know which version of Cordova that
> maps to.
> This issue has been a massive pain to debug, as the issue is not present on
> desktop computers and there are no debugging tools on mobile devices, hence
> why I need Weinre in the first place! In fact, the issue is even more
> specific than that: The issue affects all browsers WITHOUT debugging tools.
> The error is: "Unable to set property __original of undefined or null
> reference." The issue occurs on line 172 of Console.amd.js. In order to fix
> it, I added the following lines of code above line 168:
> if(!window.console)
> {
> window.console = {};
> }
> I'm sure there's a more elegant way of solving this, but it does the trick.
> Good luck!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6835) weinre - Fix header licenses (Apache RAT report)
[ https://issues.apache.org/jira/browse/CB-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014287#comment-14014287 ] Patrick Mueller commented on CB-6835: - This is a problem; can't remember what my thoughts were on resolving it in the past - I must have had positive thoughts on it though. The issue is that almost all the files hit here are from WebKit. WebKit's code is generally licensed BSD or LGPL - in this case I believe all the files are licensed BSD. I think that was part of my positive thoughts on the problem anyway. Off the top of anyone's head who happens to be reading this, can we re-ship BSD code? I think if the answer is "no", then we will have to package weinre as a library, which you would download, and then download the relevant WebKit bits to make a complete application. Which isn't a huge problem. But it would easier to continue to ship the BSD licensed files. > weinre - Fix header licenses (Apache RAT report) > > > Key: CB-6835 > URL: https://issues.apache.org/jira/browse/CB-6835 > Project: Apache Cordova > Issue Type: Sub-task > Components: weinre >Reporter: Shazron Abdullah >Assignee: Patrick Mueller > Fix For: 3.6.0 > > > JavaDocs are generated and so license header is optional > Generated files do not required license headers > Add a .ratExcludes file for files to exclude > 153 Unknown Licenses > *** > Unapproved licenses: > ./weinre.build/vendor/webkit/WebCore/inspector/InjectedScriptHost.idl > ./weinre.build/vendor/webkit/WebCore/inspector/InjectedScriptSource.js > ./weinre.build/vendor/webkit/WebCore/inspector/Inspector.idl > ./weinre.build/vendor/webkit/WebCore/inspector/InspectorFrontendHost.idl > ./weinre.build/vendor/webkit/WebCore/inspector/JavaScriptCallFrame.idl > ./weinre.build/vendor/webkit/WebCore/inspector/ScriptProfile.idl > ./weinre.build/vendor/webkit/WebCore/inspector/ScriptProfileNode.idl > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/ApplicationCacheItemsView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/AuditCategories.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/AuditFormatters.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/AuditLauncherView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/AuditResultView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/AuditRules.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/AuditsPanel.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/BottomUpProfileDataGridTree.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/Breakpoint.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/BreakpointManager.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/BreakpointsSidebarPane.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CSSCompletions.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CSSKeywordCompletions.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CSSStyleModel.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CallStackSidebarPane.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/Checkbox.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/Color.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/ConsolePanel.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/ConsoleView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/ContextMenu.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CookieItemsView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CookieParser.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/CookiesTable.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DOMAgent.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DOMStorage.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DOMStorageItemsView.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DOMSyntaxHighlighter.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DataGrid.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/Database.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DatabaseQueryView.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DatabaseTableView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DebuggerModel.js > > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/DetailedHeapshotView.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/Drawer.js > ./weinre.build/vendor/webkit/WebCore/inspector/front-end/ElementsPanel.js > > ./weinre.build/vendor/webk
[jira] [Resolved] (CB-89) Support Firefox Mobile (Fennec) as debug target
[
https://issues.apache.org/jira/browse/CB-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller resolved CB-89.
---
Resolution: Done
closing as no longer relevant, due to better tooling elsewhere
> Support Firefox Mobile (Fennec) as debug target
> ---
>
> Key: CB-89
> URL: https://issues.apache.org/jira/browse/CB-89
> Project: Apache Cordova
> Issue Type: New Feature
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> from https://github.com/phonegap/weinre/issues/22
> *brion (Brion Vibber) opened this issue July 28, 2011*
> Since the debugging shim in the web page runs in native JavaScript, it ought
> to be possible in theory to use weinre with non-WebKit debugging targets as
> long as the JS can get the info it needs. This could be quite handy for
> testing a mobile web app on several browsers including Firefox for Android &
> Meego.
> I did a quick test with Firefox 5.0.1 on the desktop to see how much works
> with weinre (my copy of Android firefox is currently not working for
> unrelated reasons, but it's built from the same codebase as desktop firefox
> and should behave about the same).
> inspector... sorta works:
> * HTML tree looks ok
> * ... but no highlight of selected item
> * ... no computed style/styles/metrics info
> * ... properties are mislabeled (but this seems to be same problem using
> Chrome and in the OSCON demo, so may be a regression in the inspector or
> weinre itself)
> * ... no event listeners info (but also doesn't work in Chrome 12)
> basic console works:
> * evaluate alert('hey')
> * evaluate 25 + 32, get 57
> * evaluate $('p').css('color', 'red') on a jQuery-using page; it works, and
> shows a list of HTMLParagraphElements as expected
> resources:
> * 'databases' is blank (ff has no websql support so that's probably fine!)
> * 'local storage' and 'session storage' on the localhost does show entries...
> but they're the setItem, clear, and removeItem methods. :)
> timeline:
> * appears to work similarly to target in Chrome
> Even with the limited inspector, I would probably find this useful already. :D
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (CB-89) Support Firefox Mobile (Fennec) as debug target
[
https://issues.apache.org/jira/browse/CB-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller closed CB-89.
-
> Support Firefox Mobile (Fennec) as debug target
> ---
>
> Key: CB-89
> URL: https://issues.apache.org/jira/browse/CB-89
> Project: Apache Cordova
> Issue Type: New Feature
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> from https://github.com/phonegap/weinre/issues/22
> *brion (Brion Vibber) opened this issue July 28, 2011*
> Since the debugging shim in the web page runs in native JavaScript, it ought
> to be possible in theory to use weinre with non-WebKit debugging targets as
> long as the JS can get the info it needs. This could be quite handy for
> testing a mobile web app on several browsers including Firefox for Android &
> Meego.
> I did a quick test with Firefox 5.0.1 on the desktop to see how much works
> with weinre (my copy of Android firefox is currently not working for
> unrelated reasons, but it's built from the same codebase as desktop firefox
> and should behave about the same).
> inspector... sorta works:
> * HTML tree looks ok
> * ... but no highlight of selected item
> * ... no computed style/styles/metrics info
> * ... properties are mislabeled (but this seems to be same problem using
> Chrome and in the OSCON demo, so may be a regression in the inspector or
> weinre itself)
> * ... no event listeners info (but also doesn't work in Chrome 12)
> basic console works:
> * evaluate alert('hey')
> * evaluate 25 + 32, get 57
> * evaluate $('p').css('color', 'red') on a jQuery-using page; it works, and
> shows a list of HTMLParagraphElements as expected
> resources:
> * 'databases' is blank (ff has no websql support so that's probably fine!)
> * 'local storage' and 'session storage' on the localhost does show entries...
> but they're the setItem, clear, and removeItem methods. :)
> timeline:
> * appears to work similarly to target in Chrome
> Even with the limited inspector, I would probably find this useful already. :D
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6161) [weinre] not working with angular-seed
[
https://issues.apache.org/jira/browse/CB-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943204#comment-13943204
]
Patrick Mueller commented on CB-6161:
-
Sorry, been in crunch mode the last few weeks.
Are you happy with the results when you use the
{{whackWebkitMatchesSelector()}} function in your code, as above? It wasn't
clear if you were satisfied with the change to the way the failing and
non-failing selectors are filtered; or if this ended "working" but being
useless, because you really needed to see those styles that were erroring out,
or ...???
I didn't see mention of the exact versions of Android that you saw this problem
on; would also be useful to know the phone vendor, and even cell provider, if
you're comfortable providing that. I will probably not be able to test on your
exact same setup, but as much info as you feel that you can provide would be
great for future reference.
> [weinre] not working with angular-seed
> --
>
> Key: CB-6161
> URL: https://issues.apache.org/jira/browse/CB-6161
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> Run angular-seed demo with these directions:
> {noformat}
> git clone https://github.com/angular/angular-seed.git
> cd angular-seed
> npm install
> scripts/web-server.js
> {noformat}
> If you instrument the {{app/index.html}} file with weinre, and then view with
> weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6251) Bug in displayed Paddings
[
https://issues.apache.org/jira/browse/CB-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938114#comment-13938114
]
Patrick Mueller commented on CB-6251:
-
Thanks, I understand now.
Now that I look at it, this appears to also be a problem with the demo app that
weinre ships with. So at least it's consistently wrong, breaking on even basic
CSS. And not some other obscure issue related to complex CSS or something.
> Bug in displayed Paddings
> -
>
> Key: CB-6251
> URL: https://issues.apache.org/jira/browse/CB-6251
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 3.4.0
> Environment: Google Chrome
>Reporter: Alex Tape
>Assignee: Patrick Mueller
>Priority: Minor
> Attachments: hccagdgj.png
>
>
> display of bootstrap container is shifted to the left border. (should be
> centered).
> CSS
> .container {
> margin-left: auto;
> margin-right: auto;
> padding-left: 15px;
> padding-right: 15px;
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6251) Bug in displayed Paddings
[
https://issues.apache.org/jira/browse/CB-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935680#comment-13935680
]
Patrick Mueller commented on CB-6251:
-
Alex, thanks for the bug report and suggested fix.
Not clear what CSS this is though. Could you identify the file in question, or
perhaps post a screen-cap of the problem so I can understand the issue?
> Bug in displayed Paddings
> -
>
> Key: CB-6251
> URL: https://issues.apache.org/jira/browse/CB-6251
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 3.4.0
> Environment: Google Chrome
>Reporter: Alex Tape
>Assignee: Patrick Mueller
>Priority: Minor
>
> display of bootstrap container is shifted to the left border. (should be
> centered).
> CSS
> .container {
> margin-left: auto;
> margin-right: auto;
> padding-left: 15px;
> padding-right: 15px;
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6161) [weinre] not working with angular-seed
[
https://issues.apache.org/jira/browse/CB-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924066#comment-13924066
]
Patrick Mueller commented on CB-6161:
-
The code is question is walking through selectors, figuring out which apply to
the element you're looking at.
What you are essentially asking for is that ALL of the selectors causing errors
should appear to apply to the element.
EVERY ELEMENT WILL APPEAR TO HAVE ALL THE STYLES THAT ARE IN ERROR.
I think that's worse than hiding it.
> [weinre] not working with angular-seed
> --
>
> Key: CB-6161
> URL: https://issues.apache.org/jira/browse/CB-6161
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> Run angular-seed demo with these directions:
> {noformat}
> git clone https://github.com/angular/angular-seed.git
> cd angular-seed
> npm install
> scripts/web-server.js
> {noformat}
> If you instrument the {{app/index.html}} file with weinre, and then view with
> weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6161) [weinre] not working with angular-seed
[
https://issues.apache.org/jira/browse/CB-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923993#comment-13923993
]
Patrick Mueller commented on CB-6161:
-
This is the same problem: https://github.com/angular/angular.js/issues/3596 -
JS code dying processing whacky styles.
This is the same problem:
http://stackoverflow.com/questions/20705457/weinre-style-inspection-not-working-with-angularjs
This was the fix to the above problem:
https://issues.apache.org/jira/browse/CB-2651 (as referenced in the above
problem).
The problem with the fix is that it causes NONE of the style data to be shown
in some cases.
In terms of "what is it blocking", you could change the function to dump the
style it was evaluating in the catch clause. I think if you write it to
console.log(), it will show up in the weinre console.
> [weinre] not working with angular-seed
> --
>
> Key: CB-6161
> URL: https://issues.apache.org/jira/browse/CB-6161
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> Run angular-seed demo with these directions:
> {noformat}
> git clone https://github.com/angular/angular-seed.git
> cd angular-seed
> npm install
> scripts/web-server.js
> {noformat}
> If you instrument the {{app/index.html}} file with weinre, and then view with
> weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6161) [weinre] not working with angular-seed
[
https://issues.apache.org/jira/browse/CB-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923435#comment-13923435
]
Patrick Mueller commented on CB-6161:
-
Wanna try something? Include the following function, and run it early on your
page. It may narrow the scope of the error checking weinre is doing, so that
you can see *some* of the styles. No idea if it will actually work or not
though.
Since it's also choking on the ng-cloak style bits, you could try removing any
refs you have to ng-cloak, but of course you might be actively using it (like I
do), which would be a problem.
I'm also afraid that even though I've only seen it throw on ng-cloak, I don't
know that the crazy styles Angular uses aren't similar to that, and it may
break on just about everything. Dunno.
{noformat}
function whackWebkitMatchesSelector() {
var oldMatches = Element.prototype.webkitMatchesSelector
function newMatches(selector) {
try {
return oldMatches.call(this, selector)
}
catch (err) {
return false
}
}
Element.prototype.webkitMatchesSelector = newMatches
}
whackWebkitMatchesSelector()
{noformat}
> [weinre] not working with angular-seed
> --
>
> Key: CB-6161
> URL: https://issues.apache.org/jira/browse/CB-6161
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> Run angular-seed demo with these directions:
> {noformat}
> git clone https://github.com/angular/angular-seed.git
> cd angular-seed
> npm install
> scripts/web-server.js
> {noformat}
> If you instrument the {{app/index.html}} file with weinre, and then view with
> weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6161) [weinre] not working with angular-seed
[
https://issues.apache.org/jira/browse/CB-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922375#comment-13922375
]
Patrick Mueller commented on CB-6161:
-
So, not a lot of time to look into this, but found something this morning.
I debugged the angular seed app with Dev Tools while using weinre - turned on
"pause on all exceptions", and shore enough, it was throwing an exception on
{noformat}
someElement.webkitMatchesSelector("[ng:cloak], [ng-cloak], [data-ng-cloak],
[x-ng-cloak], .ng-cloak, .x-ng-cloak, .ng-hide")
{noformat}
I don't remember exactly how we walk the CSS rules, but I assume we walk every
rule to see if it's applicable to the existing selected element and ... maybe
we're hitting this first. I should look at that code to see if we can catch
the error more granularly, so that at least you can see the other rules.
BTW, what platform are you wanting to debug on, there may be options beyond
weinre for ya ...
> [weinre] not working with angular-seed
> --
>
> Key: CB-6161
> URL: https://issues.apache.org/jira/browse/CB-6161
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> Run angular-seed demo with these directions:
> {noformat}
> git clone https://github.com/angular/angular-seed.git
> cd angular-seed
> npm install
> scripts/web-server.js
> {noformat}
> If you instrument the {{app/index.html}} file with weinre, and then view with
> weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6161) [weinre] not working with angular-seed
[
https://issues.apache.org/jira/browse/CB-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919338#comment-13919338
]
Patrick Mueller commented on CB-6161:
-
Ran server with --debug true --verbose true. No errors reported.
Ran weinre client and agent under Chrome Dev Tools. No errors reported
Changed {{app/index.html}} so it *only* included {{angular.js}}. Still got the
error.
Changed the order of the weinre script and {{angular.js}} script. Still got
error.
I'm wondering if SCE has anything to do with this; more info here:
http://docs.angularjs.org/api/ng/service/$sce
> [weinre] not working with angular-seed
> --
>
> Key: CB-6161
> URL: https://issues.apache.org/jira/browse/CB-6161
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
>
> Run angular-seed demo with these directions:
> {noformat}
> git clone https://github.com/angular/angular-seed.git
> cd angular-seed
> npm install
> scripts/web-server.js
> {noformat}
> If you instrument the {{app/index.html}} file with weinre, and then view with
> weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6161) [weinre] not working with angular-seed
Patrick Mueller created CB-6161:
---
Summary: [weinre] not working with angular-seed
Key: CB-6161
URL: https://issues.apache.org/jira/browse/CB-6161
Project: Apache Cordova
Issue Type: Bug
Components: weinre
Reporter: Patrick Mueller
Assignee: Patrick Mueller
Run angular-seed demo with these directions:
{noformat}
git clone https://github.com/angular/angular-seed.git
cd angular-seed
npm install
scripts/web-server.js
{noformat}
If you instrument the {{app/index.html}} file with weinre, and then view with
weinre, you won't see any style information.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CB-5731) Windows Phone 8 fails to access remote urls
[
https://issues.apache.org/jira/browse/CB-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller reassigned CB-5731:
---
Assignee: Sergey Grebnov (was: Jesse MacFadyen)
Sergey, can you look into this?
> Windows Phone 8 fails to access remote urls
> ---
>
> Key: CB-5731
> URL: https://issues.apache.org/jira/browse/CB-5731
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.3.0
>Reporter: John McLear
>Assignee: Sergey Grebnov
> Attachments: BrokenXDKXHRDemo.zip
>
>
> Doing a very simple:
> {code:javascript}
> $.get("http://google.com";, function(){alert("yay")});
> {code}
> Fails on Windows Phone 8.
> Basically Cross domain requests don't work, this includes when an explicit
> and/or wildcard exclusion is set in config.xml allowed domains
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CB-5219) weinre disconnects when history.replaceState is used
[
https://issues.apache.org/jira/browse/CB-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller reassigned CB-5219:
---
Assignee: Sergey Grebnov (was: Patrick Mueller)
Sergey, can you look into this?
> weinre disconnects when history.replaceState is used
>
>
> Key: CB-5219
> URL: https://issues.apache.org/jira/browse/CB-5219
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.1.0
> Environment: Windows 8, Visual Studio 2012
>Reporter: Björn Andersson
>Assignee: Sergey Grebnov
>
> I got an app that uses weinre and when developing on Android, BB10 and iOS I
> never had any issues. But on WP8 it kept disconnect pretty much instantly
> after connecting.
> I found that if I do:
> {code}
> history.replaceState(null, 'weinre, say bye-bye', '/some-fake-url')
> {code}
> Weinre will disconnect. I've tried this with the Cordova hello world app and
> just adding in that line above disconnects weinre.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CB-5759) Conflict between xhr.js from Intel XDK and Weinre remote hook script
[
https://issues.apache.org/jira/browse/CB-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller reassigned CB-5759:
---
Assignee: Sergey Grebnov (was: Patrick Mueller)
Sergey, can you look into this?
> 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: Sergey Grebnov
>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}
>
>
>
>/* 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);
>
> {code}
> Works
> {code}
>
> src="http://debug-software.intel.com/target/target-script-min.js#QhYeZC6N-jY-XBnNnuS5DqN6Ti72PEzRd1Oeu_TKT9g";>
>
>
>/* 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);
>
> {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)
[jira] [Commented] (CB-5759) Conflict between xhr.js from Intel XDK and Weinre remote hook script
[
https://issues.apache.org/jira/browse/CB-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868449#comment-13868449
]
Patrick Mueller commented on CB-5759:
-
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"; it does some XHRs, but back to itself so it doesn't
exercise cross-site XHR
> 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}
>
>
>
>/* 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);
>
> {code}
> Works
> {code}
>
> src="http://debug-software.intel.com/target/target-script-min.js#QhYeZC6N-jY-XBnNnuS5DqN6Ti72PEzRd1Oeu_TKT9g";>
>
>
>/* 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);
>
> {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)
[jira] [Commented] (CB-5759) Conflict between xhr.js from Intel XDK and Weinre remote hook script
[
https://issues.apache.org/jira/browse/CB-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867765#comment-13867765
]
Patrick Mueller commented on CB-5759:
-
The only reason you should need weinre to debug iOS is if you aren't using a
Mac desktop - which is a pretty difficult way to live life (developing iOS apps
on Windows|Linux), but some have chosen this path. If you ARE using a Mac
desktop, and are running both recent iOS and OS X, you should be able to use
the remote debug facility [1], which is way more functional than weinre.
For the Ripple emulator, I assume you are using it within Chrome - or I wonder
if it's also a node-webkit app as well. In either case, you should be able to
use the built-in Developer Tools [2] or maybe fiddle with the node-webkit app
[3].
[1]
https://developer.apple.com/library/ios/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html
[2] https://developers.google.com/chrome-developer-tools/
[3] https://github.com/rogerwang/node-webkit/wiki/Debugging-with-devtools
> 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}
>
>
>
>/* 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);
>
> {code}
> Works
> {code}
>
> src="http://debug-software.intel.com/target/target-script-min.js#QhYeZC6N-jY-XBnNnuS5DqN6Ti72PEzRd1Oeu_TKT9g";>
>
>
>/* 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);
>
> {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)
[jira] [Commented] (CB-5759) Conflict between xhr.js from Intel XDK and Weinre remote hook script
[
https://issues.apache.org/jira/browse/CB-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867564#comment-13867564
]
Patrick Mueller commented on CB-5759:
-
Thanks for the bug report!
Couple things:
- be gentle with me; I've never heard of the Intel XDK thing till this bug
report, still trying to figure out what it is :-)
- I noticed a "use strict" in BrokenXDKXHRDemo/js/index_user_scripts.js; we had
some problems with strict-mode in the past, I was hoping it was behind us, but
you never can tell. Could you try removing that and see if it changes anything?
- I notice you tested on an iPod touch - you should be able to get away without
using weinre for most platforms now, as the platforms have been adding remote
debug support into the browsers/web views. Remote debugging is supported for
iOS apps as of iOS 6 or so, as long as you have Mac desktop/laptop running a
recent version of OS X. I woulda guessed that whatever emulator you are using
on your host would be using a browser/web view that also supported debugging.
- what's the easiest way for me to see the contents of intelxdk.js; I'd rather
not have to download a whack of stuff if I can avoid it, just yet. I'd like to
see xhr.js as well - noticed that you didn't include it in your index.html, but
had also mentioned adding it didn't change anything. Smells like you likely
need it (for some reason) when running your app.
- do you happen to know any of the Intel XDK devs? anyone who hangs out at
Apache Cordova mailing lists?
> 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}
>
>
>
>/* 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);
>
> {code}
> Works
> {code}
>
> src="http://debug-software.intel.com/target/target-script-min.js#QhYeZC6N-jY-XBnNnuS5DqN6Ti72PEzRd1Oeu_TKT9g";>
>
>
>/* 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);
>
> {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)
[jira] [Commented] (CB-5731) Windows Phone 8 fails to access remote urls
[
https://issues.apache.org/jira/browse/CB-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867343#comment-13867343
]
Patrick Mueller commented on CB-5731:
-
Sorry, not quite sure if a weinre bug is being reported here or not; if so, you
can open a bug directly against weinre [1] or just provide more detail.
Since cross-origin is coming up in the conversation, figure I'd mention that
weinre does cross-origin requests itself just for basic operation. The weinre
server implements CORS bits, and all that stuff has worked for quite a while -
but it wouldn't surprise me if something doesn't work right on some platform.
weinre also hooks XHR, so ... that could be a problem as well, but it seems
like it's generally worked well for most folks - although there were some
recent issues reported against WP8 [2].
[1]
https://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12312420&components=12316604&issuetype=1
[2]
https://issues.apache.org/jira/browse/CB-5203?jql=project%3DCB%20and%20component%3Dweinre
> Windows Phone 8 fails to access remote urls
> ---
>
> Key: CB-5731
> URL: https://issues.apache.org/jira/browse/CB-5731
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.3.0
>Reporter: John McLear
>Assignee: Jesse MacFadyen
> Attachments: BrokenXDKXHRDemo.zip
>
>
> Doing a very simple:
> {code:javascript}
> $.get("http://google.com";, function(){alert("yay")});
> {code}
> Fails on Windows Phone 8.
> Basically Cross domain requests don't work, this includes when an explicit
> and/or wildcard exclusion is set in config.xml allowed domains
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5219) weinre disconnects when history.replaceState is used
[
https://issues.apache.org/jira/browse/CB-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831420#comment-13831420
]
Patrick Mueller commented on CB-5219:
-
I had assumed once [bug 5203|https://issues.apache.org/jira/browse/CB-5203] was
fixed, this would be fixed this as well. Sorry, shoulda linked them or
something.
Have you been able to test the fix of bug 5203 yet? Or do we know they're
different? I'll ask Sergei to look at this if there's still work to do - he's
the WP expert.
> weinre disconnects when history.replaceState is used
>
>
> Key: CB-5219
> URL: https://issues.apache.org/jira/browse/CB-5219
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.1.0
> Environment: Windows 8, Visual Studio 2012
>Reporter: Björn Andersson
>Assignee: Patrick Mueller
>
> I got an app that uses weinre and when developing on Android, BB10 and iOS I
> never had any issues. But on WP8 it kept disconnect pretty much instantly
> after connecting.
> I found that if I do:
> {code}
> history.replaceState(null, 'weinre, say bye-bye', '/some-fake-url')
> {code}
> Weinre will disconnect. I've tried this with the Cordova hello world app and
> just adding in that line above disconnects weinre.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5424) Network activity doesn't show in Weinre
[ https://issues.apache.org/jira/browse/CB-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825285#comment-13825285 ] Patrick Mueller commented on CB-5424: - Yes, debug the path through your code in a desktop debugger, to see if it uses XHR. When using JSONP, libraries will often get the JSON loaded by creating a SCRIPT element and loading it into the DOM. weinre can't track that. > Network activity doesn't show in Weinre > --- > > Key: CB-5424 > URL: https://issues.apache.org/jira/browse/CB-5424 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 3.1.0 > Environment: OpenSuse 13.1, PhoneGap (latest), Android >Reporter: Federico Kereki >Assignee: Patrick Mueller > > When using Weinre for debugging, the NETWORK and TIMELINE tabs do not ever > show any information. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CB-5424) Network activity doesn't show in Weinre
[ https://issues.apache.org/jira/browse/CB-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mueller resolved CB-5424. - Resolution: Not A Problem > Network activity doesn't show in Weinre > --- > > Key: CB-5424 > URL: https://issues.apache.org/jira/browse/CB-5424 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 3.1.0 > Environment: OpenSuse 13.1, PhoneGap (latest), Android >Reporter: Federico Kereki >Assignee: Patrick Mueller > > When using Weinre for debugging, the NETWORK and TIMELINE tabs do not ever > show any information. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5424) Network activity doesn't show in Weinre
[ https://issues.apache.org/jira/browse/CB-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13824997#comment-13824997 ] Patrick Mueller commented on CB-5424: - Please check the information on those tabs in the documentation http://people.apache.org/~pmuellr/weinre/docs/latest/UserInterface.html Basically, the network tab can only show XHRs, and timeline doesn't show much information and needs to be enabled to collect information anyway. If there are more specific concerns, please re-open and identify the concerns. > Network activity doesn't show in Weinre > --- > > Key: CB-5424 > URL: https://issues.apache.org/jira/browse/CB-5424 > Project: Apache Cordova > Issue Type: Bug > Components: weinre >Affects Versions: 3.1.0 > Environment: OpenSuse 13.1, PhoneGap (latest), Android >Reporter: Federico Kereki >Assignee: Patrick Mueller > > When using Weinre for debugging, the NETWORK and TIMELINE tabs do not ever > show any information. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5203) Using XmlHTTPRequest.open on WP8 raises a TypeError
[
https://issues.apache.org/jira/browse/CB-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821249#comment-13821249
]
Patrick Mueller commented on CB-5203:
-
For 2), I guess the question is whether we patch weinre to work with the
current Cordova/WP8 or not, right?
If we do fix it, the least intrusive thing that works would be best. I think
just adding a try/catch around the addEventListener() invocation is the easiest
- we won't log the XHRs correctly, but everything else should work, right?
I guess the other point would be - is there an easy fix in case people run into
the issue; and I'm guessing your "hack the target-script" is the easiest fix.
Lastly, when would we see a new, fixed Cordova/WP8?
My feeling is that we should opt for - do nothing, let people hand-patch it,
unless next Cordova/WP8 is very late.
> Using XmlHTTPRequest.open on WP8 raises a TypeError
> ---
>
> Key: CB-5203
> URL: https://issues.apache.org/jira/browse/CB-5203
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 3.1.0
> Environment: Windows Phone 7 + 8
> Windows 8, MS Visual Studio Express 2012 for Windows Phone version
> 11.0.60610.01 Update 3. .NET version 4.5.50709. Weinre 2.0.0-pre-HH0SN197
>Reporter: Björn Andersson
>Assignee: Sergey Grebnov
>
> Using the {{cordova-app-hello-world}} code on a WP8 device, connected to the
> device through weinre, trying to use XMLHTTPRequest like this:
> {code:language=javascript}
> var xhr = new XMLHttpRequest();
> xhr.open('GET', 'js/index.js', true);
> xhr.send();
> console.log(xhr.responseText);
> {code}
> An error is raised at {{xhr.open}}: {{TypeError: Object doesn't support
> property or method 'addEventListener'}}
> The same code on iOS runs through and shows me the content of {{index.js}}.
> Changing the call to:
> {code:javascript}
> var xhr = new XMLHttpRequest();
> xhr._url = 'js/index.js';
> xhr.send();
> console.log(xhr.responseText);
> {code}
> Returns the expected result.
> I also noticed that {{XMLHttpRequest.prototype.open}} does not match the code
> in {{cordovalib\XHRHelper.cs}}:
> {code:title=XMLHttpRequest.prototype.open|javascript}
> function() {
> var result;
> callBeforeHooks(hookSite, this, arguments);
> try {
> result = func.apply(this, arguments);
> } catch (e) {
> callExceptHooks(hookSite, this, arguments, e);
> throw e;
> } finally {
> callAfterHooks(hookSite, this, arguments, result);
> }
> return result;
> }
> {code}
> GitHub repository with the code I used:
> https://github.com/gaqzi/cordova-wp8-xhr-test
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5203) Using XmlHTTPRequest.open on WP8 raises a TypeError
[
https://issues.apache.org/jira/browse/CB-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820117#comment-13820117
]
Patrick Mueller commented on CB-5203:
-
Bummer; once again, hooking gets in the way. Did you find the cause?
I did a quick look and noticed that
{{HookSites.XMLHttpRequest_addEventListener}} never seems to be used; but I
suspect that's not the problem. I assume there's an issue with the code in
{{target/NetworkRequest.coffee}}? Something accessed incorrectly?
> Using XmlHTTPRequest.open on WP8 raises a TypeError
> ---
>
> Key: CB-5203
> URL: https://issues.apache.org/jira/browse/CB-5203
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 3.1.0
> Environment: Windows Phone 7 + 8
> Windows 8, MS Visual Studio Express 2012 for Windows Phone version
> 11.0.60610.01 Update 3. .NET version 4.5.50709. Weinre 2.0.0-pre-HH0SN197
>Reporter: Björn Andersson
>Assignee: Sergey Grebnov
>
> Using the {{cordova-app-hello-world}} code on a WP8 device, connected to the
> device through weinre, trying to use XMLHTTPRequest like this:
> {code:language=javascript}
> var xhr = new XMLHttpRequest();
> xhr.open('GET', 'js/index.js', true);
> xhr.send();
> console.log(xhr.responseText);
> {code}
> An error is raised at {{xhr.open}}: {{TypeError: Object doesn't support
> property or method 'addEventListener'}}
> The same code on iOS runs through and shows me the content of {{index.js}}.
> Changing the call to:
> {code:javascript}
> var xhr = new XMLHttpRequest();
> xhr._url = 'js/index.js';
> xhr.send();
> console.log(xhr.responseText);
> {code}
> Returns the expected result.
> I also noticed that {{XMLHttpRequest.prototype.open}} does not match the code
> in {{cordovalib\XHRHelper.cs}}:
> {code:title=XMLHttpRequest.prototype.open|javascript}
> function() {
> var result;
> callBeforeHooks(hookSite, this, arguments);
> try {
> result = func.apply(this, arguments);
> } catch (e) {
> callExceptHooks(hookSite, this, arguments, e);
> throw e;
> } finally {
> callAfterHooks(hookSite, this, arguments, result);
> }
> return result;
> }
> {code}
> GitHub repository with the code I used:
> https://github.com/gaqzi/cordova-wp8-xhr-test
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CB-5203) Using XmlHTTPRequest.open on WP8 raises a TypeError
[
https://issues.apache.org/jira/browse/CB-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Mueller reassigned CB-5203:
---
Assignee: Sergey Grebnov (was: Patrick Mueller)
Sergey, could you take a look at this?
> Using XmlHTTPRequest.open on WP8 raises a TypeError
> ---
>
> Key: CB-5203
> URL: https://issues.apache.org/jira/browse/CB-5203
> Project: Apache Cordova
> Issue Type: Bug
> Components: weinre
>Affects Versions: 3.1.0
> Environment: Windows Phone 7 + 8
> Windows 8, MS Visual Studio Express 2012 for Windows Phone version
> 11.0.60610.01 Update 3. .NET version 4.5.50709. Weinre 2.0.0-pre-HH0SN197
>Reporter: Björn Andersson
>Assignee: Sergey Grebnov
>
> Using the {{cordova-app-hello-world}} code on a WP8 device, connected to the
> device through weinre, trying to use XMLHTTPRequest like this:
> {code:language=javascript}
> var xhr = new XMLHttpRequest();
> xhr.open('GET', 'js/index.js', true);
> xhr.send();
> console.log(xhr.responseText);
> {code}
> An error is raised at {{xhr.open}}: {{TypeError: Object doesn't support
> property or method 'addEventListener'}}
> The same code on iOS runs through and shows me the content of {{index.js}}.
> Changing the call to:
> {code:javascript}
> var xhr = new XMLHttpRequest();
> xhr._url = 'js/index.js';
> xhr.send();
> console.log(xhr.responseText);
> {code}
> Returns the expected result.
> I also noticed that {{XMLHttpRequest.prototype.open}} does not match the code
> in {{cordovalib\XHRHelper.cs}}:
> {code:title=XMLHttpRequest.prototype.open|javascript}
> function() {
> var result;
> callBeforeHooks(hookSite, this, arguments);
> try {
> result = func.apply(this, arguments);
> } catch (e) {
> callExceptHooks(hookSite, this, arguments, e);
> throw e;
> } finally {
> callAfterHooks(hookSite, this, arguments, result);
> }
> return result;
> }
> {code}
> GitHub repository with the code I used:
> https://github.com/gaqzi/cordova-wp8-xhr-test
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5219) weinre disconnects when history.replaceState is used
[
https://issues.apache.org/jira/browse/CB-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812276#comment-13812276
]
Patrick Mueller commented on CB-5219:
-
That was a good experiment to try!
Yeah, posting to the PG m/l is the best approach at the moment.
Seems to me like replaceState() is going to fire the location url changed event
thingee. Perhaps someone is hooking that event and doing something ...
inconvenient
> weinre disconnects when history.replaceState is used
>
>
> Key: CB-5219
> URL: https://issues.apache.org/jira/browse/CB-5219
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.1.0
> Environment: Windows 8, Visual Studio 2012
>Reporter: Björn Andersson
>Assignee: Patrick Mueller
>
> I got an app that uses weinre and when developing on Android, BB10 and iOS I
> never had any issues. But on WP8 it kept disconnect pretty much instantly
> after connecting.
> I found that if I do:
> {code}
> history.replaceState(null, 'weinre, say bye-bye', '/some-fake-url')
> {code}
> Weinre will disconnect. I've tried this with the Cordova hello world app and
> just adding in that line above disconnects weinre.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5219) weinre disconnects when history.replaceState is used
[
https://issues.apache.org/jira/browse/CB-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808751#comment-13808751
]
Patrick Mueller commented on CB-5219:
-
Forgot to mention that you should also report this on some kind of WP8 support
forum at MS - it would be interesting to know what replaceState() is doing
under the covers!
> weinre disconnects when history.replaceState is used
>
>
> Key: CB-5219
> URL: https://issues.apache.org/jira/browse/CB-5219
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.1.0
> Environment: Windows 8, Visual Studio 2012
>Reporter: Björn Andersson
>Assignee: Patrick Mueller
>
> I got an app that uses weinre and when developing on Android, BB10 and iOS I
> never had any issues. But on WP8 it kept disconnect pretty much instantly
> after connecting.
> I found that if I do:
> {code}
> history.replaceState(null, 'weinre, say bye-bye', '/some-fake-url')
> {code}
> Weinre will disconnect. I've tried this with the Cordova hello world app and
> just adding in that line above disconnects weinre.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5219) weinre disconnects when history.replaceState is used
[
https://issues.apache.org/jira/browse/CB-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808745#comment-13808745
]
Patrick Mueller commented on CB-5219:
-
If it says IE Mobile 10.0, then according to caniuse, it must be replaceState()
must be available. Testing with hello world would seem to confirm that.
Just want to make sure that, after a replaceState() call, everything else is
fine, just weinre is dead. Can you add some code after the replaceState() -
whatever you can check - either a console.log(), update a DOM element somehow,
etc. Sometimes when a "fatal error" occurs, weinre dies, and so does the rest
of the app, but it's not noticeable because the web view doesn't change.
Assuming the app is still alive after the replaceState() call, it smells like
perhaps the replaceState() call is cancelling XHRs or timers or something. At
that point, I have no way of checking, not having a WP8 device. I'd post a
note up on the phonegap google group [1] asking for someone with WP8 experience
to help out. There were some MS devs doing some weinre work at one time,
hopefully they can help out.
If replaceState() is in fact killing weinre somehow, one possible fix would be
to monkeypatch replaceState() to call the original replaceState(), and then get
the weinre stuff running once again - whatever that means.
[1] https://groups.google.com/forum/#!forum/phonegap
> weinre disconnects when history.replaceState is used
>
>
> Key: CB-5219
> URL: https://issues.apache.org/jira/browse/CB-5219
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.1.0
> Environment: Windows 8, Visual Studio 2012
>Reporter: Björn Andersson
>Assignee: Patrick Mueller
>
> I got an app that uses weinre and when developing on Android, BB10 and iOS I
> never had any issues. But on WP8 it kept disconnect pretty much instantly
> after connecting.
> I found that if I do:
> {code}
> history.replaceState(null, 'weinre, say bye-bye', '/some-fake-url')
> {code}
> Weinre will disconnect. I've tried this with the Cordova hello world app and
> just adding in that line above disconnects weinre.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5219) weinre disconnects when history.replaceState is used
[
https://issues.apache.org/jira/browse/CB-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808445#comment-13808445
]
Patrick Mueller commented on CB-5219:
-
caniuse says you can't use it: http://caniuse.com/#feat=history
I think. Unless WP8 == "IE Mobile 10.0".
I wonder if you using a shim which is reloading the page or something?
> weinre disconnects when history.replaceState is used
>
>
> Key: CB-5219
> URL: https://issues.apache.org/jira/browse/CB-5219
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 3.1.0
> Environment: Windows 8, Visual Studio 2012
>Reporter: Björn Andersson
>Assignee: Patrick Mueller
>
> I got an app that uses weinre and when developing on Android, BB10 and iOS I
> never had any issues. But on WP8 it kept disconnect pretty much instantly
> after connecting.
> I found that if I do:
> {code}
> history.replaceState(null, 'weinre, say bye-bye', '/some-fake-url')
> {code}
> Weinre will disconnect. I've tried this with the Cordova hello world app and
> just adding in that line above disconnects weinre.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
