I am developing for Resco Mobile CRM and I am writing custom JavaScript libraries for the application, which calculate some fields for an Order and an Order Product.
Now I am experiencing a bug where I can't retrieve the ID of an Order from the Order Product (it has a lookup to the Order), but it happens in extremely rare cases. So far I've rewriten the code to retrieve it either from the lookup field or retrive it from a script on the Order where I save the ID in a localStorage variable. I've added a lot of logs as well (that's how I found that the ID is null).
These are the cases when the bug appeared:
After a synchronization between the Resco CRM and our CRM implementation (it usually disappears after another synchronization).
At the demo day, it appeared constantly and synchronizing the device again didn't helped (but the customer has very week network).
So far I've been debugging it for days and can't replicate it. I believe it is a 'networking issue' (some date is missing when the synchronization occurs), or a crash of the application (I recently found a similar crash on Resco CRM and Resco admited it was an error on their application, but they dismissed this one).
What can you suggest me to do in this case?
Thanks.
Best regards,
Evgeni Dyulgerov
Maybe it's not the answer, but it might help you to debug it.
On Chrome DevTools, you can emulate mobile devices, an inside that option you can simulate the bandwidth as you where in a terrible network.
I've never worked before with that CMS, but it seems that you're right about timing on the info retrieval. Maybe you should think about working with promises, and until the info is not fulfilled don't do a thing.
Related
I am working on a large web application.
It's been in production now for close to 2 years.
Recently, we have started getting complaints from users regarding some weird display issues.
It seems on certain screens(random as far as I can tell), when Ajax requests being made there is a weird flickering graphic that appears.
Here is a screenshot:
I don't believe this to be a CSS/JS issue.
All of our users use the latest version of chrome
We use Kendo UI and Jquery, but no other frameworks
It happens frequently, but is unrepeatable
It affects multiple users across a number of computers
Has anyone experienced this, or something similar?
This doesn't resolve the actual problem, but fixes the issue. It appears to be an issue with the Chrome setting "User Hardware Acceleration". Shutting this off fixes the problem.
Hopefully a good performance analysis and some refactoring will fix the problem and allow me to turn this feature back on.
I am using the Gamepad API "gamepadconnected" function which is not working properly. However, the "gamepaddisconnected" function works for some reason. Upon connecting my bluetooth controller, nothing shows in the console, however, it does show the information displayed when disconnected.
What I have here is very basic and standard:
window.addEventListener("gamepadconnected", function(e) {
console.log("Controller connected");
});
window.addEventListener("gamepaddisconnected", function(e) {
console.log("Controller disconnected");
});
What am I missing here? Where did go wrong? I made sure the first focused page is the one with the scripts above. Thanks for your help.
MDN states that "If a gamepad is already connected when the page loaded, the gamepadconnected event is dispatched to the focused page when the user presses a button or moves an axis.". So your page will not always receive the gamepadconnected event when you connect the pad. https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API
So it's best to e.g. let the user press a button to get your application started. This is also useful when there are multiple gamepads connected to the computer and your application has to know which one to use.
Chrome is notorious (certainly to me after working with it!) for its, shall we say, individual implementation of the GamePad API. One issue being that as far as I'm aware, it doesn't yet support the "gamepadconnected" event robustly, and you have to poll the gamePadConnected property of the GamePad object in order to do anything sensible with connections and disconnections. A total pain I know, but this is probably a reflection of the fact that the W3C standard for this API is still in flux. You'll also find that there are other issues, such as browser X on Windows behaving differently to browser X on Linux.
I don't know if anyone's tried plugging these devices into an Android or iOS device (probably superfluous to requirements on something with a touch screen unless you're planning to port a flight sim thereto!), but I suspect even more compatibility issues will arise if these experiments are performed. If you have the ability to dive into an Android smartphone with a USB port, and tinker with JavaScript in the smartphone browser, you may find even more hilarious issues coming to light.
As for legacy joysticks (such as my 10 year old Microsoft Sidewinder Pro USB), those have their own hilarity to throw at you. I'm currently struggling to make otherwise reasonable code work with the weirdness thereof, such as an axis property in the GamePad object being assigned to, wait for it, the hat switch, which on this device is a digital data source, not an analogue one. Be aware of a tidal wave of compatibility woes heading your way as you persevere with the GamePad API, until the W3C finalises the standard.
Is there any way to consistently detect PhantomJS/CasperJS? I've been dealing with a spat of malicious spambots built with it and have been able to mostly block them based on certain behaviours, but I'm curious if there's a rock-solid way to know if CasperJS is in use, as dealing with constant adaptations gets slightly annoying.
I don't believe in using Captchas. They are a negative user experience and ReCaptcha has never worked to block spam on my MediaWiki installations. As our site has no user registrations (anonymous discussion board), we'd need to have a Captcha entry for every post. We get several thousand legitimate posts a day and a Captcha would see that number divebomb.
I very much share your take on CAPTCHA. I'll list what I have been able to detect so far, for my own detection script, with similar goals. It's only partial, as they are many more headless browsers.
Fairly safe to use exposed window properties to detect/assume those particular headless browser:
window._phantom (or window.callPhantom) //phantomjs
window.__phantomas //PhantomJS-based web perf metrics + monitoring tool
window.Buffer //nodejs
window.emit //couchjs
window.spawn //rhino
The above is gathered from jslint doc and testing with phantom js.
Browser automation drivers (used by BrowserStack or other web capture services for snapshot):
window.webdriver //selenium
window.domAutomation (or window.domAutomationController) //chromium based automation driver
The properties are not always exposed and I am looking into other more robust ways to detect such bots, which I'll probably release as full blown script when done. But that mainly answers your question.
Here is another fairly sound method to detect JS capable headless browsers more broadly:
if (window.outerWidth === 0 && window.outerHeight === 0){ //headless browser }
This should work well because the properties are 0 by default even if a virtual viewport size is set by headless browsers, and by default it can't report a size of a browser window that doesn't exist. In particular, Phantom JS doesn't support outerWith or outerHeight.
ADDENDUM: There is however a Chrome/Blink bug with outer/innerDimensions. Chromium does not report those dimensions when a page loads in a hidden tab, such as when restored from previous session. Safari doesn't seem to have that issue..
Update: Turns out iOS Safari 8+ has a bug with outerWidth & outerHeight at 0, and a Sailfish webview can too. So while it's a signal, it can't be used alone without being mindful of these bugs. Hence, warning: Please don't use this raw snippet unless you really know what you are doing.
PS: If you know of other headless browser properties not listed here, please share in comments.
There is no rock-solid way: PhantomJS, and Selenium, are just software being used to control browser software, instead of a user controlling it.
With PhantomJS 1.x, in particular, I believe there is some JavaScript you can use to crash the browser that exploits a bug in the version of WebKit being used (it is equivalent to Chrome 13, so very few genuine users should be affected). (I remember this being mentioned on the Phantom mailing list a few months back, but I don't know if the exact JS to use was described.) More generally you could use a combination of user-agent matching up with feature detection. E.g. if a browser claims to be "Chrome 23" but does not have a feature that Chrome 23 has (and that Chrome 13 did not have), then get suspicious.
As a user, I hate CAPTCHAs too. But they are quite effective in that they increase the cost for the spammer: he has to write more software or hire humans to read them. (That is why I think easy CAPTCHAs are good enough: the ones that annoy users are those where you have no idea what it says and have to keep pressing reload to get something you recognize.)
One approach (which I believe Google uses) is to show the CAPTCHA conditionally. E.g. users who are logged-in never get shown it. Users who have already done one post this session are not shown it again. Users from IP addresses in a whitelist (which could be built from previous legitimate posts) are not shown them. Or conversely just show them to users from a blacklist of IP ranges.
I know none of those approaches are perfect, sorry.
You could detect phantom on the client-side by checking window.callPhantom property. The minimal script is on the client side is:
var isPhantom = !!window.callPhantom;
Here is a gist with proof of concept that this works.
A spammer could try to delete this property with page.evaluate and then it depends on who is faster. After you tried the detection you do a reload with the post form and a CAPTCHA or not depending on your detection result.
The problem is that you incur a redirect that might annoy your users. This will be necessary with every detection technique on the client. Which can be subverted and changed with onResourceRequested.
Generally, I don't think that this is possible, because you can only detect on the client and send the result to the server. Adding the CAPTCHA combined with the detection step with only one page load does not really add anything as it could be removed just as easily with phantomjs/casperjs. Defense based on user agent also doesn't make sense since it can be easily changed in phantomjs/casperjs.
I've found users are not getting updates to my Chrome App because they keep the app open, and let their browser get out of date (i.e. the hamburger icon is red for a prolonged period).
Empirically it seems the chrome.runtime.onUpdateAvailable event is not triggered when the browser itself is out of date.
At a minimum I'd like to display an in-App warning UI to tell the user the need to restart the browser to get updates (and eventually, block usage of the app altogether until updated). It seems like chrome.runtime.onBrowserUpdateAvailable was intended exactly for this, however that event is marked as long deprecated, but the replacement isn't good for this use case: chrome.runtime.onRestartRequired is only supported on Chrome OS, for kiosk apps.
The relevant bugs, http://crbug.com/177029 and http://crbug.com/242983 didn't really explain if onBrowserUpdateAvailable ever worked on non-ChromeOS versions, and if so, why it made sense to deprecate it without replacement on those other OSes.
Am I going about this all wrong? should I just use the deprecated event? Do people know that event works reliably for this scenario across OSes?
(I haven't experimented with the APIs in great depth, and only have the documentation to go on, as browser updates are sufficiently infrequent it's going to be a very long experiment to run, and API behavior may change across versions during that experiment anyway).
If you need users to update to your latest client in order to work with your non-backward-compatible server, then you have complete control over the situation: detect the client mismatch and cease functioning (with a message explaining why) until the user restarts Chrome and gets your updated app.*
But if you're merely annoyed as a matter of hygienics that users aren't updating, it's hard to justify such a drastic approach. Moreover, by definition you're dealing with users who for some reason just plain don't care about updating anything, which is why they've been ignoring the red hamburger for who-knows how long. If this is the case, then adding yet another noisy notification probably isn't going to cure their behavior. Cue your personal equivalent of Serenity Prayer here.
*Side note: I'm surprised that app updates would be stalled because of lack of browser updates. Are you sure your app wasn't updated to specify a minimum_chrome_version? That case would be understandable, because we wouldn't want to update a Chrome App to a version known to be incompatible with the current browser.
I have a few HTML pages that use javascript to run sql queries etc. these html files are accessed from a share drive on the network. this works perfectly in IE6. My workplace is updating to IE8 and I now get the following warning:
"This Web site uses a data provider that may be unsafe. If you trust the Web site, click OK, otherwise click Cancel."
This is very annoying as every sql interaction results in this warning.
I have spent a lot of time researching and the solution seems to be that I need to add the site to my trusted sites list. However, I am unable to do so due to group policy disabling access to IE settings, and my IT department says that they will not alter the trusted sites list.
Are there any other options? If I could somehow get a trusted certificate would that help? I have also researched other ways to try and run sql without javascript and without a web server but I didnt have much luck.
you're getting the cross-domain alert because your accessing data on a different server. you can put them on the same server and that should fix your problem.'
regardless, and i mean this with all sincerity, you need to get up with your it department and have a little heart-to-heart; they're going to be wary of you and most likely dissmissive...do not let them dissuade you. be polite but be just as stubborn. and if you really want to be a dick about it, when they're up on their high horse telling you nay, you should question their expertise...particularly with user-agents. if they're converting from ie6 in 2012....there's no situation they can describe that makes that acceptable. i'm assuming your intranet was built specifically for ie6 and that'll be their main excuse.....dude ie7 came out in 2007. their excuse is five years old. furthermore....it's still weak sauce.
you and all of your coworkers can enjoy chrome if you add chrome frame to your installation. look it up. wow your it department.
lastly....you're a developer that is not allowed to choose browser, and the browser they grant you access to isn't even fully functional? a)Quit b)Quit c)Quit
Albert already talked you through it (and how right he is). Otherwise a solution could be to put a pass through server (somewhere in your network) between the client and database, e.g. using node.js with an odbc library like node-tds or tedious.