Up to my elbows in what is surprisingly the most elusive bug I've encountered thus far.
I've got a site I'm working on that has issues with links opening in Safari. The issue is isolated to the target appendage. To be clear, this issue is not that links do not open in a new tab, it's that they don't open at all.
For example, this will open just fine:
blaaaahh link
This, however, will do 'nothing':
blaaaahh link
Note that this is specific to PDF files. Links to any other type of resources work fine, even with the target appendage.
Note note: There is a ton of event tracking happening on this site. And the issue is resolved when JS is disabled. I've excluded all site-specific JS for testing, so that's not the issue. Anyone aware of anything with GTM or HotJar in Safari that could cause this?
I have designed a website using Wordpress and caching it with W3 Total Cache. I have experience with them both but I encountered the next problem.
The website http://atelieruldigital.com is a one page website, with another page for the partners of the program (http://atelieruldigital.com/parteneri/). When I access the partner page, everything loads as it should. When I access the main page by clicking "Acasă" or the logo, I have the next behaviors:
Google Chrome: everything loads as it should;
Mozilla Firefox: the scripts have lots of errors in the console and the page loads broken. I have to refresh (F5) to make it work as intended;
Microsoft Edge: the same problem as Mozilla.
I am using manually minifying, only by combining the scripts, excepting the mobile-menu.js, which grants error when I try to combine it. I do not use page caching, only object and browser caching. The theme is a custom theme, based on Twenty Sixteen.
If I disable the caching plugin, everything works as intended. But I need it to help the page load faster.
I have found the solution after a couple of days of debugging. It seems like when manually combining the .js files, I had to switch around some in the load order.
I've run into an issue that crops up when I make a change to a Drupal site - www.productworld.com
This is how the problem crops up:
Make a change to site, e.g. add javascript tracking code or adding a new static webpage.
When NOT logged in as admin (viewing the site as a regular visitor), the homepage is now screwed up. It appears that the CSS and JavaScript for the homepage aren't loaded. When logged in as an admin, I see a cached version of the site, looking as it should. I use two separate browsers to confirm the problem - one where I'm logged in as Drupal admin in Chrome, and two where I view the site in Firefox as a non-logged in site visitor.
Here's some screenshots of what the site looks like when the problem crops up:
http://imgur.com/xs3hF
http://imgur.com/wMBVq
http://imgur.com/Gksb9
http://imgur.com/eZPTE
Note: the company images that you see (iWatt, Roal, Assa Abloy etc) should be in a nodequeue (a jQuery image slideshow), but instead they appear one after the other. The blue box with the gold call to action appears way down the page. This is what leads me to believe that the CSS and JS isn't loading.
3.Clearing the Drupal cache fixes the issue.
It's obviously highly undesirable to have a site that gets screwed up everytime a simple change is made to it.
If anyone has run into a similar issue, please let me know.
Thanks.
When you make changes to the site with caching enabled it will cause problems. This is because it will be using some cached copies of earlier files.
I tend to make changes to a development version of the site, then roll them out to the live site and clear the cache.
I'm having an problem where the iPad insists on loading an old copy of a .js file, instead of the current one. Strangely enough, this only happens when the page is in fullscreen mode, not when it's being run from the page.
I'm not using any kind of cache manifest;
When I open the page on Safari, it behaves as dictated by the latest version of the .js;
When I open the page through the icon, it behaves as dictated by the old .js;
Killing the running application, deleting the icon and then creating it again doesn't solve the problem; it's still using the old .js, even while in full screen.
Does anyone have an idea of what's going on?
-- update --
This seems to be an iOS 5 bug.
-- Workaround (a.k.a. ugly hack) --
Simply add some fake http params to the script tag, so that the cache thinks it's entirely another JS:
<script src="js/pentaho-jqm-repository.js"></script>
Becomes:
<script src="js/pentaho-jqm-repository.js?fkn-ios-bug=1"></script>
After using the aforementioned workaround (adding a fake parameter to the URL) and then changing it back, strangely enough, the problem stopped happening. Of course, in a production environment, one wouldn't be able to do this, so I think I'll just start numbering the js versions so that the end user won't have this problem.
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