[Ext]Session Manager 0.7.6.1 - Aug 3, 2011

[Morac]

Open the Session Manager options, go to the logging tab and check the enable logging box.

[WildcatRay]

In a way, if it weren't for"bad" luck, you'd have "no" luck at all, Morac. Minefield/Trunk just got bumped up to 4.0b3pre. Session Mgr. 0.6.8.1 is "officially" compatible up to 4.0b2pre.

Not to worry, though. Most of us know what to do for situations like this.

[Morac]

That's actually easily fixable without requiring an update, but only if you downloaded the non-development version of 0.6.8(.1). In fact I just fixed it. I'll need to figure out what to do with users who downloaded my beta version since I don't want to update the version number just for that.

Edit: And my solution is to simply put out a special 0.6.8.1.1 version only for development version users. It's the same as 0.6.8.1 for everyone else.

[Morac]

Version 0.6.8.1 is being held up by a reviewer on a technicality. The reviewer objects to the following code because it modifies a native object:

Code: Select all

// String.trim is not defined in Firefox 3.0, so define it here if it isn't already defined.
if (typeof(String.trim) != "function") {
   String.prototype.trim = function() {
      return this.replace(/^\s+|\s+$/g, "");
   };
}

The code only executes in Firefox 3.0 where the String.trim function doesn't exist. For all other browsers it does absolutely nothing. The only reason it's there is to allow the Session Manager code to use the String.trim function directly in Firefox 3.0 without having to jump through the annoying hoop of defining a function which then calls String.trim in Firefox 3.5 and above and the above code in Firefox 3.0.

I responded to the review explaining as such plus the fact that the same code exists in 0.6.8 which was approved a few days ago. If it's rejected again I can either make changes to my code to not use the String.trim function (annoying) or pull support for Firefox 3.0 (might be a good idea anyway).

In the mean time I added something to 0.6.8.1 which I forgot to add originally, namely the overwrite prompt fix when using the allowNamedReplace hidden preference. That's also why the development version updated to 0.6.8.1.2.

[Philip Chee]

Version 0.6.8.1 is being held up by a reviewer on a technicality. The reviewer objects to the following code because it modifies a native object:

Code: Select all

// String.trim is not defined in Firefox 3.0, so define it here if it isn't already defined.
if (typeof(String.trim) != "function") {
   String.prototype.trim = function() {
      return this.replace(/^\s+|\s+$/g, "");
   };
}

This is bad if you are doing it in the global scope since it has the potential to mess up both Firefox chrome javascript as well as extensions that overlay browser.xul. In the proposed Javascript 2.0 standard this may not be such a problem since added properties can be made non enumerable (this may even work in Gecko 2.0). However this won't help you with Firefox 3.0. If the scope is your own session manager window and all the code in that window is under your control then extending the prototype should be allowable. If the latter is the case, you could email amo-editors@ to point this out, or ping jorgev in irc://moznet/addons

Phil (not an amo-editor)

[Morac]

The reviewer also said that it could mess up other add-ons and the browser itself, but I don't really see that happening. Like I said the code only does the assign if there is no existing trim function assigned to String and that's only true in Firefox 3.0. And as there's no trim function for Strings in Firefox 3.0, neither the browser nor other add-ons would ever be using it in FF 3.0. Basically Firefox 3.0 never uses the String.trim function because it doesn't exist and any add-on using the String.trim function in FF 3.0 would throw an exception (without my add-on present). About the only bad thing I could see happening is if a developer had Session Manager installed when coding in Firefox 3.0 and mistakenly believed that the String.trim function existed in FF 3.0, which is highly unlikely at this point.

While it's mainly used in a Session Manager window, unfortunately it is part of a module that's pulled in under browser.xul. If I take that code out, that leaves me with two choices: either don't use the built in trim function for strings since it won't work in Firefox 3.0 or drop support for Firefox 3.0. The former makes the code more complicated than it needs to be. The latter is doable, but it seems stupid to do so only for this reason when everything else works. Though I really doubt anyone still runs FF 3.0.


On a side note, apparently Firefox 4.0 completely rewrote the common dialog interface code switching the window parameters from nsIDialogParamBlock to nsIWritablePropertyBag. This had the side effect of breaking the Session Manager shutdown prompt. This happened fairly recently because it used to work when I tested it a few weeks ago. As a result, you can't have Session Manager prompt you at shutdown in FF 4.0 until I code a work around.

[Morac]

I just realized something. The code I posted above is inside a JavaScript module and while that module is imported into something that overlays the browser window, that trim function is not exported so it doesn't leak into the global scope. I confirmed this by trying to use the Strim.trim() function in another add-on that overlays browser.xul in Firefox 3.0 and it threw an exception stating trim is not a function.

So all instances of the native object modification are being done in a private scope. So I'm not sure why it was rejected. I'm actually working on 0.6.8.2 to fix the prompt issues, but since Session Manager doesn't currently work at all for Russian locale users I'd like to push out 0.6.8.1 ASAP in the mean time. I sent an email, but didn't get a response so I'll try IRC.

[Morac]

I pushed out a fix for the shutdown prompt not working in the Firefox 4.0 betas/nightlies. Those who downloaded my beta version can get it now. Those using the version from addons.mozilla.org will need to wait for it to be approved in order to upgrade automatically (or you can manually grab it yourself).

[WildcatRay]

Thanks, Morac.

BTW-If you can, I'd like to hear what, if anything, comes about regarding the trim function you talk about above.

[Morac]

Thanks, Morac.

BTW-If you can, I'd like to hear what, if anything, comes about regarding the trim function you talk about above.

We'll see. I mentioned in the reviewer notes that it wasn't doing the redefine in the global scope. It seems most reviewers ignore it since 0.6.8.1 was the first time I've had any issues with it, though there is a newer automatic validater when uploading add-ons that checks for "bad things". Most of those turn out to be false alarms though..

[mhowie]

I pushed out a fix for the shutdown prompt not working in the Firefox 4.0 betas/nightlies. Those who downloaded my beta version can get it now. Those using the version from addons.mozilla.org will need to wait for it to be approved in order to upgrade automatically (or you can manually grab it yourself).

Thanks. Seems to now work as designed with FF 4.0 beta.

[Morac]

I'll mention I ended up pushing out a 0.6.8.2.1 version to development users since I found an issue with SeaMonkey after uploading 0.6.8.2. SeaMonkey doesn't appear to pre-define the Cc constant in the browser scope like Firefox does so the three lines in sessionmanager.js were throwing "undefined" exceptions. Since 0.6.8.2 hadn't been accepted yet, I just updated it on the Addons site.

Speaking of SeaMonkey, I found an abnormality with the SeaMonkey trunk loads with respect to the way the shutdown prompt shows. Session Manager is coded such that the shutdown prompt shows up on the quit-application-requested notification if "treat closing last open browser window as shutting down" option is not checked. If it is checked then the prompt will display on either the quit-application-requested or browser-lastwindow-close-requested notifications. The idea here is to show the prompt when Firefox is actually shutting down or if the "treat as..." option is checked to show it when all browser windows are closed (but other windows might be open).

Firefox won't send the browser-lastwindow-close-requested notification, if the last window closed is the last browser window. SeaMonkey always sends it unless SeaMonkey is quit from the File->Exit menu command. Also SeaMonkey issues the "onclose" event notifications to the window before the "quit-application-requested" notifications goes out. This discrepancy causes the nice "Save & Quit", "Save", "Save & Restore", "Cancel" session prompt not to show up in SeaMonkey if the last browser is simply closed with no other open windows. Instead a generic "Save" or "Don't Save" prompt shows up.

I could work around this in my code (to an extent), but since Firefox and SeaMonkey are behaving differently and Firefox was the first to use these notifications, I filed a bug with SeaMonkey.

[Morac]

And the hits just keep on coming. Shortly after pushing out 0.6.8.2 someone reported a problem which I fixed so here we are at 0.6.8.3.

This mainly fixes an issue with loading sessions with the "Reload All Windows" option checked. The problem is that the new method to reload windows is so fast that it didn't give the browser time to restore the tab history index. As such if you loaded a tab with a forward history there was a good chance that the last (most forward) page would load instead of the one that was displaying when saved. I had to put a slight delay before reloading in for tabs with a forward history to compensate for this. It might be noticeable depending on how long it takes for the browser to get into the "right state" to do a reload.

[makondo]

Thanks for the update, Morac!

EDIT: Morac, just want to take a minute to say how much i appreciate you implementing selective tab saving. I use often and thank you every time, the best!

[FireLove]

Morac! OMG! 0.6.8x is a great update! At last I hope my woes are alleviated for good (I endured them in silence up to this day, no kidding ) - browsing sessions is fast and seamless once again!

Yet, on the other count, let me humbly suggest that you slightly overdid UI/UX:
IIRC "backlash" was about inability to subsequently perform different kind of operations without dismissing window first (like "deletions" + "renaming", etc)
Now, frontloading UI to do that - kinda overreacting.
(Though I know I'll grow to appreciate such option when right situation finally comes around ... next year )

At least placing focus on operations type selector is not good
It's when user already chose desired operation - say "load" - focus should be placed with "session selection" pane (when only "arrows" and/or "Enter" might be required to get at desired results), not "operation selector".

I'd imagine that addressing a "problem of not having UI for doing different operations" could be solved with such UI being "introduced" into user's experience when he explicitly chooses to execute an operation/s dufferent from what he initially chose to do/from which he arrived in a window in a first place.

The other (halfway/temporary?) might be to outright "castrate" most popular single use operations (load?) from having any choice and any such UI in a face of user
(which also stealing precious screen estate as well )