Open
Bug 842871
Opened 12 years ago
Updated 2 years ago
Clean downloads button not working if you got private navigation enabled
Categories
(Toolkit :: Downloads API, defect)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox19 | - | wontfix |
firefox20 | --- | unaffected |
People
(Reporter: josematiaslemos, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
74.32 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331
Steps to reproduce:
Download some files
Actual results:
While trying to clean them (having private navigation enabled) button is disabled. Only works with private navigation disabled
Expected results:
Download list should have been cleaned
Comment 1•12 years ago
|
||
I just had two users independently pop by #firefox.de on MozNet and request help with this, within 10min of each other.
Both confirm, that they are in private browsing mode.
At such a rate I believe this problem to be possibly very wide spread.
(Going into safe mode doesn't seem to help. Tried that with one of them.)
Updated•12 years ago
|
Component: Downloads Panel → Download Manager
Product: Firefox → Toolkit
Comment 2•12 years ago
|
||
Is this a regression from previous version?
Since I think other clear utilities like Clear recent History are disabled while in private browsing mode.
Comment 3•12 years ago
|
||
One of the users indicated that going back to Fx18 'fixed it'.
Which would indeed indicate a regression?
Ofc could be that there is some specific beaviour change in Fx19 that is intended but not fully working?
Comment 4•12 years ago
|
||
The per window private browsing stuff started in 19 so it's possible it regressed, but must be verified with proper testing on both 18 and 19 to confirm different behavior.
Comment 5•12 years ago
|
||
I had one of my machines still on 18.0.2 (linux x86_64) so I tried before upgrading.
Fx18: "Clear list" works
Fx19: "Clear list" doesn't work. Button is active and becomes greyed out after the first click.
(manually selecting the download item and pressing delete on the keyboard still works)
Comment 6•12 years ago
|
||
Ok, thanks for the check, setting as a regression.
I tried with mozregression (2012-08 -> 2013-01 builds) but I'm not able to reproduce the issue in PB mode. "Clear downloads" is not grayed out and clears the downloads list as espected.
Please, reporters, could you test:
1) In safe mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
2) With a new profile (dont import anything): https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(josematiaslemos)
Comment 8•12 years ago
|
||
Yes, as expected reproducible both in safe mode and with a pristine, newly created profile. As long as in Private Browsing mode ofc.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Flags: needinfo?(thomas.ruecker)
![]() |
||
Comment 10•12 years ago
|
||
There are 2 regressions.
#1 Download stops to work: Triggered by Bug 722859
#2 Download working again but the button is grayed out: Triggered by Bug 812627
#1 Regression window
Good:
http://hg.mozilla.org/mozilla-central/rev/58ebb638a7ea
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121115172150
Download stops to work:
http://hg.mozilla.org/mozilla-central/rev/a7ed19f7d21a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121116090659
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58ebb638a7ea&tochange=a7ed19f7d21a
Triggered by:
b72fbbbfc671 Josh Matthews — Bug 722859 - Support concurrent private/public downloads in the download manager. r=paolo/mak sr=bz ui-r=shorlander
#2 Regression window
Download stops to work:
http://hg.mozilla.org/mozilla-central/rev/669ac8371d19
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20.0 Firefox/20.0 ID:20121119120559
Bad(Download finished but the button is grayed out):
http://hg.mozilla.org/mozilla-central/rev/bc69705c162d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20.0 Firefox/20.0 ID:20121119221653
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=669ac8371d19&tochange=bc69705c162d
Triggered:
86d1863c71a2 Josh Matthews — Bug 812627 - Use the proper db connection when retrieving the last insert ID for downloads. r=mak
Comment 11•12 years ago
|
||
Thank you for the range!
What do you mean by "Download stop to work", the download manager stopped working, or just the Clear Downloads button?
Flags: needinfo?(josematiaslemos) → needinfo?(alice0775)
![]() |
||
Comment 12•12 years ago
|
||
(In reply to Marco Bonardo [:mak] (Away Feb 22) from comment #11)
> Thank you for the range!
> What do you mean by "Download stop to work", the download manager stopped
> working, or just the Clear Downloads button?
Download stops with 0% progress, no download file is created.
Flags: needinfo?(alice0775)
![]() |
||
Comment 13•12 years ago
|
||
(In reply to Marco Bonardo [:mak] (Away Feb 22) from comment #11)
> Thank you for the range!
> What do you mean by "Download stop to work", the download manager stopped
> working, or just the Clear Downloads button?
Download stops with 0% progress, no download file is created. And Clear Button is staying gray.
Comment 14•12 years ago
|
||
This is almost certainly caused by the statement that's bound to the public DB connection: http://mxr.mozilla.org/mozilla-release/source/toolkit/mozapps/downloads/content/downloads.js#1356
That being said, I don't know if it's worth preparing a fix. This doesn't seem like something we would chemspill over, and we're switching to the download panel in FF 20.
Updated•12 years ago
|
tracking-firefox19:
--- → ?
Keywords: regressionwindow-wanted
Comment 15•12 years ago
|
||
(In reply to Josh Matthews [:jdm] from comment #14)
> That being said, I don't know if it's worth preparing a fix. This doesn't
> seem like something we would chemspill over, and we're switching to the
> download panel in FF 20.
I think we should just fix this for other toolkit consumers, though there should be no need to rush a fix in 19 considered other UIs (like Clear Recent History) have the same "bug" from a long time.
Comment 16•12 years ago
|
||
Not critical enough to track for FF19, and sounds like it'll be resolved in FF20.
Updated•2 years ago
|
Severity: normal → S3
Comment 21•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:mak, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(mak)
Comment 22•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(mak)
You need to log in
before you can comment on or make changes to this bug.
Description
•