361909 - (flock8499) When opening a file that opens in an external application, the OK button remains grayed-out under certain circumstances

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Steve Lis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1pre) Gecko/20061125 SeaMonkey/1.1b
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1pre) Gecko/20061125 SeaMonkey/1.1b

If tab behavior is set to open links meant open in a new window in a new tab and you open a file meant that opens in an external application and is meant to open in a new window, the OK button on the dialog box that appears remains indefinitely grayed-out until:
a)the OK button is clicked once
b)a ratio button is clicked
c)the dialog box is taken out of focus and put back into focus

Reproducible: Always

Steps to Reproduce:
1. Set tab behavior to open links meant to open in a new window in a new tab
2. Click the link in the included testcase
3. Observe incorrect behavior.

Actual Results:  
The OK button remains grayed-out until one of the above actions are taken by the user.

Expected Results:  
The OK button may be grayed-out for a second, but it should automatically become active.

I assume this behavior exists because of the new feature in which a blank tab or window that is launched to open a file that opens in an external application is automatically closed by SeaMonkey. For that reason, this incorrect behavior does not exist on the 1.0 branch. The problem also does not exist on the trunk; it is only present on the 1.1 branch.

Comment 1

[Steve Lis]

Attachment: testcase

Comment 2

[Jason Bassford]

I hate to say it, but the testcase is WFM on my computer.  (Vista RTM.)  Which may well not be a fair test, since it would have changed several things.  I'll test again when I get to work where I have XP.

Comment 3

[Jason Bassford]

(It may also have something to do with the fact that the testcase uses a .zip file which automatically starts a download for me - rather than an unknown extension where the regular dialog box asking you what you want to do with it would appear.)

Comment 4

[Jason Bassford]

Okay, I finally got the testcase to function on my XP SP2 computer at work - albeit by changing the file extension from "zip" to "vss" locally so that it would not automatically start to download and, instead, ask me what to do with it.  However, the dialog box came up with the OK button enabled - it wasn't greyed out.  So, unfortunately, I can't confirm this issue on my system.

Comment 5

[Benoît]

As stated in the MozillaZine thread, I see this too. The testcase reproduces it fine.

-> CONFIRMED

Comment 6

[Steve Lis]

Attachment: testcase that links to a mpeg file

I was wondering if the zip file would cause a problem for some people. Jason, try this one with an mpeg file instead.

Comment 7

[Jason Bassford]

The .mpg attachment opens up in a video player plugin for me.  I guess I've just configured my browsers too much...

Comment 8

[Steve Lis]

What would be a format that would open in an external application for you?

Comment 9

[Jason Bassford]

That's an interesting question.  The problem is that most of the time it opens in an external application, it opens in a plugin, or it just downloads it automatically.  I almost never see the actual dialog asking me what I want to do with something.

I do recall, one time, experiencing what this bug describes - the OK button being grayed out - but that only happened once.  Yesterday, when I got the dialog to appear by clicking on a .vss link, OK was working properly.

Comment 10

[Steve Lis]

Attachment: testcase that links to an executable file

Okay, one last try; how about one that links to a .exe? I imagine that would launch the dialog box for everyone.

Comment 11

[Jason Bassford]

> I imagine that would launch the dialog box for everyone.

Sorry, it automatically downloads for me... <sigh>

Comment 12

[Jason Bassford]

Aha!  I had some luck reproducing this with a link to a PDF file at work.  I got the "what do you want to do" dialog with "Open in default application" selected but the OK button grayed out.

Comment 13

[Matthew (lilmatt) Willis]

I can reproduce this using Fx on Mac.

Product -> Fx
HW/OS -> all

This is also Flock #8499
https://bugzilla.flock.com/show_bug.cgi?id=8499

Taking this to push our fix upstream.

Comment 14

[Matthew (lilmatt) Willis]

Attachment: Adds nsITimer to prevent race condition

Comment 15

[Shawn Wilsher :sdwilsh]

I'm willing to bet this is a duplicate of Bug 353407, but seeing as how this one has a patch, I think I'll do it the other way around.

Anyway, there is another file you should probably update as well:
http://mxr.mozilla.org/seamonkey/source/embedding/components/ui/helperAppDlg/nsHelperAppDlg.js

Comment 17

[Lech Deregowski [:lech]]

Just a confirmation that this one still exists in 2.0.0.5 and aware it's being remedied. Almost filed a new one, so I figured that Bug 313692, Bug 284579 and Bug 378169 can also be marked as duplicates of this one as they're mostly relevant.

Comment 18

[Mike Connor [:mconnor]]

Missing the freeze, moving out.

Comment 19

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

Comment on attachment 270824 [details] [diff] [review]
Adds nsITimer to prevent race condition

I haven't been able to reproduce this problem, but Joshua@flock has managed to reproduce the issue and has tested this fix. I'd like to be able to look into the core issue further, but not being able to reproduce makes that hard. r=me if you make the same changes to the embedding file per comment 15.

(When testing, I also saw some strange behavior on Mac with blur events firing at strange times, that probably deserves a new bug.)

Comment 20

[Bart Szyszka]

Can we bump up the severity of this bug? To me it seems to be a serious usability issue. I'm trying to download a file and the interface is telling me that I can't ("OK" is grayed out) and in order to continue I have to go against what the interface is saying and click anyway. Downloading files from web pages is a big part of the browser experience.

I've been in a meeting in a room full of people and got a laugh when I told my boss that he has to click on the grayed out OK button to make the option enabled and then click OK to finally have it go through. This meeting was in a conference room that only has Windows and I'm at home on a Mac always experiencing this problem (with PDFs in particular) pretty frequently.

Comment 21

[Matthew (lilmatt) Willis]

Patch landed on trunk.

-> FIXED

Comment 22

[Steve Chapel]

I'm still seeing this bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082305 Minefield/3.0a8pre if Firefox is not the active application when the dialog appears. I can reproduce by clicking on a link to a file that will opens dialog, then quickly switching to another application before the dialog appears.

Comment 23

[Daniel Veditz [:dveditz]]

This sounds like more of a cosmetic problem and isn't a regression, so doesn't meet the blocking standards. You can ask for approval on the patch anyway, but the fact that comment 22 claims it's not always fixed on trunk makes me a little nervous.

qawanted: please verify this fix on trunk, and investigate comment 22

Comment 24

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

(In reply to comment #22)
> I'm still seeing this bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9a8pre) Gecko/2007082305 Minefield/3.0a8pre if Firefox is not the active
> application when the dialog appears.

Does the button become enabled again when you focus the dialog? If so, that's expected behavior - see bug 260560.

Comment 25

[Shawn Wilsher :sdwilsh]

If people are still seeing the symptoms, they could very well be seeing Bug 264492.  However, I think this is the primary cause for most people who get the OK button disabled (I've hit it several times myself on branch).

Bug 353407 was the original bug, but then this bug had a patch so it got duped to this.  Looking at that bug you can see that a lot of people file bugs about this issues and I think it would be a good idea to port it back...

Comment 26

[Steve Chapel]

(In reply to comment #24)
> Does the button become enabled again when you focus the dialog? If so, that's
> expected behavior - see bug 260560.

Yes, when I test, the OK button is enabled very shortly after focusing the
dialog. So it looks like the problem really is fixed.

(In reply to comment #23)
> This sounds like more of a cosmetic problem and isn't a regression, so doesn't
> meet the blocking standards. You can ask for approval on the patch anyway...

It's more than cosmetic. I set someone up with Firefox, and within days she
approached me asking about this behavior. I had to explain the workaround to
click on OK to enable it, then click again. I've asked for approval to get this
checked into Firefox 2.

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 270824 [details] [diff] [review]
Adds nsITimer to prevent race condition

No answer to comment 23. Did this get verified on trunk? This code changed a lot between trunk and branch, is this the right branch patch?

Comment 28

[Shawn Wilsher :sdwilsh]

Not a regression - just a very frequently reported issue.

Comment 31

[Boris Zbarsky [:bzbarsky]]

This might have caused leak bug 417949.

Comment 32

[Stephen Donner [:stephend] Not actively reading bugmail]

And, see bug 410477, a case in which it still fails on branch.