I often know I need a mime-type ( e.g. .deploy or .xaml ).. Extensions are easy, but the types are hard to remember ( application/octet-stream is my favorite guess ).. 

Now, courtesy of  Chris Knowlton, Windows Media Server PM, I don't have to guess...

bear w/ some early (and wishful) thinking ...

I have a great RIA, with navigation inside of it (i.e. its own menus and scene transitions in the RIA).

My challenge is that I took advantage of the RIA's stateful model to optimize the experience; in other words, I avoided request-response; I do load new scenes, but of course it is all inside the RIA ...

The problem is that I often find myself clicking "Back" button... and there fore losing the state in the RIA... AAARGHHHH!!

What are the best practices for this type of app? I would love to see an app that handles this gracefully...   If you wrote one, please feel free to email me or leave a URL in the comments.. 

My best answer so far is save state often so I can come back to it.. but I have a lot of challenges (like trying to differentiate between new requests, desired reloads, etc. quite messy )

-- --------------- ----------------

In the mean time, here is a quick (not thoroughly fleshed) wish list for all browsers... 

1) Can browsers expose a "Confirm back/forward"  event for user to confirm this is what they wanted to do...

What I want is when my HTML page is loaded, and before it loads my plug-in, the browser gets told, please ask user to Confirm if they click (go back/ go forward)..

I am not saying 'ignore the users command, but allow the plug-in to let the browser know it is a RIA and ask user to Confirm when mixing navigation.. The browser can handle the confirmation, to prevent annoying session hi-jacking, which btw I see on plain standards-based sites, so I assume is doable regardless of a Confirm.  

Yes, I know some people will find it confirmation annoying, but I think it would be up to the application provider to decide..  The user or consumer is still in control - when I go to a website that annoys me, I just don't go back-.  Confirm is an 'opt-in' behavior.

2) While I am dreaming, could the browser allow "Trusted sites" to manipulate the history? Maybe an extra journal and Back button for within the RIA?  This way I can enter entries into the Journal and users follow their known paradigm ...  but with in the context of the app they are running.. {which I believe is what customers would want a large % of the time}

[ I am not saying replace Back button, I am saying offer more options; user still in control, we have this w/ active documents merging menus with their hosts ]

Thoughts??  I am sure lots a people will laugh and think I am naive about browser session hijacking, etc..  I am cool with that.. I leave it to smarter people ( e.g. IE team or w3c ) to figure how to nail the details; I still think the functionality is a nice to have and I am thinking the problem is solvable elegantly if the browsers or w3 define a standard approach..   

Does what I need exist already??  
I know smart client gets around this.. but I am trying to stay web (plus a small plug-in like Silverlight ) so bear with me...

Thanks & sorry for rambling or rant... it was in my head today and I did not seem to crack it..

Mole is a very handy visualizer for Visual Studio (.NET) developers.   I am late to try it, because it felt similar to snoop, but I installed Mole recently to see what the hype was about and now I find myself using it all the time..  It is incredibly convenient to have all this information available inside Visual Studio...

If you have not downloaded it yet, Karl Shifflett just released a sweeeettt v4. I highly recommend it..

---
A few extra Mole thoughts:

1. Congratulations to the whole Mole Team; it is pretty impressive what you have accomplished in such short time...  WOW!!
   
2. If you are a snoop user, don't miss out on mole.. They do look alike and overlap, but I found them quite complimentary...
   
   Mole is incredibly convenient since it integrates with VS; Mole also has nice features to ease navigation, finding and editing properties; mole can visualize also WCF, Windows Forms, ASPX, etc. so its scope is way broader than snoop's. 
   
   On the other side,  every now and then (but now much less) you will still need the 'injection' features of snoop (for me it is change notifications on DPs, and a little the convenience of navigating the visual tree by mousing over items) ...
   
   The good news is you can have both since they are both free..

Happy mole'ng...

I posted before on the "firefox unresponsive script warning" but enough people have asked off-line to warrant this attempt to explain the issue (since it is not what people expect, and can be tricky to track).

The explanation:
The warning is prompted by Mozilla's heuristics to check on long running scripts (details on these heuristics way below).  The problem is that for silverlight or any plug-in that makes Javascript calls, Firefox some times does not reset the timer for the scripts called from plug-ins: If you fire multiple events from a plug-in the events are obviously handled sequentially, if a new event happens while an event handler is executing, then Firefox does not reset its counter for the script time out; it measures the time from these two events as a single script. 

What does this mean (by example)? :

• If you run a script that is 11 seconds long, you will get the warning -- this one I understand and expect, this is what Firefox designed for; I do agree it is a good safety measure.
• If you run 500 event handlers that take 200 milliseconds(each) to run, but are fired continuously and each new event is fired before the previous event handler has completed, then Firefox looks at it as being one very long script and fires their warning...
• An explicit example:   If you are handling MouseMove in silverlight for an app that is pretty busy, you will likely run into this warning because Firefox will count most of your events as one long script...
• You can imagine combinations from there... ( for example: 20 scripts that take 0.5 second but are fired continuously, can trigger the warning).. it is this type of random combination that makes the "Warning: Unresponsive script.. " hard to track since most people look for long running scripts and that is not often the case..
  

How to get around it?
So far window.setTimeout  () seems to work best (though I can't say it works 100% of the time). Your mileage may vary, but here is what I do:

• For my long running event handlers ( > 2 seconds) , I just call window.setTimeout ( <longrunningCallback>, 0) -- this unfortunately means in some cases the events are slightly delayed as setTimeout will get queued (if there are events ahead this means I might handle them out of order). In most of my scenarios this has been acceptable for long running events; if it is not for you, you could write a pseudo dispatcher that queues all other events so things are always in order but of course you have higher overhead).
  
• For short, continuous event handlers (e.g. MouseMove) I don't do setTimeout for all events fired; that seemed like too much overhead..   What I do is:
• First make sure I narrow the scope of the MouseMove event as much as possible ( so no MouseMove on root element, but as low as I can on the pole).. this way less events get fired
• then keep a timer and do setTimeout every few seconds ( on a MouseMove, doing it every move can be 10s more times than doing it every two seconds)
  

Overall, setTimeout is not a perfect workaround, but best I come up with so far.

---

Does the explanation above make sense???  If not, here is a practical repro of the problem, it might make it easier for people to understand..

Requirements:

• To see the problem you must be running Firefox .. for this repro if you try IE you will see a different problem, since the heuristics for rogue scripts are very differing in IE.. (IE counts statements and my repro loops mindlessly, so creates too many instructions).
• Also, my repro below assumes you have the default timeouts in Firefox ( 10 seconds).. If yours is longer then tweak timeouts as needed.  See details below on how to find out if your timeouts were tweaked.

Steps to repro:

1. Open repro page in Firefox.
2. Click twice quickly on the button that says "run from HTML event" ..  This will run two seven seconds loops from HTML... Technically this is 14 secs of continuous scripts, but since each script is < 10 seconds, firefox works fine..
3. Click on "Clear status"  HTML button  [optional but helps keep repro readable] ..
4. Now click twice quickly (same than you did before) in the "run from Silverlight event" button in silverlight..   This event handler is the exact same than we used in Step2..  but you will see that half way through second handler, the "Unresponsive script" warning will get triggered.. Why?? because Firefox considered the two user clicks as one  :(
5. Now that you have seen the error, check the "use setTimeout workaround" that is on the "Repro via long script" table..
6. Repeat step 4. My hope is you don't see the error this time around..

To reproduce the problem using a short MouseMove handler ,

1. Open repro page in firefox
2. check the "Listen to MouseMove event"
3. Move the mouse inside the silverlight window continuously (and vigorously) for 13ish seconds..  You should see the warning... If not, continue moving mouse feverishly for long periods of time ..   [if you just can't repro it, try increasing the "handler duration" from 500 milliseconds to 1000]
4. Once you have seen the error in 3 ...  Check the "useSetTimeout on MouseMove" checkbox;
5. Repeat the moving of the mouse in Step 3.. My hope is that you don't see the error any more...

A few more details or references on Firefox and their timeout heuristics .

Firefox controls its time out based on the dom.max_script_run_time setting, which you can tweak via the about://config moniker; the default timeout in most recent versions is 10 seconds.

• The setting can not be controlled programmatically (so your script can't tweak it), nor per site ( meaning Firefox chooses to 'trust' your site)..  it is all or nothing, which seems a high ask to the visitors on most sites..
•  FYI, the issue has been reported to Mozilla and they seem to be on it, but of course given ship cycles, priorities, etc.. we might not see a change for a while.  { I do thank the Mozilla folks as they were quite responsive to confirm that I was not crazy when I was seeing the timeouts on short running scripts)