Closed Bug 243324 Opened 20 years ago Closed 19 years ago

Download manager fails to close with files that download very quickly (small files / cached files)

Categories

(Toolkit :: Downloads API, defect, P3)

Product:
Toolkit
Component:
Downloads API
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8final

People

(Reporter: RyanVM, Assigned: bugzilla)

References

Details

(Keywords: fixed1.8)

Attachments

(1 file, 6 obsolete files)

patch with nit addressed
2.81 KB, patch
bugzilla
: review+
asa
: approval1.8b4+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040503 Firefox/0.8.0+ (Darkstar)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040503 Firefox/0.8.0+ (Darkstar)

When downloading small files, Download Manager tends to not close.  I think this
is because it finishes downloading the file before I have a chance to save
(since it starts downloading before being given a save to location), so DM
doesn't get whatever flag it's supposed to get telling it the download is
finished and the window should be closed.

Reproducible: Always
Steps to Reproduce:
1. Download a small (~30k) file
2. Choose Save To location
Actual Results:  
Download Manager shows the download as complete when it pops up and the window
remains open.

Expected Results:  
It should have closed the window upon seeing no active downloads.

This has occured with nightlies over the last few weeks.
Flags: blocking1.0?
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040518 Firefox/0.8.0+ (Darkstar)

Still happens with the newest build.
I'm not sure if bug 246165 is a duplicated o this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=246165
(In reply to comment #2)
> I'm not sure if bug 246165 is a duplicated o this bug:
> http://bugzilla.mozilla.org/show_bug.cgi?id=246165

It looks to be a manifestation of this issue to me.  Again, the file's already
finished prior to being saved, so the download manager doesn't quit.

Also, problem still occurs on the newest build.
Flags: blocking1.0? → blocking1.0+
Priority: -- → P3
I've noticed this problem too, in fact was just about to file a new bug report.
Thank goodness I searched first. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Bug 246165 is remarkably similar to this one. The cause of the bug is that the
file being downloaded is either:

A) Being saved too quickly (because it's a small file, this bug)
B) Already in cache (therefore also being saved too quickly, which is bug 246165)

In both of these cases the download manager is somehow not noticing tht the
download ended, and therefore is not closing its window. I'm duping it for now,
someone with more knowledge of the inner workings of the download manager (ben?)
would have to look at this to confirm though. Bug 246165 can always be reopened
 if it turns out to not be the same issue.
*** Bug 246165 has been marked as a duplicate of this bug. ***
This does not only occur about 50% of the time when saving images
but also when clicking on music samples on sites such as amazon.com.
In addition to RealPlayer opening and playing the selected file,
an empty Downloads window pops up that has to be clicked away.
Very annoying.
This happens on Linux too, so it's not OS specific.
OS: Windows XP → All
The problem definitely seems to be triggered by the download actually finshing
before you provide the save location.  How do I know? Becuase I have had this
happen even with large files if I started the download and then got interrupted
by someone in my office and don't get around to giving it rhe save location for
5 or ten minutes.
Not a "blocker"
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Blocks: 262161
No longer blocks: 262161
Correct me if I'm wrong, but since the bug the bug about "Download Manager not
staying open after download completes" has been fixed, ie - Download Manager
ALWAYS stays open now after downloads complete... wouldn't that make this bug
useless?
always remaining open is incorrect behavior.  There is an explicit configuration
option ("Close the Download Manager when all downloads are complete") for the
opposite behavior.

So far, nobody has said that this option should be deleted (and I think a great
many users, myself included, would object to removing it.)

This bug is still quite valid.
(In reply to comment #11)
> Correct me if I'm wrong, but since the bug the bug about "Download Manager not
> staying open after download completes" has been fixed, ie - Download Manager
> ALWAYS stays open now after downloads complete... wouldn't that make this bug
> useless?

That's a different issue. This bug is for when files finish downloading prior to
have a destination folder selected, so the download manager doesn't even realize
that it's done downloading.
I'm not seeing this bug in the last week or so's nightlies. Files that finish
downloading in the background before a destination directory no longer pop up
the download manager it appears.

Can anybody else confirm that the problem appears to be fixed?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041008
Firefox/0.10 (MOOX M2)
Did it this morning with build 20041006 (Aviary) for Windows. Not fixed yet.
This bug is highly annoying. Under Tools > Options > Downloads > File Types

Set .pls files to automatically open with your favorite media player (I use
winamp) then go to www.shoutcast.com and click tune-in on any station, the
download manager doesn’t close.
I've noticed this too.
Adding self to Cc list.
I noticed this as well. I disabled the download manager from popping up 
automatically in about:config since I often save small files and it was quite 
an annoyance
Download popup won't get closed automatically, when you have selected 'Save As'
option. I tried this with the version compiled with GTK2 on Linux i586.
This is still happening for me with the latest nightly build

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0
This bug also happened in trunk builds.
*** Bug 265948 has been marked as a duplicate of this bug. ***
(In reply to comment #22)
> *** Bug 265948 has been marked as a duplicate of this bug. ***

Again, 265948 is not the same thing.
https://bugzilla.mozilla.org/show_bug.cgi?id=265948
As stated there, I'm having the issue with ALL images, REGARDLESS of size, yet 
I don't have the problem when saving small files.  Also, maybe I should clarify 
it's NOT that popup at lower right that tells you "download has completed" or 
whatever it says (I disabled that annoyance via about:config).  I'm speaking of 
the box/window that pops up at upper left showing the download PROGRESS 
information (speed, amount remaining, etc.) and it has on the bottom of it 
the "Options" button and "Cleanup" button.  Window title is "Downloads".  This 
is what will not close for me unless you manually close it, and the window is 
blank, nothing in it.


(In reply to comment #23)
> Again, 265948 is not the same thing.

Please see my comments here:
https://bugzilla.mozilla.org/show_bug.cgi?id=265948#c7
It would be nice to be able to limit the popup of the download manager to files
bigger than X kb. It's not really useful to watch the progress of a 2kb download.
Tweaking summary/whiteboard.
Summary: Download manager fails to close with small files → Download manager fails to close with files that download very quickly (small files / cached files)
Whiteboard: Please read comment 5 before commenting
(In reply to comment #26)
> Tweaking summary/whiteboard.

Could you please explain what that means?  Does that mean that's how to do what 
comment #25 mentioned, or does that refer to something else?  (Yep, I've only 
used FF for about two weeks now so FAIK, "Tweaking summary/whiteboard" could 
be  a part of FF!).
Thanks.


No, it has nothing to do with comment 25. It's a Bugzilla thing, not a function
of Firefox.

*Please* don't ask general questions in bugs. This is not the correct forum for
that at all. Feel free to come to irc.mozilla.org and join #firefox or
#mozillazine and get all the help you need. But please don't ask general
questions in bugs on Bugzilla. Bugzilla is a bug-tracking system, not a user
support forum. Thanks.

If you continue to ask questions in bugs, your Bugzilla account will eventually
get revoked.
(In reply to comment #28)
> No, it has nothing to do with comment 25. It's a Bugzilla thing, not a 
function
> of Firefox.
> *Please* don't ask general questions in bugs. This is not the correct forum 
for
> that at all. Feel free to come to irc.mozilla.org and join #firefox or
> #mozillazine and get all the help you need. But please don't ask general
> questions in bugs on Bugzilla. Bugzilla is a bug-tracking system, not a user
> support forum. Thanks.
> If you continue to ask questions in bugs, your Bugzilla account will 
eventually
> get revoked.

I AM a member of Mozillazine and THEY tell me to come HERE!!  F**k this $h!t.  
Trying to learn about FF bugs isn't worth this BS.  I've been browsing bugs 
here for DAYS and I see PLAIN CONVERSATIONS ALL THE TIME WITH basic Q & A on 
these threads, so don't tell me this is "not the place to ask questions"!!  
What hell do you think most do here??  What the hell do you expect me to do, 
just "browse and read" and that's IT????  But Oh noooooo, it's perfectly OK for 
ANYONE ELSE to ask questions, just not ME!!!!  I've tried to be kind to you, 
but you are REALLY ON MY LAST NERVE!!!!  NOW LEAVE ME THE F**K ALONE JERK!!!!!  
YOU are the one making things worse with your condescending & holier than thou 
attitude!!!  If *YOU* don't become a bit more diplomatic and understanding, and 
not so PROVOKING, it is YOU that  will "eventually get revoked"!!!  GET A LIFE 
AND STOP "TAGGING ALONG" behind me like a lost child!!!!  What the HELL have I 
ever done to you!!??????

I'm about to "head on over" to https://bugzilla.mozilla.org/show_bug.cgi?
id=248330 if you'd like to "tag along" and slam me there as well!!  C'mon!!  I 
guess now I'll also have "your comments" to look forward to at Mozillazine!!

And for your FUTURE comments (which I'm SURE will continue) email them TO ME 
PERSONALLY and NOT on these threads!!
Sorry Clint, I don't think you should remove the CC list here. Also, please
behave yourself.
*** Bug 266094 has been marked as a duplicate of this bug. ***
(In reply to comment #30)
> Sorry Clint, I don't think you should remove the CC list here. Also, please
> behave yourself.
I'm not sure how the CC list worked.  My intention was one out of courtesy to 
sub'ers of this thread so they would not get the emails from "Ali" and my 
defense of them.  Sorry if that messed things up.  I'll "behave" myself when 
ALI BEHAVES HIMSELF and leaves me ALONE.  Hopefully that BS is over now.  :-)  
In all fairness you should have told the same to HIM, but I guess he's buddy of 
yours.  

(In reply to comment #32)
> (In reply to comment #30)
> > Sorry Clint, I don't think you should remove the CC list here. Also, please
> > behave yourself.
> I'm not sure how the CC list worked.  My intention was one out of courtesy to 
> sub'ers of this thread so they would not get the emails from "Ali" and my 
> defense of them.  Sorry if that messed things up.  I'll "behave" myself when 
> ALI BEHAVES HIMSELF and leaves me ALONE.  Hopefully that BS is over now.  :-)  
> In all fairness you should have told the same to HIM, but I guess he's buddy of 
> yours.  
> 

I've debated whether or not to reply to this whole exchange, but I feel this
needs to be said (and this will be the only non-bug related reply I make in this
thread).

Ali is a MOZILLA DEVELOPER. You aren't. When people post bugspam, it's people
including himself who have to wade through it. He politely asked you to not do
that anymore, and you flew off the handle. I don't think it's at all
unreasonable to expect people new to Bugzilla to learn the rules of engagement
rather than whining and complaining because a maintainer of Bugzilla asks you
to. You say he singled you out - maybe it has to do with the fact that the bugs
you happened to reply to are ones either assigned to him or that he's on the CC
list of.

Your actions toward the CC list only go to show just how little you know about
the system, so who are you to start telling other more experienced people who
are trying to keep the bug discussion on track how to do their jobs?

OK, I've said what I wanted to say. If you have a problem with what I said
Clint, please take it to email so we don't waste further space in this bug
discussing the matter.
Clint and I have sorted this out over email, and I think I speak for both of us
when I say that the matter is closed and behind us. Let's forget that it
happened, and get back to our usual bugzilla routines.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Attached patch pass openDelay variable by value (obsolete) — — Splinter Review 
A local variable is being passed to the init timer callback function, resulting
in random openDelay values in the callback function. This patch changes the
parameter to be passed by value instead.
Attachment #163762 - Flags: review?(bryner)
forgot to add, you'll need to set the preference
browser.download.manager.openDelay to a value > 0 for it ignore files. If it is
set to 0, then it will always open the download manager window. 
Comment on attachment 163762 [details] [diff] [review]
pass openDelay variable by value

I had a re-look at this and this patch is incomplete. It only solves the
problem of small files causing the download manager to open randomly when
starting a download.

If the pref openDelay is set to 0 and closeWhenDone is set to true, the later
is still ignored.
Attachment #163762 - Flags: review?(bryner)
Don't open download window when closeWhenDone is true and the download is
complete.
Attachment #163762 - Attachment is obsolete: true
Attachment #164712 - Flags: review?(bryner)
tweak logic check and add pref null check
Attachment #164712 - Attachment is obsolete: true
Attachment #164712 - Flags: review?(bryner)
Attachment #164720 - Flags: superreview?(bugs)
Attachment #164720 - Flags: review?(bryner)
Re-requesting blocking - have patch.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
*** Bug 265093 has been marked as a duplicate of this bug. ***
interesting i've never seen this problem though i have had it never open up the
download manager when its a really small download i have it set to leave the
download manager open after a download and it never even opens on really small ones
removed trailing blank lines
Attachment #164720 - Attachment is obsolete: true
Attachment #164720 - Flags: superreview?(bugs)
Attachment #164720 - Flags: review?(bryner)
Attachment #164976 - Flags: superreview?(bugs)
Attachment #164976 - Flags: review?(bryner)
Flags: blocking-aviary1.0?
Attachment #164976 - Flags: superreview?(bugs)
Attachment #164976 - Flags: review?(bryner)
patch created against trunk
Attachment #164976 - Attachment is obsolete: true
Attachment #165755 - Attachment description: check closeWhenDone pref before opening download window (v3) → check closeWhenDone pref before opening download window (v4)
Attachment #165755 - Flags: review?(bryner)
Patch doesn't work for me on linux (debian).
Tracing in the OpenTimerCallback function show that when it is called, the
completeness counter is still at 0, so the patch has no effect.
Attachment #165755 - Flags: review?(bryner)
Hmm... I just tested this again with the latest build and it seems to work fine,
download manager opening and closing as expected.

The only behaviour which could be contrary is the saving of an image. In this
case, the download window never opened even when the Close When Down was
uncheck, however, I like it this way.

Was this a branch only bug?
(In reply to comment #46)
> Tracing in the OpenTimerCallback function show that when it is called, the
> completeness counter is still at 0, so the patch has no effect.

I tested the patch on saving images from webpages. The completeness counter for
these were often 100% and 9/10 times the download window would open regardless
of the close when complete pref option.
Attachment #164976 - Attachment is obsolete: false
An extra note: The download window actually _does_ close when you download the
_next_ item. This is _very_ disconcerting (and annoying) and still there in the
1.0 version.
I can't reproduce it systematically, but I had a vew cases where the fact that
the d/l window remained open blocked clicking on other d/l links.

Greetings
John
Lots of branch changes will be landing on the trunk in the near future, so don't
close branch-only bugs quite yet...
*** Bug 271532 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 272827 has been marked as a duplicate of this bug. ***
*** Bug 274316 has been marked as a duplicate of this bug. ***
needs aviary landing keyword
Flags: blocking-aviary1.1?
the same happens with firefox 1.0 under fedora core 3, redhat linux 9, redhat
linux ES 3, windows 2000 sp3 and windows XP sp0, 1 and 2
*** Bug 280301 has been marked as a duplicate of this bug. ***
*** Bug 268997 has been marked as a duplicate of this bug. ***
Just tested this with two large files (90-100 MB) and the Download Manager is
*not* closed when downloads finished. First one was finished before starting new
one.

Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.5) Gecko/20041221 Firefox/1.0
*** Bug 284370 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Attachment #164976 - Attachment is obsolete: true
Comment on attachment 165755 [details] [diff] [review]
check closeWhenDone pref before opening download window (v4)

Re-tested patch with the latest trunk and found it still worked okay.

Hopefully someone will get a chance to look at it this time around.
Attachment #165755 - Flags: review?(mconnor)
*** Bug 279796 has been marked as a duplicate of this bug. ***
*** Bug 289222 has been marked as a duplicate of this bug. ***
This bug is about a year old now... any updates on when/if the fix patch will be
put in place soon?
As the bug is marked blocking-aviary1.1+ it should be expected to happen...
well, by 1.1.
... or sooner if anyone would check Son Le's patch in =)
please, don't spam bugzilla. The patch waits for a review. If you can't read it
from this bug sheet, you should learn Bugzilla a bit.
I am having the opposite problem.  Download manager window does not open when a
small file is downloaded.
Replying to comment #67:
>I am having the opposite problem.  Download manager window does not open when a
>small file is downloaded.

Are you sure you have checked *both* Download Manager checkboxes in the Download
preferences tab?

JR Baas, the download manager not opening when very small files are downloaded
is as designed, I believe, because popping up the dlmgr and immediately closing
it before you manage to really see anything would just be distracting. If there
are issues with that behavior, they should be handled in a separate bug report.
*** Bug 290595 has been marked as a duplicate of this bug. ***
*** Bug 293341 has been marked as a duplicate of this bug. ***
Comment on attachment 165755 [details] [diff] [review]
check closeWhenDone pref before opening download window (v4)

I was still able to trigger this bug with this patch.  I never had time to
debug why though.
Attachment #165755 - Flags: review?(mconnor) → review-
No longer blocks: majorbugs
Assignee: bugs → mconnor
WHEN are you people at this website going to REMOVE THE DAMN EMAIL ADDRESSES 
from user's names!!!  Thanks to this website, I get NOTHING BUT SPAM on an 
email address I created **ONLY FOR** this website!!  You have no business 
publishing members' email addresses out in the open for every scumbag spambot 
email harvesting parasite on the internet!
WHEN are you people at this website going to REMOVE THE DAMN EMAIL ADDRESSES 
from user's names!!!  Thanks to this website, I get NOTHING BUT SPAM on an 
email address I created **ONLY FOR** this website!!  You have no business 
publishing members' email addresses out in the open for every scumbag spambot 
email harvesting parasite on the internet!
Thank you!!
Simply remove yourself from the CC list and stop bug spamming. :-S
If you look at the source code for the page, you'll notice that Bugzilla
obfuscates the e-mail addresses, but in a way that ends up looking the same to
the user. Whether harvester bots are smart enough to get around that I don't know.
(In reply to comment #69)
> JR Baas, the download manager not opening when very small files are downloaded
> is as designed, I believe, because popping up the dlmgr and immediately closing
> it before you manage to really see anything would just be distracting. If there
> are issues with that behavior, they should be handled in a separate bug report.

Still it seems related. I hate it when the download manager does not open, cause
then I have to move my mouse to the popup in the bottom right corner, click on
the link to open the download manager, move back to the download manager and
finally click to open the file.

Whereas if the download manager correctly opened, I would just have to move and
click "open".



Exactly. Otherwise I first have to browse to the folder where I saved the file
and then open it.
Exactly. Otherwise I first have to browse to the folder where I saved the file
and then open it. Annoying. There should be a pref to change this behavior.
ok, it sounds reasonable that when the "Close the dlmgr when downloads complete"
pref is set, the dlmgr should be opened for the very shortest downloads also,
since "it would go away right away anyway" doesn't apply. that's orthogonal to
this bug report though, search for / file another.
> ok, it sounds reasonable that when the "Close the dlmgr when downloads complete"
> pref is set, the dlmgr should be opened for the very shortest downloads also,
          ^^^ not set, that is :)
July 1st 2005.
Download window remains open 3 times of 4 after saving images from websites.
It's set to close when download finished, but it doesn't close.
This is still a problem in FF 1.04 / Win2000sp4, WinXPsp2 and Win2003.
It's very annoying.
July 1st 2005.
Download window remains open 3 times of 4 after saving images from websites.
It's set to close when download finished, but it doesn't close.
This is still a problem in FF 1.04 / Win2000sp4, WinXPsp2 and Win2003.
It's very annoying.
*** Bug 278199 has been marked as a duplicate of this bug. ***
*** Bug 302917 has been marked as a duplicate of this bug. ***
(In reply to comment #72)
> (From update of attachment 165755 [details] [diff] [review] [edit])
> I was still able to trigger this bug with this patch.  I never had time to
> debug why though.

Mike, can you elaborate on this a little? I just built Firefox (20050805) with
this patch and I've been unable to reproduce the bug.
Attached patch possible fix (obsolete) — — Splinter Review 
Looks like the patch by Son Le is good, but I don't think it handles the case
where downloads finish after the checks in
nsDownloadManager::OpenTimerCallback, but before Startup() completes in
downloads.js.

My simple fix for this is to add autoClose() at the end of Startup() in
downloads.js, to ensure that the DM only remains open at this point if there
are pending downloads.
Attachment #165755 - Attachment is obsolete: true
Attachment #191877 - Flags: review?(mconnor)
Testcase: http://indigodragyn.com/wall/middle-b.jpg
For some reason this triggers the bug quite frequently for me. Not reproducable
with the above patch.
URL: http://indigodragyn.com/wall/middle-b...
Comment on attachment 191877 [details] [diff] [review]
possible fix

>+  if (pref) {
>+    pref->GetBoolPref(PREF_BDM_CLOSEWHENDONE, &closeDM);
>+  }

nit: brackets

looks good, please make sure to get testing on Windows/Linux/Mac before
requesting approval for checkin.
Attachment #191877 - Flags: review?(mconnor) → review+
Addresses above nit (removing braces). Carrying over review. I'll go get some
third-party builders to check this out.
Assignee: mconnor → cusser.bugs
Attachment #191877 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #191956 - Flags: review+
(In reply to comment #90)
> Created an attachment (id=191956) [edit]
> patch with nit addressed
> 
> Addresses above nit (removing braces). Carrying over review. I'll go get some
> third-party builders to check this out.

This patch works on Linux.


Comment on attachment 191956 [details] [diff] [review]
patch with nit addressed

Tested on Win32, Linux and MacOS (thanks to those that helped). Seeking
approval for 1.8b4 and checkin.
Attachment #191956 - Flags: approval1.8b4?
I have been extensively testing Cusser's patch on Win2000 for a few days now.
The DM in Fx 1.0.6 doesn't close 18% of the time (I kept a list). This was on
several hundred files.
With Cusser's DPa2 build with his patch in it, the DM closed every single time
(on the same several hundred files).
Attachment #191956 - Flags: approval1.8b4? → approval1.8b4+
URL: http://indigodragyn.com/wall/middle-b...
Whiteboard: Please read comment 5 before commenting → [checkin needed]
Trunk:

Checking in mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.48; previous revision: 1.47
done
Checking in components/downloads/src/nsDownloadManager.cpp;
/cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,v  <--
nsDownloadManager.cpp
new revision: 1.54; previous revision: 1.53
done

1.8 Branch:

Checking in toolkit/components/downloads/src/nsDownloadManager.cpp;
/cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,v  <--
nsDownloadManager.cpp
new revision: 1.53.2.1; previous revision: 1.53
done
Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.47.2.1; previous revision: 1.47
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Target Milestone: --- → Firefox1.5
Version: unspecified → Trunk
Should the + from the blocking 1.5 field be taken off now that it is "fixed" in
order to be consistent with how it is done in other bugs?
(In reply to comment #95)
> Should the + from the blocking 1.5 field be taken off now that it is "fixed" in
> order to be consistent with how it is done in other bugs?

Potentially, but there's little benefit to doing so. People generally don't
search for fixed blockers unless they want a list of fixed blockers. AFAIK, the
only things that should be removed when a bug is fixed are keywords and
nominations that no longer serve a purpose. 

It looks like Gavin took care of the necessary bits when he resolved the bug
(thanks for doing so).
Thanks for fixing this very annoying thing.
Flags: blocking-aviary1.5+
Finally! :)
please don't remove the blocking-aviary1.5+ flags after the bug has been fixed.
we havent done this with any other past release so please don't start now, it
makes it very very hard for me to track the fixed blockers for my threads
http://forums.mozillazine.org/viewtopic.php?p=1423189
http://www.neowin.net/forum/index.php?act=ST&f=112&t=269046&st=0#entry585262900
and my website http://www.supernova00.biz/road-to-firefox-1.5.html
(In reply to comment #99)
> please don't remove the blocking-aviary1.5+ flags after the bug has been fixed.
> we havent done this with any other past release

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=
allwordssubstr&short_desc=&product=Firefox&long_desc_type=substring&long_desc=
&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=
allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=
FIXED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=
normal&bug_severity=minor&bug_severity=trivial&bug_severity=
enhancement&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=
1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=
include&bug_id=&votes=&chfieldfrom=2005-08-01&chfieldto=Now&chfieldvalue=
&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=
flagtypes.name&type0-0-0=anywordssubstr&value0-0-0=&field0-1-0=
flagtypes.name&type0-1-0=changedto&value0-1-0=


Sorry for the OT, but others have commented on this as well. I think this search
does it.
Watch the wrapping! (-;
*** Bug 307508 has been marked as a duplicate of this bug. ***
*** Bug 315618 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: