693920 - Taskbar Icons are Reordered when opening from Session Restore when FlashGot is installed

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[therube]

Attachment: sessionstore.json.FLASHGOT, rename to sesionstore.json

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111006 Firefox/8.0 SeaMonkey/2.5
Build ID: 20111006105555

Steps to reproduce:

 
create new profile
start SeaMonkey
open two tabs in one window
Quit, saving the session
[such that Session Restore gets enabled on restart]
 
 
(manually) replace existing sessionrestore.json with [attached] sessionstore.json.FLASHGOT (naming as sessionrestore.json)
 
 
start SeaMonkey
install FlashGot [ http://flashgot.net/getit or AMO ]
install NoScript [ http://noscript.net/getit or AMO ]
[note the order of the windows, as I call them; ONE, TWO, poltergeist, FOUR]
 
Quit (or Restart), saving the session
 


Actual results:

 
on restart, the windows are restored, but their ordering on the (Windows) taskbar is reordered after each Quit/Save Session/Restart cycle.
[note the order of the windows has changed; ONE, TWO, *FOUR*, poltergeist]
 


Expected results:

 
the windows should have been restored in the same relative location [ONE, TWO, poltergeist, FOUR] as they were when you Quit & saved the Session.
 
 
each time you repeat the Quit/restart cycle, windows "poltergeist" & FOUR flip positions.

FlashGot appears (?) to be material in causing this?
but not just FlashGot alone.  it must be FlashGot & at least one other extension, but not every pairing causes it.  the pair of FlashGot & NoScript happens to cause it.
[other pairings with FlashGot do not, such as;  inspector, debugQA, venkman, FetchTextURL]
 
 
note that FlashGot contains a binary component, FlashGot.exe, should that matter?
 
 
FF7 is not affected by this.
you can test FF the same way, only when you install my sessionstore.json.FLASHGOT, you need to name it; sesssionstore.js (rather then .json).
 
 
i don't know what determines in what order windows are reopened from Session Restore but in sessionstore.json but the physical position of "FOUR" changes within the file during these cycles.
[the "ID": & "docIdentifier": _tags_ also change, docID by 1 I believe, but I'll assume that is normal?]

Comment 1

[therube]

> [other pairings with FlashGot do not, such as;  ... venkman ...]

I was wrong about that part.

A pairing of FlashGot & venkman (JavaScript Debugger) will cause this to happen too. (FlashGot & Chatzilla does not.)

Enabling/disabling extensions in Add-ons Mananger (about:addons) is sufficient when trying pairings, or otherwise experimenting with this.

Comment 2

[therube]

I call this, "the magic of three", because the last (relative position) window ends up being the third when you restart from Session Restore.

This is not a new occurrence.
Affects SeaMonkey 2.0.14 to SeaMonkey 2.7 (Trunk).

On its own, a flip flip of windows 3 & 4 is not such a big deal.

But when you have many more windows then 3 or 4 & when the last window is continually being stuck into the 3rd position, it does not always end up being a flip flop situation, as intervening windows end up in 3rd, generally playing havoc with the relative positions of most every window.

Interesting, a pairing of FlashGot + Chatzilla does cause this to happen on SeaMonkey >2.5 (so Aurora & Trunk) where it did not occur that way on SeaMonkey 2.5.

Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20110928 Firefox/10.0a1 SeaMonkey/2.7a1

Comment 3

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111012 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111012003002

Not sure if the following (on Linux) is the same problem or something else:

I have configured SeaMonkey to open ChatZilla, Browser and MailNews at startup. The ChatZilla window always opens first but the order of the other two seems more or less random. Icons appear on my taskbar in the order the windows were opened.

Not a big deal to me, which is why I didn't report it. Mozilla problem? OS problem? Race condition? …

Comment 4

[therube]

This is not a race condition or anything like that.
Definite cause & effect.
Definitely repeatable (I can only check Windows, XP & W7).
Now I don't know that FlashGot (alone) is the cause, but it happens to cause the effect ;-).

Comment 5

[therube]

WFM.

Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111119 Firefox/10.0a2 SeaMonkey/2.7a2

Suppose it's due to some recent fixes that Misak has been porting over?
Also suppose it will remain an issue in 2.5 release, & could still be an issue in 2.6?

I'll try looking for a range at a later time.

Comment 6

[therube]

Comment 5 is INCORRECT.

This /is/ still a valid bug.

(Thinking either it did work as expected for a very short period of time & something caused it to break again, or FlashGot was [inadvertently] disabled, like becoming invalid during a browser upgrade vs. version number check, invalidating one of the requirements for the STR.)

Comment 7

[therube]

THANK YOU, THANK YOU, THANK YOU.

Looks to have resolved itself.

WORKS :-) :
Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20121220 Firefox/19.0 SeaMonkey/2.16a2
Build identifier: 20121220013005
http://hg.mozilla.org/releases/mozilla-aurora/rev/0887d48568fc

BROKEN:
Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20121219 Firefox/19.0 SeaMonkey/2.16a2
Build identifier: 20121219013006
http://hg.mozilla.org/releases/mozilla-aurora/rev/4739a79d8ab5
 
 
Are these correct?
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?startdate=2012-12-19&enddate=2012-12-21
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=4739a79d8ab5&tochange=0887d48568fc
(Nothing that /I/ see looks to be of note?)

Comment 8

[therube]

Long ago, there were still odd times that "something odd" happened.
Things didn't open quite right (in the expected order).

More recently, can't say I've noticed any problems, so marking WFM.