Overriding ve.ce.BranchNode#onSplice seems pretty scary, some bug
could cause two captions to be inserted and it wouldn't even be
visible in the editor.
Instead, allow normal splice handling to happen when the caption is
added/removed, and only override the position where it is inserted
(to account for the image node this.$a).
The caption node is already removed from DM/CE if the image type is
changed to one that doesn't have captions, and even if that failed it
is also hidden in CSS, so we don't need to handle this.
Change-Id: I54f52b288118d692708311512dd674cc85d5d9e3
5f6664e2 in VE core changed the specificity for some of the rules this
expected to override.
Bug: T189267
Change-Id: I510e151cc431c321d1d45fde9030d56f059d84ab
Various checks didn't think a rel attribute could contain multiple values.
Mostly they don't, but to play it safe let's adjust the checks.
Change-Id: I29823b7c8c65ef6b2ff41ce9a801840000972e9c
Depends-On: I33a456351ab025d0c81cfb1a1577d5a2ae9df51a
New changes:
7551f6c66 [BREAKING CHANGE] Rename class ve.dm.IndexValueStore->ve.dm.HashValueStore
Local changes:
Follow-through rename of IndexValueStore->HashValueStore
Bug: T188900
Change-Id: If60d0c637fe92f0e7afe916c064fafb17980d063
Parsoid now handles empty headings for us in
scrub_wikitext mode (which we use).
This reverts commit 884f301aa0.
Bug: T187913
Change-Id: I8690bbced64be76622929f78f9c9e0d8f85d4be8
This lets copy-paste between documents retain the numbered status rather than
falling back on pasting "<a>[3]</a>".
Update the part of LinkCache which selects on mw:ExtLink, so it will handle
possible multiple values in the link rel.
Bug: T188429
Change-Id: Ia5e4c9fa45e94da9cbfcd2a42d017d0fda1c511f
Always store immediately if fromEditedState is true. Also
now that we only store if there is state to recover, remove
the check for transactions before deciding to show the notification.
Change-Id: I5357a9098b91e303f5c71881ea03a080d2969fff
updateSize eventually calls setDimensions, which calls
positionDiffElement, so protect against infinite recursion.
Change-Id: I07992f337394712000e6e12c637c6e1442869722
Specifically, set arabic(extended) and hebrew to 'rtl'.
Logically depends on I14abd3e0c0d23f79aa01d96c216eea913024b4c8
to set the dir attribute in UI.
Bug: T56310
Change-Id: I1c7e28d3d2f20ca84115be6d49650cd9a81d78dd
1. It wastes valuable time during setup.
2. If a user reloads the page without making changes we
should give them the latest html from the server to
minimise the chance of an edit conflict.
Change-Id: I9a1f8cfd65ef2552fe2c3d6d2bbf975851b52003
After change 89aecd54ba (2014),
there is no 'border' value for the 'type' attribute, instead
there is a 'borderImage' attribute only present when 'type'
is 'none' or 'frameless'.
Change-Id: Id87ba09b647f5f69b1c9350209e66acdea2c9d69
MWBlockImageNode already can't have any slugs:
* It can't have inline slugs, because it can't directly contain
content (`this.canHaveChildrenNotContent()` is true)
* It can't have block slugs, because it can't contain paragraphs
(`this.isAllowedChildNodeType( 'paragraph' )` is false).
(The only thing it can contain is a mwImageCaption.)
Change-Id: Ice6505da2356f004ef048ed0b1a9e03d08af02d1
Let's keep the ugly regexp and the comments about why we do this in a
single place.
This is mostly without behavior changes, with three exceptions:
* ve.dm.MWImageModel#attachScalable now passes a title with spaces
instead of underscores to the Scalable (this doesn't matter because
it's normalized to use spaces later anyway).
* ve.dm.MWImageNode#getFilename now returns a title with spaces
instead of underscores. This is used in some API queries and when
rendering thumbnails for missing files, and this format is actually
more correct for both of these.
* ve.dm.MWTemplateModel now URI-decodes the template title. This
actually fixes a bug where trying to edit a template transclusion
whose title contains a '?' would throw an exception about invalid
title.
Also, clarify that the return value of ve.dm.MWImageModel#getFilename
and ve.dm.MWImageNode#getFilename is different :(
Change-Id: I8e09015cea82308017ed925ec755b7231518126e
Ensure we start with the same HTML (i.e. if an edit has
been made since the crash-recovery):
* Whenever an article target is activated, stash the initial
document html, other parsoid response data, and the request
parameters (pageName, mode, section) in session storage.
* Whenever an article is fetched through the target loader,
recover from session storage if the request parameters match.
Store transactions:
* On document transaction (debounced) append the latest
changes to session storage.
* If a document state is recovered from session storage,
attempt to re-apply the stored transactions.
Clear transactions:
* Whenever the target is torn down (i.e. save, deliberately
closing the editor to go back to read mode)
Other:
* If writing to session storage fails once, disable future
attempts for that session (assume storage quota exceeded)
* Disable tempWikitextEditor when recovering. We don't have
the transaction code loaded yet to perform the recovery.
Bug: T57370
Depends-On: I3832243fc347a99641fcb7e39a887a153c9a3b22
Depends-On: I448fb566fe9f7f5b5a76e88b70ca000e3d35b415
Change-Id: Id9d877f903cf4796a52f90991c030417a9f8786f
