Develop Reference

Refresh Browser on Window Resize (only when it is being expanded or made larger)

I found a couple different answers already such as this one How can I refresh the screen on browser resize? however I don't want it to just refresh any time the window resizes, only when the window is made larger.
This is a dirty workaround for a bootstrap menu bug. Every time i resize the window smaller the menu stays where it needs to, however when i resize the window back to larger size from small, the menus drops down below itself. It only does this in chrome and firefox. However its a annoying enough bug that I implemented the refresh triggered by resize JS but it was getting annoying with it refreshing anytime the window was resized in any way.
Anyone have a clue?

This answer seems appropriate: https://stackoverflow.com/a/12661128/498768
In summary: Keep track of window size using variables. (see the linked answer for a code example)

Trigger a function when elements need re-rendered in an extension?

I have a function that positions an element in my Firefox extension, and I need that function to be called whenever an event causes the window/chrome layout to change.
Events would be:
When a new window is created, after the chrome is rendered.*
When a window is re-sized.
Any other event that might cause the chrome layout to change size or shape?
(*) Right now, the function runs when a new window is created using:
window.addEventListener("load",myfunction);
But this runs before the chrome is rendered, and element sizes have wonky values. I need it to run after Firefox determines the actual size and placement of the chrome elements.
What are the events I would need to bind to, and how do I bind them?

I was in a similar situation, and didn't really find a good solution. However, the non-standard MozAfterPaint event may help, but comes with a somewhat sizable performance penalty however (so make sure you remove it once you don't need it anymore).
The resize event should do the trick.
There are tons of things that may cause things to change. New CSS/Images loading, toolbar customization, etc. 1. and 2. should cover most (all?), however.
The devtools layoutview ("Box Model") seems to use MozAfterPaint as well.
If possible, you should try to avoid having to calculate sizes yourself, however, by making use of the XUL/HTML flexbox model and CSS without fixed sizes (or min/max sizes only).

jquery animation freaks out in background

I have made a little animation that resembles the coverflow itunes uses as a screensaver on mac. It fetches a list with filenames using ajax and starts looping over them to randomly fill divs with them.
Demo code:
http://jsfiddle.net/FQmXK/4/
All of this works great but the problem starts when you minimize the browser or go to a different tab on google chrome. The animation seems to queue up a bunch of cycles and tries to execute them all when the window is opened up again. This is causing all sorts of problems, images being undefined, all kinds of flashing on the screen...
I was wondering if there is any established solution for this queueing behavior? Can I force it to execute all animation even if its not visible?

You can detect browser window focus :
Is there a way to detect if a browser window is not currently active?
And set a variable.
If the window is inactive, set a variable to false, and do not queue further animations
until the window becomes active.

This question discusses the same problem and provides a generalized solution:
How can I make setInterval also work when a tab is inactive in Chrome?

Most Flash games don't resize properly in a browser window. How can I easily make my game do this?

Most flash-based browser games don't seem to resize properly when the user resizes their browser window (i.e. ctrl+mousewheel).
Example of bad resizing: Boxhead The Zombie Wars. Please refrain from playing for a moment, lest you forget about my question.
Some (surprisingly very few) actually do resize properly. Example (at least in Chrome): D.N.8
Is there a simple or standard technique to accomplish proper resizing? How do you do it?

This is possible, for starters you need to ensure that the stage doesn't scale itself automatically when the player viewport is changed, and pick an alignment for where you stage will 'stick' as the viewport grows:
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;
Once that is done, you have to listen to the stage's RESIZE event, so that when the player window/viewport is resized, you can check the new size and relayout your UI accordingly:
var resizeTimeout:uint;
stage.addEventListener(Event.RESIZE, onResize);
function onResize(e:Event=null):void
{
// Try setting a delay to workaround a weird bug when leaving fullscreen mode where the
// dimensions aren't updated properly, even though a resize event is triggered..?
if (resizeTimeout)
clearTimeout(resizeTimeout);
resizeTimeout = setTimeout(
function ()
{
trace("resizing: " + stage.stageWidth+"x"+stage.stageHeight);
// Re-layout from here
},
250);
}
As you can see I work around a bug here, which may not be neccesary in your case. Without the scaling mode turned off, the player will automatically resize your stage to fit the viewport, keeping your application oblivious to the changes. This can result in problems when the width/height ratio changes.
Anyway I hope I got most of this right, it's been a while since I had to deal with this, I just happened to have this bit of code lying around still from an old project.

GET request made after window.onload is very slow, blocks page scrolling - performance analysis

I have a widget that is inserted on numerous Web pages. It's composed of some JavaScript that loads an HTML document from my server (as JSONP) which is then inserted into a dynamically created <iframe> on the page where the widget is deployed.
I use Clicky for analytics/tracking to measure the number of pageviews that my widget's host page receives. Recently, I needed to go a bit further, to track the number of actual views of the widget itself. The purpose of this data is to more accurately interpret the performance of the widget at generating clickthroughs - that is, if a visitor doesn't scroll down the host page far enough to see my widget in the first place, there's no way that I could have inspired a clickthrough.
To achieve this tracking, I wrote a function that subscribes to the browser's "onscroll" event; basically, each time it's called, it compares the distance between the top of the host page document and the top of the widget, to the distance that the viewport is scrolled down from the top of the host page plus the height of the viewport and half the height of the widget. When the latter exceeds the former, the widget can be assumed to be halfway visible in the browser viewport.
When the function determines that this has happened (the widget needs to remain in the viewport for 2 seconds or more to count), it logs an "action" to Clicky, i.e., informs the analytics software that this has happened. This is done by calling a predefined function that loads an "image" from Clicky's server - basically a way to use a cross-domain GET request to communicate some tracking data.
The problem is that this request takes time - on average, a little over a second - to complete, and during that time, the browser window can't be scrolled. This is a showstopper for me. A slight delay - ideally well under a half second - is acceptable, but nothing approaching a second will work.
I've done my best to analyze the data that various performance tools generate (Firebug's Net Panel, Google Page Speed), but I'm at a loss to explain what is happening.
I would be extremely grateful to anyone who can provide some insight into what is happening, or even better yet, share a possible solution(s) to reduce or eliminate the blocked browser scrolling. The time to fulfill the request is unimportant to me, but the amount of time that the scrollbar is "stuck" is critical. For example, is there a way to make this request to Clicky without interrupting the browser's scrollbar functionality?
As a proof-of-concept of my code, I had created a prototype, viewable here:
http://troy.onespot.com/static/3128/prototype.html
When you scroll the page down until the middle of the gray box enters the viewport for 2 seconds or more, an indicator that a "widget view" has been logged will appear on the top-right of the screen.
(I've only tested this code to work in Firefox 3.0 or more recent versions - in fact, aside from possibly Safari, it's unlikely to work elsewhere, as it doesn't honor cross-browser differences in dimension properties.)
Also, here is a screenshot of Google's Page Speed tool's output during this logging:
http://img.skitch.com/20100121-t6bt1wauaar2drg1xdmwk9g4sb.png
To generate this, I scrolled/jiggled the page constantly as I eased the gray box into the viewport. The function fired by the "onscroll" event can be seen working repeatedly as a broken black line across the top of the output. As you can see, as soon as the Clicky logging happens (the large gap in the broken black line), approximately 1.2 seconds elapse where scrolling is not possible. I have no idea what is happening during the empty span in the latter half of that period, nor do I really understand why the entire period prevents scrolling.
Firebug's Net Panel shows a shorter period of elapsed time (though it still feels like a second or more, subjectively):
http://img.skitch.com/20100121-pwf1ifngffsnqm8qekmm8wp9mt.png
In this case, the vast majority of time (544ms) is spent in the "Blocking" stage, which makes no sense to me; my understanding was that this stage is only encountered when the request is in a queue because the maximum number of requests per hostname are already being made.
Any ideas, suggestions, or other insight would be very much appreciated. Thanks!

Set the timer to 1 and not 0 in the clicky_custom config object. There is a bug in their code that says that if the timer is 0 then wait 500ms.
I found this out using Firebug's profile and their init function was taking a the time. The code was something like timer = config.timer|500. config.timer will evaluate to false so 500 was returned.