I have newest Ripple Emulator installed (newest available in Chrome Store) and everything works just fine, except events. None of them fires (not only deviceready as in some other Stack Overflow question, none).
Neither manually (using Events pane) nor automatically (deviceready) fired.
When I use manual method, Ripple writes a line to the console, that it is firing an event, but nothing actually happens. My application does not react at all. I have backbutton event bind and it is not working in Ripple. And application stopped working at all, when I moved its init part to deviceready event, as it is not being fired. Of course, on target device everything is fine, so code should be correct.
What can be causing such behavior and is there any workaround for it?
EDIT: I have Ripple Emulator (Beta) 0.9.15 installed as Chrome Extension on Windows 7. All is just fine on destination device, so JS code (events handlers) should be fine.
After deeper investigation I've managed to solve this problem (at least partially -- some events are fired some are not). In my case it was a missing .js (PhoneGap source) file problem.
The key to the success was to:
Actually have PhoneGap / Cordova JS file placed in your app content and have it correctly referenced (valid path and file name) in your source files.
Have source file in correct version (2.0.0) as of writing this.
First can be especially confusing for PhoneGap Build users, which are instructed to remove source file. Reference in source file (<script type="text/javascript" src="cordova.js"></script>) should be untouched, but file, it references, should not exits. PhoneGap Build will inject this file (in proper version) during compile / build process.
This is fine for PhoneGap, but completely wrong for Ripple. If you want Ripple to be fully functional and be able to fire events (at least certain), you should leave that file in place. I found out, that this does not interfere PhoneGap at all. Apps are builded without problems, with and without that file in place.
Second is also important. I found out, that current version of Ripple is build basing on PhoneGap API 2.0.0, which is very, very old against currently available PhoneGap API 3.0.0. So, to have Ripple working nearly without glitches, you have to [browse PhoneGap repository(http://phonegap.com/install/) and grab PhoneGap 2.0.0 sources, released 20 Jul 2012 and extract cordova.js files out of it. Then place it in source folder of your webapp, add correct reference to it and try Ripple then.
At least some events should now be fired (some, like deviceready) may still fail.
Also, keep in mind, that everything, including event handlers, must be defined in a deviceready event listener code, or the whole thing will fail.
Ripple's JIRA issues, that might be related:
Support for the last version of PhoneGap,
Ripple Emulator under Windows doesn't fire events,
Ripple should check, if phonegap.js / cordova.js files really exists.
BTW: if you open up browser's console and manually fire an event you'll see a proper notice written to console by Ripple. Which means, that Ripple thinks, if fires an even on an emulated webapp, but it actually doesn't fire it.
Related
I am currently working on a new frontend javascript framework. In past few days I refactored the DOM updater and few another code to look nicer and to get rid of some memory leaks when DOM elements stayed detached in memory.
Unfortunately, Safari on both, iPhone and iPad 2 started crashing now from unknown reason (the rest of browsers I am testing on are fine
windows:
IE10emu/11, edge 14, chrome, opera, FF - latest versions
android:
Webview 4, 38, chrome, opera, ff - latest versions
and there is no problem).
I tried to debug it with remote debugging using the Chrome on Windows and ios_webkit_debug_proxy but unfortunately it does not show anything to me.
I am almost convienced the problem occurs when I am working with the main DOM document or with the shadow DOM document.
What is strange: when I switch logging to console on (there is extensive logging
feature in the framework) just for the DOM updater module and use the remote debug feature, everything seems to be working fine (except its slow of course) and it does not crash anymore so I can't even see when it crashes.
As I have no Mac even the Apple dev license I am looking for help of somebody who owns Mac and have some dev experience. I would like to know if it is possible to somehow debug these kind of unexpected crashes or at least if it is possible to get the reason why it is crashing (some kind of safari log?) - memory leaks, out of memory... whatever what can help me to do some workaround.
The previous version was working fine. Compared to it I am not doing anything special, especially when manipulating the DOM but the code is reordered, placed in more functions / methods and optimized a little bit.
The working (less or more :) version can be found here: http://ajsfw.azurewebsites.net/
The problematic version can be found here: http://ajsdoc.azurewebsites.net/ with logging switched off (i can switch on if necessary)
Sources for the working code can be found here: https://github.com/atomsoftwarestudios/ajsdoc.
I can also provide new, problematic sources if necessary but I don't want to push them to the main until it will get fixed so I can i.e. fork or send it as zipped package. The problem is it is a visual studio solution so bit incompatible with Mac at this time :) But I am pretty sure we can find a way.
The code is quiet complicated already and it will probably require bit of coopeartion by my side to find what is going on.
Hope you can help.
Update (problem resolved):
It was crashing on adding/removing "ontouchmove" event listeners.
I am using multiple HTML documents (document.implementation.createHTML) for templates and the main document (window.document) as a managed render target. When I loaded templates to the "shadow dom" using the innerHTML the ontouch... attribute assigned to the template tag was causing the problem so before I set the template innerHTML I rename it and later during rendering to the main DOM I addEventListener with the original name.
What is strange: before refactoring it didn't matter the event listener was registered in the template "shadow DOM". But I also added some new features so maybe one of them is causing it. Hard to debug, especially when the browser is crashing. Important is it works like charm again even with small complication in the code.
Results can be seen on links provided before, ajsdoc... is with logging so slower (slow as hell with IE10/11), ajsfw if unoptimized (unminimized) release without logging so faster.
Fixed sources commited if sbdy is interrested
So I have finally obtained some crash logs from Safari.
It is crashing on adding "ontouchmove" event listener. Now I have to figure out why it didn't crash in previous version and register it in a different time.
So, just to summarise where the problem was, I am using multiple HTML documents (document.implementation.createHTML) for templates and the main document (window.document) as a managed render target. When I loaded templates to the "shadow Dom" using the innerHTML the ontouch... attribute assigned to the template tag was causing the problem so before I set the template innerHTML I rename it and later during rendering to the main DOM I addEventListener with the original name.
What is strange: before refactoring it didn't matter the event listener was registered in the template "shadow DOM". But I also added some new features so maybe one of them is causing it. Hard to debug, especially when the browser is crashing. Important is it works like charm again even with small complication in the code.
This is more of an informational post: I've spent the past few days struggling with a non-functional geolocation app on the latest iOS 8 Beta.
At first I wasn't sure if it was isolated to iOS 8, or if it was an issue of device vs simulator, but after re-downloaded XCode 6 Beta 2 (my first download had a broken simulator for some reason), I confirmed that indeed, iOS 8 Beta 2 simulator did not seem to like my attempts at grabbing a geolocation.
At first the call didn't seem to work at all; then I made a change from including phonegap.js to including cordova.js and finally made some progress. The documentation is awful on this, as following guides in the official docs seems to lead one to believe they're interchangeable. I would suggest those with issues check that first.
Rather than running the navigator.geolocation.getCurrentPosition(....) callback functions as expected, it would instead hang and not do anything at all. Sometimes navigating away from the page and back to it would force the error callback, but it was very inconsistent. After setting a { timeout: 5000 } option, it seemed to keep timing out every call. There were no errors to the console, no errors in XCode, nothing. The success function just would not run, period, and neither would the error callback if I didn't explicitly timeout after X seconds. This is an error isolated to the iOS 8 Beta, so nothing of concern to most (yet), but I felt I should post this in case someone ran into it. I'll also be posting on the Apple Dev Center.
It's a known issue and is fixed here:
https://github.com/apache/cordova-plugin-geolocation/commit/4102a332b0c6b0c3513370a4c030a32e46a51e10#commitcomment-7791523
Just tested it in iOS8, it works.
Run the following command in platforms/ios folder of your phonegap project:
cordova plugin rm org.apache.cordova.geolocation
cordova plugin add https://github.com/apache/cordova-plugin-geolocation.git
For some reason it removes the CDVLocation.m from the compilation list, you need to revert that.
The entries In XXX.xcodeproj/project.pbxproj:
979B00CA27D6412CB8C6CF74 /* CDVLocation.m in Sources / = {isa = PBXBuildFile; fileRef = E3B4F7C4AF8242A09E9BF8C1 / CDVLocation.m */; };
979B00CA27D6412CB8C6CF74 /* CDVLocation.m in Sources */,
Without these 2 lines, the plugin is not available to use in the app.
If you have that file in source control just revert the deletions related to CDVLocation.m in XXX.xcodeproj/project.pbxproj.
If not try add CDVLocation.m to the Compile Sources step in the Build Phases in the project settings.
I'm using weinre to be able to make remote debug on an app being executed on an android emulator, running on Mac OS X (latest version).
Context (eventually necessary):
The current AVD (Android Virtual Device) that I'm using is:
Device: Nexus 4 (4.7", 768 x 1280: xhdpi)
Target: Android 2.3.3 - API Level 10
Javascript Framework: Dojo, v1.9
Actual Problem:
I'm trying to initialize a method from the remote console (the weinre), but once I started calling it I get the respective output:
1st method call:
SyntaxError: Parse error
2nd method call:
TypeError: Result of expression 'lang' [undefined] is not an object.
3rd method call:
undefined
And from this point on, the method that I'm trying to call, will always give an undefined output.
I know that the first error is giving because of an array that I'm defining it. Namely:
var requiredLibraries = ["app/webpage",
"dojo/_base/window",
"dojo/dom-construct",
"dijit/registry",
"dojo/on",
"dojox/mobile",
"dojox/mobile/deviceTheme",
"dojox/mobile/compat",
"dojo/domReady!"
];
But I don't see any parse error at all. In fact, I've already passed my code through jslint and it's valid.
I've tried other android devices, other versions, namely, version 4.4, but in vain. Every time I get the same result.
NOTE: Only on Android devices/Android Emulators. I have zero problems when testing the app on a Desktop browser or iOS Devices/iOS Simulators.
Any hint?
You will first need to address this point in the DOJO FAQ:
I can’t seem to run Dojo Mobile pages on Android devices when using
libraries like PhoneGap, what am I doing wrong?
There is a known bug in the Android WebKit browser implementation that
does not allow files starting with an underscore ‘_’ character to be
loaded from local file system (for example, when using Dojo Mobile in
conjunction with PhoneGap to create a native app). The way around this
problem is to create a built version of your files (you’ll want to do
this anyway for performance).
FAQ: http://dojotoolkit.org/reference-guide/1.9/dojox/mobile/faq.html
Confirmation of this problem:
http://developer.appcelerator.com/question/144171/using-dojo-mobile-and-filenames-with-
Follow this build tutorial to create single javascript file build of your DOJO app which will do away with the individual javascript files that start with underscores:
http://dojotoolkit.org/documentation/tutorials/1.9/build/
Assuming you can build DOJO app ok then you need to follow this for integrating with Phonegap/Cordova:
https://dojotoolkit.org/documentation/tutorials/1.9/dojox_app/contactsCordova/
*If you have a problem using deviceTheme.js, notice in the middle of the page how it shows what your Phonegap/Cordova index.html file should look like:
// Your device Theme
<script src="{path_to_dojox}/dojox/mobile/deviceTheme.js"></script>
// Loads cordova
<script src="cordova.js"></script>
// Loads DOJO
<script src="{path_to_dojo}/dojo/dojo.js" data-dojo-config="app: {debugApp: 1}, async: true"></script>
// DOJO then uses this require statement to load your built DOJO app
<script>
require(["contactsApp/contacts"]);
</script>
Original thoughts helping #nffdiogosilva work through this before we took it offline:
This is mostly a debugging issue where you need to isolate the moving parts and verify your assumptions step by step. Ensure that nothing more basic that you are assuming works is not actually broken. Perhaps the dojo.js library or the initial instantiation of you dojo app object? Also, are you using any other javascript libraries?
In our other thread I mentioned how I used Weinre to figure out that my Sencha app object wouldn't load on Android 2.3. The Sencha library itself seemed to load ok but the boilerplate call to create my Sencha app object would hang for a bit and then not load and my UI didn't render at all (white screen!). I figured this out by doing some incremental console.log traces as well as commenting out some of my different javascript includes until the problem became clear. It worked fine on Android 4+ though so maybe it is a different problem in this case.
I'm trying to write a Firefox extension that intercepts a certain HTTP request and return static content without the request making it to the actual server (similar to AdBlock).
I've looked up the tutorials and I've got a basic file layout. I've also worked out that I need to use the nsITraceableChannel API and add an observer to do what I want and I have example code for that.
Problem is, where do I actually put this code? And when is my extension actually loaded and executed? Is it running constantly and asynchronously in the background or is it loaded per page view?
The documentation doesn't seem very clear on this. This extension won't need a GUI so I don't need the layouting XUL files (or do I?). I tried writing some XPCOM (I don't think I did it right though) component, registered it in chrome.manifest but it doesn't seem to run.
Can anyone explain exactly how the Firefox extensions work and where should I put my actual JavaScript code to monitor requests? Or have I got the whole idea of what an extension is wrong? Is there a difference between add-ons, extensions and plugins?
Concerning the difference between add-ons, extensions and plugins you should look at this answer. But in general, you seem to have the correct idea.
The problem is, there are currently three very different types of extensions:
Classic extensions (not restartless): these will typically overlay the browser window and run code from this overlay. Since there is one overlay per window, there will be as many code instances as browser windows. However, classic extensions can also register an XPCOM component (via chrome.manifest as of Gecko 2.0). This component will be loaded on first use and stay around for the entire browsing session. You probably want your component to load when the browser starts, for this you should register it in the profile-after-change category and implement nsIObserver.
Restartless extensions, also called bootstrapped extensions: these cannot register overlays which makes working with the browser UI somewhat more complicated. Instead they have a bootstrap.js script that will load when the extension is activated, this context will stay around in background until the browser is shut down or the extension is disabled. You can have XPCOM components in restartless extensions as well but you will have to register them manually (via nsIComponentRegistrar.registerFactory() and nsICategoryManager.addCategoryEntry()). You will also have to take care of unregistering the component if the extension is shut down. This is unnecessary if you merely need to add an observer, nsIObserverService will take any object implementing nsIObserver, not only one that has been registered as an XPCOM component. The big downside is: most MDN examples are about classic extensions and don't explain how you would do things in a restartless extension.
Extensions based on the Add-on SDK: these are based on a framework that produces restartless extensions. The Add-on SDK has its own API which is very different from what you usually do in Firefox extension - but it is simple, and it mostly takes care of shutting down the extension so that you don't have to do it manually. Extensions here consist of a number of modules, with main.js loading automatically and being able to load additional modules as necessary. Once loaded, each module stays around for as long as the extension is active. They run sandboxed but you can still leave the sandbox and access XPCOM directly. However, you would probably use the internal observer-service module instead.
I have a NPAPI plugin which I have written and been using for some time with Firefox 3.x with no problems.
The object is defined as follows -
<object class="someClass" id="pluginobj" type="application/x-plugintype"></object>
I then call methods on it using the following format -
if( document.getElementById("pluginobj") != null )
{
document.getElementById("pluginobj").someMethod(someParams));
}
This is how I understand it should be done and has always worked fine. However, I recently installed this same plugin on a Windows 7 machine (with the same version of Firefox) and it now fails to find the functions defined in the plugin, so I get the following error -
Error: document.getElementById("pluginobj").someMethod is not a function
Nothing has changed at all within the plugin, this errors occurs for any method that is called, not a particular one, and it still works fine on Windows XP machines with no problems.
Very confused! Could anyone help? Thanks.
Note: I've also tried logging inside my plugin and it appears it's not even getting in to the NP_Initialize and NP_GetEntryPoints methods.
I have seen some suggestions around that it could be to with dependencies and libraries being linked to the plugin, but i'm not sure what could be missing on win 7?
Dependency Walker is showing a error saying that the "side-by-side configuration information is incorrect"?
Are you linking to other DLL files from your npapi plugin? Windows 7 works differently in how it finds DLL files, though I don't know the details. The times I've seen this with plugins in the past the problem was that on windows 7 one of the dll files couldn't be found. You could try copying dependency dll files to your system32 directory (not permanently, just to see if that's the issue). I would expect that there it would be able to find it.
If that's the issue, I unfortunately am not certain how to fix it, but it might help.
Another possibility based on the side-by-side configuration issue thing is that your visual studio project is creating a manifest that is telling windows that it requires a specific version of one of the DLLs that isn't there on windows 7. See: http://buffered.io/2008/05/17/resolving-side-by-side-configuration-issues/
I think I've resolved that issue in plugins before by disabling the manifest. I'm not sure; I've never had this issue with the way that FireBreath generates npapi plugin dlls, so I haven't needed to worry about it in the last year. You might consider looking at FireBreath, which works on both IE and Firefox (activex and npapi) and has a very good community for tracking down issues like this.