897726 - Can't open url link in Microsoft Outlook due to munged url casing when Outlook is chosen through app chooser's 'browse' feature

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[George Sexton]

Attachment: 1_Page_With_Links.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

From a machine running Microsoft Windows with MS Outlook installed, go to this page:

http://www.mhsoftware.com/caldemo/iCal.html?integral=0

Click on one of the WebCal:// links




Actual results:

The link does not open in Outlook as expected. This appears to be because Firefox is converting the URL to lower case before passing it to Outlook.


Expected results:

The URL should be passed to Microsoft Outlook, which would then create a subscription to the calendar.

In the attached images, image 1 shows the link. Images 2-4 are the sequence when executed with Firefox, and images 5 & 6 are the same link executed from IE. Note that in 3 and 6, the case is different. The word "iCal" is forced to lower case in Firefox, breaking the link.

Comment 1

[George Sexton]

Attachment: 2_LaunchOutlook.png

Comment 2

[George Sexton]

Attachment: 3_Outlook_Open_Calendar_From_Firefox.png

Comment 3

[George Sexton]

Attachment: 4_Outlook_Open_From_Firefox_Fail.png

Comment 4

[George Sexton]

Attachment: 5_LaunchLink_From_IE.png

Comment 5

[George Sexton]

Attachment: 6_Open_Calendar_In_Outlook.png

Comment 6

[Josh Matthews [:jdm]]

Boris, I traced the execution flow of nsExternalHelperAppService to LoadURI and nsMIMEInfoWin::LoadURIInternal (http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/win/nsMIMEInfoWin.cpp#214), the latter of which doesn't appear to modify the URL at all. Do you know if nsIIOService::NewURI would lowercase the scheme at all? Furthermore, do you know anything about the "default" protocol handler? I can't find any trace of it outside a call to GetService in nsIOService::GetProtocolHandler.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Do you know if nsIIOService::NewURI would lowercase the scheme at all?

Yes, it definitely would.

> do you know anything about the "default" protocol handler?

It's in nsExternalProtocolHandler.cpp.  NewURI on this creates an nsSimpleURI, and nsSimpleURI::SetSpec does ToLowerCase(mScheme).

Note that per URI spec:

   Although schemes are case-insensitive, the canonical form is lowercase
   and documents that specify schemes must do so with lowercase letters.  An
   implementation should accept uppercase letters as equivalent to lowercase
   in scheme names (e.g., allow "HTTP" as well as "http") for the sake of
   robustness but should only produce lowercase scheme names for consistency.

(RFC 3986 section 3.1; in RFC 2396 the scheme was simply required to be all-lowercase syntactically.)

Comment 8

[Josh Matthews [:jdm]]

So this becomes a tech evangelism issue?

Comment 9

[George Sexton]

But this issue isn't really about the scheme being converted to lower case, but the path component being converted to lower case. My reading of RFC-2396 says that the scheme and host names are insensitive but I don't see anything that says path elements are case insensitive.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Right, the earlier comments in this bug sounded like they were about the path... the path should _not_ be getting case-folded.

Comment 11

[Manuela Muntean [Away]]

George, are you still reproducing this issue?

Comment 12

[George Sexton]

Yes, using Firefox 25.0.1 on Windows 7, the issue is still happening. When Outlook appears and displays the URL for the subscription, it has been converted to lower case as shown in attachment 780568 [details] [diff] [review].

Comment 13

[Manuela Muntean [Away]]

I don't have Outlook on my Win 7 64-bit machine. I've tried to install Outlook Express (which is free), but I found out that it isn't supported on Win 7.

So I've installed Windows Live Mail (the whole Windows Essentials package actually, from http://windows.microsoft.com/en-us/windows-live/essentials), and after opening http://www.mhsoftware.com/caldemo/iCal.html?integral=0 in Firefox 25.0.1 I get the dialog shown here: https://bug897726.bugzilla.mozilla.org/attachment.cgi?id=780657  The problem is that I don't have an outlook.exe file on my computer, so I can't choose it to open the calendar from your link.

George, could you please try with other browsers (besides IE, since it's also a Microsoft product), to see if you still reproduce the issue (Chrome, for example)? It might be an Outlook issue.

Also, you could try the following:

1) try this with a clean profile: http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

2) running in Safe mode: http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 14

[George Sexton]

I tested this with Chrome and it works as expected.

I started Firefox 25.0.1 with the profile selection and chose a clean profile. It works as expected.

I chose my default profile and disabled all plugins and add-ons. Using my default profile, it is still broken.

I understand at this point it's easy to write this off and say "corrupt user profile" HOWEVER, I had a customer report this issue to me so there is some mechanism that's reasonably common that causes the problem to happen.

I looked through about:config but didn't see any options that were labelled "mess up links before handing them to other programs…" :)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Are you willing to check whether copying your prefs.js from the broken profile to the working one causes it to break?

If it doesn't, can you try copying other files from the profile to see which of them is responsible?

Comment 16

[George Sexton]

Attachment: Working mimeTypes.rdf file.

Comment 17

[George Sexton]

Attachment: non-working mimeTypes.rdf

Comment 18

[George Sexton]

OK, I did some more testing using your suggestions. The critical file seems to be mimeTypes.rdf. I have attached working and non-working mimeTypes.rdf files to this bug.

Here are the steps I followed to determine this:

I created a new default profile. The link worked as expected.

I copied the mimeTypes.rdf file from the profile that did not work to the new, clean profile. After copying the file, the URL to open Outlook did not work.

So, it looks like there's something about the presence of the mimeType handlers in mimeTypes.rdf that affects the URL that's getting passed to Outlook. I tried changing the option to save file and that had no effect.

Comment 19

[George Sexton]

and just to be totally sure, I copied the minimal mimeTypes.rdf from a new profile to the non-working profile and it now works as expected.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Hmm.  So I just looked through our code that does external handler dispatch and I see no obvious tolowercase calls on things other than extensions and MIME types.

George, what happens if you remove these two lines from the broken mimeTypes.rdf:

    <NC:possibleApplication RDF:resource="urn:handler:web:http://30boxes.com/external/widget?refer=ff&amp;url=%s"/>
    <NC:possibleApplication RDF:resource="urn:handler:web:https://30boxes.com/external/widget?refer=ff&amp;url=%s"/>

?  Does that make things work?

Comment 21

[George Sexton]

Removing the 30boxes links does not resolve the issue.

Removing ALL webcal entries does.

Comment 22

[Boris Zbarsky [:bzbarsky]]

OK.  Does putting either of:

    <NC:externalApplication RDF:resource="urn:scheme:externalApplication:webcal"/>

and 

    <NC:possibleApplication RDF:resource="urn:handler:local:C:\Program Files (x86)\Microsoft Office\Office12\OUTLOOK.EXE"/>

make the issue reappear?  That is, is the issue caused by some particular one of those two entries, or does either one cause it?

Comment 23

[George Sexton]

Removing:

  <RDF:Description RDF:about="urn:scheme:externalApplication:webcal"
                   NC:prettyName="OUTLOOK.EXE"
                   NC:path="C:\Program Files (x86)\Microsoft Office\Office12\OUTLOOK.EXE" />

From around 
  <RDF:Description RDF:about="urn:scheme:handler:webcal"
                   NC:alwaysAsk="true">

Remove:

    <NC:possibleApplication RDF:resource="urn:handler:local:C:\Program Files (x86)\Microsoft Office\Office12\OUTLOOK.EXE"/>

Fixes the issue.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Not sure I'm following comment 23.  Do you mean you have to remove both of those things to make it work, or something else?

Comment 25

[George Sexton]

Yes. You have to remove both lines to make it work. I think this is because the external application of outlook is listed multiple times. It's listed as urn:scheme:externalApplication:webcal and as "urn:scheme:externalApplication:text/calendar"

Comment 26

[Boris Zbarsky [:bzbarsky]]

George, thanks.

Jim, are you willing to take a look at this on Windows?  It sounds like dispatching a url to a given helper app will somehow lowercase it (how?) but dispatching it to the system-default helper app works fine...  If you can't look at this, do you know who owns the Windows file handling bits nowadays by any chance?

Comment 27

[Jim Mathies [:jimm]]

(In reply to George Sexton from comment #1)
> Created attachment 780657 [details]
> 2_LaunchOutlook.png

Where did that extra OUTLOOK.EXE come from? Did you add it by browsing to the app at some point? I get the original outlook listed (without the icon, yuck) which works. But I don't have the all caps outlook listing by default.

Comment 28

[George Sexton]

Starting from a fresh, minimal mimeTypes.rdf.

1) If I click on the link and choose "Microsoft Office Outlook" from the Launch Application dialog, things work as expected.

2) If I click on the "Choose" button and navigate to the path for Outlook.exe, then when outlook opens, the path has been converted to lower-case.

On subsequent visits, the Launch Application dialog shows "OUTLOOK.EXE" as a choice.

--

So, at some point in my years of using Firefox, I had browsed for the application.

Comment 29

[Jim Mathies [:jimm]]

(In reply to George Sexton from comment #28)
> Starting from a fresh, minimal mimeTypes.rdf.
> 
> 1) If I click on the link and choose "Microsoft Office Outlook" from the
> Launch Application dialog, things work as expected.
> 
> 2) If I click on the "Choose" button and navigate to the path for
> Outlook.exe, then when outlook opens, the path has been converted to
> lower-case.
> 
> On subsequent visits, the Launch Application dialog shows "OUTLOOK.EXE" as a
> choice.
> 
> --
> 
> So, at some point in my years of using Firefox, I had browsed for the
> application.

thanks, I'll take a look.

Comment 30

[Jim Mathies [:jimm]]

This looks like a bug in Outlook related to command line processing. You should avoid using the browsed-to entry for the app. I traced this to a ShellExecuteEx call down in our xpcom/threads/process code [1] and confirmed we aren't mucking with the url. I also put together a simple test app to be sure (attached) that you can browse to that prints command line params to a console. There too things look ok.

[1] http://mxr.mozilla.org/mozilla-central/source/xpcom/threads/nsProcessCommon.cpp#409

Comment 31

[Jim Mathies [:jimm]]

Attachment: showcmdline test app

Comment 32

[George Sexton]

Thanks. Just to confirm this I opened a command window and ran the command from a prompt:

outlook.exe http://www.mhsoftware.com/caldemo/iCal/calendar_id/2.ics

and when the subscribe notice was displayed by Outlook, the case was converted.