User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100526 Minefield/3.7a5pre ( .NET CLR 3.5.30729) Firefox/3.6.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100526 Minefield/3.7a5pre ( .NET CLR 3.5.30729) Firefox/3.6.5 I tried to test bug 534147 this with a recent hourly.. I removed all items from the Freq jumplist section but now I cannot get recent items or freq items to update. Reproducible: Always Steps to Reproduce: addToRecentDocs is already true, I turned off taskbar pref Freq list = false and turned on Recent List = true, restarted, went to PB mode, tried to download a file, saw the file on the DLM but not the Jumplist (at all). Exit PB mode, the file was not in the DLM, and Jumplist is still empty. Actual Results: I'm not sure add to Recent Docs or Recent Tasks work when I turn them on in about:config Or I don't know if its there but my Jumplist menu doesn't update (bug 522481) or if there is a recent item update bug, or once you delete all items from the list, the jumplist never creates the recent or freq section again. Expected Results: Recent/Freq list should exist and populate as expected when prefs set to true..

also note that installing another hourly, deleting pinned icons, restarting the browser or updating the taskbar prefs to enable the list or modify the list size didn't change the jumplist.

I wonder if this also triggered the issue I noticed in bug 519985 comment 14 where I did see the tasklist switch after I entered PB mode on the jumplist menu, but now it doesn't switch the tasklist either. Its like the whole jumplist menu is borked from being recreated and refreshed.

For testing purposes, we should ignore privacy mode changes and just concentrate on the lists. So with Frequent enabled, you delete everything in the list, the list will never come back? Also - note! deleting an item will delete it from your history, so use a test profile or whatever if you don't want to mess up your normal session.

(In reply to comment #4) > For testing purposes, we should ignore privacy mode changes and just > concentrate on the lists. > Ok.. but I did find it, its all related I think. > So with Frequent enabled, you delete everything in the list, the list will > never come back? > Yep, in a nut shell that kills it for all profiles. I believe and the only way to get it working again is to create another new profile, which fixes all profiles. Read on for more detail. Sounds like a registry thing.. ?? Testing: Freq list deletion only.. I created a new profile (using the current hourly). Had not tried what a new profile does prior till now, I tested last night's build and it didn't fix it. I created a new profile with the profilemanager and the jumplist menu and PB tasks, everything worked with the new profile. Then I went back into my original profile, the jumplist menu and tasks, everything was there too, just a different freq list. I then killed the freq file list again in my original profile to see if I could reproduce and confirmed it did. It also messed with task PB again. I then opened the newly created profile and that jumplist menu didn't work either nor its PB task.

(In reply to comment #4) > For testing purposes, we should ignore privacy mode changes and just > concentrate on the lists. > > So with Frequent enabled, you delete everything in the list, the list will > never come back? > Deleting all items off the list will bork the entire jumplist and tasks from being displayed/created or refreshed properly. Only creating a new profile will fix the jumplists for all profiles already setup. This is reproduceable even with a new profile, so its not a one time issue, but more of deeper issue which persists across builds and profiles.

(In reply to comment #6) > Deleting all items off the list will bork the entire jumplist and tasks from > being displayed/created or refreshed properly. on reuse of the same profile (issue #1) > Only creating a new profile will fix the jumplists for all profiles already setup. ...that only appears to be true, but its different then that.. so further testing revealed some interesting finds here: So again I deleted everything from the list, created a new profile, using that new profile the jumplist is broken, close that profile, reopen it, the jumplist menu should work. (issue #2) To double check now if you delete the list again under that same given profile (or any profile rather), the jumplist stays broken on subsequent uses of that same profile. (issue #1) But if you then switch profiles, then switch back, the profile jumplist is then populated and works. (issue #3) or the main reason I can see the jumplist being fixed. I guess I don't know if that means its related to places causing issues or its just not refreshing when it should.

(In reply to comment #4) > For testing purposes, we should ignore privacy mode changes and just > concentrate on the lists. > So even simplifying the STR, removing one item (using remove from list) also causes the jumplist PB task to be borked.

changes: - ioserive.newURI was missing two params I thought were defaults. This was causing the history update to fail, which caused the build list to fail since we were adding back deleted items. - don't fail on the build when one list fails, which keeps the privacy option up to date regardless.

So the _build* methods don't really need return values anymore, do they?

nope!

Comment on attachment 448089 [details] [diff] [review] patch v.2 I'd probably write 'if (items.length > 0)' and omit the return _buildTasks and _buildCustom.

(In reply to comment #12) > (From update of attachment 448089 [details] [diff] [review]) > I'd probably write 'if (items.length > 0)' and omit the return _buildTasks and > _buildCustom. s/omit the return _buildTasks and _buildCustom/omit the 'return' in _buildTasks and _buildCustom/

The seems like something to nominate for 1.9.2.5+ since some of the other win7 cleanup got approval.

(In reply to comment #14) > The seems like something to nominate for 1.9.2.5+ since some of the other win7 > cleanup got approval. Jump list integration in the browser never landed on 3.6.

(In reply to comment #16) > (In reply to comment #14) > > The seems like something to nominate for 1.9.2.5+ since some of the other win7 > > cleanup got approval. > > Jump list integration in the browser never landed on 3.6. Oh right. Thanks for fixing this.