358297 - MS-Windows: XPS Viewer incorrectly redirects to firefox (Vista, XP)

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Basically, according to the shell, a .xps file is set to open using the "XPS Document Viewer".  In the registry, this seems like it chains down into the PresentationFramework assembly, to MS.Internal.IO.Packaging.XpsFilter.  However, if Firefox is set as the default browser, double-clicking an XPS file tries to open it in Firefox.  We don't know what to do with the file, so we offer to open it with the default app (which is the "XPS Document Viewer", "XPSViewer").  If I click ok there, the system tries to pass it on to Firefox again.

An even worse situation happens if the user selects "Always do this for this type of file", because we get stuck in an infinite loop with the system trying to open the file in Firefox.

I'm guessing that what's happening is that the XpsFilter handler is trying to pass off the XPS to IE.  But instead of passing it to IE explicitly, it instead hands it off to whatever the default browser is -- in this case, firefox.  This sounds like a bug inside XpsFilter/XPSViewer.  (It's fairly simple to reproduce -- install Firefox, set it as the default browser, and then try to open a XPS document; it'll attempt to open in Firefox.)

(Note: I sent this off to MS as well, haven't heard back yet.  I think that this is a bug on their end, but if they don't fix it for RTM, we should figure out a way to work around it on our end -- even special handling XPS files if necessary, as the behaviour above is pretty bad and could look like we're at fault.)

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Bug 218257 is related, but I guess it wouldn't fix this bug if the handler isn't firefox.exe explicitly.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, it's not; firefox has no idea about this mime type.  I got a response from MS; they've reproduced the problem, and are still digging deeper.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The response I got back from Microsoft made no mention of whether this would be fixed or not.  The two suggested workarounds I was given were:

1, embed IE in a tab ("like the IE Tab extension") to display XPSs
2, embed the WPF components to display XPS ("and also gain access to XAML and other WPF content")

Neither of these is really acceptable for us.  I'm surprised "just hand it off to IE" was not a suggestion, but I think that's what we should do, even though it means sending people to IE instead of keeping them in Firefox.

Comment 4

[Jay Patel [:jay]]

Not blocking 1.8.1.1 based on recent discussion around Vista, so let's try to get a handle on this for 1.8.1.2.

Comment 5

[Daniel Veditz [:dveditz]]

Is this intended to be part of the Vista release? If so we ought to get an owner on it. If not please clear the blocking nomination.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I think it needs to be; MS didn't fix this for Vista final.

Comment 7

[Jay Patel [:jay]]

mconner: We need an owner for this bug, any ideas?

Comment 8

[Roy Levow]

This isn't just a Vista issue.  There is similar behavior with Windows XP.  The first attempt to open an XPS file yields a request to install dotNET Framework v3.0.  After that a dialog opens for the file with XPSViewer.Document (Default).  OK opens a new tab and then shows the dialog again, with a new tab each time.

Comment 9

[Jay Patel [:jay]]

Not blocking, but would like to have a fix for this.  Assigning to mconnor to find  someone to look into this one.

Comment 10

[Bernd Oliver Sünderhauf]

IMHO this IS a blocker! Especially because of the possible infinite loop, this bug is unacceptable and makes Firefox look very buggy to users of XPS files.

Comment 11

[Daniel Veditz [:dveditz]]

Still not blocking the branch. If we get a trunk fix we can look at the risk of back-porting it.

Comment 12

[u279076]

I found this bug on 1.5.0.12 while doing BFTs today.  I can also confirm this on all versions back to 1.5.0.5 and 2.0.0.3 so far.

All on Windows XP SP2.

Comment 13

[Jim Mathies [:jimm]]

Attachment: os helper 'big patch'

Comment 14

[Jim Mathies [:jimm]]

Attachment: nsfile 'small patch'

Comment 15

[Jim Mathies [:jimm]]

Attached are two diffs, for two different fixes for bug 358297. 

The first patch (the larger of the two files) provides a more user friendly way of handling the problem, however the amount of code required is much larger than the second patch. The code for the first patch lands in mozilla\uriloader\exthandler\win\nsOSHelperAppService.h/.cpp. Essentially what it does is patch up the mimeTypes.rdf file, adding a custom handler that points directly to internet explorer. The code is triggered the first time the user interacts with an XPS file in Firefox. I think the advantage of this patch is that it allows the user to modify the settings once the touchup takes place. For example, the user might like to point xps files to a different handler other than IE. As long as there’s a generic handler configured and userSystemDefault is set to ‘false’ in mimeTypes.rdf, the patch doesn’t do anything. If however userSystemDefault is set, or no handler is configured, it’ll do its thing and point xps files out to IE.

The second patch I rolled together after the first. Looking at the first, I was concerned about the amount of code required to pull it off. So I put together another, smaller patch that lands in mozilla\xpcom\io\nsLocalFileWin.cpp. This is the location where ShellExecute gets called on xps files. It’ pretty straight forward, before the call to ShellExecute, the patch checks to see if the file extension is .xps, and whether or not Firefox is set to be the default browser. If both these conditions are true, it pipes the XPS file directly out to IE. The advantage here is that it is small and relatively simple, the disadvantage is that users can’t override it in any way. I’m also not sure if putting something like this in this location is appropriate – from my understanding this area of the source is more general purpose, and ends up getting compiled in multiple apps, not just Firefox. I looked around for a compile def I could use to isolate it to Firefox’s compile (something like MOZ_FIREFOX) but didn’t find anything. 

One other note on the second one, in it a browser check takes place. I had to add some COM related definitions into nsLocalFileWin.cpp to support this, however, the same code is currently available through an interface in mozilla\browser\components\shell\src\nsWindowsShellService.cpp. Unfortunately when I tried to source the header file into nsLocalFileWin to get at the interface, the compiler couldn’t find it. If anyone has a suggestion on how to get nsIShellServices instantiated in nsFile, please let me know and I'll patch it up.

I noticed the last poster mentioned a problem on XPSP2. This “works for me” – I see no issues on XP with XPS files. Microsoft has a stand-alone viewer for XP and 2K similar to Acrobat. Once installed all browsers handle XPS files as expected – they hand them off through ShellExecute to this viewer.  If anyone is experience problems on XP please post additional detail and I’ll take a look.

Comment 16

[u279076]

This problem occurs for me on XP SP2.  I have tested it with FF 2004 and Minefield 3.0a5pre with the same results.

To ensure that my xps viewer was up to date and set as the default, I went to microsoft.com and downloaded the .net framework 3.0 (which comes with xps viewer and writer).

I then went to this bug page and printed it out to XPS document writer, calling it test.xps and saving it to my desktop.  Before opening it I verified that the program default was set to XPS viewer.  The icon is even the XPS icon.

When double clicking on the file, it asks me if I want to open the document with the XPS viewer.  Clicking on OK results in firefox trying to open the file as a "download".

Please see the attached screenshot to see what dialog I am talking about.

Comment 17

[u279076]

Attachment: Firefox tries to download XPS file

Comment 18

[Jim Mathies [:jimm]]

Hey Anthony,

To confirm - your not using the "XPS Essentials Pack" stand alone viewer, you've just installed .NET 3.0 framework on XPSP2 and the XPSViewer came down with that.

For reference, the essentials pack is available here - 
http://www.microsoft.com/downloads/details.aspx?FamilyId=B8DCFFDD-E3A5-44CC-8021-7649FD37FFEE&displaylang=en

Comment 19

[u279076]

Correct, I am downloading the .net framework found here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en

Which comes with both the XPS writer and viewer.

I will try the XPS essentials pack and see what happens.

Comment 20

[u279076]

OK.  The XPS Essentials pack worked.

Right now I have 2 versions of XPS viewer installed.  XPS Viewer (which came with .net) and XPS Viewer EP (which came with the Essentials Pack).  Setting XPS Viewer EP as the default, it opens the way it should.  Setting XPS Viewer as the default, the file tries to open in FF.  Also, if you right click the file and select Open with > XPS Viewer (not XPS Viewer EP), the file tries to open with FF.

What the difference between these two versions is, I do not know.

Comment 21

[Jim Mathies [:jimm]]

Looks like we'll have to detect which viewer's set to the default on XP then handle the file appropriately (stndard shellexecute vs. pipe directly to ie).   I'll work up another edition of the nsfile patch. Thanks for the feedback.

Comment 22

[Jim Mathies [:jimm]]

Attachment: updated nslocalfilewin patch for xp issues

Tested on various configs - xp, xp/.net3, xp/stand alone viewer, xp/.net3/stand alone. Looks to be handling things appropriately for all the various setups related to this document type.

Comment 23

[Jim Mathies [:jimm]]

Attachment: final patch

Comment 24

[u279076]

I am going to test both xps viewer and xps viewer EP on windows XP and post my findings.

Comment 25

[u279076]

Ok, now what happens is the XPS document tries to open in firefox, displaying the download prompt.  When the user selects to "open" with "XPSViewer.Document (Default)" from the download prompt, the xps file opens in XPS Viewer EP (but only if XPS Viewer EP is installed.

One other thing I noticed...
Trying to open the XPS document without an instance of firefox.exe already running, starts a new instance of firefox.exe but firefox does not actually launch.  Nothing actually happens, aside from the process in task manager.  I can only get the document to load if an instance of firefox is already running properly.

For now it looks like users on WinXP have to do the following as a temporary workaround while experiencing this issue:

1. Ensure XPS Viewer EP is installed
2. Launch firefox
3. Double click on the xps file
4. Tell firefox to open with XPSViewer.Document

Comment 26

[Jim Mathies [:jimm]]

Hey Anthony,

When you installed the essentials pack, it should have offered you the opportunity to register it as the default viewer. Did you choose to do this? If so the viewer should open on its own, Firefox should not have been involved. It seems you have the stub app marked as the default viewer, which is why you’re seeing this behavior. 

I'll see if I can reproduce the "Firefox launches but nothing happens" thing as this is a possible config for users who have .net3 but no stand along xps viewer. Firefox should launch, present the download dialog, and then hand the file off to whatever viewer you choose to send it to.. (IE for XPSViewer.Document, stand alone for Windows.XPSReachViewer).

Comment 27

[u279076]

Yes, I set XPS Viewer EP as the default.

To verify, I just went into My Computer > Tools > Folder Options > File Types, scrolled down to XPS and it's default program is set to XPS Viewer EP.

Comment 28

[u279076]

I just tested on a second windows XP computer with the same results in our QA lab.

Comment 29

[u279076]

Jim, your patch appears to have fixed the problem.  I no longer have this issue on 3.0a5 or 3.0a6 in Win XP.

Comment 30

[u279076]

Ok, this works on both XP and Vista using 3.0a6, but only if the user has XPS Essentials Pack installed and set as the default for XPS documents.

Comment 31

[Robert Strong (they/them - no direct email)]

Jim, is it that the XPSViewer registers itself as the handler in the registry when installed via the XPS Essentials Pack and not normally? If so, perhaps we could just add those same registry entries if needed during install?

Comment 32

[Jim Mathies [:jimm]]

Hey Rob, The Essentials Pack, by default registers itself as the default viewer. The only time it’ll ask the user if this is “ok to do” is when .NET 3 is already installed, in which case the EP install confirms the user wants to replace the embedded IE viewer (which comes down with .NET3) with the stand alone. 

Regardless of how the user has these various packages setup, were handling things in the best way we can with this patch-

Double click on a local XPS file:

XP/Essentials Pack – XPS file opens in stand-alone viewer. 
XP/.NET3  – XPS file opens in IE. [A Firefox browser window is left hanging around since it’s the registered handler.]
XP/.NET3/Essentials Pack (EP ‘register’ install selected) - XPS file opens in stand-alone viewer.
XP/.NET3/Essentials Pack (EP ‘do not register’ install selected) - XPS file opens in IE. [A Firefox browser window left hanging around since it’s the registered handler.]

Click on a link to an XPS file:

XP/Essentials Pack – XPS file opens in stand-alone viewer. 
XP/.NET3  – XPS file opens in IE. 
XP/.NET3/Essentials Pack (EP ‘register’ install selected) - XPS file opens in stand-alone viewer.
XP/.NET3/Essentials Pack (EP ‘do not register’ install selected) - XPS file opens in IE.

Aside from the minor nit that we leave our window open after handing something off to a 3rd party handler, this working well now with the patch.

Comment 33

[Robert Strong (they/them - no direct email)]

I doubt that we are actually the registered handler since the registry keys aren't present and that IE is just handing it off to the default browser thinking that since it handles XPS it should handle XPS as well. I would think if this is in fact what is going on (e.g. verify with MS) that we could add those keys when not present so XPS is handled as any other file type not handled by the browser by either letting the OS handle it or if it is opened in our app we hand it off to the shell... that way we don't have one-off code.

Comment 34

[Jim Mathies [:jimm]]

We could take that route, honestly it’s the first thing I thought of too when I started messing around with this. However there are some issues. For one thing the stub app handles more than just handing the file off to IE, it also handles things like icon thumbnails and file property sheets for the doc type. We can get around some this with some creative registry hacking, but your still going to run into the classic problem with the registry –apps competing for file associations. It would be nice if in our install we could just touch up the registry once and forget about it, but that doesn’t guarantee those changes remain in place. Installing service packs and security updates to .NET will often re-register all kinds of things, including file type associations, installing and uninstalling the essentials pack will re-register the file type as well. When MS releases the next .NET library that will most likely reassign these types as well. So changing these once isn’t going to be reliable – you would have to put something in the source that updates these changes every time Firefox runs, and even that doesn’t assure you that it’ll work perfectly every time since Firefox might be open when some new software gets installed. In the end, it’s kind of a choice between trying to constantly maintain control of somebody else’s registry area, or handling the file itself when we receive it.   I ended up looking for the latter. 

If you want though I can work out how we would do the registry thing and we could test it – try installing / upgrading / uninstalling some things, see what breaks.    

Comment 35

[u279076]

Since it is the .net version that does not work properly, maybe we can add something to the release notes page saying something like:

"Using XPS?  We recommend XPS Essentials Pack!" with a link to the correct download.

Or maybe there is some way we can package this download with firefox?

Or maybe there is some way that we can get our betters to negotiate with Microsoft to get them to provide the XPS essentials pack bundled in with their .net framework updates?

However, this last one is largely just wishful thinking.  I am starting to think that I think way too far out of the box sometimes...

Comment 36

[Jim Mathies [:jimm]]

The one point I'd make is that with the right settings in place (hand it off to the .NET3’s XPSViewer.Document, and “always use these settings”) this bug represents a race condition with the browser opening tabs repeatedly until Firefox crashes or the system hangs. Suggesting users install 3rd party software to address this seems a little risky.

My hope would be that Microsoft releases a plug-in viewer for compatible browsers as they’ve done with Silverlight. It’s in their best interests to do so if they are interested in promoting this doc standard over PDF. At which point we could bundle that and remove any fixes associated with this bug. I can’t make the decision on bundling the stand alone but something tells me we're not going to be distributing something like it. (The veterans on the cc list might be able to better clarify our position on issues of this nature.)

Comment 37

[Robert Strong (they/them - no direct email)]

Jim, excellent point regarding the possibility of service packs, etc. breaking xps handling if we managed the registry keys and agree with your approach until MS provides a fix. Also, I doubt very highly that we could bundle an MS plugin with our app due to licensing.

Comment 38

[u279076]

Let me reiterate that I dont think we need to "bundle" an MS plugin with our product.  I believe that pointing that niche of our user base that uses XPS documents in the right direction to get the XPS Essentials Pack is the right way to go for now.  A link of the release notes or welcome page is probably sufficient.

I really do not like the idea of the band-aid treatment (ie. registry hack/patch).  Not only does this seem subversive, it will have to be done every time a user gets an update or installs something that may potentially change the keys.

Or how about this...

I do not know how big that niche really is...I am assuming 1% of our user base, if that.  But what if we set up a wiki or something that walked them through manually editing the registry, or manually downloading the XPS essentials patch.  This keeps it off our release notes and away from our other users.

I honestly think the only other way around this is to get MS to stop distributing their crappier version of XPS a la .net framework, and start providing the XPS EP as standard.

Comment 39

[Robert Strong (they/them - no direct email)]

Anthony, take a look at Jim's patches... they don't modify the registry. My statement about bundling the plugin was in response to Jim's comment #36. The band-aid treatment Jim is proposing is to handle xps within our app as a one-off. It may be acceptable to just point users to the XPS Essentials Pack but we would have to one-off the code to do that as well so I am leaning toward just handling it as best we can on our end as Jim's patch does and letting MS handle their bug regarding improperly assuming xps files should be handled by the default browser going forward.

Comment 40

[Jim Mathies [:jimm]]

This is interesting, I'll ping Andy and see if he'll talk to me a bit - 

"We are planning on having viewers that support Mac and Unix—cross platform support is a critical part of the XPS story.  I also know that there are several third-parties looking at building solutions for other platforms – so potentially the market will deliver something on its own, which would be great."

http://blogs.msdn.com/andy_simonds/archive/2005/10/31/487487.aspx

Comment 41

[u279076]

Rob> I never said that Jim's patch did modify the registry.  However,  modifying registry keys was mentioned, which is what I was against doing in a patch but for doing if we had some sort of a guide for users.

Jim> That blog was interesting.  Perhaps someone could make an XPS addon for Firefox.  Or maybe Mozilla could make their own XPS viewer.

Otherwise, another work around for this problem is to associate XPS files with IE.  This works without the XPS EP installed because IE understands Active X.  The only quirk with this method is that you lost the thumbnail preview feature.

Comment 42

[u279076]

We want to be careful not to infringe on Microsoft's patents though :)

Comment 43

[Robert Strong (they/them - no direct email)]

Anthony> cool, it was just inferred by your comment #38 (ie registry hack/patch) after it was already stated that I was for Jim's method. (In reply to comment #41)
> Rob> I never said that Jim's patch did modify the registry.  However, 
> modifying registry keys was mentioned, which is what I was against doing in a
> patch but for doing if we had some sort of a guide for users.
cool, it was just inferred by your comment #38 (ie registry hack/patch) after it was already stated that I was for Jim's method.

> Jim> That blog was interesting.  Perhaps someone could make an XPS addon for
> Firefox.  Or maybe Mozilla could make their own XPS viewer.
> 
> Otherwise, another work around for this problem is to associate XPS files with
> IE.  This works without the XPS EP installed because IE understands Active X. 
> The only quirk with this method is that you lost the thumbnail preview feature.
This was what I was referring to in my initial comments and would require modifying / maintaining registry keys which you already stated you are against.

Comment 44

[u279076]

The IE method does not require going into the registry at all.  There are two ways to change file associations:

1. Right click on any xps file, click properties, there should be an option to choose the default program

2. My Computer > Tools > Folder Options > File types, scroll down to XPS and change the default program

Also, I am always against a general user blindly going into the registry if I can avoid it.  I think anyone who has worked in tech support can understand where I am coming from.  That's all I was trying to get at.  I guess I misunderstood the preceding comments...sorry.

Comment 45

[Robert Strong (they/them - no direct email)]

I think I see... you were advocating having the user make the change which is btw stored in the registry. This would have the same issues as Jim mentioned in comment #36 in that updates may overwrite the entry in the registry.

Comment 46

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I don't think Mozilla is at all interested in promoting XPS (via an addon, or even linking to plugin release pages, etc.); remember that this bug is basically a workaround for a Microsoft bug that they've shown no interest in fixing, despite it being acknowledged.

The simplest thing to do might be to force save-as as the only action possible for any XPS documents.

Comment 47

[Jim Mathies [:jimm]]

Hey Vlad - Forcing save-as presents a problem in that the file would then be sitting on the local machine. If the user double clicked on it, Firefox would again open and prompt them to save as again. :) 

The basic problem is this - With .NET3 installed, Windows is configured to hand xps files to the default browser. The patch I've provided traps these when we receive them and sends them over to IE directly. With the stand alone installed, everything just works as expected. 

Comment 48

[Doug Turner (:dougt)]

Comment on attachment 267446 [details] [diff] [review]
final patch

robert should be the person reviewing this.  He has alot better knowledge of Vista than I do.

I think that this is a crappy solution.  isn't there a way we can stop xps files from reaching xpcom?

Comment 49

[Jim Mathies [:jimm]]

Ok, well I’m open to suggestions at this point. Some things that have been tried –

1) Trapping xps files prior to the download helper dialog being displayed. 

I wrote a patch which patches up the user's mimetypes.rdf, adding a handler for xps that points to IE. It ended up requiring a lot of code and was shot down. We could do something very simple like Vlad suggested and force these to "save to disk". However as I pointed out, with Firefox as the default double clicking on an xps on the local system open Firefox causing a loop. Imho, users will blame Firefox for this funny behavior not Windows. We could also simply not respond when these files are handed in to us, essentially just dropping them as if we never received them. User's would not be able to double click the files to open them, but they would be able to open IE and drop them in there to view them. 

2) Modifying (and maintaining our changes) in the registry so that these files go directly to IE.

3) Handle sending these off to IE in xpcom, or prior. 

I wrote a patch for this as well, nsLocalFileWin seemed like the most appropriate place based on my understand of how this event traces through Firefox for both double clicks on local files as well as link clicks in web pages that point to xps documents.

4) Make no changes - recommend to the user through release notes how to adjust for this problem by either setting up a custom handler, installing the essentials pack (no support for this on vista), or I guess just recommend not interacting with these files types.

Some way out suggestions - 

5)  xps documents are encased in a simple zip format with a different file extension - maybe rename them to .zip and point them out to whatever we use to handle archives. (Oddly enough older versions of IE actually do this if there's no .NET3 or EP installed.)

6) Figure out some way to display something in the window, some sort of info page explaining we can't handle the file type.

I'll think on it a bit, maybe there's something else I haven't thought of. 

Comment 50

[u279076]

Jim, when you say no support for XPS EP on vista, do you mean from us or MS?

Because MS does support XPS EP on Vista:
http://www.microsoft.com/downloads/details.aspx?FamilyID=b8dcffdd-e3a5-44cc-8021-7649fd37ffee&displaylang=en
"supported operating systems: Windows Server 2003, Vista, XP"

Comment 51

[Jim Mathies [:jimm]]

Yes, your correct. It is supported however it does not install as the default. The update comes down as KB update and there are no options for controlling it. The xps blog talks about what user's would have to do to set this up.

http://blogs.msdn.com/xps/archive/2007/04/16/microsoft-xml-paper-specifications-essentials-pack-v1-0-is-released.aspx

Comment 52

[Alan Duquette]

When I try to print a map at google this xps problem happens where all I get is a "save to" dialog.  Running windows xp sp2 and latest firefox.  Have associated xps files with xps EP but no change. Am running net 3.  Don't know why no one mentioned google maps and other xps using sites not printing.

Comment 53

[Jim Mathies [:jimm]]

Hey Alan,

I believe that's the way it works. If you are printing using the "XPS Document Writer" - a "save as" dialog is what you would expect since you are printing to a file rather than to a printer.

Comment 54

[u279076]

(In reply to comment #52)
> When I try to print a map at google this xps problem happens where all I get is
> a "save to" dialog.  Running windows xp sp2 and latest firefox.  Have
> associated xps files with xps EP but no change. Am running net 3.  Don't know
> why no one mentioned google maps and other xps using sites not printing.
> 

Alan, would you be so kind as to walk us through your steps to reproduce what is happening?  Please be as detailed as possible.

Thank you.

Comment 55

[Alan Duquette]

At google maps after pushing the print button on their page a pop up opens with the header of "printer" and print on the bar and a name of microsoft xps document.....Wait I just talked myself through a "fix" while I had another tab open.  Just had to change the "name" drop down to canon i860.  On the same subject, sort of, I can not change tabs while this pop up is open?  Normal?

Comment 56

[Alan Duquette]

PS    Is their a way to make "canon i80" the default in the name field?

Comment 57

[u279076]

Correct, when the print dialog is engaged, it is the top level dialog and negates any activity below it until the dialog is either ok'd or canceled.

Comment 58

[u279076]

(In reply to comment #56)
> PS    Is their a way to make "canon i80" the default in the name field?
> 

On Windows XP:
Start > Control Panel > Printers > Right click on the "canon i80" printer > Left click "set as default printer" from the menu that appears

There should be a "check" on the corner of the icon for that printer now.

Your default printer should appear first in the list for any print dialog.

Comment 59

[Alan Duquette]

It was and is the default printer, maybe because it is the only printer? 
PS   IE prints on the same web page without having to take this step of selecting the name.

Comment 60

[u279076]

Are you talking about the print dialog?  I believe IE, among other MS software will automatically print to the default printer when selecting print from the file menu due to it's integration with Windows.

Firefox on the other hand does not do this.  It uses the print dialog so that you can configure how you want the print to perform.

If the problem is that you want to have firefox automatically print to the default printer, I suggest that you file an enhancement bug.

FYI this is how the general printing to XPS process should work:
1. Go to a page you want to print
2. Click file > print
3. Select the XPS Document Writer printer
4. Click print
A save file dialog should come up asking you to save the XPS file somewhere
5. Enter a file name for the XPS file and click save
6. A progress bar dialog should display as the html content is converted to the XPS file.
Once this is done, you should find your XPS file exactly where you saved it.

If this is not what is happening, please let us know and give us details on what IS going on so that we can work on this with you.

Comment 61

[Alan Duquette]

Actually I did just want it to print with no input from me other than telling it to print as you mentioned in the first part of your reply.  Also now that I selected the i860 it is now the default automatically as I wanted.  All is right with the world.
I am sure things would work as expected in the second method you mentioned except on step 3 the choice does not have the word "printer".  As I recall now that I think about it it did work exactly as your steps said except that "printer" thing.

Comment 62

[u279076]

So if I am reading this correctly, you no longer have a "problem".  It is just that you would like to be able to do the automatic print thing like IE can do.

Is this a correct assumption?

Comment 63

[Alan Duquette]

Correct that I no longer have a problem.  Wrong that I would like to be able to auto print because it is auto printing now.  Thanks for your help.

Comment 64

[u279076]

Alan, excellent.

Vlad, could you please resolve this bug as fixed.

A week of inactivity will result in this bug being resolved.

Comment 65

[Robert Strong (they/them - no direct email)]

Anthony, the original issue as reported still needs to be fixed.

Comment 66

[u279076]

Heh heh, sorry.  My bad.

Comment 67

[Jim Mathies [:jimm]]

hey guys - i'll be back on this in a bit. i'm working in the helper app stuff now on something else. I'll try to work something up for this thats higher up in the call chain, not in xpcom. re - Doug's comment.

Comment 68

[Jim Mathies [:jimm]]

I'll be rolling this in with the "Open With" dialog for bug 348808, since once that's finished this is going to be easy to address. 

The idea is to filter out the XPSViewer.Document handler from the unknownContent dialog drop down list.  Users will see other viewers they have configured (like the reach viewer). If none are available, they'll be able to select the choose app option which will bring up the new dialog. That dialog will replace XPSViewer.Document with an Internet Explorer item.

Comment 69

[Matthias Stevens]

I don't know if it has been mentioned but this also happens on Windows XP (with .NET framework 3.0 installed, which includes XPS support) and Firefox 2.0.0.x.

Comment 70

[Rowin Zapanta]

just download the xps viewer at http://www.microsoft.com/whdc/xps/viewxps.mspx
and never choose firefox to open any file in the pc except .html files.

Comment 71

[Mike Connor [:mconnor]]

its waited this long, it can wait till M10

Comment 72

[Jim Mathies [:jimm]]

This still stands to be closed out as soon as bug 348808 is checked in. (348808 is sitting at checkin-needed right now) Nothing has really changed here.

Comment 73

[wearyofallthiscrap]

This either never got fixed, or is re-broken.  All of the exact same original behavior happens to me on Win XP SP 3 using FF 19.0.

Comment 74

[u279076]

(In reply to wearyofallthiscrap from comment #73)
> This either never got fixed, or is re-broken.  All of the exact same
> original behavior happens to me on Win XP SP 3 using FF 19.0.

This was fixed 5 years ago. If it's happening for you now it's possible something landed which regressed this behaviour. Can you please file a new bug describing your steps to reproduce and what you are seeing? When filing the bug, please also indicate if any previous versions (18, 17, or earlier) reproduce this bug. Thank you.

Comment 75

[u451271]

No this was NOT fixed!
I have Firefox 20.0.1 running and although my xps file is liked to the XPS viewer, Firefox opens and wants to save the file.
This is SUPER annoying, even more that this is a 6 Year old bug no one cares about.
I am using Win XP SP3 and the ff. mentioned above.

Comment 76

[Jim Mathies [:jimm]]

We fixed this a long time ago such that if the stand alone viewer was installed we would launch that rather than the browser. This is still working for me locally.  I see an "XPS Viewer (default)" in the attachment handler dialog, and when I click on that it launches the stand alone.

Comment 77

[Jim Mathies [:jimm]]

If you are still seeing the problem, maybe something with the way the xps viewer is configured has changed. Would you mind posting a new bug with steps to reproduce and your os info? cc me as well please.

Comment 78

[Biju]

Attachment: test.xps

Tested with IE 9 in Win Vista and
23.0a1 (2013-05-02) Nightly - fixed
22.0a2 (2013-04-25) Aurora - fixed
22.0a2 (2013-05-02) Aurora - fixed

Comment 79

[napking]

This is a bug generating procedure of my environment.

(1) Double click the xxx.xps
    -> New tab appeared in Firefox
    -> "Open xxx.xps" Dialog-box
       Open program(O) : Reference(B)
       Save the file
       [OK]  [Cancel]
(2) Check "Open program(O)" then push "Reference(B)"
    -> "Select program" Dialog-box
       Firefox
       XPSViewer.exe
       WinFX Runtime Components
         .
         .
         .
       [Reference...]  [OK]  [Cancel]
(3) Push "Reference..."
    -> "Select program" Filechooser Dialog-box in C:\Program Files
(4) Select "c:\WINDOWS\system32\XPSViewer\XPSViewer.exe"
    -> Return (1) Dialog-box
       Open program(O) : XPSViewer.exe
       Save the file
       [OK]  [Cancel]
(5) Push "OK"
    -> New tab appeared in Firefox.
    -> (1) Dialog-box
    -> Loop forever


Firefox: 21.0
Windows XP Command-prompt: 
C:\Documents and Settings\"machine-name">ftype | findstr XPS
XPSViewer.Document.1="c:\WINDOWS\system32\XPSViewer\XPSViewer.exe" "%1" %*

Comment 80

[Robert Strong (they/them - no direct email)]

(In reply to napking from comment #79)
> This is a bug generating procedure of my environment.
Please file a new bug with these steps to reproduce

Comment 81

[ppostma1]

wow! amazing intellect and technical evaluations here! May I point out 2 facts, and offer an alternate (and simplified) solution?

1: Installing XPS viewer adds filters to the system for the OS to read the files.
2: XPS-V does not have a graphical interface, defaulting its operations to IE to render and view (but fails because it uses default browser instead of IE specifically).

Just change the default application for .xps files to IE.
Then they can be opened and viewed without problems