On my website, I've had some Javascript that's been running perfectly fine for over a year now (and I pride myself on it working in every browser, as far as I can tell). But recently it suddenly broke and after some debugging I found this.
I have some code that creates an eventHandler as follows:
window.addEventListener(
'devicemotion',
function (e) { ... },
false
);
This handler is used to handle device accelerations, but for some reason, as of some recent Chrome update this handler is getting called on all my computers (laptop, desktop, etc.) instead of just my mobile devices. As far as I know, none of these devices have any accelerometers in them, and this handler was never executed on them in the past.
Could anyone shed some light on why this behavior has changed? It seems pretty counter-intuitive for this handler to ever get called on a desktop computer. I tried searching for updates in Chrome that talk about this, but I'm not really familiar with searching Chrome or Chromium repos/source code.
According to r196645 google wanted to fix the support for the device motion part of the Device Orientation API.
The W3C specification draft said:
Implementations that are unable to provide all three angles must set the values of the unknown angles to null. If any angles are provided, the absolute property must be set appropriately. If an implementation can never provide orientation information, the event should be fired with all properties set to null.
To correct this part of the Device Orientation API they opened r263415
and told chrome to fire the devicemotion event on all devices and just pass null values as specified in the W3C specification draft.
So that's why this behavior changed.
What about if you wrap the listener inside an if browser width / navigator statement? I know it's not ideal but a lot of things do seem to be going wrong with chrome lately. I'm currently suffering from an incurable bug (or that's how it seems) where my console remains constantly blank and I have to use canary for any debugging tasks.
Related
I have an application (built on React) that seems to be causing more overhead -- likely DOM updates -- than it should. Normally when a user enters any data, e.g. a single character, a DOM update would occur, but a denounce has been implemented so this shouldn't happen, though perhaps the debounce itself is problematic.
While I could devise some visual ways to diagnose this, I thought it might be useful to collect profiling data, in particular, something like a histogram or graph of DOM updates per second sounds useful.
I don't mind using either Firefox or Chrome to do the profiling, but I will note as an aside that Firefox seems to be hit even harder than Chrome by this performance issue.
Honestly, the best browser is Microsoft Edge Dev. Here is a link to the download page. Edge Dev a bunch of extra options, under the Settings wheel, and turn on all the extra ones that you may need. There are 3 options but like I said I suggest Dev. It has a feature (3-D View) that enables you to see all the elements on the page and how they are stack/interacting with each other, plus you can change it to DOM View if that helps. It allows you to move around and interact with the 3-D model and it will show above what it's actually doing. It is a great way to "See" your page. You can also download Firefox Developer Edition which has Dev tools too, but not like Edge. Run your program in an Edge browser, right-click and Inspect the page, it is easier if you un-dock the console. Change the settings to fit your needs and then click the Profile Tab. You should be able to run it through there and get results. Look around in the Inspect window and the Console Tab, which will log errors and details if you choose those options, that may tell you if there is some request that is holding things up.
I have built a website that uses some simple JavaScript. I make use of many events throughout the website such as the input and submit event for validating and processing a contact form, the focus event for some form-related things and a dynamically-created tab interface, etc. I register all of these handlers using element.addEventListener("event", handler).
My JavaScript works wonderfully everywhere that I have been able to test (Firefox and Chrome on Ubuntu; Firefox and Chrome on Android), except for on iOS devices (regardless of what browser is used), where it seems that very few events are being fired.
It has been difficult for me to debug what the issue is on iOS devices because I do not have an OSX computer to connect an iOS device to so that I can use the remote console. I have come to the conclusion that the events are not firing for a few reasons:
The contact form on the website is being submitted even though I make a call to event.preventDefault() in the form's submit event handler, and do not explicitly submit the form anywhere after that.
I have tried catching any errors and displaying them in an alert like so:
window.onerror(function(err) { alert(err) })
to no avail (i.e. no errors were caught).
I have adapted all my functions to make use of only the click event, and then they work perfectly!
The last point is a possible solution to the problem, but I think it is bad practice to adapt all my work to one specific platform and rely only on a single event when there are so many purpose-built events that can be used and that are supposedly supported by iOS in the first place.
Why are so many events not being fired on iOS devices?
The problem was actually that I had made a const declaration in strict mode, which is, according to caniuse, not recognized in the current versions of both Safari and iOS Safari (9.1 and 9.3, respectively, as of writing).
I have better documented this problem in another question and answer.
I am having an issue where dynamically-created links are working on all devices I have tested (in all desktop browsers, on my iPhone, on my iPad, and on my Samsung Galaxy Tablets Chrome Browser), but will not work when clicked on Android phones (I've tested on three Android phones running Chrome, sorry don't have the Chrome versions, but one phone is really new and the others are 1-2 years old at most).
I am dynamically-creating the links to add items to a cart (inside of a larger dynamically-created entity) in a loop.
The link in question is constructed basically like this:
var itemHTML = "";
...
itemHtml += '...<span>\n'
...
Where gAddLink is just a standard URL. I am then inserting that itemHTML (in addition to other HTML) onto the page dynamically using document.write().
Since this is being dynamically created on page load (for reasons out of scope for this question, but it is a necessity), I know I have to have a click handler set up as so:
$('.elementToInsertTo').on('click', '.add2CartLink', function() { ... });
Where '.elementToInsertTo' is the parent element that is NOT dynamically created, and is present on the page at page load. There are multiple of these parents, hence why I can't use an element ID. Don't think it makes a difference though.
Again, I can confirm that the function call in this click listener works everywhere except Android phones (as far as I can tell). Any idea why this may be? I've read StackOverflow pages all day, but nothing seems related to this. I've read a bunch about JS closures (which may still be the issue) and the like, but none of that seems to be relevant since the link click listener is working on most all devices I have tested on (even the Android tablet's Chrome browser, which is the part that really is confusing to me).
If you happen to have seen this issue before or have any idea why this may be happening, please write it out before reading the next part, so as not to confuse or bias you.
Ok, now to the part that is even more mind-boggling, though I hope this only helps figure this out and doesn't confuse the situation.. I connected one of the phones to my computer with a USB and did some remote debugging using Chrome developer tools as described here (https://developers.google.com/chrome-developer-tools/docs/remote-debugging). I could confirm there that the click listeners were not working (they weren't being triggered)... (and now here comes the crazy part) UNTIL I did some element inspection on the link (i.e. the link was highlighted on my phone as I was inspecting the DOM-element in my browser, again using Chrome dev tools) and then clicked the link. This made it so that the click listener worked! What?? To debug further, if I inspected any of the DOM elements on the page and clicked the link, the click listener worked. If I changed tabs away from the dev tools tab, or simply stopped inspecting the DOM elements in Chrome Dev tools, the link click listener no longer worked. I really don't know what to make of this, but I'm hoping this part of information narrows down what may be going on with the Android phones and the click listeners.
Happy to try to provide any other info I can, though I am without the Android phone for testing at the moment.
Thanks!
Tap was still needed (thanks for both suggestions), but the issue was with a 3rd party JS library stopPropogation() call. Apparently this only happened on Android phones, but regardless, after removing the line, the click (on computers) and tap (on mobile) now works everywhere. Thanks!
I have a problem with DOM exceptions in Google Chrome as well as in all other Webkit based browsers. I'm working on a Google Maps based data stream browser, and in these browsers it freezes the map after several zoom-ins and zoom-outs.
It throws an INDEX_SIZE_ERR: DOM Exception 1 with a rather unintelligible stack trace. And what's even worse, when I try to use the inspector to pause on exceptions, the tab crashes.
I've tried it in Google Chrome, in Chromium and in Midori, all three give the same result.
I would appreciate any input on how to trace this problem, or on what can possibly be causing it.
Just one last thought - the problem has appeared after Google had rolled out it's API v.3.4. Until recently I have been able to suppress this problem by using the 3.3 version, but now that it has been retired, I have no choice but to face it.
Open up Chrome DevTools (Ctrl-Shift-I on Windows/Linux), switch to the Scripts tab and click the "Pause" button in the status bar (tri-state) until its tooltip shows "Pause on uncaught exceptions", then activate the failing code.
INDEX_SIZE_ERR can happen when accessing a typed array, like an Int8Array or something, outside of its bounds. Are you doing that anywhere?
Last night, I thought I'd do a quick project to demonstrate HTML5 capabilities and to try some things out. However, I can't seem to figure out how to get drag and drop to work in Safari, while it works perfectly in Chrome and Firefox. More precisely, it seems that drop event does not fire in Safari, when you try to drag an image inside the website into the drop area. At the same time it does fire when you drag and drop a file from desktop.
I'm not really sure, but I'm pretty certain that when I tried the same script at work (where I have Safari 5.0.2 etc), it fired the drop event (going to check it tomorrow to be sure) and gave me the FileReader-related errors that were expected. But when I just installed Safari 5.1 on my own PC, I only get dragover, enter and leave events (and drop too if the file was dragged into the browser).
I've been Googling for some time now and don't seem to find a single example of drag and drop that actually works in Safari 5.1. Even Safari's dev-centre's sample doesn't work, let alone html5demo.com 1 and html5demo.com 2. This leads me to think whether the Safari has a bug, or maybe they have implemented something mandatory that isn't reflected in the dev-centre (last updated in 2009).
The script I'm trying to fix is at my site (sorry guys, no problem specific code to post, as it seems to be broken elsewhere too).
PS! I might have introduced some bugs into my own site while desperately trying to fix the drag and drop in Safari, but I'm too tired to fix them right now.
UPDATE: Just confirmed at work that the drop event does fire in Safari 5.0.2 on Mac OS X.
UPDATE 2: Also confirmed that everything works perfectly fine with Safari 5.0.6 on Win 7, the same computer that fails with 5.1
Testing with Safari 5.1.7 Mac:
To see the drop event fire, you have to handle the dragover event and call event.preventDefault().
Here's the (quite entertaining) discussion where I found the answer:
http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html
I don't know if this really solves the question because the asker's site (at least as of today) does this. It works fine on my machine (as do the HTML5 demo pages). But this may help someone coming to this thread with this problem who doesn't know about this rather unintuitive implementation detail.
I am using Safari 5.1.5 (7534.55.3) on a Windows 7 PC which I just installed the other day, no previous installs of Safari and I cannot get any of the online HTML5 drag-n-drop demos to work.
I am working on a project with drag-n-drop and Modernizr tells me that I'm good to go with Safari (Modernizr.draganddrop == true), but when I actually drop the item the drop event does not fire.
I've added alert debugging and nothing.
My testing shows that Safari 5.1.5 (7534.55.3) on a Windows 7 PC drop event is broken. All other drag events seem to work: dragstart, dragend, dragenter, dragleave, dragover.
Just to clarify: Visited your site and found no errors. Opened the console, no error, and everything appeared to function as designed. Tried all provided examples with no error.
All examples work fine Safari Version 5.1 (7534.48.3). Sorry, mate – Maybe it's a setting you've changed?
Allow me to suggest a possibility:
Go to Safari->Empty Cache... Then Safari->Reset Safari... Try reloading the page.
Likely, there's something cached that's creating a conflict. There seems to be nothing wrong with your script in the slightest.
Edit
Some things to check...
Are any of your function names containing reserved words? I've done this, had it not throw any errors, but it simply wouldn't work.
I've had some weird issues with Safari not running methods written as funcName = function(){}. If you can pin down the method that isn't firing (I add a little function when I'm developing called DBG which I'll add below – basically, if a debug flag is set, you log to the console), you can try rewriting the function.
// Some sort of boolean flag.
var debug = true;
// This is kind of an obvious function, but can be expanded as you like.
// Little tricks to make life easier.
function DBG(str) {
debug ? console.log(str) : return;
}
I still think ultimately this boils down to something caching wrong, but it's worth a try.
I encountered similar issues, the drop event appeared to not be firing. Safari apparently expects the "dragover" event to also be bound. As soon as I also added that, it worked. So ... I'm sharing in case it's relevant.
My first attempt:
$(document).bind
drop: (e) ->
// This never gets fired in safari (does work in chrome)
console.log e.originalEvent.dataTransfer.files
false
My "fix":
$(document).bind
dragover: (e) ->
console.log e
false
drop: (e) ->
// This does get fired (in chrome and safari)
console.log e.originalEvent.dataTransfer.files
false