Download manager window refuses to close after an image is saved

VERIFIED DUPLICATE of bug 243324

Status

()

Toolkit
Downloads API
--
major
VERIFIED DUPLICATE of bug 243324
13 years ago
9 years ago

People

(Reporter: Clint Hamilton, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: FireFox .9.3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) 

Every time any image is right clicked and saved, the "download status" box 
stays open and will not close until you manually close it.  (Yes, "close the 
download manager when all downloads are complete" IS CHECKED).

Reproducible: Always
Steps to Reproduce:
1.  Right click any image and "Save image as".
2.  Click "Save" to save to any folder
3.  Download status box will not close

Actual Results:  
See above.

Expected Results:  
Automatically close the download status box the same way when FILES are 
downloaded.

Comment 1

13 years ago
This could be a dupe of bug 243324
(In reply to comment #1)
> This could be a dupe of bug 243324

Yes, I'm sure. I always can see that behavior when having the closing pref enabled.

*** This bug has been marked as a duplicate of 243324 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 3

13 years ago
(In reply to comment #2)
> (In reply to comment #1)
> > This could be a dupe of bug 243324
> Yes, I'm sure. I always can see that behavior when having the closing pref 
enabled.
> *** This bug has been marked as a duplicate of 243324 ***

No, it's not a duplicate.  They didn't mention it happens to IMAGES, ALL of the 
time, and it only happens with IMAGES in this thread, plus I also don't have 
the problem with the small file sizes.  I only have it when saving images, and 
images of ANY size.

Comment 4

13 years ago
No. This IS a duplicate. If the image is big enough (in terms of file size), you
won't see the bug.
(Reporter)

Comment 5

13 years ago
(In reply to comment #4)
> No. This IS a duplicate. If the image is big enough (in terms of file size), 
you
> won't see the bug.

Who's computer is it, mine or yours?  See this:
https://bugzilla.mozilla.org/show_bug.cgi?id=243324
It happens on LARGE IMAGES as well.

How big are these images?

Comment 7

13 years ago
Chris, three people have already told you it's a dupe. I'm going to be the
fourth. Please read this carefully:

https://bugzilla.mozilla.org/show_bug.cgi?id=243324#c5

The the problem has nothing to do with filesize, but rather with download time.
Since your images are cached, there is zero download time, so it has the same
effect as a "small" download.

I'm verifying resolution.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

13 years ago
(In reply to comment #7)
> Chris, three people have already told you it's a dupe. I'm going to be the
> fourth. Please read this carefully:
> https://bugzilla.mozilla.org/show_bug.cgi?id=243324#c5
> The the problem has nothing to do with filesize, but rather with download 
time.
> Since your images are cached, there is zero download time, so it has the same
> effect as a "small" download.
> I'm verifying resolution.


It's "Clint".  Ok, if you're saying that even though the fact that it ONLY 
happens to me on ALL IMAGES, even LARGE ones, and **NOT with small files** 
(like exe, zip, etc.), please explain how this can be a duplicate.  Also please 
explain what the "resolution" is.
Thank you.

Comment 9

13 years ago
Sorry, Clint, my bad.

It's a duplicate because the other bug's summary is a little misleading. It has
to do with the *time* it takes to download a file, not it's size. Understand
that downloading a small file and saving an image that you've already downloaded
both take very little time. Hence they can suffer from the same bug.

As I said, this is all well laid out in bug 243324 comment 5. The resolution of
*this* bug is that it is a duplicate of bug 243324. If you want to know more
about Bugzilla resolutions, you can see here:

https://bugzilla.mozilla.org/bug_status.html
(Reporter)

Comment 10

13 years ago
(In reply to comment #6)
> How big are these images?

Hello, it's happening on images about ~100k in size.  I call that a "large 
image".  However, to test this I just uploaded a very large 1.4mb image and 
when I saved it, I DID NOT have the problem with it.  So thanks for pointing 
that out.  I'm not sure where the "cut off" point in size would be from having 
the problem to not having the problem.  So for accuracy sake I need to update 
my comments to say it's not happening with me on very large images (like 1.4mb 
in this case).
Thanks again.

(Reporter)

Comment 11

13 years ago
(In reply to comment #9)
> Sorry, Clint, my bad.
> It's a duplicate because the other bug's summary is a little misleading. It 
has
> to do with the *time* it takes to download a file, not it's size. Understand
> that downloading a small file and saving an image that you've already 
downloaded
> both take very little time. Hence they can suffer from the same bug.
> As I said, this is all well laid out in bug 243324 comment 5. The resolution 
of
> *this* bug is that it is a duplicate of bug 243324. If you want to know more
> about Bugzilla resolutions, you can see here:
> https://bugzilla.mozilla.org/bug_status.html

Ok thank you.  I was hoping you meant it had been "resolved" as in fixed.  I'm 
still not clear on why it does not happen to me with small file sizes that 
download *INSTANTLY*.  This is not covered on the so called "dupe" ID's.  I 
reiterate; it ONLY happens to me on images (ones so far that are 100k or less), 
yet I can d'load a infinitesimal file of 1k and the window does not remain open 
on it.  If you STILL call that a dupe, then I accept your definition, but it's 
really not fully accurate.  ;-)

You or someone mentioned earlier about images being cached, therefore the issue 
still existing with large images, which makes sense.  But evidently the caching 
isn't it since (see my last post above), I don't didn't have the problem with a 
huge 1.4mb image, yet it was "cached" I guess since it was fully displayed.  
BTW, in case I didn't mention it, I don't notice this problem on 1.0PR, only 
on .9.3.

Comment 12

13 years ago
To be honest, I'm not seeing either of the bugs. Sometimes some people see bugs
when others do not. Sometimes other people see bugs exhibit in slightly
different ways. It's odd like that.

Bug reporting is not often as exact a science as one would hope, and some (a
little) variation in the way bugs exhibit is not uncommon.
(Reporter)

Comment 13

13 years ago
(In reply to comment #12)
> To be honest, I'm not seeing either of the bugs. Sometimes some people see 
bugs
> when others do not. Sometimes other people see bugs exhibit in slightly
> different ways. It's odd like that.
> Bug reporting is not often as exact a science as one would hope, and some (a
> little) variation in the way bugs exhibit is not uncommon.

Are you using FF .9.3?  If so, perhaps you did a "tweak" somewhere to fix this 
behavior?  Or, are you on a slow dial-up connection?  It's feasible that those 
on fast broadband connections (I am) could see this problem more so than those 
on slow connections due of course to the differences in d'load speeds.

Comment 14

13 years ago
I'm using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041022 Firefox/1.0

I don't think I'm using any tweaks. I'm on a slow connection right now, but I
don't recall seeing this on fast connections either.

If you'd like to discuss this further, you can often find me (aebrahim) on
#firefox on irc.mozilla.org. I'd be happy to discuss this with you or help you
learn about how Bugzilla works, and where else you can find support. If I'm not
around, someone else can help you.
(Reporter)

Comment 15

13 years ago
(In reply to comment #14)
> I'm using:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041022 
Firefox/1.0
> I don't think I'm using any tweaks. I'm on a slow connection right now, but I
> don't recall seeing this on fast connections either.
> If you'd like to discuss this further, you can often find me (aebrahim) on
> #firefox on irc.mozilla.org. I'd be happy to discuss this with you or help you
> learn about how Bugzilla works, and where else you can find support. If I'm 
not
> around, someone else can help you.

Ok, if that list bit "Gecko/20041022 Firefox/1.0" denotes 1.0PR, then that may 
explain why you don't see it.  I indicated this only happens (in my case) 
on .9.3, I don't have it on my 1.0PR install.

Thank you, I appreciate it.  Could you please tell me how one can subscribe to 
certain bug reports to get updates on them?  I didn't see things pertaining to 
this under Account settings.  I'm wondering if there is a way to receive 
notifications to specific reports.  I'm only getting the notifications for 
maybe 3 threads now.
Thanks again.
(In reply to comment #15)
> 
> Thank you, I appreciate it.  Could you please tell me how one can subscribe to 
> certain bug reports to get updates on them?  I didn't see things pertaining to 

Please stop asking questions here which don't belong to this bug. Do this over
personal mails or irc but don't spam bugzilla for that. Thank you. 

But anyway: You have to input your address into the cc field before submitting
the form.
Henrik: that's a bit harsh. Everyone has to learn sometime. If this bug had a CC
list of 20 people, it might be a bit more serious. But until we improve the
Bugzilla interface so that it's obvious how to do everything, such questions
are, IMO, reasonable.

Gerv
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.