Develop Reference

Simple Ajax Uploader Plugin Stopped Working

We're using the javascript plugin Simple-ajax-uploader to upload files on your web site and it suddenly stopped working today (09/05/2019).
The upload div/button can't be clicked on anymore.
This is happening on our site and even on the official plugin site.
This is only happening on Chrome and only on computers where Chrome has been closed and restarted today.
We found out this article indicating that Chrome Dev tools have just been updated today but our version of Chrome hasn't changed since the restart (76.0.3809.132). However the restart definitely triggered the bug so something happened there. But what?

Same problem here found this morning.
Quick jQuery fix...
$('input[type=file]').css('position','relative');

UPDATE: Issue has been fixed with version 2.6.5 of the plugin. Ignore the below.
Plugin maintainer here. A short term fix is to remove or comment out line 2002:
'position' : 'absolute',
Alternatively: the issue does not appear to be present in Firefox. At any rate, I'll try to have a fix pushed soon.

I've just checked on Chrome and you're right about the button not working. It is a problem with the Stacking Context, unfortunately each browser has its own implementation.
Basically the outer div is preventing the click events from reaching the inner input.
My suggestion would be to use a custom button or to restyle the current one (I've found that if you remove the position property from the outer div it will work again. Consider that many properties can cause stacking context problems: position, transform, opacity, z-index. Try adding/removing/modifying some of them, in the outer div and in the inner input).
Anyway, it is guaranteed to be a style problem and not a JavaScript problem.

svg animation does not start when loaded with settimeout

I'm loading 2 embedded svg-lets in a page. One animated one not. They're loaded in sequence with a setTimeout.
When I load the animated first all goes well, the animation starts as expected and the second static svg is correctly displayed afterwards. When I first load the second, and afterwards the animated one, the animation does not start.
Code is here: jsfiddle switch #svg1, and #svg2 in the javascript.
Upon browser checking I found out this is probably a webkit bug as chrome and safari both show this behavior FF 12 and Opera are well.
Can this be fixed with JS code or should I file a bug with webkit?
== Added
I think the question should be rephrased why the animation does not start after the svg is loaded with a settimeout.
As Jared investigated below it works when the element is present in the DOM and is reordered via dom manipulation into the focus element, Chrome and webkit need a kick with a beginElement() call to the animate element. This still doesn't work out for elements constructed from plain text. As I only do have a mac and I still consider this a hobby project I leave MS IE completely out of the loop.

Well, it took quite a bit longer than I anticipated, but I got it worked out. Basically, the method you were using with the semi-SVG and the regex on the markup, etc., was to say the least not quite the way to get it done.
The answer is to use svg DOM animation methods and attributes, especially to start/stop the animation when you want it to run. Apparently, Firefox was just fine with reinitializing the element and the animation just by manipulating the inner HTML/markup. Chrome (Webkit?), however, actually needs you to programmatically access and control the element. I have not checked in IE, Opera or Safari.
I redid the example, leaving out the arrow altogether, as it is unrelated to the problem. I instead concentrated on creating and testing the animation functionality. The critical points you were missing before were:
var $lasso = $('#lasso'),
animater = $lasso.find('animate')[0],
...
animater.beginElement();
...
animater.endElement();
Here is the demo I made, which is significantly different that what you have in your question:
http://jsfiddle.net/9hBfs/
What I call the "lasso" effect is still there, though.
I would reference the Mozilla Developer Network (MDN) site, as they have a lot of great information and are a highly trusted authority:
https://developer.mozilla.org/en/SVG
https://developer.mozilla.org/en/SVG/Element/animate
http://www.w3.org/TR/SVG11/animate.html#animation-mod
http://www.w3.org/TR/SVG11/animate.html#InterfaceElementTimeControl
http://www.w3.org/TR/SVG11/animate.html#RestartAttribute

Unwanted Page Jump when using hash URLs

I've checked out the other page jump questions here on SO and I haven't found anything that matches, so here we go...
I'm working on building a website that uses CSS3 transitions and a bunch of hash-links as opposed to using jQuery to load/transition different pages/elements (just for fun/to prove that I/CSS can). The problem I'm having is that when I click on one of my links, the scrollbar automagically jumps down about 100px for no apparent reason.
I don't recall it doing this the entire time, so maybe something in my CSS went weird. I also added some <a name> tags at the top to try to pull it back up, but that's not working either. I also tried putting onclick="window.scrollTo(0,0);" in the links as well and that doesn't work either :(
Any ideas/help would be awesome, as it's really annoying/poor usability to have to scroll every time you navigate to the page. You can view the page here.
System Info:
Browser(s): Chrome 16.0.912.75, FireFox 9.0.1, Opera 11.6
OS: Windows 7

I'm not familiar with CSS3 transitions, so I don't fully understand what you're doing. However:
I assume this behavior that you find undesirable has something to do with the browser's native behavior of scrolling an element into view based on the fragment identifier in the URL. I'm not sure if overriding that with <a name> elements would work, but in any case you've incorrectly set the name values by prefixing them with a hash. E.g should be <a name="about"></a> not <a name="#about"></a>.
At least for debugging purposes, I'd try adding a click event listener and calling preventDefault() in it to see if it stops the scrolling.
It would be helpful to state what browser (including OS and version) you're experiencing the issue in.

Notice that it is not just jumping down to a random place, it is jumping down to the element that has the ID of the hash. (Try adding #footer to the end of your url) I do not think you can get around that without using preventDefault in JavaScript.

JavaScript error in Safari, only sometimes

I have a webpage that is using jQuery to hide divs on the page load and show them later based on user interactions.
In my $(document).ready() I execute a bunch of code to hide these divs and to bind a function to the click() handler from jQuery for the regions that trigger showing these divs. It also grabs some values out of the HTML to be used by scripts later. The latter is what's causing an issue.
This code works fine in Firefox and Chrome/Chromium (we're still working on the CSS for IE, but the JS works as far as I can tell). In Safari, it works flawlessly about 70% of the time. Every few page loads however, a line in my $(document).ready() gives me an error and stops the JS from executing, also halting the drawing of HTML for the rest of the page.
the line is:
var itemCount = document.getElementById('itemCount').innerHTML;
The debug console in Safari says "Null Value". The thing is, I see the following in my HTML (from the "view source" of the page after it failed to load right):
<div id="itemCount" style="display:inline">0</div>
and it is the only item with this id (obviously.)
I'm thinking that somehow the JS is getting run before the document is actually ready, and was thinking I'd try testing to see if document.getElementById('itemCount') returns null and wait for a bit if it does, but I don't know if this would work, or if there is a less ugly solution.
Let me know if I'm missing something obvious, or being dumb some other way.

From the way your code is written, I think there must be some other error on the page that is causing this. Your first code block should be:
var itemCount = $('#itemCount').html();
...and the second:
<span id="itemCount">0</span>
A <div> set to be displayed inline is a <span>. A <span> set to be a block-level element is a <div>. That's the only reason there are the two tags. They're otherwise identical. Use the right one for the task.
Not that I expect either of these changes to change your symptom. I just suspect you have other...questionable things on your page, and that's what's really causing the problem. Wild guess: move the <script> block containing the ready() handler to the bottom of the document's <body>.
If you're not already using Safari 4, by all means do so. Turn on the Develop menu in the advanced preferences, then say Develop > Show Web Inspector before loading your page. If there are errors, it will do a better job of showing you why than Safari 3.

Seems to be an old bug. See ticket 1319 and ticket 4187.
See this potential workaround:
After some experimenting and deleting 99% of this post :) - adding an empty style tag dinamically magically fixes the problem:
(function(){
if (!/WebKit/i.test(navigator.userAgent)) return;
var el = document.createElement("style");
el.type = "text/css";
el.media = "screen, projection";
document.getElementsByTagName("head")[0].appendChild(el);
el.appendChild(document.createTextNode("_safari {}"));
})();

TinyMCE not working with Chrome when I dynamically setContent

I have a site that I put:
<body onload="ajaxLoad()" >
I have a Javascript function that then inserts data from my database into the text editor by using the setContent Javascript method of the textarea. It seems fine in Firefox and IE but in Chrome sometimes nothing shows up. There is no error, just a blank editor.
In the body section I have:
<textarea id="elm1" name="elm1" rows="40" cols="60" style="width: 100%">
</textarea>
In the head section I have:
function ajaxLoad() {
var ed = tinyMCE.get('elm1');
ed.setProgressState(1); // Show progress
window.setTimeout(function() {
ed.setProgressState(0); // Hide progress
ed.setContent('<p style="text-align: center;"><strong><br /><span style="font-size: small;">General Manager's Corner</span></strong></p><p style="text-align: center;">August 2009</p><p>It’s been 15<sup>th</sup> and so have a Steak Night (Saturday, 15<sup>th</sup>) and a shore Dinner planned (Saturday, 22<sup>nd</sup>) this month. urday, September 5<sup>th</sup>. e a can’t missed evening, shas extended it one additional week. The last clinic will be the week of August 11<sup>th</sup>. </p><p> Alt (Tuesday through Thursday) </p><p> I wouClub.</p><p> </p><p> </p><p> </p><p> <strong></strong></p>');
}, 1);
}
I am not sure if its some of the formatting that Chrome is rejecting but it seems like if TinyMCE can parse it in one browser, it should be able to do it in any browser, so I am confused.
Any suggestions?

Background:
For various reasons onload() is not considered the proper approach for loading Javascript, see for example Launching Code on Document Ready, with the most important/noticeable one being that Javascript code isn't run until the page has finished downloading entirely, including images and the like, which might take an eternity therefore (e.g. if an external banner ad server is down etc.).
Instead it is recommended to load Javascript as soon as the DOM is ready, but unfortunately there is no cross browser compatible native solution for this, see Getting notified when the page DOM has loaded (but before window.onload); please note that my entire answer is based upon the most excellent Javascript library jQuery, which offers a cross browser solution for this problem, consequently I'd definitely favor the two higher voted answers over the accepted solution myself.
Likely cause:
Your issue seems to be caused by the opposite behavior though: Chrome facilitates the WebKit rendering engine, just like Safari, and for the latter onload() is discussed to behave differently, see section When does onload fire? in Is Safari faster?. Another description of this problem specific to Chrome can be found in window.onload not working correctly in Chrome, without an explanation though.
In conclusion I suspect onload() to fire before the DOM is actually loaded completely, at least concerning the requirements of TinyMCE, which is notoriously fragile regarding issues like this and simply ceases to load.
Possible solution:
Just facilitating attribute defer on the script tag as outlined in window.onload not working correctly in Chrome is again not cross browser compatible, hence I'd simply go with the widely deployed and proven approach of using the already mentioned jQuery cross browser solution for the onload() problem, which is good practice anyway and should in principle take care of your inverse issue as well.
Update:
There are indeed some bugs filed against WebKit which could back my conclusion (no matter whether this behavior actually constitutes a bug or is intentional), see:
onload sometimes fired before all resources are loaded
window.onload fires before all subresources loaded
Window.onload is firing before image resources are loaded

I had a similar problem (editor not showing in chrome) and read in some forum, that if tinyMCE is unable to locate some files, it just stops loading. Try tracking down if everything is found using firebug's net tab (clear your cache first).

First of all; see to it that you have the latest version of TinyMCE.
I could not reproduce your problem given the information you provides. It seems just fine ( with the faked ajaxload ).
You could always try to go the "back entrance" in;
var myed = document.getElementById('elm1_ifr');
myed.contentDocument.getElementById('tinymce').innerHTML="<p style=\"text-align: center;\"><strong>hacking <span style=\"font-size: small;\">my</span> way in.</strong></p>";
Hope you good luck!

SOLUTION:
Ive been struggling with the TinyMCE toolbar not appearing in all kinds of secnarios....it would work in one user's IE browser, but not another. It would not work in Firefox or Chrome, etc.
Turns out if in the newest 3.3 version there are STILL bugs they have not fixed. This one occurs when in your webpage JavaScript code, where you instantiate the TinyMCE, if you added code for the plugin part where you load up two specific plugins, the toolbar fails to appear and you see HTML:
plugins:
"safari,spellchecker,pagebreak,style,layer,table,save,advhr,advimage,advlink,emotions,iespell,
inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,
fullscreen,noneditable,visualchars,nonbreaking,xhtmlxtras,template,**imagemanager,filemanager**",
Remove all references to imagemanager and filemanager in your web page, then refresh your browser...
When you do, retest in Chrome and Firefox and IE and the TinyMCE suddenly appears! Wow....a miracle, huh?
Turns out their "main developer" hasn't fixed the issue but does explain it as such, if you want to try and still use those plugins and yet fix the problem. His quote is as follows:
"If the ImageManager/FileManager are old they might not use the new
scriptloader api. And the new 3.3 version will load all dependent
scripts async instead of sync. - Spocke - Main developer of TinyMCE"

There are a few ways to set content in a TinyMCE editor. If you want the content to be there when the page first loads, you can just put it between the tags.
Otherwise, you can do this through script in the following way:
window.onload = function() {
tinyMCE.getInstanceById("ProfileText").setContent('test');
};
I have wrapped the code in a window.onload block. If you have other functions that set content dynamically through this way after the TinyMCE editor has already loaded, then you do not need that.

There is an option oninit for the function tinyMCE.init(), put your method there:
tinyMCE.init({
oninit: function(){
tinyMCE.activeEditor.setContent('blah');
}
});
It works this way.
The editor is not fully loaded on document load event, as it the editor loader will post-load a bunch of files.

same problem here, ie needs
var ed = tinyMCE.get('content');
ed.setContent('zzz');
other browsers
document.getElementById("content").innerHTML="zzz";
i am quite disapointed
will need to check browser in javascript to get it working properly, thats suxx