UA override not used on redirect

[Nicola]

How to reproduce on Aquaris E4.5:

- open the web browser
- search for a song on google
- click on a youtube video
- while page is loading turn up the volume to maximum
- when page is completely loaded tap on video to make it start

What should happen:
- music video should start at maximum volume

What really happens:
- music video don't start, even if you continue to tap on it

How to fix:

- close the web browser
- open the web browser
- wait for the page to reload
- play music video

[Pat McGowan (pat-mcgowan)]

Reproduced on stable

[Olivier Tilloy (osomon)]

I can’t reproduce on rc-proposed (krillin #156).

[Pat McGowan (pat-mcgowan)]

I also reproduced it on mako running rc-proposed r268

The vol key does not seem to be part of the issue, the first time the youtube page loads the video will not play. Hitting refresh to reload the page will allow it to play.
When the page is reloaded the video shows "HQ" but not on first load

[Nicola (jackoswebsolutions)]

I have made this test with WIFI ON. I have don't check with normal network connection.

[Nicola (jackoswebsolutions)]

@Pat

For me problem comes up only while using the volume key, rarely without pressing it

[Olivier Tilloy (osomon)]

The volume key thing really sounds like a red herring.

@Nicola, can you confirm that when the video doesn’t play the original thumbnail doesn’t have the blue "HQ" icon in the bottom-left corner, whereas it has it when the video can play?

I’m able to reproduce the issue now, on krillin with the latest rc-proposed. It seems like a new symptom for bug #1499394.

[Olivier Tilloy (osomon)]

What happens when opening a youtube video from google search results is the following:

GET /url?q=http://m.youtube.com/watch%3Fv%3D-tJYN-eG1zk&… HTTP/1.1
Host: www.google.fr

    HTTP/1.1 302 Found
    Location: http://m.youtube.com/watch?v=-tJYN-eG1zk

GET /watch?v=-tJYN-eG1zk HTTP/1.1
Host: m.youtube.com
User-Agent: Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36
Referer: http://www.google.fr/search?q=we+will+rock+you&…

As can be seen from the second GET request, the UA override for youtube (http://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/view/head:/src/Ubuntu/Web/ua-overrides-mobile.js#L23) hasn’t been applied.

[Olivier Tilloy (osomon)]

This appears to be a bug in oxide, where the user agent overrides are not used for redirections (e.g. HTTP 302).
I can reproduce locally with the following standalone code:

== server.py ==

#!/usr/bin/python3
# -*- coding: utf-8 -*-

import http.server as http
import threading

class HTTPRequestHandler(http.BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/foo":
            self.send_response(302)
            self.send_header("Location", "http://localhost:8080/bar")
            self.end_headers()
            self.wfile.write(b"foo")
        elif self.path == "/bar":
            self.send_response(200)
            self.send_header("Content-Type", "text/plain")
            self.end_headers()
            self.wfile.write(b"bar")
        else:
            self.send_error(404)

if __name__ == '__main__':
    server = http.HTTPServer(("", 8080), HTTPRequestHandler)
    server.allow_reuse_address = True
    server.serve_forever()

== client.qml ==

import QtQuick 2.4
import com.canonical.Oxide 1.9

WebView {
    url: "http://localhost:8080/foo"
    context: WebContext {
        userAgent: "default"
        userAgentOverrides: [
            ["^http:\/\/localhost:8080\/foo", "overridden1"],
            ["^http:\/\/localhost:8080\/bar", "overridden2"],
        ]
    }
}

Then run `python3 server.py` in one terminal, monitor network traffic with e.g. wireshark, and in another terminal run `qmlscene client.qml`.

The request to "/foo" has the first override as expected, but it redirects to "/bar" and the corresponding request still has the first override, instead of the second one.

[Nicola (jackoswebsolutions)]

@Olivier

Confirmed ;-)

[Olivier Tilloy (osomon)]

The linked branch has a failing unit test for this issue. Now all that’s left to do is fix it :)