Closed Bug 361909 (flock8499) Opened 13 years ago Closed 12 years ago
When opening a file that opens in an external application, the OK button remains grayed-out under certain circumstances
467 bytes, text/html
427 bytes, text/html
492 bytes, text/html
5.27 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20061125 SeaMonkey/1.1b Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) 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.
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.
(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.)
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.
As stated in the MozillaZine thread, I see this too. The testcase reproduces it fine. -> CONFIRMED
Status: UNCONFIRMED → NEW
Ever confirmed: true
I was wondering if the zip file would cause a problem for some people. Jason, try this one with an mpeg file instead.
The .mpg attachment opens up in a video player plugin for me. I guess I've just configured my browsers too much...
What would be a format that would open in an external application for you?
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.
Okay, one last try; how about one that links to a .exe? I imagine that would launch the dialog box for everyone.
> I imagine that would launch the dialog box for everyone. Sorry, it automatically downloads for me... <sigh>
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.
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.
Assignee: download-manager → lilmatt
OS: Windows XP → All
Product: Mozilla Application Suite → Firefox
Hardware: PC → All
Target Milestone: --- → Firefox 2
Version: 1.8 Branch → 2.0 Branch
Attachment #270824 - Flags: review? → review?(gavin.sharp)
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
Target Milestone: Firefox 2 → Firefox 3 beta1
Flags: blocking-firefox3? → blocking-firefox3+
Just a confirmation that this one still exists in 220.127.116.11 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.
Missing the freeze, moving out.
Target Milestone: Firefox 3 M7 → Firefox 3 M8
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.)
Attachment #270824 - Flags: review?(gavin.sharp) → review+
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.
Patch landed on trunk. -> FIXED
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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.
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
Flags: blocking18.104.22.168? → blocking22.214.171.124-
(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.
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...
(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 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?
Attachment #270824 - Flags: approval126.96.36.199? → approval188.8.131.52-
Not a regression - just a very frequently reported issue.
This might have caused leak bug 417949.
And, see bug 410477, a case in which it still fails on branch.
You need to log in before you can comment on or make changes to this bug.