Chrome v. 35.0.1916.114 m seems to have changed the way that it handles or implements iframe in the DOM. This has had the effect that some previously working code has become broken. For example:
frames['SomeFrame'].location.href = "SomePage.html";
No longer works because location is undefined. How should this be handled moving forward? It's likely that this old code improperly used the DOM, and until now Chrome had supported it.
Replace that with frames['SomeFrame'].src
Related
Since the new DevTools of Firefox came out iI have this Problem on multible PCs:
I open a Webpage and inspect the DOM
I trigger an AJAX call or some DOM Creation by JavaScript and place the new elements into the DOM
I Can't pick the new Elements anymore and they are gray and not light blue. (sometimes the HTML Tag gets picked)
the elements are shown in the DOM inspector
I can't find any bug report or option to change this behavior. There are any information about this?
The same is happening for me as well. I have tried by best to find a fix or know more about this.
Unfortunately no one has posted anything about this issue in any of the forums. I would definitely say this is a bug in Firefox.
I suggest you to downgrade your browser version until firefox releases a fix or next stable version. Meantime you can use Chrome browser if you're confortable.
I'm working on a popup and i'm having some hard time with Internet Explorer 9. This is the piece of code that gives me trouble:
var popUp= document.getElementById('projectInfo');
popUp.style.left=(tempX-310)+'px';
popUp.style.top=(tempY-110)+'px';
In IE9 (haven't tested in prior versions), popup is null. In adition, i've tried including my .js file just before the body closing tag and wrapping my function in a "document.ready()" function but none of this worked. The same code though works perfectly in Opera, Chrome and Firefox.
Does anyone know what's going on?
Note: The function is called in the body's onLoad atribute of my html.
Without using function it can't work
window.onload = function() {
var popUp= document.getElementById('projectInfo');
popUp.style.left=(tempX-310)+'px';
popUp.style.top=(tempY-110)+'px';
}
IE is having some known issues with getElementById.This post may help .
http://webbugtrack.blogspot.com/2007/08/bug-152-getelementbyid-returns.html
http://www.impressivewebs.com/avoiding-problems-with-javascript-getelementbyid-method-in-internet-explorer-7/
In previous versions of IE (and apparently Chrome and Firefox), getElementById would check for an object with the given id and if it didn't find it, it would take an element with that name.
IE9 doesn't do this, so you need to make sure you have an element with id = projectInfo, not just name=projectInfo. We just discovered this throughout one of our applications. Not great.
EDIT: I've identified a link to the below problem to the use of $(document).ready() instead of using the old fashioned onload attribute of the body
The problem
In IE7 the canvas/excanvas does not render until you hit reload -- I've cleared my cache multiple times, and the result is consistent.
The canvas is always empty on initial page load, and an error comes up "object does not support this property or method" -- a message that refers to the .getcontext() call. However, once I hit reload, it magically works. Always after a reload.. it works. never by any other means of reaching the page does it work. There is always an error on initial page load.
By "initial page load" i mean when the page loads from a clicked link, a manual entry to the address bar or via the back/forward buttons.
Here's a reproduction:
http://www.trevorsimonton.com/canvas_problem/example7.html
Note that there's a lot of extra Javascript in there to reproduce the Drupal environment where this problem originated.
The code
I am using excanvas r3 -- http://code.google.com/p/explorercanvas/downloads/detail?name=excanvas_r3.zip and Drupal 6
EDIT: I removed a bunch of the code I had, because I have 2 places on the site where I am handling canvases completely differently. I was able to reproduce the problem at the destination above (http://www.trevorsimonton.com/canvas_problem/example7.html)
The root of the question
Does anyone know more about how excanvas or IE7's behavior that might trigger this kind of issue? What, aside from the browser's cache, could be causing the page to load differently between a "reload" command and anything else?
Because this is Drupal 6 I'm using Jquery 1.3.2
Apparently $(document).ready() fires before excanvas is really ready. Although that's not the case in most browsers, of course IE is going to be different.
IE7 needs all calls to getContext() to originate from a function passed into the body tag's onready attribute.
Do do this in drupal is a little tricky, but I just hard coded it into the page template.
See this if you want the full how-to: excanvas and JQuery 1.3.2 document ready don't get along
Further to this question, I'm getting a curious result when binding a function to the change event of the Storage object in Chrome 8.0.552.224.
The test:
<!DOCTYPE html>
<html>
<head>
<title>Chrome localStorage Test</title>
<script type="text/javascript" >
var handle_storage = function () {
alert('storage event');
};
window.addEventListener("storage", handle_storage, false);
</script>
</head>
<body>
<button id="add" onclick="localStorage.setItem('a','test')">Add</button>
<button id="clear" onclick="localStorage.clear()">Clear</button>
</body>
</html>
Open up the page in two Chrome windows, one window with two tabs,
Click the 'Add' button
When I do this I get an alert box displayed on on the second tab and on the second window but not on the tab that invoked the event (the I clicked on). As I understand it I should see three alert boxes (one for each tab opened).
Is this a bug? Is anyone else getting this behaviour? If not what version are you running? Or have I just got this all completely wrong?
Update and final conlusion
It turns out that the spec actually says that this is the desired behavior, therefore IE9's implementation is broken.
4.2 The sessionStorage attribute
When the setItem(), removeItem(), and clear() methods are called on a Storage object x ... if the methods did something, then in every HTMLDocument ... [that is] associated with the same storage area, other than x, a storage event must be fired....
So as we can see, the spec does do a really bad job at making it clear, that this is the specified behavior. That was the reason why Opera 10's implementation was broken and it's most likely also the reason why IE9's implementation is broken.
What do we learn from that? Always read every, single, word of the specification (especially if you're implementing the stuff...).
Old answer
As you said the basic behavior here is "Invoke on all but the current page".
There's an old Chrome Bug Report from last July.
As one can read there, Firefox has the same "issue". I've tested this with the latest nightly, still behaves the same way like in Chrome.
Another test in Opera 11 shows that this must be some kind spec'ed behavior, since Opera 11 does the exact same thing but Opera 10 did fire events on all windows / tabs. Sadly the official changelogs for Opera 11 do not state any change for this behavior.
Reading through the specification, nothing there states this behavior. The only thing I could find is:
The storage event is fired when a storage area changes, as described in the previous two sections (for session storage, for local storage).
When this happens, the user agent must queue a task to fire an event with the name storage, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at each Window object whose Document object has a Storage object that is affected.
Note: This includes Document objects that are not fully active, but events fired on those are ignored by the event loop until the Document becomes fully active again.
Well, what does the Note mean?
From another specification:
A Document is said to be fully active when it is the active document of its browsing context, and either its browsing context is a top-level browsing context, or the Document through which that browsing context is nested is itself fully active.
Doesn't make sense? Yes. Does it help us in any way? No.
So we (in the JavaScript Chatroom) poked on #whatwg to see what all of this is about, so far there has been no response. I'll update my answer as soon as we get any response.
To conclude for now
Firefox, Chrome, Safari and Opera have the exact same behavior. That is, they do not fire on the tab / window that made the chance to localStorage.
But IE9 Beta behaves like Opera 10, so it fires on all tabs / windows.
Since the author of the localStorage spec works at Google in R&D, I hardly doubt Chrome would get this wrong. And since there are no Bugs on this over at Bugzilla and Opera changed the behavior in 11, it seems that this is the way it should work. Still no answer why it works this way and why IE9 behaves differently, but we're still waiting for a response from #whatwg.
Ivo Wetzel's answer for what is going wrong is correct.
I was having the same problem but managed to work around this limitation in the spec by manually creating and firing a StorageEvent in the tab that initiated the storage change (see StorageEvent#initStorageEvent).
I have the following javascript being called to request a focus when page is loaded.
This code works 100% OK with Firefox and IE7, but Chrome and Safari do not seem to move the focus at all. How to make it work with all browsers?
document.getElementById("MyFlashFile").focus();
It took me hours searching the Internet, but finally I found a solution that works on the lastest versions of IE, Firefox, Chrome and Safari.
The following code solves the problem for good:
<head>
<script type="text/javascript" src="swfobject.js"></script>
<script>
function setFocusOnFlash() {
var f=swfobject.getObjectById('myFlashObjectId');
if (f) { f.tabIndex = 0; f.focus(); }
}
</script>
</head>
<body onload="setFocusOnFlash()">
This example assumes the flash is embedded using the SWFObject library. If not, you should set the f variable to the Object or Embed tag which holds the flash movie.
Edited on 5 May 2012: Well, unfortunately it seems that the tabIndex workaround no longer works for all combinations of browser (Chrome/Safari) and operating system.
For instance, currently Chrome 18 on Windows fails.
See the link below, provided by Christian Junk, to get the status of the problem's resolution.
Unfortunately there is no way to ensure that you can set focus to a flash file that works in all browsers. IE and Firefox have solved this problem (for the most part), but Chrome and Safari are both based off of Webkit which does not have a solution.
If you ever notice on YouTube or other video / flash site that the first thing you see is something to entice you to click on the player, that is due to this problem.
One developer came up with a clever workaround, but it does involve adding some ActionScript to your flash file, this can be a pain in the ass if you are building a generic player.
Gary Bishop: Fixing Firefox Flash Foolishness
Another sort of solution is to set your wmode to opaque. I've heard this works in some situations, but will screw up cursors in text areas. I haven't had much luck with this either, but you can give it a shot.
You can find more information about the no focus bug on bugzilla.
It seems that there is a bug in Chrome:
"window.document.getElementById('swfID').focus() not working for flash objects"
http://code.google.com/p/chromium/issues/detail?id=27868
I've tried to find a workaround but I was not able to find one ;(
Regards,
Christian
In addition to Cláudio Silva answer , you need to set wmode="opaque"
Ensure this code is being called after the entire page has been rendered. It's probably being called above the HTML it refers to, so the element will not exist yet.
Various JavaScript frameworks have utilities to tell you when the DOM is ready.