Yes, we really need to be able to automatically enable the mobile skin for mobile devices and mobile-specific URLs. But for that, we should be able to tell mobile devices from non-mobile ones because desktop Opera is currently detected as mobile WebKit, for example :P

preilly wrote:

Well, we do have:
$detector = new DeviceDetection();
$userAgent = $_SERVER['HTTP_USER_AGENT'];
$acceptHeader = isset( $_SERVER["HTTP_ACCEPT"] ) ? $_SERVER["HTTP_ACCEPT"] : '';
$formatName = $detector->detectFormatName( $userAgent, $acceptHeader );

We would just need to refactor for a non wmf mode to sent that return value as the xdevice.

— Patrick

preilly wrote:

s/sent/set/

The problem is that SeviceDetection can only tell one mobile platform from another, not mobile from non-mobile. For example:

• Opera, Safari & Chrome are detected as 'webkit',
• Firefox as 'capable'.

If you try to enable the mobile skin based on this information, you will always see it.

s/SeviceDetection/DeviceDetection/

"Opera Mini" and "Opera Mobi" can be detected from the User Agent without confusion, right?

"Fennec" (and "Minimo") should be good to detect the right Firefox mobile browsers. All the other mobile browsers have some string the UA that clearly marks them as mobile.

http://www.useragentstring.com/pages/Mobile%20Browserlist/

Or am I missing something?

WURFL is great to get all the heuristics but most MW sysdmins could do with a much more simpler and fuzzier list. No matter how imperfect this solution is, it will be better than letting users find the link at the bottom - and wishing they click it.

I've started a fix for this:
https://gerrit.wikimedia.org/r/11569

It is incomplete but should deal with the problem

Change above was abandoned. Patrick suggested having a meeting to thrash out
the details of how we can do this better.

Can you please explain the change from Major to Enhancement? Detecting mobile browsers seems to be a basic feature of the Mobile Extension, unless this problem is being solved by another piece of software.

I'm just trying to understand your approach to this problem. Thank you!

We tend to use enhancement's for bugs that require thought and are not immediately actionable. We want this but someone needs to drive the work/conversations to make this happen - start sending patches or start or continue conversations about what should happen.

Anything that is not an enhancement in the mobile frontend extension in theory is urgent or should be actionable. bug 36936 is another great example - it's something that needs to be fixed but requires some sort of upfront design work to actually be fixed.

Really it's a workaround flaw in bugzilla which doesn't make it easy to distinguish between actionable bugs and more complicated bugs that need unravelling. If you have a better suggestion for separating these types of bugs I'd love to hear!

Thank you for the explanation, Jon. CCing Andre, our new Bug Wrangler. He might want to dig further on Bugzilla processes to address your point.

The simplest thing we can do:

• check for 'Mobi' in the user-agent string
• blacklist if also contains 'iPad', since tablets currently want the desktop interface

(See recent talk on bug 40919 for instance.)

If there are modernish phones that don't have 'Mobile' in their UA string, I would be surprised... older ones I'm sure there are but they're less important for most third-party wiki users, probably.

(In reply to comment #10)

We tend to use enhancement's for bugs that require thought and are not
immediately actionable.

If you use the term "bugs" here in the meaning of "not an enhancement request" I'd say: Just because a bug is harder to fix doesn't make it less of a bug by definition. ;) Enhancement = new feature that would be nice to have.

What does "actionable" exactly mean? Fixable without too many thoughts and hence more trivial to fix? I'd say that's what the severity field is for, plus the priority field exists to mark urgent tickets by setting it to "High" or "Highest".

I think Ryan Lane's patch might take care of this (not confirmed)
Note: would add Ryan to cc list but there are 2 Ryan's and not sure which if either is him.
https://gerrit.wikimedia.org/r/40298

No, having detection work through an Apache module is good but not enough. Guess we can simply borrow the regexes from Squid ACLs.

Is this food for a possible project in a mentorship program or not quite?

http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects

eichi237 wrote:

You can use php-mobile-detect: https://code.google.com/p/php-mobile-detect/

eichi237 wrote:

It's not possible to use media queries?

Reply to comment #18

Not relevant.

Currently there is a separate site for mobile. This is being built with mobile in mind and will use media queries to enhance itself for desktop browsing. Little work (that I know of) is happening on the desktop site to make it mobile friendly using media queries and this is the wrong way round as many older mobile devices do not support media queries whereas most modern (and used) desktop browsers do.

On the cluster we use addition software to determine whether to redirect a user to the mobile site or the desktop site based on their user agent. There is no default setup for this behaviour which is what this bug relates to.

https://gerrit.wikimedia.org/r/#/c/48583/

Merged.