What % of traffic is Windows Phone 7.5?

It's pretty measly. One day of traffic suggested IE Mobile on Windows 7 Phone is about about 0.0031% of total mobile web traffic for ar.m.wikipedia.org by pageviews by os+osver+browser+browserver tuple. Contrast this with IE Mobile 10 on Windows Phone 8, which is 0.6905% along the same lines. Of course there is a very long tail of browsers.

It seems to me like the question here is whether we ought to put it on the ResourceLoader blacklist and be guaranteed somewhat predictable UX through Special:Search, as opposed to confusion via the ResourceLoader invoked search. @Jdlrobson, @Nirzar, what do you think?

Query used:

select * from (
select
user_agent_map['os_family'],
user_agent_map['os_major'],
user_agent_map['browser_family'],
user_agent_map['browser_major'],
sum(view_count) c
from pageview_hourly
where year = 2016
and month = 7
and day = 17
and access_method = 'mobile web'
and project = 'ar.wikipedia'
and agent_type = 'user'
group by
user_agent_map['os_family'],
user_agent_map['os_major'],
user_agent_map['browser_family'],
user_agent_map['browser_major']
) order by c desc;

Given Windows Phone 7.5 runs IE9 and we support it we shouldn't add it to ResourceLoader.

We should aim to fix it but given the low usage, the fact the bugs are not severe enough (e.g. they don't prevent reading/interaction) and the fact it will be one of the next that MediaWiki does not support I would say this is a much lower priority than most of our other bugs.

For Android 2 we degrade the search ui. Let's do this for this phone too given other functionality works fine:

	if ( browser.isAndroid2() ) {
		$( 'body' ).addClass( 'client-use-basic-search' );

• There are HTTPS certificate issues on the test device which make connecting/searching impossible but you can hit enter and search.

• The soft keyboard issue is a known upstream bug that you cannot programmatically trigger a focus event in this browser.
• I can replicate the viewport issue, but this seems to be due to the search input in the header chrome having width 100% and a browser specific bug. I don't think there's any value in trying to work around it.

I'm not sure there is anything actionable about this task.
I'd suggest declinin this task given search is mostly usable and this is not a "grade A experience browser" so issues like this are to be expected.

Given support has been dropped for non-ES5 browsers I think this would include this browser @phuedx ?
If so I think we can decline this.

In T140504#3115912, @Jdlrobson wrote:

Given support has been dropped for non-ES5 browsers I think this would include this browser @phuedx ?
If so I think we can decline this.

The rendering engine is based on IE9, so yes, it's likely that we can decline this issue. We should do so after making sure that the Windows Phone 7 browser does indeed get the Grade C experience.

ES3 support will be dropped during (likely at the start of) April, 2017.

I don't have a Windows 7.5 phone. @ABorbaWMF do you think you could look into this? All we need to verify is that the search works (ie. type search term -> hit search button -> see results).

Unfortunately, the emulators we use do not cover Windows 7.5. The closest I could get was a Windows Phone 8 simulator with IE 10 and a Lumia 520 with Windows 8.1. These were available on crossbrowsertesting and browserstack respectively.

Mostly it worked fine, but I was able to reproduce the missing keyboard on the Windows Phone 8 simulator.

Windows Phone 8 Simulator
En Main	Search
Lumia 520 Windows 8.1