* 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
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
This fixes two issues:
1. .initializeAllStickyHeaderHeights() is now executed after the
.ve-ui-mwTransclusionDialog-single-transclusion CSS class is set.
This is critical because in this mode the sticky header does
have a different height.
2. We get rid of 2 references to .sidebar that should not have been
in this class in the first place.
Also bring some more calls in an order that makes sense. This does
not make a difference and is only for readability.
Bug: T315292
Change-Id: I22f6c11de8f693edb03485adcaa186bd4b283b2f
I'm pretty sure this extra call is just pointless. This "choose"
event is triggered every time a new parameter is added to the list of
parameters. But there is another code path that is triggered in the
exact same situations: the onReplacePart event handler.
As far as I remember this "choose" handler was added very early when
the other events haven't been implemented yet.
This should be fairly easy to test. The only situation where this
could make a difference is:
1. When you have a template with 3 parameters and you add a 4th
parameter.
2. When you edit an existing multi-part transclusion that contains a
lot of parameters, but the parameters are initially hidden. The
widgets are only created when you click "show all" or start
searching.
Change-Id: I59e3873a4fe6fa5a01d681fce89fbe00756ae815
This was missing when you:
* Insert a new template and select a template with a lot of
parameters.
* Same when you edit an existing multi-part template and add a new
part (Ctrl+D) with many parameters.
Bug: T315292
Change-Id: Icd281c21a1b40d8e29343fa4975e27e8d927cd15
This is only an issue when a long parameter description is collapsed.
The float is a left over from a time when there was a delete button
on the right side of each parameter label. This is gone.
Bug: T310137
Change-Id: I249f0592de9c73a07af22bd7f86241caf0207770
