Help Needed with Aero Peek Tab Previews
Bug 522262 is one of the more important blocking bugs for turning Aero Peek on for the next version of Firefox (with a slight chance of backporting to 3.6). I am having trouble determining the cause and reliably reproducing it on my machine. As some of you may know, I am a fulltime graduate student (school takes priority) and my Windows 7 laptop is suffering from intermittent (but frequent) screen corruption (it is becoming increasingly difficult to fix). For both of these reasons, I have not been able to work on the taskbar tab preview feature for the last 2.5 months. If you have experience debugging on Windows and would like to help out by determining the cause (or even a fix!), please feel free to do so! I would be very thankful for any assistance in tracking down the cause. And if there are other Aero Peek bugs that interest you (for example, this bug should be fairly easy to fix), by all means please take a stab at them.
5 comments5 Comments so far
Leave a reply
I hope this feature will remain optional. Because when there are more than 10-ish windows open, Aero’s thumbnail list reverts to a plain text list. Already I hit this limit sometimes, and if every single tab would be included, I would get to this limit in no-time.
i suggest you add “helpwanted” on bugzilla’s keywords field.
It will remain optional. There may even be a GUI option for it. Because Windows does revert to the plaint text list, I added a soft limit to the number of previews (default is 20) – once you have more than that, it will disable itself. There’s no way for a program to know when it will get the list view or not, hence the pref’d number.
Laurens Holst: you can tell windows how many thumbnails you want to see – http://preview.tinyurl.com/yal3fa2
Rob,
I have a theory I am working on.. after testing a change to the file the other day, I decided to keep playing, which I think not only fixes this (or at the very least forces a refresh) to fix most of the taskbar preview bugs.
I have been playing with the JSM file. I basically think we can prevent most of the bugs from occurring if every time we make a change, do a task or look at or close out of taskbar previews that we recount the number of tabs, and force a reordering and re-draw. Basically instead of one or two code paths, bolt it to all them. like going from 10FPS to say 30FPS. It would I think increase the CPU cycles overall, but I think for me it fixes have a dozen bugs. I have the JSM file. Let me know (you can email directly) I was thinking of opening a new bug to investigate that.
My theory stems from issues trying to create accurate reports and tools for people. An example would be that had to force an Access database to do more frequent refreshes than the standard database code paths, because my users were using the database in code path scenarios that didn’t force some sort of update/refresh/recalculate step. Then noticing issues because I didn’t add that type check into the system. It did slow down the database, but it was worth it.
So I had to push access to update the data as much as possible to eliminate the case of the data doesn’t look right.
I think the Wintaskbar JSM needs to do this as well. I can upload a test file that we can review what I’ve been trying. Though, I remember you have a bug open about invalidating more often, but I wasn’t sure if that is directly what I’m trying to do since what I think I’m doing is forcing more array updates after we do any task like close/add/drag/activate/select a preview/close down the panel, etc.
thanks,
cuz84d