Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: weinre
    • Labels:
      None
    • Environment:

      ubuntu/windows

      Description

      weinre doesn't work in strict mode ,because it trys to access "func.caller" which isn't allowed in strict mode

        Issue Links

          Activity

          Hide
          Patrick Mueller added a comment -

          Is that the only issue w/strict mode? Wondering what ALL the hits are to get weinre to work in strict mode. Dealing with console evaluations seems like another obvious place that could have hits here.

          Show
          Patrick Mueller added a comment - Is that the only issue w/strict mode? Wondering what ALL the hits are to get weinre to work in strict mode. Dealing with console evaluations seems like another obvious place that could have hits here.
          Hide
          hongbo lu added a comment -

          for now, it's the only issue, I saw in target-script-min.js, at line 904, you have :

          func = args.callee;

          which causes problem. because callee is not accessible in function that uses strict mode.

          Show
          hongbo lu added a comment - for now, it's the only issue, I saw in target-script-min.js, at line 904, you have : func = args.callee; which causes problem. because callee is not accessible in function that uses strict mode.
          Hide
          Peter Paul Elfferich added a comment -

          Seems to be a regression as I'm pretty sure I've used Weinre successfully with strict mode JavaScript in the past (about a year ago). That being said; is there any way I could easily experiment with older versions of Weinre? I really need a working console right now

          Show
          Peter Paul Elfferich added a comment - Seems to be a regression as I'm pretty sure I've used Weinre successfully with strict mode JavaScript in the past (about a year ago). That being said; is there any way I could easily experiment with older versions of Weinre? I really need a working console right now
          Hide
          Patrick Mueller added a comment -

          All weinre versions are available here: http://people.apache.org/~pmuellr/weinre/builds/

          But I don't think this is a regression. I think weinre has always had some number of issues with "strict mode".

          If you find some older version of weinre DOES work where the latest doesn't, please post back here, with the version of weinre that DOES work.

          Show
          Patrick Mueller added a comment - All weinre versions are available here: http://people.apache.org/~pmuellr/weinre/builds/ But I don't think this is a regression. I think weinre has always had some number of issues with "strict mode". If you find some older version of weinre DOES work where the latest doesn't, please post back here, with the version of weinre that DOES work.
          Hide
          Peter Paul Elfferich added a comment -

          Thanks, gave them a quick go and found you are correct; this is not a regression. I guess we only just started to move all of our code into strict mode at the time I last remembered Weinre to work.

          Do you have time to look at this issue anytime soon Patrick or should I rather consider getting involved myself? Do you reckon this will be a lot of work to fix in the first place? I guess it could get complicated if you really depend on things like callee and caller.

          Show
          Peter Paul Elfferich added a comment - Thanks, gave them a quick go and found you are correct; this is not a regression. I guess we only just started to move all of our code into strict mode at the time I last remembered Weinre to work. Do you have time to look at this issue anytime soon Patrick or should I rather consider getting involved myself? Do you reckon this will be a lot of work to fix in the first place? I guess it could get complicated if you really depend on things like callee and caller.
          Hide
          Patrick Mueller added a comment -

          I've completely avoided the whole "strict mode" thing, and so know almost nothing about it. If we can get weinre to work with it, somehow, sounds like a good thing. I don't know where to start. Perhaps the simplest possible example of a "strict mode" web application that fails is the place to begin.

          Show
          Patrick Mueller added a comment - I've completely avoided the whole "strict mode" thing, and so know almost nothing about it. If we can get weinre to work with it, somehow, sounds like a good thing. I don't know where to start. Perhaps the simplest possible example of a "strict mode" web application that fails is the place to begin.
          Hide
          hongbo lu added a comment -

          it's simple to reproduce it, create an index.html:
          <html>
          <head></head>
          <body>
          <script type="text/javascript" src="http://localhost:8080/target/target-script-min.js#anonymous"></script>
          <script src="http://ajax.googleapis.com/ajax/libs/dojo/1.8.0/dojo/dojo.js"></script>

          <script type="text/javascript">
          'use strict';
          require(["dojo/request"],function(request){
          dojo.xhrGet(

          { url:"./index.html" }

          ).then(function(d)

          { alert(d); }

          );
          })
          </script>
          </body>
          </html>

          while trying to use httpRequest, it throws error:

          TypeError: Illegal access to a strict mode caller function.

          the error lines are:

          in Google Chrome:

          modjewel.define.getTrace target-script-min.js:1049
          StackTrace target-script-min.js:1008
          modjewel.define.module.exports.NetworkRequest.installNativeHooks.HookSites.XMLHttpRequest_open.addHooks.before target-script-min.js:2820
          modjewel.define.callBeforeHooks target-script-min.js:567
          modjewel.define.hookedFunction target-script-min.js:543

          in Firefox:

          TypeError: func is undefined
          [Break On This Error]

          hookedFunction.displayName = func.displayName || func.name; target...-min.js (line 554)

          Show
          hongbo lu added a comment - it's simple to reproduce it, create an index.html: <html> <head></head> <body> <script type="text/javascript" src="http://localhost:8080/target/target-script-min.js#anonymous"></script> <script src="http://ajax.googleapis.com/ajax/libs/dojo/1.8.0/dojo/dojo.js"></script> <script type="text/javascript"> 'use strict'; require( ["dojo/request"] ,function(request){ dojo.xhrGet( { url:"./index.html" } ).then(function(d) { alert(d); } ); }) </script> </body> </html> while trying to use httpRequest, it throws error: TypeError: Illegal access to a strict mode caller function. the error lines are: in Google Chrome: modjewel.define.getTrace target-script-min.js:1049 StackTrace target-script-min.js:1008 modjewel.define.module.exports.NetworkRequest.installNativeHooks.HookSites.XMLHttpRequest_open.addHooks.before target-script-min.js:2820 modjewel.define.callBeforeHooks target-script-min.js:567 modjewel.define.hookedFunction target-script-min.js:543 in Firefox: TypeError: func is undefined [Break On This Error] hookedFunction.displayName = func.displayName || func.name; target...-min.js (line 554)
          Hide
          hongbo lu added a comment -

          my weinre version is : version: 2.0.0-pre-H41DGW8S-incubating
          installed via NPM (NodeJs)

          Show
          hongbo lu added a comment - my weinre version is : version: 2.0.0-pre-H41DGW8S-incubating installed via NPM (NodeJs)
          Hide
          Walter Rumsby added a comment -

          Looking into this, it seems like the problem is caused by the private getTrace function defined in the StackTrace module.

          My guess is that when Weinre instruments the code it instruments strict mode code where accessing caller is illegal. Walking the call stack (to get the stack trace) and strict mode are at odds with each other, so I'm not really sure how you could provide a strict mode compliant implementation without there being an endorsed way of accessing the call stack. Maybe a browser extension could provide a solution here (I'm speculating, I have no idea if that's possible)?

          The current situation isn't great. I want to write my JavaScript using strict mode, it helps identify errors and potential problems every day saving me a great deal of time. I also want to use Weinre for those times I need to debug on a tablet, etc.

          Would providing a distribution of Weinre that doesn't provide a Stack Trace be feasible? e.g. Folks who use strict mode would load target-script-no-stacktrace-min.js rather than target-script-min.js.

          Show
          Walter Rumsby added a comment - Looking into this, it seems like the problem is caused by the private getTrace function defined in the StackTrace module. My guess is that when Weinre instruments the code it instruments strict mode code where accessing caller is illegal. Walking the call stack (to get the stack trace) and strict mode are at odds with each other , so I'm not really sure how you could provide a strict mode compliant implementation without there being an endorsed way of accessing the call stack. Maybe a browser extension could provide a solution here (I'm speculating, I have no idea if that's possible)? The current situation isn't great. I want to write my JavaScript using strict mode, it helps identify errors and potential problems every day saving me a great deal of time. I also want to use Weinre for those times I need to debug on a tablet, etc. Would providing a distribution of Weinre that doesn't provide a Stack Trace be feasible? e.g. Folks who use strict mode would load target-script-no-stacktrace-min.js rather than target-script-min.js .
          Hide
          Patrick Mueller added a comment -

          Anyone can provide a distribution of weinre that does whatever.

          I would be in favor of adding code to weinre to enable/disable strict mode access; likely we would "build" multiple versions of the target script - a new one you could use in "strict" mode.

          I just don't have any interest in figuring out what "working in strict mode" means. If you can produce a patch / pull request that "handles strict mode", in some fashion, that would be a great first step to getting this going.

          Show
          Patrick Mueller added a comment - Anyone can provide a distribution of weinre that does whatever. I would be in favor of adding code to weinre to enable/disable strict mode access; likely we would "build" multiple versions of the target script - a new one you could use in "strict" mode. I just don't have any interest in figuring out what "working in strict mode" means. If you can produce a patch / pull request that "handles strict mode", in some fashion, that would be a great first step to getting this going.
          Hide
          Jay Proulx added a comment -

          Unhandled exceptions are just bad to begin with. We probably need 2 approaches, one, throw a try/catch around that sucker. If I don't get a stack trace because the browser won't let me, it's not the end of the world.

          On the post-compile code:

          1049,1053c1049
          < try

          { < func = func.caller; < }

          catch ( ignore )

          { < // if this throws an error, we're in strict mode, and this isn't allowed, too bad for you < }


          > func = func.caller;

          Show
          Jay Proulx added a comment - Unhandled exceptions are just bad to begin with. We probably need 2 approaches, one, throw a try/catch around that sucker. If I don't get a stack trace because the browser won't let me, it's not the end of the world. On the post-compile code: 1049,1053c1049 < try { < func = func.caller; < } catch ( ignore ) { < // if this throws an error, we're in strict mode, and this isn't allowed, too bad for you < } — > func = func.caller;
          Hide
          Patrick Mueller added a comment -

          yeah, depending on the # of places that need "protection", if-checking, try-catch-wrapping, etc may be appropriate.

          I just have no idea how many of these that we need. In my nightmares, it's a bunch of places. In which case it might be easier to have strict- and non-strict- versions of some of the modules.

          Show
          Patrick Mueller added a comment - yeah, depending on the # of places that need "protection", if-checking, try-catch-wrapping, etc may be appropriate. I just have no idea how many of these that we need. In my nightmares, it's a bunch of places. In which case it might be easier to have strict- and non-strict- versions of some of the modules.
          Hide
          Jay Proulx added a comment -

          I patched that one single line, and I've been using Weinre for the afternoon without any other issues. It's possible that I didn't touch on some use cases that may still be affected, but it may only be a handful of places.

          Show
          Jay Proulx added a comment - I patched that one single line, and I've been using Weinre for the afternoon without any other issues. It's possible that I didn't touch on some use cases that may still be affected, but it may only be a handful of places.
          Hide
          Peter Paul Elfferich added a comment -

          Thanks Walter and Jay! Patched my target-script-min.js with the try-catch workaround and have been able to use Weinre again ever since (though I'm sure some things will not be fully functional anymore).

          Show
          Peter Paul Elfferich added a comment - Thanks Walter and Jay! Patched my target-script-min.js with the try-catch workaround and have been able to use Weinre again ever since (though I'm sure some things will not be fully functional anymore).
          Hide
          Patrick Mueller added a comment -

          Did a quick check to see where in weinre we're using arguments, .callee and .caller.

          Do a

              cd [path-to-weinre-source]/weinre.web
          

          Then run

              grep -r "\(arguments\)\|\(\.callee\)\|\(\.caller\)" . | grep \.coffee
          

          Here is a list of the affected files:

          • modules/weinre/client/Client.coffee
          • modules/weinre/client/DOMTemplates.coffee
          • modules/weinre/client/InspectorBackendImpl.coffee
          • modules/weinre/client/InspectorFrontendHostImpl.coffee
          • modules/weinre/common/Binding.coffee
          • modules/weinre/common/Callback.coffee
          • modules/weinre/common/EventListeners.coffee
          • modules/weinre/common/Ex.coffee
          • modules/weinre/common/HookLib.coffee
          • modules/weinre/common/IDLTools.coffee
          • modules/weinre/common/MessageDispatcher.coffee
          • modules/weinre/common/StackTrace.coffee
          • modules/weinre/common/WebSocketXhr.coffee
          • modules/weinre/common/Weinre.coffee
          • modules/weinre/target/Console.coffee
          • modules/weinre/target/SqlStepper.coffee
          • modules/weinre/target/Target.coffee
          • modules/weinre/target/Timeline.coffee
          • modules/weinre/target/WiCSSImpl.coffee
          • modules/weinre/target/WiDOMImpl.coffee
          • modules/weinre/target/WiDOMStorageImpl.coffee
          • modules/weinre/target/WiInspectorImpl.coffee

          Note, this is just the weinre source, and likely only the common and target files are implicated. But there is also some injected code from Web Inspector itself, and it showed up in a different scan I did.

          Bummer.

          Show
          Patrick Mueller added a comment - Did a quick check to see where in weinre we're using arguments, .callee and .caller. Do a cd [path-to-weinre-source]/weinre.web Then run grep -r "\(arguments\)\|\(\.callee\)\|\(\.caller\)" . | grep \.coffee Here is a list of the affected files: modules/weinre/client/Client.coffee modules/weinre/client/DOMTemplates.coffee modules/weinre/client/InspectorBackendImpl.coffee modules/weinre/client/InspectorFrontendHostImpl.coffee modules/weinre/common/Binding.coffee modules/weinre/common/Callback.coffee modules/weinre/common/EventListeners.coffee modules/weinre/common/Ex.coffee modules/weinre/common/HookLib.coffee modules/weinre/common/IDLTools.coffee modules/weinre/common/MessageDispatcher.coffee modules/weinre/common/StackTrace.coffee modules/weinre/common/WebSocketXhr.coffee modules/weinre/common/Weinre.coffee modules/weinre/target/Console.coffee modules/weinre/target/SqlStepper.coffee modules/weinre/target/Target.coffee modules/weinre/target/Timeline.coffee modules/weinre/target/WiCSSImpl.coffee modules/weinre/target/WiDOMImpl.coffee modules/weinre/target/WiDOMStorageImpl.coffee modules/weinre/target/WiInspectorImpl.coffee Note, this is just the weinre source, and likely only the common and target files are implicated. But there is also some injected code from Web Inspector itself, and it showed up in a different scan I did. Bummer.
          Hide
          Patrick Mueller added a comment -

          Due to the potentially large # of changes to make, I've not made any changes at present.

          However, I have added a test case, so someone can start playing with this a bit more, if they want.

          See the commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-weinre.git;a=commit;h=588b2e90ca1e3c56599f587a1f71911f99877dfc

          Note, this commit has been main-lined into master, but I'm not doing a new build since there's no new function. To make use of this commit, you'll need to be set up to do weinre development.

          Show
          Patrick Mueller added a comment - Due to the potentially large # of changes to make, I've not made any changes at present. However, I have added a test case, so someone can start playing with this a bit more, if they want. See the commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-weinre.git;a=commit;h=588b2e90ca1e3c56599f587a1f71911f99877dfc Note, this commit has been main-lined into master, but I'm not doing a new build since there's no new function. To make use of this commit, you'll need to be set up to do weinre development.
          Hide
          colin mcdonald added a comment -

          This is affecting my use of weinre because I'm using twitter bootstrap which uses strict mode. Any workarounds or anyway I can try to help? All links to weinre are 404 I'm assuming because of it's transition to ASF.

          Thanks, Colin

          Show
          colin mcdonald added a comment - This is affecting my use of weinre because I'm using twitter bootstrap which uses strict mode. Any workarounds or anyway I can try to help? All links to weinre are 404 I'm assuming because of it's transition to ASF. Thanks, Colin
          Hide
          Patrick Mueller added a comment -

          Looks like, previously, bootstrap was built with "use strict" stripped out - https://github.com/twitter/bootstrap/issues/1655 - so you might want to open a new bug.

          Other than that, see previous comments regarding the work that I think needs to be done, or places to start looking anyway. Pull requests welcomed.

          Show
          Patrick Mueller added a comment - Looks like, previously, bootstrap was built with "use strict" stripped out - https://github.com/twitter/bootstrap/issues/1655 - so you might want to open a new bug. Other than that, see previous comments regarding the work that I think needs to be done, or places to start looking anyway. Pull requests welcomed.
          Hide
          Mihai Paun added a comment -

          @Colin, to answer your question from the weinre Google Group thread which I only received a couple of hours ago (and it shows up as deleted there), I got it working in a twbootstrap + requirejs environment but I honestly don't remember how I did it right now and sadly the source code is on the intranet at my company so I will have access to it only on Monday. Will post here if I remember and sorry that I cannot be of much help right now.

          Show
          Mihai Paun added a comment - @Colin, to answer your question from the weinre Google Group thread which I only received a couple of hours ago (and it shows up as deleted there), I got it working in a twbootstrap + requirejs environment but I honestly don't remember how I did it right now and sadly the source code is on the intranet at my company so I will have access to it only on Monday. Will post here if I remember and sorry that I cannot be of much help right now.
          Hide
          Patrick Heneise added a comment -

          Just set up a project with AngularJS which uses strict mode for everything. So weiner doesn't work here either.

          Show
          Patrick Heneise added a comment - Just set up a project with AngularJS which uses strict mode for everything. So weiner doesn't work here either.
          Hide
          Rodney Rehm added a comment -

          I've created minimal test cases at http://rodneyrehm.github.io/edge-inspect-problems/

          http://rodneyrehm.github.io/edge-inspect-problems/strict-with-hbs.html loads a handlebars template via some script via RequireJS - all of it with "use strict" - the thing works fine. So far so good.

          Calling jQuery.ajax() will cause the thing to break. If loaded via Adobe's Edge Inspect, I get an error and the thing dies. If loaded on the tablet I get the page - but the console stays empty. If I add an alert() [for the fun of it] I get some console output (but not all of it). See http://rodneyrehm.github.io/edge-inspect-problems/jquery-ajax-no-console.html and http://rodneyrehm.github.io/edge-inspect-problems/jquery-ajax-alert-console.html

          Show
          Rodney Rehm added a comment - I've created minimal test cases at http://rodneyrehm.github.io/edge-inspect-problems/ http://rodneyrehm.github.io/edge-inspect-problems/strict-with-hbs.html loads a handlebars template via some script via RequireJS - all of it with "use strict" - the thing works fine. So far so good. Calling jQuery.ajax() will cause the thing to break. If loaded via Adobe's Edge Inspect, I get an error and the thing dies. If loaded on the tablet I get the page - but the console stays empty. If I add an alert() [for the fun of it] I get some console output (but not all of it). See http://rodneyrehm.github.io/edge-inspect-problems/jquery-ajax-no-console.html and http://rodneyrehm.github.io/edge-inspect-problems/jquery-ajax-alert-console.html
          Hide
          Patrick Mueller added a comment -

          Thanks for the additional test cases!

          Have you also tried the use strict demo we started shipping a few commits ago?

          https://github.com/apache/cordova-weinre/blob/master/weinre.web/demo/weinre-demo-strict.html

          I wouldn't mind having that beefed up a bit more, if need be.

          Show
          Patrick Mueller added a comment - Thanks for the additional test cases! Have you also tried the use strict demo we started shipping a few commits ago? https://github.com/apache/cordova-weinre/blob/master/weinre.web/demo/weinre-demo-strict.html I wouldn't mind having that beefed up a bit more, if need be.
          Hide
          Rodney Rehm added a comment - - edited

          I built the test-server and ran the demo. There were no errors, the console showed:

          SQL Error 5: no such table: clicks
          doing interval stuff at Mon Apr 15 2013 09:20:54 GMT+0000 (GMT)
          [...]
          doing interval stuff at Mon Apr 15 2013 09:21:04 GMT+0000 (GMT)
          SQL Error 5: no such table: clicks


          Running the jQuery XHR test (http://rodneyrehm.github.io/edge-inspect-problems/jquery-ajax-no-console.html) I get a failure but the console now shows:

          initializing require.js
          Uncaught TypeError: Illegal access to a strict mode caller function. http://localhost/edge-inspect-problems/jquery-ajax-no-console.html 56
          Reader :: Recognize :: INFO - Script is evaluating. recognizeArticle Start
          Uncaught TypeError: Cannot read property 'tagName' of null http://localhost/edge-inspect-problems/jquery-ajax-no-console.html 308
          Uncaught Error: Load timeout for modules: hbs!template_unnormalized2,hbs!template
          http://requirejs.org/docs/errors.html#timeout http://localhost/edge-inspect-problems/libs/require.js 1754

          That tagName thing may be Android related - http://stackoverflow.com/questions/12510198/uncaught-typeerror-cannot-read-property-tagname-of-null

          Show
          Rodney Rehm added a comment - - edited I built the test-server and ran the demo. There were no errors, the console showed: SQL Error 5: no such table: clicks doing interval stuff at Mon Apr 15 2013 09:20:54 GMT+0000 (GMT) [...] doing interval stuff at Mon Apr 15 2013 09:21:04 GMT+0000 (GMT) SQL Error 5: no such table: clicks Running the jQuery XHR test ( http://rodneyrehm.github.io/edge-inspect-problems/jquery-ajax-no-console.html ) I get a failure but the console now shows: initializing require.js Uncaught TypeError: Illegal access to a strict mode caller function. http://localhost/edge-inspect-problems/jquery-ajax-no-console.html 56 Reader :: Recognize :: INFO - Script is evaluating. recognizeArticle Start Uncaught TypeError: Cannot read property 'tagName' of null http://localhost/edge-inspect-problems/jquery-ajax-no-console.html 308 Uncaught Error: Load timeout for modules: hbs!template_unnormalized2,hbs!template http://requirejs.org/docs/errors.html#timeout http://localhost/edge-inspect-problems/libs/require.js 1754 That tagName thing may be Android related - http://stackoverflow.com/questions/12510198/uncaught-typeerror-cannot-read-property-tagname-of-null
          Hide
          Patrick Mueller added a comment -

          Now I'm confused. I'm pretty sure the state I left this was use-strict demo was that it was failing somewhere, but now I'm not seeing that. Almost like "use strict" is allowing access to caller or something now. This is under a chome beta on a mac, and chrome on android. On Safari on mac, it still fails.

          Show
          Patrick Mueller added a comment - Now I'm confused. I'm pretty sure the state I left this was use-strict demo was that it was failing somewhere, but now I'm not seeing that. Almost like "use strict" is allowing access to caller or something now. This is under a chome beta on a mac, and chrome on android. On Safari on mac, it still fails.
          Hide
          Rodney Rehm added a comment -

          I've been testing on an Android 4.0.3 Stock Browser. If that helps confusing you more

          Show
          Rodney Rehm added a comment - I've been testing on an Android 4.0.3 Stock Browser. If that helps confusing you more
          Hide
          Jonathan Knapp added a comment -

          Still broken for me in "2.0.0-pre-HA5N9T49". When I make a jQuery ajax request, the deferred fails with an error about `callee` not being available in strict mode.

          For now, I have a part of the build script that changes the compiled js code from "use strict" to "do not use strict", though you could change it to any other string.

          Show
          Jonathan Knapp added a comment - Still broken for me in "2.0.0-pre-HA5N9T49". When I make a jQuery ajax request, the deferred fails with an error about `callee` not being available in strict mode. For now, I have a part of the build script that changes the compiled js code from "use strict" to "do not use strict", though you could change it to any other string.
          Show
          Patrick Mueller added a comment - fixed in commit: https://git-wip-us.apache.org/repos/asf?p=cordova-weinre.git;a=commit;h=80ca5c76f150e680102c0deea3547b0fc1040741
          Hide
          Frederico Costa Galvão added a comment -

          I've installed Weinre via npm today (version 2.0.0-pre-HG9PLCRF), and the problem still exists.
          Had to remove all 'use strict' from all libraries used in my project (which were enquire.js, jquery.qtip.js, matchMedia.js, require-text.js and underscore-string.js) to make it work. Could not find a way to debug it deeper.

          Show
          Frederico Costa Galvão added a comment - I've installed Weinre via npm today (version 2.0.0-pre-HG9PLCRF), and the problem still exists. Had to remove all 'use strict' from all libraries used in my project (which were enquire.js, jquery.qtip.js, matchMedia.js, require-text.js and underscore-string.js) to make it work. Could not find a way to debug it deeper.
          Hide
          Patrick Mueller added a comment -

          What platforms have you tried?

          weinre now ships with a "strict" demo, if you go to the server home page (http://[server]/), you can launch it directly. Would be interested to see if you can run this (press the start/stop button a few times).

          If you can host your broken app on the web somewhere, I'd be happy to try it.

          Show
          Patrick Mueller added a comment - What platforms have you tried? weinre now ships with a "strict" demo, if you go to the server home page ( http://[server]/ ), you can launch it directly. Would be interested to see if you can run this (press the start/stop button a few times). If you can host your broken app on the web somewhere, I'd be happy to try it.
          Hide
          Jonathan Knapp added a comment -

          The issue occurred while I was running my js through an Adobe DPS app on iPad.

          I'll make a note about the strict mode demo and will test it out if I get some time.

          • Jon Knapp
          Show
          Jonathan Knapp added a comment - The issue occurred while I was running my js through an Adobe DPS app on iPad. I'll make a note about the strict mode demo and will test it out if I get some time. Jon Knapp
          Hide
          Patrick Mueller added a comment -

          "Adobe DPS app on iPad" == iOS UiWebView (PhoneGap/Cordova/etc?).

          I hadn't tried on my iPad (doh), but just did, seemed to work fine. iOS 6.1.2

          Could you also try running the server with options --debug and --verbose, to see if it catches anything.

          Show
          Patrick Mueller added a comment - "Adobe DPS app on iPad" == iOS UiWebView (PhoneGap/Cordova/etc?). I hadn't tried on my iPad (doh), but just did, seemed to work fine. iOS 6.1.2 Could you also try running the server with options --debug and --verbose , to see if it catches anything.
          Hide
          Frederico Costa Galvão added a comment -

          As a matter of closure, the issue I was facing on strict mode was related to (wrong versions)(globals)(cache) on npm/node. After cleaning up I confirm it works as expected. [version=2.0.0-pre-HH0SN197]

          Show
          Frederico Costa Galvão added a comment - As a matter of closure, the issue I was facing on strict mode was related to (wrong versions) (globals) (cache) on npm/node. After cleaning up I confirm it works as expected. [version=2.0.0-pre-HH0SN197]

            People

            • Assignee:
              Patrick Mueller
              Reporter:
              hongbo lu
            • Votes:
              6 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development