#16874: https://sports.yahoo.com/dailyfantasy is broken with Tor Browser 5.0 on Windows -------------------------+------------------------------------------------- Reporter: gk | Owner: tbb-team Type: defect | Status: new Priority: normal | Milestone: Component: Tor | Version: Browser | Keywords: tbb-usability-website, Resolution: | tbb-5.0-regression Actual Points: | Parent ID: Points: | -------------------------+-------------------------------------------------
Comment (by arthuredelstein): Browsing to https://sports.yahoo.com/dailyfantasy, I noticed that a `window.Intl is undefined` error appears in the JS console on Windows. This error is caused by our use of `--without-intl-api` in `.mozconfig- mingw` (our Windows build). So I wondered if this error might be causing the problem, but our TBB-4.5.3 builds also use `--without-intl-api`. I then discovered that a `polyfill.min.js` script is loaded by the page in TBB-4.5.3 that compensates for the lack of a built-in `window.Intl` object. This file adds `IntlPolyfill` and `Intl` properties to the `window` object, such that `Intl === IntlPolyfill` returns true in the JS console. On TBB-5.0.2, the page attempts to load `polyfill.min.js`, but the server responds with an empty file (200 OK). The request headers from the two browser versions are almost identical. One difference is the User-Agent, which is controlled by the `general.useragent.override` pref: * TBB-4.5.3 has `Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0` * TBB-5.0.2 has `Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0` If I set the `general.useragent.override` in TBB-5.0.2 to emptry, or to * `Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/31.0` or * `Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/38.0`, then the Yahoo server returns a non-empty `polyfill.min.js` and the links in https://sports.yahoo.com/dailyfantasy are no longer broken. So there are two possible solutions to this bug: (1) cross-compile Firefox for Windows with the Intl API, and (2) change the User-Agent as above. Solution 1 may not be easy (see https://bugzilla.mozilla.org/show_bug.cgi?id=1019744#c19), but Solution 2 seems like an weird thing to do for an issue specific to this one site. On the other hand, since we have a habit of disabling dangerous new features, there might be an argument for not presenting a User-Agent that claims support for 38.0 features. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16874#comment:3> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
