Closed Bug 701098 Opened 8 years ago Closed 8 years ago

Taskbar window registration call to NS_GetSpecialDirectory is using the wrong profile constant

Categories

(Core :: Widget: Win32, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla11
Tracking Status
firefox10 --- verified

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Keywords: verified-aurora, verified-beta, Whiteboard: [qa!])

Attachments

(1 file)

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.
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.
Summary: Taskbar window registration call to NS_GetSpecialDirectory(NS_APP_PROFILE_DEFAULTS_50_DIR) returns invalid path in release builds → Taskbar window registration call to NS_GetSpecialDirectory(NS_APP_PROFILE_DEFAULTS_50_DIR) are made too early
 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.
Summary: Taskbar window registration call to NS_GetSpecialDirectory(NS_APP_PROFILE_DEFAULTS_50_DIR) are made too early → Taskbar window registration call to NS_GetSpecialDirectory is using the wrong profile constant
Attached patch patchSplinter Review
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.
Attachment #573260 - Flags: review?(benjamin)
Attachment #573260 - Flags: review?(benjamin) → review+
https://hg.mozilla.org/mozilla-central/rev/d2558deedcca
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
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.
Attachment #573260 - Flags: approval-mozilla-aurora?
Attachment #573260 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Is this something QA needs to verify?
Whiteboard: [qa?]
(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.
Whiteboard: [qa?] → [qa+]
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.
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
No longer blocks: 577867
You need to log in before you can comment on or make changes to this bug.