519207 - [Collector Extension] Login problems in TB2 because of no mozBackgroundRequest

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Collector Extension, defect, P1)

Description

[Brian King [:kinger]]

Les, I'm assigning to you initially mainly to solicit feedback and see if you think something can/should be done on the API end for this.

In Thunderbird 2, a login prompt for some API calls comes up. This is because mozBackgroundRequest = true on XMLHttpRequest is ignored. Click Ok on the prompt causes problems, the main one being we are stuck on the login screen. A workaround right now is to click Cancel in the prompt.

Here are a few possible fix scenarios:

1) Hard code the URL of the authentication call, then we could get around
this. But it would break the way we're supposed to use the API (i.e. only
knowing the URL of the service document).

2) Send the platform id and version to the API, which can then handle things differently for TB2.

3) Write our own XMLHttpRequest class that mimics the built in, but doesn't cause the auth. dialog to pop up.

4) backport a working copy of the xmlhttprequest component for TB2, mainly the mozBackgroundRequest feature. This would mean messing with cpp which would add a huge overhead in terms of build maintenance to the add-on.

Comment 1

[Les Orchard [:lorchard]]

This sounds like a TB2 bug, which I'm not really familiar with.  Not sure what the API needs to do here.

Comment 2

[David McNamara [:mackers]]

To get the URL of the API call to authenticate, we first need to get the
service document URL. When we request the service document URL, the API is
(expectedly) returning a standard "Unauthorized" HTTP response code, so TB2 is
popping up an authentication dialog.

(In reply to comment #1)
> This sounds like a TB2 bug, which I'm not really familiar with.  Not sure what
> the API needs to do here.

We're looking for a workaround. Any thoughts on 1) or 2) ?

Comment 3

[Brian King [:kinger]]

(In reply to comment #1)
> This sounds like a TB2 bug, which I'm not really familiar with.  Not sure what
> the API needs to do here.

It is not so much a bug, but a missing feature not in XMLHttpRequest. So as Dave said, we are looking for a workaround.

Comment 4

[Les Orchard [:lorchard]]

Hmm, Not sure I entirely understand the issue - but if hardcoding the auth URL fixes it, that doesn't seem like the end of the world

Comment 5

[Brian King [:kinger]]

(In reply to comment #4)
> Hmm, Not sure I entirely understand the issue - but if hardcoding the auth URL
> fixes it, that doesn't seem like the end of the world

I agree. Especially if we fork it only for TB2. It is the path to least resistance.

Dave, can you please have a look.

FYI, I am forking code this way right now...

if (Bandwagon.Util.getHostEnvironmentInfo().appVersion.substring(0, 1) == "2") {
  // do TB2 way
}
else {
  // do other way
}

comparison operators did not work on appVersion well, even when converted to integers or floats. Anyway, my point being that there might be a better way, and it should be moved to a utility function called isTB2() or similar.

Comment 6

[David McNamara [:mackers]]

I've added a Bandwagon.Util.isTB2() function. I've replaced any instance of the above conditional with the function call instead.

r52517

Comment 7

[David McNamara [:mackers]]

I've added the auth hack for tb2 only. It works fine when the user puts in their correct credentials.

However, if the user enters incorrect credentials, the api auth dialog still appears. If they then put in their correct password, the login will proceed. If they put in their incorrect password, bandwagon will display the "incorrect password" message.

I'm not sure if this solution is acceptable?

r52520

Comment 8

[Brian King [:kinger]]

(In reply to comment #7)
> I've added the auth hack for tb2 only. It works fine when the user puts in
> their correct credentials.

On a virgin TB profile (TB2), I get the auth dialog on first login. After that a big scary 1-time TB warning dialog comes up, which could have something to do with it coming up.

Comment 9

[Brian King [:kinger]]

I think we'll have to live with this on TB2. Not worth the cycles to look more into it, so closing.

cc'ing a couple of TB folks in case they know a quick and elegant workaround.