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).
Related
For a sandwich, there is a piece of bread at the bottom.
I've tested window.blur() in
https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_win_blur
Please test the code in the above link.
But it seems it does not work.
The new window does not go to the bottom.
It appears on the top since it was created.
I can always see the popup since clicking the button.
I have tested it in two PC(windows 7 and 10) with newest chrome, firefox, IE. But none of them worked.
Maybe I am not understanding what window.blur() mean?
P.S window.focus() works well in any case.
Browsers generally ignore window.blur(). This is recommended by the spec.
User agents [browsers] are encouraged to ignore calls to this blur() method entirely.
Though the title is decently explanatory, I'm curious as how netflix detects how a user is afk. I've looked through the code via chrome's inspect element, and found it may be done through javascript/jquery depending on the mouse position. Is there anyway anyone can verify this or if incorrect, discover the method it is determined? I'm looking to make a plugin to prevent it from pausing.
It's hard to know for sure what Netflix exactly uses to determine if a user has left Netflix, as Netflix probably obfuscates their JavaScript code and it's illegal to reverse engineer it. But there a few possibilities:
A timer that constantly calls document.hasFocus() to see if it has changed.
Most web browsers (Firefox v10+, Chrome v13+, Internet Explorer v10+, Opera v12.10+, and Safari v7+) have a built-in event to check if a window/tab is active or not. Mozilla has documentation on using the visibilitychange event, including an example with a video that pauses or plays when the visibility changes.
Whenever the javascript events onmousemove or onkeydown is called and the page is loaded for the first time, a variable is set to the current unix time. A timer checks this variable to see if so much time has elapsed since the event is called to see if the user has left the window. This is highly unlikely as people may watch a 2 hour movie without ever touching their mouse or keyboard.
There's also this previous question on StackOverflow which includes many different answers to the same question you asked.
I'm trying to debug a web page that makes heavy use of events, and so I need to monitor all events that are fired.
Most of the events are bound using jQuery. Hence, it would be particularly useful if there was a way to specifically monitor only those events.
Of course you can do just fine with Firebug, the console and the scripts tab where you can add breakpoints and watches, but you want to do it smarter / easier obviously.
There is a neat Firebug plugin called EventBug that just logs all the events and groups them by event type so you can expand and see what triggered them.
EventBug doesn't do it realtime, you have to refresh though.
One other way is to use the 'Log Events' feature against any DOM element in Firebug. This does do it realtime and you can see what order events are fired / triggered as well.
Try this:
Toggle open Firebug
Right click the element in HTML tab, if you want to see all events then right click <body>
Choose Log Events from the context menu
Make sure the Console tab is enabled
Click to enable the 'Persist' mode in the Console tab (otherwise Console tab will clear after the page is reloaded)
You may have to select Closed (manually)
Voila! watch events stream in the console tab
This is what you see with Log Events:
Also worth trying the FireQuery add-on for Firebug to see what elements in the DOM have jQuery events attached to them and what they are.
And as benvie's answer mentions, this is possible in webkit's developer tools as well.
This has been introduced some versions ago but as of Firefox 35 events associated with an element can be seen on the Inspector: next to the element which you want to see the events (in case there is any) there will be an icon with the 'EV' letters. Click it and you will see a small popup window with the events for that element.
More info: http://flailingmonkey.com/view-dom-events-in-firefox-developer-tools/
This doesnt exist in Firebug I believe, and the underlying problem is lack of support or lack of exposure at the api level. Alternatively, there's only a few ways to subscribe to DOM events: Element.prototype.addEventListener (and window.addEventListener and document.addEventListener and XMLHttpRequest.addEventListener and some others) aside from 'onevent' properties which are observable and interceptable.
But realistically, the WebKit debugger and Chromium's debugger (which is webkit's with extra points) allow one to debug and observe attached listeners. Sometimes it's easier to debug one browsers's bugs in another browser with better exposure of application/runtime state, even when that browser doesn't exhibit the bug.
https://developers.google.com/chrome-developer-tools/docs/elements
Event Listener Breakpoints have been introduced in FF 69 (and further improved in FF 71). Relevant docs are here.
It allows you to automatically break on any event of a given type. This screenshot (from above article) shows how it breaked on a Keyboard event:
The article further explains (1) how instead of breaking every time, it can just log matching events, and (2) how you can blackbox certain sources, to avoid having to wade through the internals of framework code (such as jquery, react etc.).
They present another screenshot of how that looks like:
I am creating a JavaScript bookmarklet that dynamically updates the title bar, but it doesn't display the changes in IE (I've tried IE7 and IE8). Here's a simplified example that demonstrates my issue:
javascript:document.title='new title';alert(document.title);
Notice that the the value is updated in the alert, but not on the title bar or tab. It is working fine for me in Chrome.
It's a bug in IE. It's possible to work around it by changing the URL's fragment identifier ("hash"), which may or may not be feasible for your purpose:
javascript:document.title='foobar';location.replace('#'+new Date().getTime())
new Date().getTime() is used to get a unique number that is unlikely to be used as a name or ID anywhere in the page (so that the page does not actually scroll).
From my experience most browsers will update the new TITLE in the browser window or tab.
However it seems with IE browsers they only set it one time and then that's it - no further updates. If thats true (would love to see a solution as well) then there is no way around it.
I'm currently working on a jQuery plugin that tracks a visitors mouse behavior. Movements, clicks, scrolling and resizing are all recorded and sent, via Ajax, to a location where this data is parsed and stored.
Originally, the data is sent to a script when the user leaves the page. By 'leaves' I'm referring to refreshing, going back and forth though history, closing the window/tab and going to a different address.
The solution works in all browsers EXCEPT for Opera. I'm using jQuery's 'unload' event which isn't supported by Opera at all. Neither is onbeforeunload or onunload.
The question is, how do I implement this kind of functionality for Opera browsers?
One solution I had was to make special use of a 'polling' feature I created. This feature allows you to specify an interval which pushes the content to the server every 'x' seconds. Setting this to 1 second specifically for Opera browsers would probably solve this issue, but it's an awful amount of overhead and the requests aren't always completed in sequence, etc ...
Any suggestions or am I only stuck with the above option?
Thanks!
I suppose I could just link you guys to the plugin source. http://www.thedrunkenepic.com/junk/jquery.mousalytics.js
Regarding the code linked above, adding:
if(window.opera)
{
options.interval = 1;
}
On line 89 works great. My only concern is overhead, so I'm still looking for a more elegant solution.
According to http://bytes.com/topic/javascript/insights/799229-browser-quirk-onload-onunload-do-not-fire-back-forward-refresh-opera, Opera never really fires onload / onunload events, so functionality like this isn't possible without hacks.
http://dev.opera.com/articles/view/efficient-javascript/?page=4 seems to confirm this, and basically states that opera tries to maintain the state of the page across requests.
On further investgation, http://unitehowto.com/Onunload indicates that it might be possible with opera.io.webserver.addEventListener('_close', onunload, false); (where onunload is a previously defined function), however it also indicates that this functionality is not consistent across all versions of opera, and might not work at all.
I think that your best option is probably to use the polling option for Opera, or possibly use a server-side check for the current page and where it falls in the history queue.
Does adding this line of JavaScript work for you?
history.navigationMode = 'compatible';
Source: http://www.opera.com/support/kb/view/827/
I've had the same problem and this saved my day:
if( typeof(opera) != 'undefined' )
{
opera.setOverrideHistoryNavigationMode( 'compatible' );
history.navigationMode = 'compatible';
}
More info about this problem can be found at: http://www.opera.com/support/kb/view/827/