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

Status: NEW

(Thunderbird :: General, defect)

Description

[Shawn Wilsher :sdwilsh]

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.

Comment 1

[Shawn Wilsher :sdwilsh]

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

Comment 2

[David :Bienvenu]

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

Comment 3

[Shawn Wilsher :sdwilsh]

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...

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 5

[Shawn Wilsher :sdwilsh]

(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).

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

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...

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 8

[Shawn Wilsher :sdwilsh]

(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.

Comment 9

[Bryan Clark (DevTools PM) [:clarkbw]]

(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.