One of my Q1 goals was "Make recommendation on what to do with WAP
(WML or XHTMLMP) content in Fennec."
I blogged about the problem [1] and the Telemetry probe I landed to
investigate this at [2].
In a nutshell, Firefox for Android and Firefox OS users sometimes
receive WAP content--which can mean a lot of things, but for the sake of
telemetry it means receiving a response with one of the following
content types: application/wml+xml, application/vnd.wap.xhtml+xml,
text/vnd.wap.wml, or application/vnd.wap.wmlc. What it definitely does
mean is a crappy user experience since we don't know what to do with the
response so we treat it as "application/octet-stream" and attempt to
download it.
What we didn't know was how common this was on the web. There are still
some questions to be answered there, for the markets we are not
measuring (i.e., primarily China which doesn't have a Nightly userbase
(or the patches in question)), but FHR + Telemetry unification landing
should help us in the future).
After measuring WAP hits for part of the 38 Nightly and all of the 39
Nightly trains, we have some data.
I wrote a comment at [3] which is a few days old, but check that out if
you want to see the data for 38 and 39. Or just look at my sweet donut
charts at [3] and [4].
In aggregate we have the following from a total of 123,100,255 HTTP
responses recorded for Fennec and 1,380,028 for B2G:
Fennec
non-WAP response 123099695 99.999545%
WAP response 560 00.000455%
B2G
non-WAP response 1379772 99.981449%
WAP response 256 0.0185503%
(Telemetry will run through 40, so we can revisit in 6 weeks and see
what, if anything has changed with the trend.)
In many of our tests, we seem to be sent WAP content due to our
unrecognized UA string. Most of these sites send HTML to Chrome for
Android, for example. But looking at the data, it's clear that this
problem is exceedingly rare for Fennec users to run into.
One idea Brad tossed around was "if WAP received, then re-request with
Chrome/iPhone UA to get HTML content (+ record telemetry if that fixes
it or if we still get WAP after that)". I wouldn't mind attempting to
write the patches for this, if we think it's worth the time.
Based on the data we have in front of us, it's probably not worth the
time - but China is still a huge unknown to us and there's good reason
to believe this is way more common there (see [5], which hints at some
common nginx configuration).
The other option is to just log a message to the user saying "lol this
content is designed for graphing calculators" (Bug 941241). Perhaps
after showing the message, passing the site off to an Android
intent/activity (whatever it's called) if the user has one that can
display WAP. I'm not crazy about sending our users to another browser,
however and it doesn't work for B2G.
So anyways. A conclusion. My recommendation is to wait until we can
somehow measure what's going on in China for Fennec and start
experimenting with this re-request with spoofed UA hack in the meantime.
I think the numbers are too high for B2G to just WONTFIX everything. So
hopefully the solution can be shared.
Thoughts?
[1]
<https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#1484>
[2] <https://miketaylr.com/posts/2015/03/wap-telemetry-how-to.html>
[3] <https://bugzilla.mozilla.org/show_bug.cgi?id=941241#c27>
[4]
<http://miketaylr.github.io/compat-telemetry-dashboards/wap-39-nightly.html>
[5] <https://bugzilla.mozilla.org/show_bug.cgi?id=997668>
--
Mike Taylor
Web Compat, Mozilla
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
