I have some strange behavior going on with safari, im using the jQuery.GridLayout plugin and css for styling.
Just for some context, this website layout is a simple header followed by the content which are a collection of blocks (each block is a div) positioned by the javascript and rearranged every time the window is re-sized.
When I direct safari to the website url all the blocks overlap to some degree (like 50%) but as I re-size the window if they have to move, automatically all goes to the correct place and only breaks if I refresh the page.
So it seems that loading the page is messing it up either because something fails to register or because something does not happen until I re-size the window.
As anyone experienced such behavior within safari?
It works perfectly in firefox and opera, its an valid html 4.01 transitional page and the css is also validated (wc3 wise that is).
I know that publishing the code is invaluable to sort this kind of issues but this is a production project and I'm obliged not to it.
Either way I appreciate any advice on were to start looking?
How do one goes about debugging this issues in safari?
Thank you.
Safari fires DomReady before linked resources are loaded. This race condition regarding calculating sizes of elements defined in CSS can usually be avoided by loading your CSS resources before any JavaScript (eg: make sure the tags appear in the before ANY tags (which are blocking, but give a change for CSS to load asynchronously). Worse case scenario, move your blocks to the last element in , leaving your tags above.
CSS concatenation of multiple files (if you have them) is also recommended.
If you aren't able to post the actual code of the page for us, you might find your solution while trying to reproduce the problem without your specific content. In the past, I've solved some of my own problems while trying to generate a page that shows the problem to post on IRC / SO. If you are able to reproduce the problem without your content, post it for the community, and an answer will be much easier to find.
My shot-in-the-dark guesses lead towards:
You may find that one of your content blocks is causing the issue.
You may find that a different library you are using is causing the issue.
Some javascript code for your layout may be running before everything is ready / filled in. From my memory, Safari is quick to display pages before images are loaded for instance.
Perhaps you need to specify the an exact width/height of some of your Grid Containers.
Small update:
(new update at bottom)
http://www.howtocreate.co.uk/safaribenchmarks.html
And also something that is working is this small script:
<script language="JavaScript">
// CREDITS:
// Automatic Page Refresher by Peter Gehrig and Urs Dudli www.24fun.com
// Permission given to use the script provided that this notice remains as is.
// Additional scripts can be found at http:
//www.hypergurl.com
// Configure refresh interval (in seconds)
var refreshinterval=20
// Shall the coundown be displayed inside your status bar? Say "yes" or "no" below:
var displaycountdown="yes"
// Do not edit the code below
var starttime
var nowtime
var reloadseconds=0
var secondssinceloaded=0
function starttime() { starttime=new Date() starttime=starttime.getTime() countdown()
} function countdown() { nowtime= new Date() nowtime=nowtime.getTime() secondssinceloaded=(nowtime-starttime)/1000
reloadseconds=Math.round(refreshinterval-secondssinceloaded) if (refreshinterval>=secondssinceloaded)
{ var timer=setTimeout("countdown()",1000) if (displaycountdown=="yes")
{ window.status="Page refreshing in "+reloadseconds+ " seconds"
} } else { clearTimeout(timer) window.location.reload(true) } } window.onload=starttime
</script>
I find it odd that a refreshing script solves the issue in safari, but if i manually refresh the page the page havoc ensues...
########UPDATE##########
Well I finally got some more time to work on this and after doing some reading a rather obvious thing came to my mind, let the content load and then format it, so for now all of my js sits between </body> and </html>.
Its not perfect since now you can catch a glimpse of the content without being properly placed when the page first loads.
Maybe ill try calling the js a second time after a few ms have passed of loading.
I know this was proposed a bit upper the thread I just needed time to get my hands dirty thanks all, Ill keep updating till I get it solved in a more proper fashion :)
Related
I"m wondering if anyone can give me some insight into a really strange IE9 issue I've been struggling with.
I'm finishing up production of a site for work - it works well in ff/chrome/ie7/ie8 with no script errors.
On IE9 the last step of the application causes the entire tab to whitescreen with no script errors or warnings. (changing the document mode to ie8 will fix the problem but is obviously unsuitable for production)
Unfortunately the site pretty complex with a ton of ajax, and in-page scripts so I can't really post the relevant code easily. I'm more trying to figure out how to diagnose this.
I've checked the IE error logs and they are empty. Web developer tools tells me nothing. The site is not using any plugins (Flash/Silverlight, Ect. ) just javascript w/jQuery.
There is a PDF being displayed in an iframe around the step where it fails - but a nearly identical pdf is displayed in the previous step (using the same method) without problem. The code fails around a call to the jquery UI window but I can't seem to get the exact line.
If anyone has a clue how to try to diagnose this further I'd really appreciate it. I can keep hunting for the bug but I've never seen this kind of behavior before and just am not sure what I am looking for.
Thanks for all the input on this. Sorry I got completely overwhelmed by a few projects at once so I wasn't able to post updates on the debugging steps.
It took forever but I finally realized that everything was crashing when I closed the dialog containing the first PDF.
One of my helper functions was opening the dialog and automatically destroying the contents on close. Normally this works fine as I'm either removing a div containing the page fragment, or the iframe.
In this situation I had a page fragment loaded into the dialog which contained some buttons and the pdf iframe. I called the .remove() method on the parent element containing the iframe rather than the iframe itself. For some reason this seems to work fine in every other browser - but in IE9 it pretty much kills the page rendering without any warning or message.
I strongly suspect that the culprit is the adobe plugin but I'm not entirely sure.
Here is the fix-
Html:
<div id="container">
<iframe src="loremipsum.pdf"></iframe>
</div>
Javascript:
//Ruins my entire week
$("#container").remove();
//Works as the pdf is removed directly
$("#container").find("iframe").remove().end().remove();
I ran into the same issue on IE11 while trying to remove an iframe in a div with AngularJS. Removing the iframe first would just cause the same issue, so I navigated the iframe src to a new page (about:blank) first, then removed the div which worked. Hopefully this helps someone with a similar problem.
Pseudo-code below:
$ctrl.iframeUrl = 'about:blank'; // change the iframe url here
$timeout(function(){
$ctrl.removeIframe(); // remove the iframe here
});
As a thing to try - see what's in the IE9 DOM viewer after it whitescreens. There's a decent chance that most of the stuff is there and just not rendering properly (or having something else rendered over it). At the very least, knowing whether it's losing a ton of stuff out of the DOM or not should give you some useful data.
I don't understand this at all. Here is some Javascript code that works in every browser but IE 9. It is called from a Flash movie using ExternalInterface, and is meant to dynamically resize the movie in the DOM if the size of the movie changes internally
function vResizeFlash(swfId, ht) {
document.getElementById(swfId).height = "100%";
document.getElementById('flashContainer').style.height = ht + "px";
}
But it works fine if I alter the document.title:
function vResizeFlash(swfId, ht) {
// IE 9 won't run the rest of this function unless
// we go through the charade of changing the document title.
if (navigator.appName.indexOf("Microsoft") != -1) {
var docTitle = document.title.replace(/^(.+?)\s*$/,"$1");
document.title = docTitle + " ";
}
// Well-coded browsers begin here
document.getElementById(swfId).height = "100%";
document.getElementById('flashContainer').style.height = ht + "px";
}
Here I simply trim any white-space from the right side of the document.title, then add a single white-space character to it. Suddenly the following lines get executed. Note: there are other ExternalInterface calls on the page, and all of them work fine, even in IE 9, so it's not a Flash/IE 9 problem.
I stumbled on the fix because I was altering the title to show the function arguments (as a quick debugging test), just to make sure the function was getting run. And suddenly the code worked. Take it out? Doesn't work. 100% reproducible.
Anybody know why this absolutely stupefying behavior takes place?
UPDATE
#c69 has posed the question: "Maybe its IE9's dead code remover?"
I didn't know about this, so I went and Googled and found this article on the topic, as well as some discussion of it elsewhere. I don't know enough about it to evaluate how this would affect a two-line Javascript function, however, especially since one of the lines does have a referent on the page (although it is late-loading through the SwfObject code). Still, it would be a pretty bad bug for a code "optimizer" to remove lines of code it deemed unnecessary because it doesn't understand how they are called. And if it did fail to understand how the lines are called, how does inserting a line making a bogus change to the document.title render that code suddenly "necessary"?
UPDATE 2
Another piece of the puzzle This may have something to do with IE 9's compatibility mode. The page starts out in IE 9's standards mode.
Now, if I turn on IE's compatibility mode,
the problem goes away without using the above hack. Turn it off, and the problem returns (if no hack present).
But when I tried to make a simple test using the exact same HTML (minus a couple of JSP tags) and a stripped down SWF that only contains the resize code and the tools to test, everything works fine. In that case, however, no compatibility icon is displayed at all.
We're using Tomcat 6.0.32. I'm not aware that we are using any special headers, and there are no meta tags regarding IE compatibility mode (in either the main app or in my test app).
like InvertedSpear mentions, check your doc type out, i've had problems with IE9 recently and most of it boiled down to the Doc type tags triggering a compatability mode i didn't need, the same can be true of the meta tags so it might boil down to your Meta tags.
You can always impose a working compatibility mode using the links below too.
from: http://evolpin.wordpress.com/2011/02/25/ie9-compatibility-and-the-meta-tag/
I’ve discovered that this is indeed documented by Microsoft…
http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx
“The X-UA-Compatible header is not case sensitive; however, it must appear in the header of the webpage (the HEAD section) before all other elements except for the title element and other meta elements.”
Whenever I see something like this happen in any language it's because there is other code that has a bug. As you pointed out your simple case doesn't produce the problem. Try removing other code a few lines at a time until the problem disappears - the last removed code should contain the problem.
Cheers
I am unable to replicate the problem when I want to but it seems like every now and then, my site using FCKeditor will load the interface but not the content (Clicking the buttons don't do anything). No javascript errors show and once it starts doing it, it usually is tough to get back to normal. The way I found to work best is to click the refresh button multiple times in a row, then the FCKeditor loads correctly. I have only seen this in Firefox
Has anyone else run into this problem or know a solution. It is a little annoying for me but I am afraid my client would be really confused
I have experienced the phenomenon you describe in FCKEditor's successor, CKEditor. Somehow, the IFRAME that contains the WYSIWYG content doesn't get loaded. What always helps is switching to source code view and back, but that's no solution.
I have seen the problem described on the Internet but with no solution.
Caching is not the problem, I think. Sometimes, if you press "reload" 20 times, it will break at the 21th time, and work again on the 22nd time.
What minimized the number of occurrences for me was to activate the thingy to the editor's bottom that shows the element path (body > p > span, I forgot it's name). I don't now why but since I turned it on, it very rarely breaks any more.
I have had this problem. I solved it by pre-loading FCKeditor in a hidden iframe during the login process so that when it got to the pages where it was used it was already in the cache.
i would strongly advise to upgrade to CKEditor which can not only be spelled out verbally without offending anyone, but also optimizes the loading time to minimal. I find it much more responsive than his F- friend.
I encountered this problem with firefox (not reproducible) and chrome (reproducible).
The solution that worked quite well in both cases was to wait for some milliseconds before initializing CKE :
setTimeout(function() {textarea.ckeditor({customConfig : 'custom/schnonfig.js'})} , 100);
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 {}"));
})();
I'm hoping some Javascript/ASP.Net gurus can give me some hints here.
I've written an application which (unfortunately) uses UpdatePanel (yes, I'm aware that was a dumb idea, too late now though, I understand it more now - even though its an intranet site I'm having troubles with it)
The site is a web based timesheet site, kind of tabular format. Anyhow, it basically saves everything in it in an update panel, and autosaves once a minute. This seems to work fine for me, but I use firefox. Other users with more timesheet entries, and IE7 have problems with IE memory usage increasing and their browser slowing down.
I ran Sieve (checks for memory leaks on a website) and it was pretty obvious it was bad:
alt text http://rodh.org/images/Programming/sievemain.png
Thats my site loaded up and left running for a bit, refreshed it at the dip and left it and you can see once a minute it jumps up a little bit. THe area on the timeline before the dip was when i was hitting the save button a bit, so its obvious what is causing it. The DOM nodes and memory both go up.
I'm using a ScriptManager.RegisterClientScriptBlock's (mainly to get the clientID's of controls so I can do javascript totals) and also a ScriptManager.RegisterStartupScript on page_load to get set the focus to be the same after a partial postback. Maybe they are contributing?
Is there any tools that can help me out further to this? Sieve reported alot of empty divs being made when the postback occurs? bit I've never used sieve before so maybe this always happens?
alt text http://rodh.org/images/Programming/sievnodes.png
Is there some sort of code analysis I can do, or something that at least lets me see the new DOM nodes created each time...
I'm thinking hte problem might be to do with my code behind hackery to get the client id's, it stores them in an array, and then recreates taht array on each postback, perhaps something is going wrong there?
I've uploaded my JS file which does that hackery, and also the code behind in case anyone needs more info.
http://rodh.org/images/Programming/javascript.txt
http://rodh.org/images/Programming/codebehind.txt
So I guess my question is:
- Can anyone think of anything immediately that would be causing this?
- what are some common causes of increased DOM usage on UpdatePanels (using Jquery too btw)
- what tools can I use to debug?
I can tell you first hand Microsoft knows about the IE problem(KB 2000262) with UpdatePanels. Its a DOM parser issue. I had a site that ran fine up until a certain page content size and then IE(all versions) had a fit. FF and other browsers handled the same pages with ease.
Things I did to make my pages faster:
Use UpdateMode=Conditional wherever possible
Implement the KB 2000262 fix
UpdatePanel Async Postsback slow in IE…Part 3