Page MenuHomePhabricator

browsertests: triggers for VisualEditor
Closed, ResolvedPublic

Assigned To
Authored By
Sep 2 2013, 9:21 PM
Referenced Files
F11112: injectJs.js
Nov 22 2014, 1:45 AM
F11109: ve-ff.png
Nov 22 2014, 1:45 AM
F11111: ve-ph.png
Nov 22 2014, 1:45 AM
F11108: phantomjs-ve.png
Nov 22 2014, 1:45 AM
F11106: screenshot.png
Nov 22 2014, 1:45 AM
F11105: ve.png
Nov 22 2014, 1:45 AM


Similar to bug 52120 for ULS. Once we've got this running on merge, we'll want to move to running on submit (V+2 submit?), but for now…

Version: wmf-deployment
Severity: enhancement
See Also:



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:45 AM
bzimport set Reference to bz53691.

jhall wrote:

Assigning to myself per an e-mail thread with Antoine, Chris, and Željko.

Change 100797 had a related patch set uploaded by Hashar:
[browser test] cucumber default profile for CI

And I manage to get VisualEditor + Parsoid to be setup automatically using Jenkins. The related job configuration is pending in (need to be polished).

I confirmed the wiki is functional and managed to edit a page using VE \O/

Next steps:

  • cleanup the job configuration
  • make the wiki faster (sqlite is not on tmpfs as an example)
  • try to get at least ONE browser test scenario to pass (anon ones are good candidates apparently)

jhall wrote:

Sorry I wasn't able to get to work on this bug quickly Antoine - let me know if you want me to work on creating a new browser test that will succeed in this scenario (the existing anon test will fail since it presumes the existence of a User page in the target wiki).

Jeff : sure, if you can get a test that roughly does:

  • anonymous user
  • go to main page
  • press Edit (visual editor version)
  • ensure visual editor is loaded

That would be a nice first step that would validate the Jenkins job and VE/Parsoid is properly setup :-)

jhall wrote:

I went ahead and amended the existing Gerrit ID:

…with an additional anon test case that edits a random page (which will likely always be the "Main Page" for a fresh wiki install).

The test case currently does not work with PhantomJS, so I'll spend more time tomorrow trying to figure out why PhantomJS can't click into Visual Editor editing mode.

(In reply to comment #6)

The test case currently does not work with PhantomJS, so I'll spend more time
tomorrow trying to figure out why PhantomJS can't click into Visual Editor
editing mode.

In phantomjs, "edit" link is not visible by default, see attached screen shot.

Created attachment 14080
phantomjs screen shot


ve.png (5×529 px, 462 KB)

jhall wrote:

PhantomJS screenshot from VE editing mode URL

Thanks Željko. I tried modifying the "anon.feature" test to navigate directly to the Visual Editor editing URL (?veaction=edit), but from capturing both a screenshot (attached) and the raw HTML that PhantomJS lands on, it does not appear that PhantomJS is successfully entering into Visual Editor editing mode.

In any case, we're getting closer step-by-step, so I'll continue to work on this.


screenshot.png (1×546 px, 189 KB)

Could it be that phantomjs lack some javascript functionality that would cause VisualEditor to disable itself ? Might be a browser whitelist as well. Honestly, I have no clue how it is handled in VisualEditor.

jhall wrote:

Looks like it's not a problem with PhantomJS being blacklisted, per the VisualEditor browser blacklist which begins at line 890 of this file:

…so I'll spend some more time tomorrow to see if I can figure out why PhantomJS doesn't seem to work as intended even when navigating directly to an "editing mode" URL.

Looks like phantomjs is blacklisted (or not whitelisted). There is no visual editor edit option (see screen shot).

Created attachment 14130
phantomjs screen shot


phantomjs-ve.png (1×1 px, 550 KB)

jhall wrote:

Ah, I believe Željko is correct - looks like VE has a whitelist in addition to a blacklist. See section beginning on line 169 in this file:

Will talk to the VE dev team and see if we can get PhantomJS whitelisted.

If a browser is not on the blacklist, and meets the functionality criteria, then the edit tabs for VisualEditor should show up. A browser not being on the whitelist just means the user gets a warning when they edit. Adding PhantomJS to the whitelist will not make VisualEditor appear if it doesn't already.

(Also, you can bypass the blacklist with ?veaction=edit&vewhitelist=1 which should trigger VE even if you don't have a functional browser, as long as it has JS.)

Strange. I am pretty sure PhantomJS has JS. :)

But, this simple script takes screen shot that shows it can not load visual editor.

require "watir-webdriver"
browser = :phantomjs
browser.goto ""
browser.window.resize_to 1280, 1024 "ve.png"

If :phantomjs is replaced with :firefox, then visual editor opens just fine (see screen shots).

Created attachment 14137
ve ff


ve-ff.png (918×1 px, 115 KB)

Created attachment 14138
ve phantomjs


ve-ph.png (1×1 px, 92 KB)

jhall wrote:

Timo pointed me in the right direction:

jeffrey-hall:browser jeffreyhall$ phantomjs
phantomjs> Function.prototype.bind

Turns out PhantomJS is built with an old version of JavaScriptCore that is missing the "bind" implementation, which is needed to satisfy Visual Editor's es5 features check:

…but a workaround is available:

…so I'll investigate the workaround next.

Change 102960 had a related patch set uploaded by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

jhall wrote:

Changing bug status since task in still WIP.

jhall wrote:

Scripts used to evaluate PhantomJS "bind" injection

After a pairing session with Željko, I went back to basics and tried to get Function.prototype.bind injection working directly with PhantomJS (ignoring the rest of our test infrastructure for the time being).

Per the attached scripts, I tried all of the relevant methods noted in the PhantomJS API documentation:

...and still no luck. The Main_Page loads fine, with the exception of the VE editing link/tab, which is available to other browsers (Chrome, Firefox, etc) at the same URL.

Per a suggestion from Antoine, it might be time to investigate using Firefox in a headless mode as a potential substitute for PhantomJS.


jhall wrote:

After some further investigation, we've decided to use the "headless" Rubygem for headless browser testing, and we've decided to incorporate that support into the mediawiki-selenium Rubygem so that it will be available to all WMF repositories that have browser tests. The task for updating the mediawiki-selenium is captured in Bugzilla 60584.

Change 102960 abandoned by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

Abandoning this patch since we have implemented support for headless browser testing in the mediawiki-selenium Rubygem (rather than implementing it in each individual repo).

Change 110468 had a related patch set uploaded by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

Change 110468 abandoned by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

Abandoning this change since I'm going to start fresh with a slightly different approach.

Change 111890 had a related patch set uploaded by Jhall:
[Browser test] New test for headless browser testing on a fresh Mediawiki install with VisualEditor.

Change 100797 abandoned by Hashar:
[browser test] Cucumber default profile for CI

we are using something different than the ciwmf profile.

Change 111890 merged by jenkins-bot:
[Browser test] Headless browser test(s)

jhall wrote:

Basic test is merged and in place, so marking this bug resolved.