Wikimedia Bugzilla is closed!

Though I understand the wish here, I'm afraid we in the core team have got our work cut out for us just supporting the latest, core versions of Firefox, Chrome, Safari and IE.

We've already spent a good deal of time looking at compatibility with older versions of these four, with Opera, and other browsers or forks of these browsers (like Iceweasel, which from our testing is not just a re-badge of Firefox, but works differently in unexpected ways). It's not a case of just adding browses to the whitelist and assuming all will be fine.

Our current browser support policy [0] is still in draft, but given the huge variance we're finding between browsers on their JavaScript models, how they react to key-press events, and similar issues that are key to making VisualEditor work. That's quite apart from the browsers that claim to support key technologies but don't (like Android native browser before 3.0) and those that don't even reach that far (like Opera Mini).

It's very important to us that we don't give people false expectations of the VisualEditor working for them only to break somewhere down the line because their browser can't or won't follow what limited standards there are, or that appear to work only to break wiki content terribly when people save their changes.

We would of course be delighted to accept git pushes that would fix the compatibility issues with Iceweasel and other more minor browsers, though that will be quite a lot of work in some cases. Sorry that we can't give the support you want here.

[0] - https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q1_forward-look#Browser_matrix

but it's difficult for people to dig into code and find out the behavior that doesn't meet VE's requirement.

maybe create some abstract layers over browsers?

Iceweasel seems to contain some backports from newer Firefox.

I agree that it's difficult.

For example, most of the point of the approach we've taken is to re-use browsers' native capability - this means that we can support IME, spell-checking and other things important to users of our wikis that would be (even more) hugely complex or impossible to implement in VE itself. However, this means that abstracting behaviour would go in completely the wrong direction - for more on this, see our (abandoned) EditableSurface attempt, before we switched over to ContentEditable for the core surface earlier this year.

A simple example of the difficulties is that Firefox triggers a keypress event on special keys that other browsers don't, such as the cursor keys; this means we need to catch these but only on Firefox to avoid hugely unexpected behaviour (such as removing text when you make a selection with the keyboard). This, and dozens of issues like this example, is why we don't have the resources to support browsers further down the chain.

Abstract layers can be done in another way. For example in your case, keypress is different, so we make our own keypress_ve, and for normal browsers, just use a wrapper function to map keypress_ve to keypress, but for Firefox, filter special keys out before mapping.

So now for a new browser, use a simplest wrapper and ask people to press keys to test it. Once we find its behavior strange, make a special wrapper for that browser.

I assume you have some kind of tests for the different functionalities. Exposing them would allow:
a) Users to beta test the functionality on the UA of their choice.
b) Vendors to actually test what fails and needs fixing (eg. Iceweasel maintainers)
c) It's much more clear what is not working for each browser (or if it just hasn't been tested).

Looks done in Gerrit change #46668?

(In reply to comment #7)
> Looks done in Gerrit change #46668?

Whoops, sorry, yes, we didn't mark this bug as fixed then. Resolved since the 4 February roll-out.