354701 - MS Exchange Web Access kills window upon download finish with SWM set to "reuse"

Status: RESOLVED FIXED

(Camino Graveyard :: Downloading, defect)

Description

[Kurt Weinschenker]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060922 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060922 Camino/1.2+

When downloading a file as an email attachment, such as a MS Office document from my work email account on an Exchange based server, Camino downloads the file okay to the desktop.  After that, the currently open window closes, without any user intervention.  

To get back to the MS Exchange web access window I had been working in, I have to command-N, and use the Go menu to pull up the page.  

I can't authorize public access to an Exchange server to test this, so perhaps someone else out there might supply a URL.  My work email account server is running Exchange under Windows Server 2003.

Caveat:  I'm not sure if Camino's the problem, or the configuration of the company's email server.  While the office I work at is all PC, one office elsewhere is all Mac.

Reproducible: Always

Steps to Reproduce:
1.Surf to an Exchange Server web access site, log in as usual.
2.Download a file attachment from an email.
3.Open Camino window closes without any user intervention.

Actual Results:  
Camino's open window closed entirely on its own.

Expected Results:  
Camino should have keep the current window open.

Comment 1

[froodian (Ian Leue)]

This sounds like a (possibly already filed) regression from bug 241972.

Comment 2

[Kurt Weinschenker]

No, this experience is different from bug 241972.  In that bug, a blank window appeared, and one had to close it manually.  I'm hitting the attachment link in MS Exchange Web Server, the dialog box appears to save the attached file, the window then disappears after the download starts, leaving the download window the only window Camino has open.  Hope I've got it straight, now.

I think I should have mentioned I do have pop-up blocking enabled.  However, previous versions of Camino did not exhibit this behavior.  Off the top of my head, I would say 1.0 worked with this MS Exchange server normally, but apparently, the nightlies aren't.

I'll see in the next week or so if I can't pin down the regression.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

You don't have browser.link.open_newwindow set to 1, do you?  Although that should be working fine since bug 344808 landed (can you try the testcase on bug 344795 just to be sure?)

Comment 4

[Kurt Weinschenker]

As it turns out, Smokey, I *do* have browser.link.open_newwindow set to 1.  Thanks for typing to me how to find that out.

Even so, I took a couple minutes to run the testcases of bug 344808, and 344795.  Those testcases were fixed as advertised.  Camino was working as it should.

I cannot reproduce this bug with anything other than a MS Exchange Web Server.  Give me a couple days, my schedule looks horrid, but I'll try to track the regression down as best I can.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

A couple of other questions/things to try:

Does the problem persist if you switch that pref to 3 aka "new tab" (or to 0, which is "off")?

Does the problem also exist on branch builds, or just trunk?

Comment 6

[Torben]

I see this too with a current trunk build. This only happens with browser.link.open_newwindow set to 1, 0 or 3 works as expected (as do 1.0.3).

Comment 7

[Torben]

> Does the problem also exist on branch builds

Yes, just tested 2006092804 (v1.0+).

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Hmm, I wonder what MS is doing differently there that causes this to fail with the fix for bug 344808 in.

Can one of you test Fx2 RC1 and/or Minefield; I assume it fails there, too.

Comment 9

[Torben]

> Can one of you test Fx2 RC1 and/or Minefield; I assume it fails there, too.

Correct, also fails on Fx2 RC1.

Comment 10

[Håkan Waara]

Sounds quite serious considering that it's such a major web app? Raising severity.

Comment 11

[Samuel Sidler (old account; do not CC)]

I'm not sure "File Handling" is the best place for this bug, but I don't know where bugs related to browser.link.open_newwindow belong.

Comment 12

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

(In reply to comment #11)
> I'm not sure "File Handling" is the best place for this bug, but I don't know
> where bugs related to browser.link.open_newwindow belong.

I would say either Core: Embedding APIs or Core: Docshell. Pick one :)

Comment 13

[Chris Lawson (gone)]

Fixing typo in summary.

Comment 14

[Torben]

Now I am confused:

Current branch builds (Camino 2006092804 (v1.0+) and Fx2 RC1) show this bug but not bug 344808 and bug 344795.
Current Minefield (20060929 3.0a1) has neither this bug nor the others.
Current Camino-trunk (2006092822 1.2+) has _all_ three bugs (even with a new profile with only setting SWM to reuse).

Kurt, are you sure you tested bug 344808 and bug 344795 with a trunk (v1.2+) and not a branch (v1.0+) build?

I can also only reproduce this on a MS Exchange Web Server, saving as html-complete works as expected (i.e. not closing the window).

A work-around for this bug is to opt-click on the attachment to bring up the save as... dialog.

Comment 15

[Kurt Weinschenker]

Clarification; amplification.

The testcase in bug 344808 failed with the following trunk build:  Camino 2006092722 (v1.2+), from the Camino -> About Camino menu.  Behavior on the testcase for this bug was similar to what I witnessed on my company's MS Exchange web server.

The testcase in bug 344795 also failed with Camino trunk build 2006092722 (v1.2+).

My apologies to all for any confusion on this bug.  Apparently I confused version of Camino was on my machine, and I should have double-checked before posting comment 4.  This report is for a trunk build of Camino; I've triple-checked, and posted what I found in the About Camino dialog box.  Sorry for the confusion factor.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Er...  So can someone who actually has a Camino debug build look into this?

Breakpoint in nsDocShell::InternalLoad at the line where we do |win->Open()| and see what happens after that?  Are we hitting the |aFlags |= INTERNAL_LOAD_FLAGS_NEW_WINDOW| line (which we shouldn't be in this case)?  If so, why?

I suspect the key is likely to end up being the fact that CHBrowserListener::ProvideWindow sets *outWindowIsNew = PR_TRUE when it provides a window.  Always.  If it's actually reusing an existing window that would be like ... wrong.

Comment 17

[Boris Zbarsky [:bzbarsky]]

And yes, looks like reuseExistingBrowserWindow() (in BrowserWrapper.mm) will return the existing window in some cases.  It needs to also indicate to the caller whether it did that.

Comment 18

[Håkan Waara]

Attachment: Possible fix v1

Here's a possible fix, if Boris' hypothesis is correct. Can someone who is able to repro the bug try out the patch?

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #18)
> Created an attachment (id=241169) [edit]
> Possible fix v1
> 
> Here's a possible fix, if Boris' hypothesis is correct. Can someone who is able
> to repro the bug try out the patch?
 
This seems to fix the testcase on bug 344795 for me in my trunk build.

Assuming it doesn't fix the  branch issue with MS Exchange (which I'm guessing it won't, since that bug apparently bites BonEcho, too), we should probably spin the trunk regression off to a new Camino bug and leave this bug for the MS Exchange thingy (after thanking bz for finding the source of the Camino regression!).

Torben, can you test Håkan's patch against the MS Exchange bug?

Comment 20

[Boris Zbarsky [:bzbarsky]]

> Assuming it doesn't fix the  branch issue with MS Exchange

That issue is basically bug 346404, no?  Or is it something else?

Basically, I don't care much about this aspect of window targeting on the branch.  The "same window" thing is not well-supported there, and never will be.  So I'd just keep this as the bug for Camino issues...

Comment 21

[Torben]

(In reply to comment #18)
> Created an attachment (id=241169) [edit]
> Possible fix v1
> 
> Here's a possible fix, if Boris' hypothesis is correct. Can someone who is
> able to repro the bug try out the patch?

Fixes all cases (MS Exchange, bug 344808, and bug 344795) on my trunk-build.

(In reply to comment #20)
>> Assuming it doesn't fix the  branch issue with MS Exchange
>That issue is basically bug 346404, no?

Most likely, yes.

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Since the shared 1.8branch bug seems like it's not fixable within the parameters for the branch, moving this bug back to Camino to fix our Cm-only trunk regression.

Since what we're now is 1) wrong and 2) identical on the branch and trunk, I assume that for correctness's sake we want Håkan's patch on the branch, too, even if it doesn't fix the MS Exchange bug on the branch (does it fix that, or is that fix essentially bug 346404?).

Comment 23

[Håkan Waara]

(In reply to comment #22)

Yeah, we want this on the branch. What we have now is simply incorrect, we were just lucky to get away with it.

Comment 24

[Torben]

> I assume that for correctness's sake we want Håkan's patch on the branch, too,
> even if it doesn't fix the MS Exchange bug on the branch (does it fix that,

Unfortunately no :-(

Comment 25

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 241169 [details] [diff] [review]
Possible fix v1

*shrug* ok

Comment 26

[Håkan Waara]

Checked in to trunk & branch.