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
Setting the config var then loading mediawiki.action.view.postEdit
will already trigger the notification code, so we can remove this
duplicated code now.
Bug: T240041
Change-Id: If0d1aa4e734dab7cca168e78216f229b9924bab7
This follows up the initial fix with additional sanitation and a
regression test. See I21c7a2b2541061a858a9791a2cb12866acd38dc5.
Bug: T318083
Change-Id: I4e433e711c068336a888f4aafa243455764fd710
All code that used to live in ParsoidHelper has been moved to
VisualEditorParsoidClientFactory and VRSParsoidClient.
ParsoidHelper is no longer needed.
Change-Id: I21c4a8cd86f8d085e75a601ed6d2509dedd75d42
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
A lot of this just repeats what is already set by some other rule,
e.g. because it is the OOUI default anyway. Warning. This patch is a
little more agressive. I tested it on desktop and mobile, even with
MonoBook, and could not spot a different. Please do some more tests.
Change-Id: I0ee6e70f4f14c20d431643c53031d6d5b8df1aa2
In order to make this interface cleaner and not promote the
use of optional parameters when not needed, make the factory
required so that callers should worry about it and not overwork
the helper.
In this case, DiscussionTools extension is already using this
interface and has the factory injected appropriately.
Depends-On: If682af406c0fc7a9eca106eb3ebd95e6c14baddd
Change-Id: I836c0ad73687d8b99d1e067a5c3a3e512b4bd37a
Getting the correct client is now done via the VisualEditorParsoidClientFactory
so this is no longer needed. Follow-up of: I787c0afb227308aab56770d.
Depends-On: I4b9e7362a1bf1b4f224c8c652d40851a18c19824
Change-Id: I175aef2326a0d784fb8211542a3fe90cbf6c6d08
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
$targetContainer was calculated at the top of the file,
but it's only guaranteed to be available after jQuery ready event.
Bug: T314952
Change-Id: Id5d0c71433bfc51cb7193ee1b931a7dd8a4324d9
Follow-up to 951348dbbf. When creating a
new page on a RESTBase wiki, ETag is actually expected, but it will be
in a different format; the code comment was wrong.
Bug: T316969
Change-Id: Ia36488616ced70b900d2e67ce8e28993cc2c7514
Factor out getAvailableEditPageEditor from getEditModeFromUri
and use instead of getEditPageEditor everywhere.
Bug: T316776
Change-Id: I34bab092b829124c52f8bc0e262a9c3aa17f2c52
This means if you load the editor on a single edit tab wiki,
then press back then forward, the editor will re-open.
Bug: T316869
Change-Id: I1ea33de7d7324a53399be9155c474a14ae21dfe8
This code is supposed to be similar to the code in activatePageTarget()
however it was checking if the *link* URL looked like a veaction link,
not the view URL. It also then tried to push this.href as the new state
which was always undefined. This meant:
* If the section edit link was veaction= then nothing happened. The URL
in the address bar would get updated *after* the editor loaded by code
in DesktopArticleTarget.
* If the section edit link was edit= (single edit tab wikis) then the
view URL would get replaced with and edit URL, meaning if you browser-
backed out of the editor, the URL was stay as the edit URL.
Bug: T316771
Change-Id: Idb5e3c51a22361e0d9916d3c31444daeff310ed2
