543.47 KB, image/jpeg
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.14 Safari/534.24 Build Identifier: Yahoo.com - after video ends play error code 302 is displayed in FF Reproducible: Always Steps to Reproduce: 1. Go to yahoo.com in Firefox browser on Motorola Xoom 2. tap to play video, there is pop up asking to play video in other application 3. tap ok 4. Once the video finishes playing and returns to Firefox browser verfiy that yahoo page is displayed properly Actual Results: HTTP error code 302 is displayed in Firefox browser on Motorola Xoom. when perform same steps in native android browser on Motorola Xoom No such error is displayed and proper yahoo page is shown Expected Results: The yahoo page with video should be displayed properly Motorola Xoom OS 3.0.1
Created attachment 521093 [details] Scrennshot of error code 302 is displayed in FF after video ends playing Device Type - Motorola Xoom, uTest bug ID#132236
also occurs with Mozilla/5.0 (Android; Linux armv71; rv2.0b13pre) Gecko/20110323 Firefox/4.0b13pre Fennec/4.1a1pre Device: Droid 2 OS: Android 2.2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Nominating for post 4.0 work.
tracking-fennec: --- → ?
Priority: -- → P3
Assignee: nobody → doug.turner
tracking-fennec: ? → 2.0-
is this still an issue?
tracking-fennec: - → ?
Yes, it's still an issue. Mozilla/5.0 (Android; Linux armv71; rv6.0a1) Gecko/20110510 Firefox/6.0a1 Fennec/6.0a1 Device: Droid 2 OS: Android 2.2
What URL should I use to see this? Right now I don't see a link to any videos on yahoo.com.
Created attachment 540112 [details] [diff] [review] completely wrong patch This patch is probably wrong, but it fixes the bug and has no immediate obvious downsides. The current code has what appears to be a hack (see comment in the patch), it says the request to open an external application failed even when it succeeded. But if the request succeeds, which seems to be the right thing to do anyhow, then all is well.
Attachment #540112 - Flags: feedback?(doug.turner)
Attachment #540112 - Flags: feedback?(doug.turner) → feedback?(bzbarsky)
Well, the attached patch is definitely wrong. Why does it help? Where is that 302 thing coming from to start with?
I am not sure why this helps, still wrapping my head around this code. Do you have any pointers about how to understand this - what would be a straightforward way to find where the 302 occurs?
First question: is that HTML page shown in the screenshot generated by the server, or by us?
I'm not sure how to find out what generated that HTML page. No ctrl-u in fennec :( But after a few more hours debugging this, it looks like this is what happens: 1. We load m.yahoo.com/.., some url of a media element 2. This 302 redirects us to rtsp://some cdn somewhere, which we handle with an external app on android. 3. The external app returns failure, as mentioned in a previous comment, as sort of a workaround. It *did* succeed, but it will not fire any OnStart etc., so it returns an error code, NS_ERROR_NO_CONTENT. 4. Since the redirect is considered failed, HttpChannelParentListener::OnRedirectResult will continue with the original channel. This might be where we diverge from single-process desktop, if HttpChannelParentListener is only used in multiprocess setups? It looks like we need the external app channel to say "I succeeded, but will not fire any followup OnStarts, etc.". Not sure how this ends up working in the single-process case. But this can be done by changing rv = mRedirectChannel->AsyncOpen(mListener, mListenerContext); if (NS_FAILED(rv)) to rv = mRedirectChannel->AsyncOpen(mListener, mListenerContext); if (NS_FAILED(rv) && rv != NS_ERROR_NO_CONTENT) in nsHttpChannel::ContinueProcessRedirection. That is, to accept no content results as success - the redirection did not fail, the redirected channel is just empty, and we should *not* try to continue with the previous one.
Sorry, forgot to paste the next line in that snippet, which is return rv;
> I'm not sure how to find out what generated that HTML page. Well, one option is to grep the fennec source for that string. If it's not there, we didn't generate it. ;) > 2. This 302 redirects us to rtsp://some cdn somewhere, which we handle with an > external app on android. Aha. So the question is... what should we show in the browser at this point? The previous page (as in, don't navigate at all)? The 302 response body (which is what we seem to be showing here)? A blank page? Something else? > This might be where we diverge from single-process desktop, if > HttpChannelParentListener is only used in multiprocess setups? No idea, but in the situation you describe above I would expect desktop to also show the 302 response body. > It looks like we need I'd really like us to figure out what behavior we want before trying to figure out how to achieve it. So let's start there. What's the expected behavior here? Some options are listed above.
Over to core networking, since this does not seem to be fennec-specific. Arguably, the right behavior is to keep showing the previous page (which is what we'd do if it had a direct link to rtsp:// instead of going through a redirect).
Component: General → Networking: HTTP
Product: Fennec → Core
QA Contact: general → networking.http
Attachment #540112 - Flags: feedback?(bzbarsky) → feedback-
Please check if all your plugins are up-to-date. To do this, go to the Mozilla Plugin Check site. Once you're there, the site will check if all your plugins have the latest versions. If you see plugins in the list that have a yellow Update button or a red Update now button, please update these immediately. To do so, please click each red or yellow button. Then you should see a site that allows you to download the latest version. Double-click the downloaded file to start the installation and follow the steps mentioned in the installation procedure.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.