Closed Bug 456895 Opened 17 years ago Closed 16 years ago

Error: Uncaught Exception [@ nsIShellService.isDefaultBrowser][@ delayedStartup] (GetShortPathNameW fails due to permissions)

Categories

(Firefox :: Shell Integration, defect, P2)

Product:
Firefox
Component:
Shell Integration
Version:
3.0 Branch
Platform:
All
Windows Vista
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.6a1

People

(Reporter: whimboo, Assigned: robert.strong.bugs)

References

(
URL
)

Details

(Keywords: verified1.9.1)

Attachments

(2 files, 4 obsolete files)

programs.acl
144 bytes, application/octet-stream
Details
patch rev5
5.95 KB, patch
mconnor
: review+
beltzner
: approval1.9.1+
Details | Diff | Splinter Review
This bug was created based on bug 453304 comment 17: Starting Firefox with MOZ_NO_REMOTE and SessionStore enabled, following exception is shown in the Error Console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIShellService.isDefaultBrowser]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/browser.js :: delayedStartup :: line 874" data: no] http://hg.mozilla.org/mozilla-central/annotate/920a4326d108/browser/components/shell/src/nsWindowsShellService.cpp#l249 http://hg.mozilla.org/mozilla-central/annotate/969757f7a831/browser/base/content/browser.js#l1029 Steps: 1. Start Firefox and enable SessionStore 2. Close Firefox 3. Start Firefox again with MOZ_NO_REMOTE set I've no idea whats the correct component for this bug. Because it happens for the default browser check I've chosen to take OS integration.
Possibly due to bug 390060
(In reply to comment #1) That patch didn't touch nsIShellService at all and therefore can't possibly cause NS_ERROR_FAILURE inside isDefaultBrowser.
Henrik, are you using a zip build?
btw: with session restore enabled and either specifying -no-remote on the command line or setting the MOZ_NO_REMOTE env var to 1 I wasn't able to reproduce this.
No longer blocks: 453304
(In reply to comment #3) > Henrik, are you using a zip build? Whatever way (installer or zip) I've used to make Firefox available the problem occurs. Probably I have to mention that I use nightly builds and not the official releases. No idea if this could be a reason why you cannot reproduce it? Or have you also used nightly builds for the tests? Can be reproduced for Gran Paradiso and Minefield.
There are several ways how nsIShellService::IsDefaultBrowser could fail, e.g. if ::GetModuleFileName or ::GetShortPathName fail or if we can't get a nsILocalFile for the Firefox executable. Any way we can easily determine which of this it is? Then again, I don't see any of these depend on MOZ_NO_REMOTE...
URL: http://mxr.mozilla.org/mozilla-centra...
Whiteboard: [vista specific?]
I'm using the latest nightly. I think it best to get another QA person preferably with one of the QA machines in building S to try to reproduce this... perhaps at the same time do the same for bug 451779.
Keywords: qawanted
Martijn, are you using Vista?
Target Milestone: --- → Firefox 3.1b1
While testing the patch on bug 451300 I also noticed that Ctrl-Tab stopped working when Firefox is started with MOZ_NO_REMOTE set. Shall I file a new bug or depend both bugs on the same root problem which can be fixed here?
This bug makes it hard for QA to run nightly builds in parallel. Blocking Firefox 3.1?
Flags: blocking-firefox3.1?
Probably Tony sees the same thing on his OS X machine. We should do some QA if its the same underlaying issue.
Keywords: regression, regressionwindow-wanted
How exactly are you running Firefox? The fact that it only happens with no-remote makes me think that it must be somehow related to the way Firefox is invoked.
Gavin, I always use the following batch script to start Minefield in parallel while Firefox 3.0.4pre is running: SET MOZ_NO_REMOTE=1 firefox3.1\firefox.exe -p
Does it work if you call it directly from cmd.exe? What about with -no-remote instead of MOZ_NO_REMOTE? Are your UAC settings weird?
I believe I used -p when trying to reproduce but I may have used -profilemanager which is actually the correct command line switch to use unless you are specifying a profile to use. Henrik, can you also try reproducing it with -profilemanager? btw: I tried with both the command line -no-remote as well as the env var MOZ_NO_REMOTE.
I got some more information lately. I did several tests and noticed that it works in some way. Finally I've found the reason for. This bug only occurs if you run Firefox from within "C:\Program Files\". Means a start script which looks like the following: SET MOZ_NO_REMOTE=1 "C:\Programme\Mozilla Firefox 3.1\firefox.exe" -p I run the script with my own privs first and with admin privs later. In both situations it fails. Moving the application to another folder where I've full access it works. I haven't changed any folder specific ACL settings so it's just default and hopefully someone can reproduce it now.
Output from icalcs command line application of the installation folder. Sorry for the German output but I don't know I can force an English one (if even possible). C:\Program Files>icacls "Mozilla Firefox 3.1" Mozilla Firefox 3.1 VORDEFINIERT\Benutzer:(OI)(CI)(RX,W) NT SERVICE\TrustedInstaller:(I)(F) NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F) NT-AUTORITÄT\SYSTEM:(I)(F) NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(IO)(F) VORDEFINIERT\Administratoren:(I)(F) VORDEFINIERT\Administratoren:(I)(OI)(CI)(IO)(F) VORDEFINIERT\Benutzer:(I)(RX) VORDEFINIERT\Benutzer:(I)(OI)(CI)(IO)(GR,GE) ERSTELLER-BESITZER:(I)(OI)(CI)(IO)(F)
Hmmm... the following doesn't show up when running icacls on my system with no permission changes. VORDEFINIERT\Benutzer:(OI)(CI)(RX,W)
Yes! I've found the underlying problem. And it's understandable why you aren't able to see it Robert. This issue only happens on localized versions of Vista! So lets explain: In former Windows versions the application folder is called "Programme". This has been changed a bit with Vista. Now it's a link which points to "Program Files". Normally there shouldn't be a difference in starting an application with one of the following commands: "C:\Programme\Mozilla Firefox 3.1\firefox.exe" -p "C:\Program Files\Mozilla Firefox 3.1\firefox.exe" -p But at least using the former one with a fresh profile results in the mentioned exception. Later starts do not show up this anymore if you run the profile with the latter command in between. So there is something wrong while initializing the profile. And it seems we are doing this repeatedly on each start of Firefox. Here the icacls output for both entries: Program Files NT SERVICE\TrustedInstaller:(F) NT SERVICE\TrustedInstaller:(CI)(IO)(F) NT-AUTORITÄT\SYSTEM:(M) NT-AUTORITÄT\SYSTEM:(OI)(CI)(IO)(F) VORDEFINIERT\Administratoren:(M) VORDEFINIERT\Administratoren:(OI)(CI)(IO)(F) VORDEFINIERT\Benutzer:(RX) VORDEFINIERT\Benutzer:(OI)(CI)(IO)(GR,GE) ERSTELLER-BESITZER:(OI)(CI)(IO)(F) Programme Jeder:(DENY)(S,RD) Jeder:(RX) NT-AUTORITÄT\SYSTEM:(F) VORDEFINIERT\Administratoren:(F)
I can reproduce this issue on my Vista box at home by doing following steps: 1. Use the Firefox 3.1 beta 1 installer and install it to the default location 2. Do not run Firefox from within the installer 3. Startup profile manager and create a fresh profile (don't start) 4. Exit the profile manager 5. Start Firefox by using: "C:\Programme\Mozilla Firefox 3.1 Beta 1\firefox.exe" -no-remote" With these steps I'm able to reproduce this failure. Probably it will happen for all localized versions of Firefox.
Target Milestone: Firefox 3.1b1 → ---
Not a blocker as -no-remote isn't a user facing feature. Feels like it should be fixed, though.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Henrik, can you please provide the target for a shortcut created by the installer?
I don't have a system to test this on atm with the folder shortcut to Program Files. Since C:\Documents and Settings has the following permissions I tried reproducing with it C:\Documents and Settings Everyone:(DENY)(S,RD) Everyone:(RX) NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) but was unable to
For what it is worth I have been able to find some unusual behavior when running the app as I described in comment #25 though I haven't been able to reproduce the exact same error as comment #0, etc.
Rob, I tried to save the permissions via "icacls /save" which also worked but I'm not able to overwrite the permissions of another file with the stored values. You can try it on your own. I'll attach the exported file. Just do the following steps: mklink /J Programme "Program Files" icacls c:\ /restore programs.acl /L /C Perhaps you have to manually remove all permissions before step 2. (In reply to comment #24) > Henrik, can you please provide the target for a shortcut created by the > installer? Our installer doesn't create this softlink. It's already done during the installation of Vista. For localized versions of Vista this folder is more common. "Programme" points directly to "Program Files".
Attached file programs.acl —
(In reply to comment #27) >... > (In reply to comment #24) > > Henrik, can you please provide the target for a shortcut created by the > > installer? > > Our installer doesn't create this softlink. It's already done during the > installation of Vista. For localized versions of Vista this folder is more > common. "Programme" points directly to "Program Files". I am asking about the shortcuts for the app as in whether they have been created successfully and not the link from Programme to Program Files.
Attached patch patch rev1 (obsolete) — — Splinter Review
It appears that GetShortPathNameW is failing when working with files that use a path that uses a symbolic link AND has the permissions as cited in this bug. I was planning on removing the checks for short paths when checking if the app is default sometime after Firefox 3.0 and removing it now is fine. I'm going to verify this in fact fixes it.
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Removing keywords since with the current findings they are no longer applicable
Keywords: qawanted, regression, regressionwindow-wanted
As for it being Vista specific this could likely happen on W2K and above using symbolic links... it is just more likely with Vista since Vista itself makes extensive use of symbolic links.
Whiteboard: [vista specific?]
Attachment #359694 - Attachment description: patch - untested → patch rev1
Attachment #359694 - Flags: review?(mconnor)
Comment on attachment 359694 [details] [diff] [review] patch rev1 Hey Mike, this mainly removes code to support short paths when checking if Firefox is the default browser. This was added so people upgrading to 3.0 wouldn't be asked to set Firefox on first run and now that 3.0 has been out for a while I would like to remove this for 3.1 to fix this bug. I also fixed a bug with OpenApplication in that it was checking the wrong registry hives
Filed bug Bug 476107 for Thunderbird and Bug 476108 for SeaMonkey. Sunbird doesn't have Shell Integration code as of yet.
Filed bug 476106 for a similar bug with the installer when setting an app as default
Attachment #359694 - Attachment is obsolete: true
Attachment #359694 - Flags: review?(mconnor)
Comment on attachment 359694 [details] [diff] [review] patch rev1 bah... missed some code removal
Attached patch patch rev2 (obsolete) — — Splinter Review
I'm going to verify this before requesting review
Attached patch patch rev3 (obsolete) — — Splinter Review
Attachment #359699 - Attachment is obsolete: true
Attachment #359715 - Flags: review?(mconnor)
Comment on attachment 359715 [details] [diff] [review] patch rev3 Found a couple of reg close keys I want to clean up in this patch.
Attachment #359715 - Attachment is obsolete: true
Attachment #359715 - Flags: review?(mconnor)
Attachment #359715 - Attachment is obsolete: false
Attachment #359715 - Flags: review?(benjamin)
Rob, can we have a better summary for the bug, so it really reflects what you are doing here?
Summary: Error: Uncaught Exception [@ nsIShellService.isDefaultBrowser][@ delayedStartup] → Error: Uncaught Exception [@ nsIShellService.isDefaultBrowser][@ delayedStartup] (GetShortPathNameW fails due to permissions)
Comment on attachment 359715 [details] [diff] [review] patch rev3 Trying to fix this is a PITA... going to do a more investigating over the weekend. btw: even Windows has trouble with these paths. Just type the path in the Vista search box and it won't autocomplete until you type a subdirectory's name WITH the ending backslash.
Attachment #359715 - Attachment is obsolete: true
Attachment #359715 - Flags: review?(benjamin)
Henrik, I still need an answer to comment #24. Specifically, open the properties of the shortcut, click the shortcut tab if it isn't already the selected tab, and copy the target for the shortcut into this bug.
Rob, I've sent a message to your gmail account yesterday. Looks like you have over-seen it. So again, I don't have a shortcut. I'm using the zip builds under windows. I unzipped one from the 1.9.1 branch a while ago into "Program Files". To call the application I run following command: "c:\programme\mozilla firefox\firefox.exe". I think this is the information you wanna have.
Henrik, per your comment #22 you have used the installer previously and I need to find out if the shortucts get created properly along with what the target contains for a shortcut. Also note the (do not email) in my bugzilla name... I use extremely aggressive spam filters and I want all bugzilla related communications to be in bugzilla.
This is turning into a bit of a blackhole to solve what appears to be an edgecase. I'll come back to this when time permits and the info requested is supplied.
Assignee: robert.bugzilla → nobody
Ah ok, will remember. The installer places the correct shortcuts on the desktop, and start menu. The target points to "C:\Program Files\Mozilla Firefox\Firefox.exe". Running Firefox with this patch even with -no-remote works fine. It only breaks when exchanging "Program Folder" with "Programme" in the path. Means the latter one has probably the wrong permissions set.
(In reply to comment #46) > snip... Means the latter one > has probably the wrong permissions set. No, those are the correct permissions created by MS during install. It is just that these paths through certain OS created symlinks (e.g. c:\programme\) have more limited permissions than the normal paths (e.g. c:\program files\).
One way to fix this is to traverse up the path returned by GetModuleFileNameW and check if each dir is a reparse point and reconstruct the real path to the binary. Another way to fix this is to only use the long path when the short path is unavailable. If the user were to launch the app with an installer shortcut they would be prompted again to set as default. Since this happens during startup I am slightly leaning towards the second option.
or remove support for shortpaths in shell integration since we always set longpaths as of Firefox 3.
Attached patch patch rev4 (obsolete) — — Splinter Review
Hey Benjamin, paths including symlinks may not have directory traversal permissions which appears to be needed by GetShortPathNameW. Since we only set long paths for Shell Integration as of Firefox 3.0 I'd like to remove the short path checks. I was planning on removing them when I had the time and this bug makes it more of a priority. I also removed some old cruft that is no longer necessary.
Assignee: nobody → robert.bugzilla
Attachment #359837 - Flags: review?(benjamin)
Rob, I've created a tryserver build to verify that your patch works on my system: https://build.mozilla.org/tryserver-builds/2009-02-01_11:27-hskupin@mozilla.com-bug456895/ As what I can say after having it started several times and compared with a normal build, all issues are solved. Session restore works as expected and no error is visible anymore in the Error Console. Thanks!
btw: I believe this also affects using Firefox without -no-remote. The issue is that the path uses a symlink that has restricted permissions which fail when using GetShortPathNameW.
Priority: -- → P2
Another note, if there is a short path in the registry that points to this installation they are converted to a long path after an app update so removing the short path checks is very safe to do.
(In reply to comment #52) > btw: I believe this also affects using Firefox without -no-remote. The issue is > that the path uses a symlink that has restricted permissions which fail when > using GetShortPathNameW. At least not for my installation. I definitely have to start Firefox with -no-remote or the environment variable set to see this effect. Otherwise it works fine.
Try launching an install that isn't set as default using the path through the symlink with the System Defaults -> Always check... checkbox checked. I see the following in the error console Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIShellService.isDefaultBrowser]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/browser.js :: delayedStartup :: line 841" data: no] I can reproduce without any command line params or with any number of command line params. The no remote code shouldn't have any affect on the shell integration code and doesn't for me using a 3.0.5 build I had handy to verify this.
Damn! If you ever run tryserver builds don't forget to delete them immediately after the test. Now it's clear why that was working. Sorry Rob. You are right with your assumption.
Hey Mike, I'm renominating this to block since it was originally thought to only affect users using no remote, we don't have a good idea as to how many international Vista users this affects, and we have a very safe patch in this bug.
Flags: blocking-firefox3.1- → blocking-firefox3.1?
Not blocking, but we'd take that simple patch once reviewed.
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Attached patch patch rev5 — — Splinter Review
Hey Benjamin, this patch removes the check for short paths in the registry which are no longer necessary since long paths are used as of Firefox 3.0 when installing, updating through app update, and when setting as default. It also removes code that is no longer necessary and explicitly uses a long path for comparing with the shell integration registry keys. These are all good things to do by themselves but it also fixes this bug since it removes the call to GetShortPathNameW.
Attachment #359837 - Attachment is obsolete: true
Attachment #360816 - Flags: review?(benjamin)
Attachment #359837 - Flags: review?(benjamin)
Comment on attachment 360816 [details] [diff] [review] patch rev5 Hey Mike, requesting review from you in case Benjamin doesn't find the time to look at this.
Attachment #360816 - Flags: review?(mconnor)
Comment on attachment 360816 [details] [diff] [review] patch rev5 looks good to me.
Attachment #360816 - Flags: review?(mconnor) → review+
Attachment #360816 - Flags: review?(benjamin)
Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/50257d40e146
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Two things to verify with this bug. The first one was reported by Henrik and is best verified by Henrik unless you are running a non en-US version of Windows since it requires several steps to prepare your system to reproduce. The second you can verify by setting an installation of Firefox as default, the check for default should be enabled, and run Firefox with the short path from a command line. Without this patch you will be prompted to set as default and without you won't.
Comment on attachment 360816 [details] [diff] [review] patch rev5 Drivers, this fixes this bug where we throw when using a non en-US version of Windows and run Firefox using the localized directory name for Program Files which is a symlink / junction point / etc. It also fixes a bug where Firefox prompts to be set as default when it is default when launching the app with a short path. The majority of the patch is code removal with the pertinent part of the patch being getting the long path for the check and hence is very safe.
Attachment #360816 - Flags: approval1.9.1?
Verified fixed on trunk with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090219 Minefield/3.2a1pre ID:20090219032045
Status: RESOLVED → VERIFIED
Hardware: x86 → All
Target Milestone: --- → Firefox 3.2a1
Comment on attachment 360816 [details] [diff] [review] patch rev5 a191=beltzner
Attachment #360816 - Flags: approval1.9.1? → approval1.9.1+
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090221 Shiretoko/3.1b3pre ID:20090221033633 Robert, the updater still fails. Here the message from the error console: AUS:SVC UpdateService:canUpdate - unable to update. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: file:///C:/Programme/Mozilla%20Firefox%203.1/components/nsUpdateService.js :: anonymous :: line 1607" data: no] Is this already covered in another bug or shall I file a new one?
Keywords: fixed1.9.1 → verified1.9.1
(In reply to comment #68) > Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; > rv:1.9.1b3pre) Gecko/20090221 Shiretoko/3.1b3pre ID:20090221033633 > > Robert, the updater still fails. Here the message from the error console: Still fails? It was never mentioned that it was failing... I was afraid there would be other components that fail in this configuration... another one would likely be the EM's write access tests.
See Also: → 1118150
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: