Supplying a retryHandler does not give the option to retry in the UI

NEW
Unassigned

Status

9 years ago
2 years ago

People

(Reporter: sdwilsh, Unassigned)

Tracking

unspecified
Bug Flags:
wanted-thunderbird +

Firefox Tracking Flags

(blocking-thunderbird3.1 -)

Details

(Reporter)

Description

9 years ago
When supplying a retryHandler to an nsIActivityProcess and the process has an error and the state is set to STATE_WAITINGFORRETRY, the UI does not offer the user to retry.
(Reporter)

Comment 1

9 years ago
FWIW, this makes using the activity manager for processes mostly useless from an add-on perspective.

Updated

9 years ago
Flags: blocking-thunderbird3.1?
OS: Mac OS X → All
Hardware: x86 → All

Comment 2

9 years ago
We didn't end up implementing retry, but we left the hooks in (apparently).
(Reporter)

Comment 3

9 years ago
I did some digging on the train.  It looks like all the code is in there, and the button is properly unhidden, but the CSS doesn't actually display anything for it.  This might be pretty trivial to fix after all...
This doesn't seem like a 3.1 blocker to me.  It's not actually clear to me what activities we're interested in allowing the user to retry.  If someone decides to renominate this bug in the future, enumerating those would make this easier to evaluate.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1?
(Reporter)

Comment 5

9 years ago
(In reply to comment #4)
> This doesn't seem like a 3.1 blocker to me.  It's not actually clear to me what
> activities we're interested in allowing the user to retry.  If someone decides
> to renominate this bug in the future, enumerating those would make this easier
> to evaluate.
I filed this bug because I was trying to use this UI from an add-on.  In the core, you may not have a need for it, but from an add-on the need can come up.  Specifically, I wanted bugzilla helper to try to resubmit a comment if it happened to fail (due to network issues or whatever).
If this were the last bug standing for 3.1, I don't think we'd block on it, however it would be a very very fine thing to get, given our platform focus.  Marking as wanted+ for now.  Adding our add-on cabellero (asuth) to see if he disagrees with this prioritization...
Flags: wanted-thunderbird+
caballero, please :)

I don't think sdwilsh was contesting the prioritization, just explaining the background.  Happily, by virtue of having looked at the activity manager code, he is the developer most familiar with the code and the ideal person to provide the fix.

As an aside for the use case, it's likely better UX to just do the exponential back-off / wait for offline/online transition thing than requiring the user to click.
(Reporter)

Comment 8

9 years ago
(In reply to comment #7)
> I don't think sdwilsh was contesting the prioritization, just explaining the
> background.  Happily, by virtue of having looked at the activity manager code,
> he is the developer most familiar with the code and the ideal person to provide
> the fix.
FWIW, I tried coming up with a fix for this, but got rather stumped. :(  Could be my lack of UI work in a while is starting to hit me.
(In reply to comment #7)
> As an aside for the use case, it's likely better UX to just do the exponential
> back-off / wait for offline/online transition thing than requiring the user to
> click.

Agreed, a ( Cancel ) button of the back-off would be nice there too however at some point I assume you have to just fail and then offer a retry option anyway.
You need to log in before you can comment on or make changes to this bug.