Firefox extension: window activate/deactive event - javascript

in my Firefox extension I try to handle the event when the browser window is activated or deactivated. Adding the events "activate" and "deactivate" to the window does basically work. But noticed that when I move the window, first "deactivate" (when I start moving) and then "activate" (when I finished moving through releasing the mouse key) occurs. For me, the whole time the window is active.
What is the best / simplest way to the "deactivate"/"activate" event pair when moving the Firefox window? Thanks a lot for any tips!
Christian

If I understand you correctly, you can use this:
window.addEventListener("blur",function(){
//mystuff
},false);
and this:
window.addEventListener("focus",function(){
//mystuff
},false);

I finally decided to user timer-based solution: I don't handle DEACTIVE events at once, but only if there weren't any ACTIVATE events after, say ten, seconds. So only after ten seconds I consider a window as deactivated. Resizing/Moving is typically done in way less than 10 seconds. No the optimal solution, of course, but serves my purpose sufficiently.

Related

Is there a way to detect if the browser window is visible to the user?

Is there a way to detect if the browser window is visible to the user? I know this has been asked before. However, the answers I have seen suffer from the following problems:
Using visibilityChange event. The problem with this approach is that (at least on a Mac) when one uses cmd+tab to switch between applications, this event is not fired.
Using onBlur and onFocus events. These solve the above problem. However, these also fire when a page's visibility does not change. For example, if the browser is open in one half of the screen and another application is open in the other half, then switching between these will cause these events to fire; even though the user has the browser window visible all the time.
Using onPageShow and onPageHide events - these appear quite useless for the task of visibility. For example, onPageHide does not fire either when the page is minimized, or when cmd+tab is used to switch to another application that occupies the whole window.
What is the ideal solution for checking whether the page is visible to the user given the above issues?
Thank you.
Could you use setIterval polling and document.hidden?
nice wrapper Visibility.js

Hack for `mouseup` outside of window in IE 7/8

I understand the event mouseup for the window just isn't there for IE 7 and 8. I was wondering if anybody has found a work-around for this or if that is even possible.
I am currently working on a project where the user can click, drag to draw a line, and if the user drags outside of the window and lets up on the mouse, the drawing transaction will be cancelled.
Your difficulty sounds like it would be more from the window losing the scope of the event.
Are you using jQuery? With jQuery you can also tag onto the mousemove event and use the "which" attribute to detect if the button is pressed. This even fires when you come back into the window. But it DOES NOT fire when you are outside of the window.
Alternatively you can use $(window).mouseleave to detect when it leaves the window. However once it has left the window you cannot detect further mouse events (that would be a horrible flaw if they could detect when you right clicked on your desktop etc).
So you are somewhat limited by the browser security implementations in ALL browsers and won't be able to bypass that... but you can add some work around events to provide a "similar" experience.
Not directly, but I believe this should work.
In your mousemove event, check the Event.buttons property. If it is zero, then the user must have released the mouse outside the window and you can cancel the drag.
I am checking the browser compatibility of this now, so this answer may be edited. My computer's being slow right now!

Firefox extension: observing "user-interaction-inactive" across multiple browser windows

I'm trying to observe within my Firefox extension when a user is inactive. My current solution is derived from a similar question, found here (see accepted answer). And it basically works just fine.
I noticed, however, that it doesn't seem to distinguish between multiple open browser windows - that is, a user cannot be active in one window and inactive in another one. At the moment the active/inactive state is some global state across all Firefox windows. Thus, a user becomes really inactive, if the user is active in all open browser windows
Is there a way to distinguish between different windows, or do I have to deal with it (wouldn't be to bad, but still...)? Thanks a lot for any hints on that!
This is something that you will have to implement yourself. It also largely depends on what you mean by "inactive in a particular window". I guess that you mean the lack of mouse and keyboard activity in this window. So you would have to add a listener for keydown, keyup, mousemove, mousedown, mouseup, DOMMouseScroll, touchstart, touchend, touchmove events. The listener for these events would set a timeout, e.g. for one minute. However, it would first clear the already existing timeout if any. This way the timeout will fire one minute after the last event received, one minute after the user stopped generated keyboard or mouse events in the window.
The subject parameter the observer passes should be the window of the currently active browser window.

Chrome javascript debugger pauses on timeouts, can't debug click events

Almost every webpage has all sorts of timeouts and intervals that are continuously running, so using the pause javascript button in chrome has always just broke on those events and never given me a chance to test anything.
For example, I want to follow what happens when I click something on a page. Instead of digging through the resources, it would be helpful to pause the js, click the thing, and see what code is run. Unfortunately, as soon as I click pause, it breaks on one of the page's interval events.
Is there a way around this?
I think you may find this bookmarklet helpful...and usable in more than just Chrome (though that's where I like to develop too)
Visual Event

Why does the 'window.resize' event fire when changing tabs in Chrome (6.0.472.55)?

I came across an interesting bug feature tonight when writing a handler for window.onresize in Chrome (the latest version 6.0.472.55). First open two tabs, then in the first tab open this jsFiddle.
Resize the window at will and the dialog box works as expected. Now, try switching to the 2nd tab -_-. Why is resize firing when the tab is changed? Could someone provide insight/more details if I need to file a bug?
The bug has been filed with Google. For the time being, I've just ignored it since my actual onresize handler doesn't display alert boxes.
Well how about that? Sounds like a bug. I would guess that onresize is listened-for by a combination of behaviors, probably new data about the page size that, for whatever reason, is coming in when a tab is focused.
In the version I use on Windows, 5.0.375.127, it doesn't happen, but if I actually resize the window, the resize event fires twice.
Knowing it's there, you can take a step to defeat it (that Google ought to do for you eventually). Wrap an if statement around your handler that checks for an actual change in the clientHeight or clientWidth if you need something to happen only if the event (as we understand it) actually occurs.
From the bug report:
When using Dev Tools in splitview and switching to a Tab without Dev
Tools opened in split, the resize-Event will be fired.
So, if the next Tab doesn't have the same window size, resize() will
be fired.
Without a working knowledge of how Chrome handles tab switching and page rendering, my guess is as good (or bad, depending how you look at it) as the next guy's. I would guess that rerendering the page, or reloading the already rendered page if it caches it, triggers the onresize event. This is what happens when the tab is switched. Following my theory, I would guess that Chrome doesn't trigger the resize event on initial page view because it has been designed not to. But again, as I don't know how Chrome handles tab switching internally, this is just speculation (food for thought).

Categories