597953 - Downloads: Dependent behavior on other files

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Ioana Chiorean]

Build Identifier: Mozilla/5.0 (Android; Linux armv7l; en-US; rv:2.0b7pre)
Gecko/20090919 Firefox/4.0b7pre Fennec/2.0b1pre 
Device Motorola Droid 2.2 

Steps to reproduce:
1. Download several files (some identical, some different)
2. Slide page to left and go to Download Manager
3. Press Pause at two identical files. 
4. Press Cancel at both files from step 3

Expected result:
- the cancel button and retry should apply modifications only to the focused/chosen file

Actual result:
- first canceled file goes to failed when the second file is pressed cancel. no buttons for it only when tab again on it.
- if press retry at the second file, the buttons appear for the first also

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Brian - If this turns out to be a front-end bug, please let me know.

Comment 2

[Wesley Johnston (:wesj)]

I think this is just a front-end bug. Any download-retry item has the "Failed" label, even if it was just canceled by the user:

http://mxr.mozilla.org/mobile-browser/source/chrome/content/bindings/downloads.xml#130

If you cancel any download, it will show the red "FAILED" line until it is selected, at which point it hides the failed and shows buttons for Retry and Remove. Is that the bug you're seeing Ioana?

Beyond not writing "Failed" when the user canceled something, I think these need to be restyled. Selected items don't really have a highlight state, which can make it difficult to determine what is selected and what isn't. Active downloads always show buttons, which makes them resemble selected items, even when they aren't.

Comment 3

[Wesley Johnston (:wesj)]

Attachment: Hide "FAILED" Logo

Comment 4

[Ioana Chiorean]

|If you cancel any download, it will show the red "FAILED" line until it is
|selected, at which point it hides the failed and shows buttons for Retry and
|Remove. Is that the bug you're seeing Ioana?

My problem stated was that I cancel a document and a failed status appears to other document(not the canceled one)

Comment 5

[Wesley Johnston (:wesj)]

Ioana, I suspected that what is happening is something like this:

Download 1 (Paused)   --  Resume  Cancel
Download 2 (Paused)   --  Resume  Cancel

Click cancel on Download 1

Download 1 (selected) --  Retry  Remove
Download 2            --  Resume Cancel

Click cancel on Download 2

Download 1            --          FAIL
Download 2 (selected) --  Retry Remove

So it looks like canceling Download 2 has caused Download 1 to fail, when really it is just an artifact of us not showing the FAIL message on selected downloads.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 476910 [details] [diff] [review]
Hide "FAILED" Logo

>diff --git a/themes/core/browser.css b/themes/core/browser.css

> /* downloads panel UI   ---------------------------------------------------- */
> .download-retry-failed {
>   color: red !important;
>+  display: none;
> }

>+richlistitem[typeName="download"][state="2"] .download-retry-failed {
>+  display: -moz-box;
>+}
>+

Instead of requiring the | richlistitem[typeName="download"][state="2"] | let's try doing:

.download-retry-failed[state="2"] {
  display: -moz-box;
}

And changing this: http://mxr.mozilla.org/mobile-browser/source/chrome/content/bindings/downloads.xml#140

to:
<xul:label class="hide-on-select download-retry-failed normal" value="&downloadFailed.label;" xbl:inherits="state"/>

Test this and attach a new patch.

Comment 7

[Wesley Johnston (:wesj)]

Attachment: Fix v2

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 477219 [details] [diff] [review]
Fix v2

Who ever checks this in should move the .download-retry-failed[state="2"] rule to just below the .download-retry-failed rule.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed:
http://hg.mozilla.org/mobile-browser/rev/514eba1ea98b

Comment 10

[Ioana Chiorean]

Build Identifier: Mozilla/5.0 (Android; Linux armv7l; en-US; rv:2.0b8pre)
Gecko/20101109 Firefox/4.0b8pre Fennec/4.0b3pre 
Device Samsung galasy S Cativated

Steps to reproduce:
1. Download several files (some identical, some different)
2. Slide page to left and go to Download Manager
3. Press Cancel at two files

when tapping the second entry the first one remains without buttons.SO the bad behavior still can be reproduce

Comment 11

[Ioana Chiorean]

Due to the fact that the bad behavior reproduces I'll reopen the bug (please see the Steps from comment 10)

Comment 12

[Wesley Johnston (:wesj)]

Not sure what exactly you mean by "when tapping the second entry the first one remains without buttons". Cancelling a download moves it to the bottom of the list, so my flow up above is actually more like:

Download 1 (Paused)   --  Resume  Cancel
Download 2 (Paused)   --  Resume  Cancel

Click cancel on Download 1

Download 2            --  Resume Cancel
Download 1 (selected) --  Retry  Delete

Click cancel on Download 2

Download 2 (selected) --  Retry  Delete
Download 1            --

Comment 13

[Wesley Johnston (:wesj)]

Only selected downloads or active downloads should show any buttons, so I am a bit confused here. When you click cancel on the second, the first should no longer be focused, and should not show buttons. Alternatively, you could be seeing what I described above. Active downloads are kept at the top of the list, so maybe the download is moving and confusing you.

Can we get screenshots (or better yet a video) to help diagnose what the real confusion is?

Comment 14

[Ioana Chiorean]

Here is a video: http://www.youtube.com/watch?v=KVmyX1mzF_I
As you can see canceling the -i386.iso will affect the -i386-1.iso. Also for retrying.

It doesn't seem normal for me. If we want to loose focus on a cancel file we should do that when we cancel that file , not other one.

Comment 15

[Madhava Enros [:madhava]]

After watching the video, I'm thinking that we should probably not re-order items in the list like that.  I think the intention (carried over from desktop) was to keep active items at the top, but, in practice, it's pretty confusing.

Comment 16

[Wesley Johnston (:wesj)]

Attachment: Dont move patch v1

Doesn't move items if the view is showing.

Comment 17

[Wesley Johnston (:wesj)]

pushed: http://hg.mozilla.org/mobile-browser/rev/71f769f50df1

Comment 18

[Andreea Pod]

Mozilla /5.0 (Android;Linux armv7l;rv:2.0b12pre) Gecko/20110218 Firefox/4.0b12pre Fennec /4.0b5pre

On the today's build it is still reproducible, due to this I will reopen the bug.

Comment 19

[Mark Finkle (:mfinkle) (use needinfo?)]

What is reproducible? There are too many different issues here. Please be specific.

Comment 20

[Andreea Pod]

Like in the youtube video... you have two files, one is canceled and the other not. If you hit "Cancel" at the second file the buttons for the first file disppear.

Comment 21

[Aakash Desai [:aakashd]]

Andreea, can you offer what the final behavior should be? After the fix in comment #17, I believe this fixed the issue. Re-opening with some explanation would be a good starter for Mark and Wesley to see what remains (also whether a new bug needs to be opened or if the work needs to continue on here).

Comment 22

[Andreea Pod]

So you have two files downloading. Press cancel to the first one, now you can see the buttons for the both files even if the one canceled is in focus. If you cancel the second file you should still see the buttons for both files even if the second file is in focus.

Comment 23

[Wesley Johnston (:wesj)]

You should not be seeing buttons on downloads that are not selected unless they are actively downloading.

Comment 24

[Andreea Pod]

Ok, thank you.