Polymer/platform.js breaks jQuery on Firefox - javascript

I seem to have reached a showstopping bug with Polymer in my current project, and none of the solutions I've found have worked.
Essentially, whenever I load platform.js alongside jQuery, I get the following error every time I click anywhere on the page:
TypeError: elem.getAttribute is not a function
elem.getAttribute( name ) :
jquery-2.1.1.js (line 1430)
Now, this doesn't actually prevent any of my code from running, but it freezes the page for about half a second, which is obviously unaccaptable since it's triggered by every click event. I can't have my UI take half a second to respond to click/touch events.
I'm aware that there is already a question addressing this issue on SO, but I've already wrapped the one occurrence of document in my code as per the accepted solution, and nothing has changed.
I've already decided to stay the hell away from Polymer for the foreseeable future because of various bugs like this and lack of polish in general, but I can't just drop it now because I'm already using a lot of custom Polymer elements. Can somebody please help me get this resolved?

Related

Google Places Autocomplete not working only sometimes [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
Places autocomplete (javascript) has been weird in a lot of ways. I'm to the point that it works seemingly all the time on certain browsers, but intermittently on others. And to get here I've had to do some things counter to other advice, (though the 'correct' way works even less) so I have a lot to list.
The specific issue (on any browser) is that the callback initAutocomplete() does fully occur, but sometimes the input field just doesn't get the suggestions appearing. There are, however, no errors logged. I've found 2 things of note when it fails: pac-container is not created, and no requests are sent for AutocompletionService.GetPredictions.
The errors does not seem to ever occur on FireFox or on Edge. It happens most of the time on Chrome. It never works on iOS Chrome but does rarely on Safari... Not a useful pattern, so far.
There is more than one call to Maps APIs on the page, causing the "You have included the Google Maps JavaScript API multiple times on this page. This may cause unexpected errors." error. However, there does not seem to be an actual problem from this as the calls are to different libraries (geometry and places). And the callback function of the place script absolutely always functions, at least.
Aside from that, no errors of any kind report. It is notable that I'm currently attaching a sessiontoken that is actually session based (for the user, so for multiple requests.) This is directly contrary to information such as stackoverflow.com/a/50452233/5140781 (I've searched a lot before posting) that says a sessiontoken is not needed and will be handled automatically. It is contrary because not including it makes the service break far more often. Without it it breaks a good amount of the time on Firefox and Edge which are currently fine and Chrome will only work once per user session, after one refresh or on any subsequent form it is definitely not going to work any more.
I've also tried attaching a random session token on every page load, that didn't help either. Though since in all cases the error is fairly random it could be that the error has nothing to do with the session token and everything I've seen is just human pattern seeking and [bad] luck. Maybe it is just a race condition of the different API calls for all I know. I get it to work on Chrome more if I do a 'empty cache and hard reload' than just F5; add that to it typically working the first time in a session and maybe you have that loading the scripts from cache is more likely to cause an issue than when they load for real? I'm out of ideas, or at least ones I think are reasonable.
The code for the initAutocomplete is almost exactly as given in the example, save adding the sessiontoken (and again, without that it fails more).
Any help would be appreciated.
It was, in fact, the double inclusion of a google API. This is despite the fact one include library was geometry and this was places, and that the callback on the Place script was happening even in fail states..
Simply removing the geometry include on the relevant pages fixed the Autocomplete functionality 100% (and we could drop the sessiontoken), but geometry was needed for other functions on the page. That was solved by adding it to the include made for the place library. Simply use commas to target multiple libraries; I didn't see that mentioned in the documentation, but is was an easy guess:
<script src="https://maps.googleapis.com/maps/api/js?key=********&libraries=places,geometry&callback=initAutocomplete" async defer></script>
Now, if you need geometry (or whatever other library) higher and sooner than your place include, that is a new problem I did not have. But for anyone finding this, my most simple recommendation would be moving the whole autocomplete chunk up there and combining the include in the same way. There are then 2 possible issues: The other script already having a callback, and the form potentially not existing yet.
The callbacks can be combined trivially if only the first point is your issue; just do the other callback code then the autocomplete. For just the second, there are two options: First, if you can have your form appearing trigger an event, then have the callback set a listener for it to then to its usual (watch for the form possibly loading first though!). Second, a setInterval that checks for the element existing and does the work when it is found (and stops checking)--that is dirty, but will work with just vanilla js; there is probably a better option if whatever framework you have. If you have both problems, just have the listener/interval at the start of the callback.

Auto-refresh HTML tab in internet explorer

I made a nice website that does a lot of DOM manipulation. Works very nicely in chrome and firefox. Though the client has requested now that it also works in Internet Explorer. The latest version is good enough to start with (that would be 10.0.9200.16721 in my case).
So the adventure starts, i press F12 and see a set of pretty familiar developer tools (coming from chrome and firebug). As i'm tracking the JS code i notice that the HTML tab (with the DOM) doesn't actually update.
According to the manual here http://msdn.microsoft.com/en-us/library/ie/gg589512(v=vs.85).aspx it's "a good idea to refresh the HTML tab to get the current DOM, especially when you use dynamic elements." (d0h ??) problem is .. i can't find a button to enable automatic update of the HTML tab. So i would have to click the refresh button everytime i step into a new line of JS (never mind of real-time DOM view).
But that's not all ... every time i click the refresh button the whole DOM tree view collapses. And i have to click a bunch of pluses to view the node i'm interested in.
Does anyone have a solution for this? Because what would take days will take weeks this way...
Duplicate of How to inspect elements on dynamically created DOM by using IE developers tools
From doing a little digging aroung, it seems like this is an issue other people have reported too. This thread might be of some interest to you.
The most relevant part of it:
The problem is when you modify the dom (with or without jquery) from a callback which is called by a timeout, which is in a callback bound to an event, IE freaks out and doesn't update the dom tree in the development tool. Subsequent modifications to the changed tag in the dev tool won't have any effect.
According to my tests, it's the combination of that sequence of calls that make this happen. If the dom is modified from a settimeout callback but without being inside of an event callback, it works. If instead of settimeout you directly call a function that modifies the dom, it works.
Here's a working example of what you're saying to compound the issue.
Basically, this is an issue with IE. There is no fix available at the moment. The accepted answer on the other thread seems like a very poor workaround.

console.trace or stack trace to pinpiont the source of a bug in javascript?

I've used some complex javascript (jQuery) to create an editor of sorts where users can drag, drop and resize different divs. The problem is that sometimes, for seemingly no reason, divs that contain text suddenly get "frozen" or "stuck" on the containing div and cannot be dragged around, despite still maintaining a class list that includes ui-draggable, right after I mention:
$this.draggable( "option", "disabled", false );
So technically there's no reason why the dragging should stop. I used Ctrl+Shift+K to use the web console of firebug but when I drag things around that doesn't trigger anything on the console, and the fact that I can't drag one particular around also doesn't show anything up. I've tried profiling but these things just tell how much time is spent in a certain script. How can I possibly figure out why an element's drag just gets turned off and cannot be turned on again? I can't put breakpoints because I don't know where in the code something's going wrong. It almost seems arbitrary. Is there any way to to simply see what's happening on the stack in realtime?
Edit
In Firebug we can see an entire list of properties for an object, much more than what fits in this little screenshot below. Does anyone have any idea which object properties I should concerned with, that pertain to an issue like mine? I'm really lost on how to diagnose the problem.
#Allendar - too many bindings was indeed the issue. I followed up with this question: Am I binding events over and over again in this jQuery code? and with the help of Visual Event, I got rid of bindings that I was doing over and over again, and then it worked fine.

Javascript firefox issue

I developed a .htm document with an in-built script for javascript to run a program. In google chrome, the program works fine, but I got a beta test complaint that it didn't work on firefox 14.01 or opera. On testing with firefox 14.01, I can confirm it doesn't work (I assumed opera to be the same). I cannot insist the audience upgrade their browsers, as this is supposed to be widely compatible.
Doing a little tracing of the issue, I installed Firebug, which, on clicking the Javascript button to generate a coordinate the first time, it worked (clearly showing the function is defined and exists), but the second time, Firebug complained that:
"ReferenceError: GenerateCoord is not defined".
This wouldn't be so ironic if it only did this after generating an (encrypted) coordinate (thus calling GenerateCoord that is supposedly 'undefined').
If one looks in the code, one can clearly see that the function GenerateCoord is clearly defined before it is called. I would say firefox has an 'onclick' issue, but then it begs the question why did it work the first time I clicked it (calling GenerateCoord via 'onclick') but not the second?
Reloading the file allows the button to work the first time, and the first time only. I am baffled as to how firefox can call a function one time that it then says is undefined the next. Am I missing something here?
Javascript and HTML code can be viewed here:
http://pastebin.com/4qykTfEW
-
How do I solve the problem, and is there an easier solution than re-writing the code to avoid onclick (that seems to work in certain circumstances but not others)?
The problem is that using document.write overwrites the entire HTML page, thus inadvertently removing the GenerateCoord script. I'd suggest appending the link to the document (in ShowTarget) rather than attempting to re-write it.
For example, have a container element where the link should be:
<div id="links_container"></div>
Then to append the links, use:
document.getElementById('links_container').innerHTML = Link;

"Stop running this script" error in IE7 and IE8 while trying to navigate to another page

I have created a Drupal website that uses Openlayers to display maps. In one of these maps there are some "Filters" which the user can use to dynamically change the data shown in the map. The data are related to countries are shown as bubbles over the countries. The bubbles are drawn using Openlayers' API. A good amount of calculations go behind the scene while filters are selected. I have used setTimeout to avoid long running loops. The filters work fine. However, after a number of filters are clicked (e.g. if 12 filters are clicked), if the user tries to move to another page by clicking a link, in IE7 and IE8 the following error shows -
"Stop running this script?
A script on this page is causing your web browser to run slowly.
If it continues to run, your computer might become unresponsive."
This error does not show in any other browser and does not show in IE7, 8 until a link is clicked. Any pointer in this regard will be highly appreciated.
UPDATE : The problem was in OpenLayers' event cache. OpenLayers's clears the event cache in the window unload event and this was getting stuck in IE7 and IE8 (I am not sure why). So far I have been able to solve the issue when user clicks another link, by calling OpenLayers.Event.unloadCache() on click of normal links.
jQuery can be very resource expensive. The articles linked bellow gives you 10 good advices to perform better your jQuery applications. The most useful for me (I had the same problem a month ago) was to replace $.each() with traditional for lops and to replace extensive DOM construction with jquery templates. Also the use of ID instead of classes and to give a context for the selectors, selector caching, and so on.
This list is ordered using my own criteria of "usefulness" in the advices.
10 ways to instantly increase your jquery performance
improve your jquery 25 excellent tips
10 advanced jquery performance tuning tips from paul irish
8 jquery performance tips
You need to optimize your client script. Please refer to answers here.

Categories