Last Comment Bug 701098 - Taskbar window registration call to NS_GetSpecialDirectory is using the wrong profile constant
: Taskbar window registration call to NS_GetSpecialDirectory is using the wrong...
Status: VERIFIED FIXED
[qa!]
: verified-aurora, verified-beta
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal (vote)
: mozilla11
Assigned To: Jim Mathies [:jimm]
:
Mentors:
Depends on:
Blocks: 577867
  Show dependency treegraph
 
Reported: 2011-11-09 11:05 PST by Jim Mathies [:jimm]
Modified: 2012-05-19 15:59 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified


Attachments
patch (1023 bytes, patch)
2011-11-09 11:22 PST, Jim Mathies [:jimm]
benjamin: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Jim Mathies [:jimm] 2011-11-09 11:05:29 PST
Code is here:

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/WinTaskbar.cpp#280

The result returned is:

"C:\Program Files (x86)\Nightly\defaults\profile"

This works fine with debug builds but release builds get this default profile directory. Not sure what's going on here but I'd like to get it fixed and landed on aurora before the next merge date.
Comment 1 Jim Mathies [:jimm] 2011-11-09 11:12:48 PST
So debug builds also point to the default, it's just that those directories happen to exist, so the call succeeds. Since we are calling this as late as we can (the creation of the first nsWindow object) we may not be able to fix this. If not, I'll switch this bug to backing out the code.
Comment 2 Jim Mathies [:jimm] 2011-11-09 11:16:21 PST
 I think the problem is the use of the wrong constant for the profile dir. Looks like NS_APP_PROFILE_DEFAULTS_50_DIR isn't the right match.
Comment 3 Jim Mathies [:jimm] 2011-11-09 11:22:40 PST
Created attachment 573260 [details] [diff] [review]
patch

bsmedberg, hoping you know if this is the right constant or not. Testing shows this yields the real profile directory, which was what I wanted the first time around.
Comment 5 Marco Bonardo [::mak] 2011-11-10 03:22:21 PST
https://hg.mozilla.org/mozilla-central/rev/d2558deedcca
Comment 6 Jim Mathies [:jimm] 2011-11-10 07:17:27 PST
Comment on attachment 573260 [details] [diff] [review]
patch

This is a touch-up fix for some code that is in the current Aurora build. Would really like to get it in since it makes a new hidden pref feature work. Risk level is super low.
Comment 8 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-28 14:15:18 PST
Is this something QA needs to verify?
Comment 9 Jim Mathies [:jimm] 2012-01-03 07:05:09 PST
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8)
> Is this something QA needs to verify?

You can confirm this by setting the taskbar.grouping.useprofile bool pref and verifying that the browser groups separately on the taskbar from the default install. Normally we group based on an id generated using the install path, with taskbar.grouping.useprofile set we group based on the profile path.
Comment 10 Ioana (away) 2012-01-05 06:44:35 PST
Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a2) Gecko/20120104 Firefox/11.0a2
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:12.0a1) Gecko/20120104 Firefox/12.0a1

STR:
1. Create multiple Firefox profiles.
2. Add the taskbar.grouping.useprofile bool pref to about:config and set it as "true" for at least one profile.
3. Launch multiple instances of Firefox using different profiles for each instance (multiple windows per profile too).

The windows from the profiles with taskbar.grouping.useprofile set are grouped separately on the taskbar. The windows from all the other profiles are grouped together on the taskbar.

Note You need to log in before you can comment on or make changes to this bug.