Bugzilla

Ok, so I dug into this a bit yesterday.

So the reason for the timeout is that the WebExecutor's C++ helper is convinced the URI it gets from Send is not a blob URI (specifically, opening the channel to start the download produces NS_ERROR_MALFORMED_URI, which currently isn't caught anywhere, hence the silent timeout). The schema is most definitely "blob" - I am logging the URI before calling `onExternalResponse`. At the same time, trying to create an http channel of the channel produced with the uri fails either.

I then tried downloading something from Send in Focus - just for funzies, and wasn't disappointed:  Focus is perfectly able to download. GV in Focus was last updated on May 7th, so the bug 1635862 fix isn't even remotely there... Then I decided to see if ye olde C++ code works in reference browser - maybe the bug 1635862 fix broke something? - it doesn't. The code predictably fails at the point of creating an http channel. So it seems like the URI that the WebExecutor's C++ helper gets in Focus is somehow different from the URI it gets in reference browser.

Arturo, I wonder if you could investigate how the flow is different in AC vs Focus in the case of FF Send downloads?

Meanwhile, I'm going to see if the folks from Send team can shade any light on this. It seems to me there's something peculiar about how FF Send generates these links and what they really are. It doesn't look like they are straightforward blob URIs.

Ok, so I dug into this a bit yesterday.

So the reason for the timeout is that the WebExecutor's C++ helper is convinced the URI it gets from Send is not a blob URI (specifically, opening the channel to start the download produces NS_ERROR_MALFORMED_URI, which currently isn't caught anywhere, hence the silent timeout). The schema is most definitely "blob" - I am logging the URI before calling `onExternalResponse`. At the same time, trying to create an http channel of the channel produced with the uri fails either.

I then tried downloading something from Send in Focus - just for funzies, and wasn't disappointed:  Focus is perfectly able to download. GV in Focus was last updated on May 7th to GV76, so the bug 1635862 fix isn't even remotely there... Then I decided to see if ye olde C++ code works in reference browser - maybe the bug 1635862 fix broke something? - it doesn't. The code predictably fails at the point of creating an http channel. So it seems like the URI that the WebExecutor's C++ helper gets in Focus is somehow different from the URI it gets in reference browser.

Arturo, I wonder if you could investigate how the flow is different in AC vs Focus in the case of FF Send downloads?

Meanwhile, I'm going to see if the folks from Send team can shade any light on this. It seems to me there's something peculiar about how FF Send generates these links and what they really are. It doesn't look like they are straightforward blob URIs.

Ok, so I dug into this a bit yesterday.

So the reason for the timeout is that the WebExecutor's C++ helper is convinced the URI it gets from Send is not a blob URI (specifically, opening the channel to start the download produces NS_ERROR_MALFORMED_URI, which currently isn't caught anywhere, hence the silent timeout). The schema is most definitely "blob" - I am logging the URI before calling `onExternalResponse`. At the same time, trying to create an http channel of the channel produced with the uri fails either.

I then tried downloading something from Send in Focus - just for funzies, and wasn't disappointed:  Focus is perfectly able to download. GV in Focus was last updated on May 7th to GV76, so the bug 1635862 fix isn't even remotely there... Then I decided to see if ye olde C++ code works in reference browser - maybe the bug 1635862 fix broke something? - it doesn't. The code predictably fails at the point of creating an http channel. So it seems like the URI that the WebExecutor's C++ helper gets in Focus is somehow different from the URI it gets in reference browser.

Arturo, I wonder if you could investigate how the flow is different in AC vs Focus in the case of FF Send downloads?

Meanwhile, I'm going to see if the folks from Send team can ~shade~ shed any light on this. It seems to me there's something peculiar about how FF Send generates these links and what they really are. It doesn't look like they are straightforward blob URIs.

Ok, so I dug into this a bit yesterday.

So the reason for the timeout is that the WebExecutor's C++ helper is convinced the URI it gets from Send is not a blob URI (specifically, opening the channel to start the download produces NS_ERROR_MALFORMED_URI, which currently isn't caught anywhere, hence the silent timeout). The schema is most definitely "blob" - I am logging the URI before calling `onExternalResponse`. At the same time, trying to create an http channel of the channel produced with the uri fails either.

I then tried downloading something from Send in Focus - just for funzies, and wasn't disappointed:  Focus is perfectly able to download. GV in Focus was last updated on May 7th to GV76, so the bug 1635862 fix isn't even remotely there... Then I decided to see if ye olde C++ code works in reference browser - maybe the bug 1635862 fix broke something? - it doesn't. The code predictably fails at the point of creating an http channel. So it seems like the URI that the WebExecutor's C++ helper gets in Focus is somehow different from the URI it gets in reference browser.

Arturo, I wonder if you could investigate how the flow is different in reference browser vs Focus in the case of FF Send downloads?

Meanwhile, I'm going to see if the folks from Send team can ~shade~ shed any light on this. It seems to me there's something peculiar about how FF Send generates these links and what they really are. It doesn't look like they are straightforward blob URIs.

Ok, so I dug into this a bit yesterday.

So the reason for the timeout is that the WebExecutor's C++ helper is convinced the URI it gets from Send is not a blob URI (specifically, opening the channel to start the download produces NS_ERROR_MALFORMED_URI, which currently isn't caught anywhere, hence the silent timeout; also, `dom::IsBlobURI(uri)` returns false for these URIs). The schema is most definitely "blob" - I am logging the URI before calling `onExternalResponse`. At the same time, trying to create an http channel of the channel produced with the uri fails either.

I then tried downloading something from Send in Focus - just for funzies, and wasn't disappointed:  Focus is perfectly able to download. GV in Focus was last updated on May 7th to GV76, so the bug 1635862 fix isn't even remotely there... Then I decided to see if ye olde C++ code works in reference browser - maybe the bug 1635862 fix broke something? - it doesn't. The code predictably fails at the point of creating an http channel. So it seems like the URI that the WebExecutor's C++ helper gets in Focus is somehow different from the URI it gets in reference browser.

Arturo, I wonder if you could investigate how the flow is different in reference browser vs Focus in the case of FF Send downloads?

Meanwhile, I'm going to see if the folks from Send team can ~shade~ shed any light on this. It seems to me there's something peculiar about how FF Send generates these links and what they really are. It doesn't look like they are straightforward blob URIs.