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 {}"));
})();
Related
I am trying to create a bookmarklet that will insert some text in a textarea on a webpage (webpage is for internal use so no point in linking).
Here is example of javascript code i tried:
(function(){document.getElementById("textareaID").value="Some text";})();
I'd like to point out that i tried different element selectors (byClass, query...) and different attributes (even tabindex) to the same result. Also tried in both Chrome and IE11.
So, for some weird reason my javascript runs when i run it from console (or as a snippet) but i get an error "Cannot set property 'value' of null" when i try to run it from bookmark menu.
I tried creating a bookmarklet by myself
javascript:(function(){document.getElementById("textareaID").value="Some text";})();
and tried using online bookmarklet creators to encode special characters
javascript:(function(){document.getElementById(%22textareaID%22).value=%22Some%20text%22;})();
but no luck.
Bookmarklets definitely work on a page (tried with alert "Hello") but i seem to have a problem "capturing" elements.
Also i noticed that ID's of some elements change sometimes (not sure why though), but i always inspect to make sure that ID i try to use exists or i use some fixed value like tabindex. Besides, as i said it works when run from console, so i couldn't have screwed it up somehow... or could have i?
So the problem was execution context.
Because IDs of elements were changing i had to inspect them before running js from console and inspecting changes the execution context from top to wherever the element is. That's why it was working from console and not from bookmark...
So, to write into a textbox inside specific frame:
let Iframe = document.getElementById('yourIframe').contentWindow.document
let value = Iframe.getElementById("textboxID").value = "Some Text"
After that only thing left is to wrap everything inside a javascript:(function(){..your code here..})(); to create a bookmarklet.
I am experiencing a very strange issue i am hoping someone can answer (its kind of broad, but i will explain it my best), code works on local page when opened, but as soon as the same page is uploaded it throws an error. Two others have also looked at this, resulting in more confusion.
I downloaded FancyBox to use the inline feature to pop up a user form via href link, instead of taking the user to an additional page.
You can see the "stock" fancy box here:
1 fancyapps.com/fancybox/demo
Under various options, Inline is what i am using.
I didnt need all of the other features that came with FancyBox so i stripped the page to the following, which works just fine:
2 *Fancy Box Demo Stripped to Inline Feature only*
So then, i applied this code to our sandbox copy of the page to implement:
3 *Sandbox Copy with Fancy Box inline feature added to "make offer" link*
It stops working! There are no conflicts with other javascript on the page, and the only difference is that it has a couple of color .css changes, all .fancybox was named to .ptroffer and that the css code is not inline on the page (which wouldn't cause this error anyway).
This same page, opened locally works beautifully - upload and it throws error.
SCRIPT5007: Unable to get value of the property 'ptroffer': object is null or undefined
<script type="text/javascript">
$(document).ready(function() {
$('.ptroffer').ptroffer();
});
</script>
Works fine with link #2, and with link #3 locally, but with #3 uploaded it throws error.
Please!
Something in your code somewhere is overriding $. If you change that "ready" handler to call
jQuery('.ptroffer').ptroffer();
you won't get that error. However, things may not work; I think that an older version of jQuery is being imported by something (1.3!), which is bad.
edit oh I see, something's pulling in Prototype. You've got a regular script soup going on there, and things are going to be unpredictable and bizarre until you get that straightened out. Probably somewhere in there something's calling jQuery.noConflict(), but that "ready" handler you're adding isn't written to expect that. Whatever code that's expecting jQuery 1.3 may be in for a surprise also.
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 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 :)