browser shell use of NS_XPCOM_CURRENT_PROCESS_DIR breaks with bug 755724

RESOLVED FIXED in Firefox 20

Status

()

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jimm, Assigned: glandium)

Tracking

Trunk
Firefox 20
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [metro-preview] [completed-elm])

Attachments

(2 attachments)

(Reporter)

Updated

6 years ago
No longer blocks: 789461
Depends on: 789461
Summary: browser shell use of NS_XPCOM_CURRENT_PROCESS_DIR breaks with bug 755724 → browser shell use of NS_XPCOM_CURRENT_PROCESS_DIR breaks with bug 755724, should use ExecutableD
Whiteboard: metro-preview
Summary: browser shell use of NS_XPCOM_CURRENT_PROCESS_DIR breaks with bug 755724, should use ExecutableD → browser shell use of NS_XPCOM_CURRENT_PROCESS_DIR breaks with bug 755724
Created attachment 665007 [details] [diff] [review]
Patch v1.

This is a review for m-c even know the patch will need to be rebased slightly to land on m-c. 

After review, it will land at the same time on m-c as the new dir service provider string define (soon).
Assignee: nobody → netzen
Attachment #665007 - Flags: review?(jmathies)
Whiteboard: metro-preview → metro-preview completed-elm
(Reporter)

Comment 3

6 years ago
Comment on attachment 665007 [details] [diff] [review]
Patch v1.

approving this simple change assuming the final string id has been solidified in another bug.
Attachment #665007 - Flags: review?(jmathies) → review+
(Reporter)

Comment 4

6 years ago
(In reply to Jim Mathies [:jimm] from comment #3)
> Comment on attachment 665007 [details] [diff] [review]
> Patch v1.
> 
> approving this simple change assuming the final string id has been
> solidified in another bug.

It appears I approved the wrong patch, this comment had something to do with stub installer I think. Regardless this patch looks ok.
wrong bug?
(Reporter)

Comment 6

6 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #5)
> wrong bug?

Actually now that I look at it my original review comment makes sense. :) I'm trying to track of too many bugs in my head today.
Whiteboard: metro-preview completed-elm → [metro-preview] [completed-elm] [Ready to land after bug 789461 is done]
(Reporter)

Updated

6 years ago
No longer blocks: 755724
(Assignee)

Comment 7

6 years ago
Created attachment 691785 [details] [diff] [review]
Use XRE_EXECUTABLE_FILE in browser shell instead of guesswork from NS_XPCOM_CURRENT_PROCESS_DIR and MOZ_APP_NAME
Attachment #691785 - Flags: review?(felipc)
(Assignee)

Updated

6 years ago
Assignee: netzen → mh+mozilla
(Assignee)

Updated

6 years ago
Attachment #691785 - Flags: review?(felipc) → review?(jmathies)
(Reporter)

Updated

6 years ago
Attachment #691785 - Flags: review?(jmathies) → review+
(Assignee)

Comment 8

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9f1337be665
No longer depends on: 789461
Whiteboard: [metro-preview] [completed-elm] [Ready to land after bug 789461 is done] → [metro-preview] [completed-elm]
(Assignee)

Updated

6 years ago
Duplicate of this bug: 820205
https://hg.mozilla.org/mozilla-central/rev/a9f1337be665
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Comment on attachment 691785 [details] [diff] [review]
Use XRE_EXECUTABLE_FILE in browser shell instead of guesswork from NS_XPCOM_CURRENT_PROCESS_DIR and MOZ_APP_NAME

>   nsCOMPtr<nsIFile> appHelper;
>-  rv = directoryService->Get(NS_XPCOM_CURRENT_PROCESS_DIR,
>+  rv = directoryService->Get(XRE_EXECUTABLE_FILE,
>                              NS_GET_IID(nsIFile),
>                              getter_AddRefs(appHelper));
>   NS_ENSURE_SUCCESS(rv, rv);
> 
>-  rv = appHelper->AppendNative(NS_LITERAL_CSTRING("uninstall"));
>+  rv = appHelper->SetNativeLeafName(NS_LITERAL_CSTRING("uninstall"));
>   NS_ENSURE_SUCCESS(rv, rv);
Not quite sure what the point of this change was, because you weren't guessing the name of the executable here?
You need to log in before you can comment on or make changes to this bug.