Talk:Compatibility

Jump to: navigation, search

About this board

Amire80 (talkcontribs)

Are we really supposed to support all versions of Safari since 5.1? It's a bit old.

Reply to "Safari 5.1+?"
ChristianSirolli (talkcontribs)

Is PHP 7.2.0 compatible with MediaWiki? That is the current stable version of PHP (as of 1/1/2018).

星耀晨曦 (talkcontribs)

Currently, MW1.30(current stable version) is not yet fully compatible with PHP 7.2. PHP will be issued a warning level error. If you disabled display_error in php.ini, there should not be any big problems.

Reply to "PHP 7.2 Compatibility"
EddieGP (talkcontribs)

I see the browser support matrix for mobile hast two columns named "Chrome", one stating that version 48+, the other stating that version 43+ is supported. This either was mistyped and one column needs to be removed or it needs clarification what the distinction here is. @Jdlrobson, you've added this in https://www.mediawiki.org/w/index.php?title=Compatibility&diff=2416446&oldid=2415223, can you help with that?

Reply to "Chrome on mobile"
Danny B. (talkcontribs)

Is there MariaDB support? If yes, can it be added to the compatibility table? Thanks.

GoodMagician (talkcontribs)

Now that the Wikimedia Foundation uses MariaDB on it's cluster, does the table need to be updated?

Is there a timeline for how far into the future MySQL support will continue? In other words, as the MariaDB and MySQL projects diverge is there a point in time that Mediawiki might be expected to drop official support for MySQL?

Reply to "MariaDB support?"
Alex Mashin (talkcontribs)

The Future of HHVM. It seems that HHVM is going to diverge from PHP to Hack; so perhaps it time to migrate to PHP 7.1 (as the only version that is going to be maintained long enough).

Legoktm (talkcontribs)

There's an ongoing discussion on wikitech-l about this.

GoodMagician (talkcontribs)

Phabricator issue T176370 is tracking the proposal to migrate to PHP7.

Reply to "HHVM"

Update A-grade browser support to reflect jQuery 3 on Opera

3
Summary by 2003:72:6D71:1900:F969:60C6:115F:73EF

Updated the page to reflect the current state correctly again.

Volker E. (WMF) (talkcontribs)

Following up a conversation with @Nikerabbit on CX SVG updates, we've identified, that out-of-the-box jQuery 3 is not supporting Opera 12.x any longer. We should update the matrix accordingly.

Kghbln (talkcontribs)

Go for it. :)

2003:72:6D71:1900:F969:60C6:115F:73EF (talkcontribs)

Fixed it.

Izno (talkcontribs)

I have at least one question based on the discussions related to HTML in phabricator: What is the process by which we decide to change MediaWiki's compatibility? Is it well-defined? Does it need calling out on this page?

Reply to "Process to change compatibility"
Spiros71 (talkcontribs)

Perhaps update the php table for MW 1.29 php 7.1 compatibility?

Kghbln (talkcontribs)

Updated assuming that 1.29 now fully plays with 7.1. The related task is fully messed since it cheerfully mixes the issue for core with the issue for extension.

Who doesn't use JavaScript and Why?

5
Summary by Quiddity (WMF)

These notes are now all at No-JavaScript notes.

Quiddity (WMF) (talkcontribs)

I was asked about the demographics of no-JS users, and didn't have a great or solid answer ("Corporate intranet users? old browser users? users avoiding banner ads?"), so went looking. Here's what I found:

Reasons for disabling JavaScript
  • Security
    • For security - (javascript vulnerabilities in browsers)
    • Corporate proxy disabled it - (for intranet security)
    • For privacy - (preventing some tracking/advertising systems, usually coupled with disabled-Cookies)
  • Preference
    • For annoyance prevention - (to prevent things like animations, particularly for users who find these overwhelmingly distracting)
  • Performance
    • For faster site downloading - (less to download (bytes))
    • For faster browser rendering - (less to calculate (complexity))
Other reasons for which users encounter the no-JS version
  • lost connection mid-download - (especially mobile users, and unstable wifi users)
Methods for disabling JavaScript
  • en:NoScript and similar browser extensions
  • Browser settings
  • Connection proxy
  • A browser that doesn't support it - (lynx, etc)
Prevalence
  • 2010 - 1.6% average (2.06% in U.S., 0.26% in Brazil) (according to developer.yahoo.com)
  • 2013 - 1.1% in U.K. (according to gds.blog.gov.uk
  • 2014 - ???
  • (newer stats, and other Reliablesources, would be appreciated. Statcounter doesn't yet reveal no-JS usage)
Sources and good links

Let me know if I missed anything major/minor, or add it to the list :)

Nemo bis (talkcontribs)

Thanks. I don't understand what "Other reasons that users encounter the no-JS version" means.

Quiddity (WMF) (talkcontribs)

That header is intended to list: the reasons why a user would get the no-JavaScript version of the site, whilst using a browser that does support javascript.

Mobile users apparently get this fairly often? The gov.uk link mentions it ("network errors, especially on mobile devices"), and I was told this directly by a WMF mobile dev.

Feel free to edit for clarity :)

Krinkle (talkcontribs)

Now that we've entered 2012 I'd like to update Compatibility#Browser with what we've basically been doing the last year already.

Instead of:

  • Internet Explorer 6+
  • Firefox 2.0+
  • Safari 3 (WebKit 525)+
  • Opera 10.0+
  • Chrome 5.0+

New proposed browser support:

  • Internet Explorer 6+
  • Firefox 3.0+
  • Safari 4 (WebKit 531)+
  • Opera 10.0+
  • Chrome 13.0+

We could go further and raise Firefox to 3.6 and Chrome to 15. However so far everything we've done happened to work during testing in those, so we might as well keep those in the compatibility until we have to do otherwise.

Platonides (talkcontribs)

If there's no problem in keeping compatibility with them, I'd continue supporting them, until dropping provides a clear benefit.

Krinkle (talkcontribs)

Updating the document isn't going to break anything. I'm simply proposing to make it reflect, what afaik is, the status quo.

If most or all features work in those browsers, that's great. But that's not the same as being officially supported. It's not like things will be forced to break in those browsers, simply no systematic testing. Frontend features aren't been systematically been tested in Firefox 2, Safari 3 or older versions of Chrome right now, and haven't been in a long while.

It's not like people using browsers not matching this will get warnings of anything, nothing changes. Other than bugs reported for those browsers perhaps getting a lower priority, but then again, those bugs probably already are..

For what it's worth: jQuery is currently officially supported in "IE 6.0+, FF 3.6+, Safari 5.0+, Opera, Chrome". So for all we know certain jQuery features may already be broken in older browsers, and since we're using jQuery..

Alarbus (talkcontribs)

We should be talking of dropping IE6; it's over ten years old and has been retarding the whole internet for years. Ensure that they get the content and don't sweat most styling issues.

Peachey88 (talkcontribs)

Our standard is any browser with more than %1 usage on the wikimedia cluster just close to full support as possible (with some degradations allowed), IE6 is/was at ~%2.22 usage the other night when I checked.

Alarbus (talkcontribs)

IE6 is especially deficient, as I expect you know. It is undeniable that these deficiencies hold back good improvements for the other ~98%. The deployment of class="hlist" on en:wp (w:en:WP:HLIST, horizontal list styling in navboxes) is a good example. IE6 support is via js, which bogs down on larger pages (it's supporting IE7&8, too). It's quite possible that IE6 will linger indefinitely at something a hair above 1%. Mostly it's pirated copies in China on XP. Most people in the developing world are jumping at the various modern-and-free browsers. That 1% set in stone? Oh, and thanks for the 2.22% data point. Good to know.

Reach Out to the Truth (talkcontribs)

If the English Wikipedia doesn't want to support IE6, that's up to them. They can make the decision to drop hlist support for IE6 if it's so much of a hassle.

Platonides (talkcontribs)

If IE7 & IE8 don't need it to be done through javascript, there's no reason to do the javascript fallback in them, too. At that point, it would only "bog down" those users that you are proposing to leave with no support at all.

88.73.3.93 (talkcontribs)

You probably should dig deeper in the details: according to Microsoft, IE6 has 6% of the total market share, but below 1% everywhere except Asia:

http://www.ie6countdown.com/ (official Microsoft site)

Krinkle (talkcontribs)

I agree we don't need to update this chart unless there is a bug we can't fix in an older browser. As long as it works we can officially support it.

Because of a recent change in support by jQuery (which ResourceLoader and thus most enhanced functionality depends on), I have updated the page and split it between "Grade A" (where everything should work), and "Grade B" (which we will maintain until either we can't (impossible bug in an old browser), or we don't have to (< 0.1% wmf usage stats). Right now the only difference in "Grade B" is support for jQuery (Firefox 2 > Firefox 3.6, Safari 3 > Safari 4)