This isolates this extension from knowledge about the constructor
signature of the helper classes. Constructore signatures are not stable
interfaces.
Needed-By: Ie430acd0753880d88370bb9f22bb40a0f9ded917
Depends-On: I10af85b2da96568cfffd03867d1cb299645fb371
Change-Id: If1914dbfbefc3501b4d4cef4beb1fae307c36455
* Rename imported classes in VE that will be renamed in core
* Re-enable tests that would fail when the core patch is merged
Depends-On: I506f3303ae8f9e4db17299211366bef1558f142c
Change-Id: I59ebeb24fa0de5f10d1501cc0830c7e4805e1003
HTMLTransform is being renamed at I506f3303ae8f9e4db17299211366bef1558f142c.
This is a temporary measure to allow CI to succeed in the core patch
Change-Id: Id11068e34d4b3ed6ccc210c91e449656e74138a2
When receiving HTML from a VE session, process it with the same kind of
ParsoidClient that was originally used to generate the HTML. If we were
to use a different implementation, the ETag wouldn't match, so we would
fail to find the stashed data-parsoid map, and the edit would fail.
Bug: T320704
Change-Id: I3b73431fccacecb4ad88b82f8f5675b1042e03ce
AutoConfig was used to set VE to call internal REST API endpoints exposed by the parsoid extension.
With DirectParsoidClient available, this is no longer needed.
NOTE: this causes all wikis that do not have a RESTbase backend
configured to start using DirectParsoidClient. This is true in
particular for officewiki and labswiki.
Bug: T320704
Change-Id: Ia4c6184dd75a653c3202ea160b6605335f36f6eb
If VE is configured to call parsoid directly in PHP, the client
should not try to fetch HTML from restbase. Doing so will
lead to inconsistencies, and may cause edits to fail.
Bug: T320704
Bug: T320703
Change-Id: I98bfdd305dcd188d91db6a8fe5885156cdeca7db
* DirectParsoidClient makes use of parsoid directly for performing
transformations on both wikitext and/or HTML contents.
* Also, it's used to fetch HTML from parsoid's parser cache. Before,
this operation was done via RESTBase but now it's being fetched in
core's parsoid parser cache.
* This patch also enables VE clients to transform HTML to
Wikitext when switching from HTML to source mode on. It
makes use of the HtmlInputTransformHelper to perform this
transformation.
* Now, VE client can make use of core code for switching
between HTML to source mode and back without RESTBase.
Change-Id: I5c7cfcc4086d8da7905897194d8601aa07418b59
This adds assertions for the return values of the following pactions:
metadata, parse, parsefragment.
It also adds a test that asserts that edits are not possible with
an invalid token.
Change-Id: Idb453d3561a46930afb5366c1a96787895fc8e40
This VE paction was removed in I90d775dd71d5f5a61d651b63d946ab60a27e2ca3
so this code can be deleted per Bartosz, so this patch removes the code.
NOTE: A merged API test that uses this is also removed along side.
Change-Id: I4ff75df57fd58f508ef7212486e52cb11a7cfb57
The test file is just a placeholder for now, so we can enable the CI job.
Actual tests will follow in a separate patch.
Bug: T318403
Change-Id: I8105f49f8898c8ebfd80eb898d30a49e58db5b25
* DirectParsoidClient: Actually allow null to be provided.
Previously we tried to call methods on it unconditionally.
* VRSParsoidClient: Require the param to be provided (even if null).
No reason to diverge from the interface, which requires it.
Change-Id: Id9a450dc8b8eb3e82cf87718b96975e5a3c6180c
This follows up the initial fix with additional sanitation and a
regression test. See I21c7a2b2541061a858a9791a2cb12866acd38dc5.
Bug: T318083
Change-Id: I4e433e711c068336a888f4aafa243455764fd710
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
This patch introduces a factory service for creating VE Parsoid
clients.
NOTE: This patch also injects a GlobalIdGenerator to the client
and avoids usage of deprecated UIDGenerator class.
Change-Id: I787c0afb227308aab56770d14d62e08eb0084a6c
EditPage.activationComplete() was flaky.
We have replaced it with EditPage.toolbar.waitForDisplayed().
We have run all the tests 100 times in a row in CI and it works fine.
Bug: T310772
Change-Id: I321b4114ca03ebd02a79d8bd3863ea0e68494dc2
The 'should save an edit' test is skipped because saving an edit fails
in CI because of T309712.
Bug: T296187
Bug: T309712
Change-Id: Ie4f067ed9b49a993acadaa01c953a9fe46aaae81
selenium-daily-beta-VisualEditor Jenkins daily job became really
unstable. Let's run just the simplest test for a few days to see if that
would help with job stability.
Bug: T296187
Change-Id: I858a3c5614277ea029fdabfd4468bb0d124e94d5
Looks like Selenium tests are flaky. To improve debugging:
- Move code from beforeEach hook to specs.
(Video recording happens only in specs, not in hooks.)
- Increase logLevel from error to info.
Bug: T296187
Change-Id: Iffcfae9a76085670eb8858fbcf622e596a4ff2f0
The goal is to have some tests fail if a new property is added to the
API result, but it's not stored in auto-save data.
Bug: T305225
Change-Id: I9ac328c71c616a8f33e1cfb39431cd9a665adafc
This is needed because the $params array is then passed on to
ApiEditPage, so if the hook implementer wants to alter the data used
with the edit, it needs to be able to modify the $params.
See I494d72a42d9103c28c4d44077cfe0f1269fc7b00 for an example where
GrowthExperiments would like to modify the 'tags' parameter for an
edit.
Depends-On: Idd052281898f99e4f13f241d5633294b59b29329
Bug: T304747
Change-Id: Ia4842a1593028f5fa145de167ccf9b72efa81351
A better assertion if the VisualEditor is opened would be to check for
editing toolbar instead of checking for a notices popup.
Bug: T296187
Change-Id: Ide816646254bc856b44725490c25b2b9962188c9
This allows nonexistent translated pages to fall back to the
corresponding page in a suitable language.
Bug: T299544
Change-Id: I43f461e9f595c364ecdaf2faccbd580fc0df6799
Use paction 'metadata' instead of 'parse' by default, to avoid
accidentally using VirtualRESTServiceClient when testing cases
that don't require it.
Change-Id: I02492a2dc444cf531a5c8767b0dcfe0d20ac7339
