Closed Bug 579502 Opened 14 years ago Closed 7 years ago

Better handling of AMO search failure in the Add-ons Manager

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -

People

(Reporter: bparr, Unassigned)

References

Details

(Whiteboard: [AddonsRewrite])

Once the patch for Bug 558287 lands, when the user completes a search inside the Add-ons Manager, the Add-ons Manager will not notify the user that an AMO search failed (silent failure). So, to the user, it looks like the search succeeded, but returned zero AMO results.

Is this sufficient handling of an AMO search failure? Should something else be done to notify the user of the failure (e.g. changing the throbber to a warning symbol)?
blocking2.0: --- → ?
I suspect that this isn't a blocker, but it depends how strongly Boriss feels about it.
Keywords: uiwanted
Agree with Dave that this isn't a blocker.  Still, let's figure out how to handle it.

Ben, how much can we know about a failure in search?  Only that the search has failed, or anything about the manner in which it failed?  A warning icon and a (hopefully) relevant message should be sufficient.
blocking2.0: ? → -
As of right now, there is no way to know; nothing is passed to searchFailed when it is called. There are only three ways in which a search can failed: request.onerror is called, if request.status is incorrect, or if the returned XML is malformed. So, we could easily pass information about the error when calling searchFailed.
(In reply to comment #3)
> As of right now, there is no way to know; nothing is passed to searchFailed
> when it is called. There are only three ways in which a search can failed:
> request.onerror is called, if request.status is incorrect, or if the returned
> XML is malformed. So, we could easily pass information about the error when
> calling searchFailed.

What specifically calls request.onerror and makes request.status incorrect?

What's important is whether search failures are on the side of AMO/Firefox or that of the user.  If they're all on our side, it's probably not worth communicating the detail of the error in a message to the user.  If the errors originate from a problem on the user's end, that may be worth communicating or suggesting a fix for.  It sounds like all the former and none of the latter, though.
(In reply to comment #4)
> (In reply to comment #3)
> > As of right now, there is no way to know; nothing is passed to searchFailed
> > when it is called. There are only three ways in which a search can failed:
> > request.onerror is called, if request.status is incorrect, or if the returned
> > XML is malformed. So, we could easily pass information about the error when
> > calling searchFailed.
> 
> What specifically calls request.onerror and makes request.status incorrect?
> 
> What's important is whether search failures are on the side of AMO/Firefox or
> that of the user.  If they're all on our side, it's probably not worth
> communicating the detail of the error in a message to the user.  If the errors
> originate from a problem on the user's end, that may be worth communicating or
> suggesting a fix for.  It sounds like all the former and none of the latter,
> though.

Assuming the user's internet connection is working correctly, all of the problems will be on our/AMO's side.
Keywords: uiwanted
(In reply to comment #5)
> Assuming the user's internet connection is working correctly, all of the
> problems will be on our/AMO's side.

Lame.  Yeah, just an error icon and the message with an mea culpa string, then.  Perhaps "Sorry, this search could not be completed because an error occurred."
Actually, I missed a few cases where searchFailed could be called that are added in my current patch to Bug 551274.

- If a search is already in progress, and another search tries to start. This should never actually happen in the Add-ons Manager because it cancels searches before beginning a new one.
- If a search is requested for 0 or less items. Unless the user is messing with their preferences in about:config, then this should not happen.
- If the application does not define the preference storing the URL template for the request. Within the Firefox Add-ons Manager, this should not happen.

I don't think these cases changes anything. However, I thought I'd bring them up just in case.
(In reply to comment #7)
> Actually, I missed a few cases where searchFailed could be called that are
> added in my current patch to Bug 551274.
> 
> - If a search is already in progress, and another search tries to start. This
> should never actually happen in the Add-ons Manager because it cancels searches
> before beginning a new one.

Yeah, re our discussion, a throbber would just be displayed in the search results section, clearing whatever was there before. 

> - If a search is requested for 0 or less items. Unless the user is messing with
> their preferences in about:config, then this should not happen.

Yeah, handling this doesn't seem worth the effort.  Afaik that isn't even a main-level about:config option.
We are just going to remove this search, its too problematic, see bug 1263313.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.