If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Download notification still remains even when the download has been canceled and deleted

VERIFIED FIXED

Status

Fennec Graveyard
General
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: ashah, Assigned: alexp)

Tracking

Trunk
ARM
Android

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
BuildID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b8pre) Gecko/20101018
Firefox/4.0b8pre Fennec /4.0b2pre 

STR:
1. Open fennec
2. Start a file download
3. Drag down the android notification bar and tap on the download progress notification.This will take you to the download manager. 
4. Here, tap on cancel. this will cancel your download
5. Then, tap on delete. This will delete the file from the system and the download manager.
6. Drag down the android notification bar.

Expected result:
The downloading notification should have been removed when the user has canceled and deleted the download.

Actual result:
The download notification still persists in the android notification bar.
(Reporter)

Updated

7 years ago
tracking-fennec: --- → ?
Assignee: nobody → alexp
tracking-fennec: ? → 2.0b3+
(Assignee)

Comment 1

7 years ago
Isn't this a dupe for bug 603378?
Status: NEW → ASSIGNED
Can we get the Update notification to launch Fennec with a commandline param? 

fennec -alert <cookie>

so:
fennec -alert update

Then the commandline handler can run some code
Oops, I mean in the download context, not the update context
(Assignee)

Comment 4

7 years ago
(In reply to comment #2)
> Can we get the Update notification to launch Fennec with a commandline param?
> ...

Mark, I guess you meant to add this comment to the bug 604491?
Because this one looks just as a dupe for bug 603378 and should be already closed as fixed.
Yep
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 603378
I don't think this is a dupe as the duped-to bug has been verified, but I'm seeing this behavior on build:

Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101115 Namoroka/4.0b8pre Fennec/4.0b3pre
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Working for me
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → WORKSFORME
Not working for me in the Gecko/20101117 nightly build
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The code seems to trying to hide the notifications, but I wonder if the "name" is wrong
(In reply to comment #7)
> Working for me

(In reply to comment #8)
> Not working for me in the Gecko/20101117 nightly build

Ayan, can we get a regression range?
(Assignee)

Comment 11

7 years ago
Created attachment 491426 [details] [diff] [review]
Fix

Can you spot the difference? :)

I believe this code worked before. Was preprocessor changed recently?
Anyway, I believe it should handle whitespace better.
Attachment #491426 - Flags: review?(mark.finkle)
Attachment #491426 - Flags: review?(mark.finkle) → review+
The code was changed recently in bug 604719, which added the whitespace issue. Yes, it should handle whitespace better.
pushed:
http://hg.mozilla.org/mobile-browser/rev/c7af5c33c019
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED

Comment 14

6 years ago
VERIFIED FIXED:

Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:7.0a1) Gecko/20110608 Firefox/7.0a1 Fennec/7.0a1 

Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a2) Gecko/20110607 Firefox/6.0a2 Fennec/6.0a2 

Device: HTC Desire Z (Android 2.2)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.