I'm more in favor of leaving no garbage behind. The TODO with a date
is a good way of making sure this gets removed eventually.
This could have been part of Ie6eea76. The new code is added to the
same spot where the code removed in Ie6eea76 originally was.
Bug: T296471
Depends-On: Ie6eea76dacdc614ecb910c48e7e1f519b8c69322
Change-Id: Idec63201ff4aa52a0c53c6d007577a93c94e0ec0
Following the MediaWiki changes from T301203, we should use
the messages 'skin-view-edit' and 'skin-view-create' instead
of 'edit' and 'create'.
(Also remove redundant definitions in extension.json, we load
all messages listed in 'VisualEditorTabMessages'.)
Bug: T310529
Change-Id: If055fa2a4dc009be869425e6c2262c9b62056179
The "mediaClass" property now only serves to capture the original class
found on the media so that it can be roundtripped without causing dirty
diffs. In the 2.4.0 version of Parsoid's output, that will still be
the usual Image/Audio/Video. As of 2.5.0, it will always be File and
the mediaClass property can be dropped.
Parsoid is currently forward compatible with serializing mw:File, so
edited or new media can use that type already.
The contextmenu item for media has been updated to make use of the
"mediaTag" instead of mediaClass to continue distinguishing media types.
That was the only place a grep of mediaClass turned up any use.
Bug: T273505
Change-Id: If5dc6b794dacd6973d3b2093e6b385591b91d539
Before the (intentional) design decision was to not do anything special
when the same parameter is used multiple times (via aliases). Garbage
in, garbage out. Only the first usage of the parameter would work as
intended. The rest was ignored and subsequently removed from the
wikitext.
New design decision: Track and display duplicates as they appear in the
wikitext.
Notes:
* It's not possible to create such a situation in VE. Do this via
wikitext.
* Labels will be made distinguishable via T309198.
* Possible warning messages will be added later.
* The behavior when unchecking a duplicate will be specified later.
Bug: T309198
Bug: T310248
Change-Id: I6011344638cdad8529d8f57513ef51b5237eb878
Parsoid stopped emitting figure-inline in content version 2.2.0 and VE
requests 2.4.0, which isn't satisfied by the earlier versions.
Change-Id: I5f47fbe85fdca7fe429952709b62f5d1cc548daf
This only happens in AMC. Currently it is also not possible
to update categories in VE, but this may become possible if
we enable 2017WTE on mobile.
Change-Id: Ifeb6cc18910ce2fca634bc3e2245aac7e5c37e52
The previous comment was true, but we forgot another edge-case. The
same parameter can appear multiple times. The old code tried to
delete it 2 times, which deleted something else.
Note that the behavior for duplicates is larely unspecified. We
will work on this soon. This is only a first quick step to fix this
specific bug.
Bug: T309203
Change-Id: If0afb2c19626c3d9db0d109d6559ae74698ed378
This avoids a meaningless attirbute change with the image
is unmodified (as thumbUrl can be a different size).
Change-Id: Ib79a4703382552e38022a3f345ca5cd762c52303
Needed after Ia18f31a299338f94e69f1882e6e477f3a22ae905 in VE core.
Bug: T307849
Depends-On: Ia18f31a299338f94e69f1882e6e477f3a22ae905
Change-Id: I87f3ac0974702ecaf7f5459604371de06f4a5756
Now done in VE core since Ie86217ba5651df8c427464e460ed836903834a3c.
Bug: T308200
Depends-On: Ie86217ba5651df8c427464e460ed836903834a3c
Change-Id: I3f65b0bc100895f7bd2262c3cbb5231fb055758b
This lets us begin the import from another page, for example an edit
tab or button.
If the CollabPad page already exists, it will be opened without
overwriting with freshly-imported page contents.
Change-Id: I89293b9b06253243826d8f8144a5e93d55856e7c
* Implement ve.dm.MWGalleryImageNode.static.isDiffComparable to
match ve.dm.MWImageNode, in that images with different resources
are not compared.
* Diff galleries as documents so remove/inserts are rendered.
Bug: T308747
Change-Id: Ide6f4110e65cad7f6bb6d13766815413602fd991
Visual Editor currently requests MediaWiki DOM version 2.0.0
when talking to Parsoid. Since Parsoid treats that as a request
for 2.4.0, its current version, and Parsoid doesn't have a
2.4.0->2.0.0 downgrade path, passing the latest Parsoid version
(2.4.0) should make no difference in practice -- but would better
match current reality.
Change-Id: Ia2bc0c1981db6f573a69fb1910cef4304c80ae00
Now that Parsoid's ServiceWorkers have been merged to core, this adds
support for "zero configuration Visual Editor" to the master branch.
Like earlier zero-conf work, this does not use RESTBase for stashing
or for reliable selective serialization. Future integration work
with ParserCache will reintroduce this functionality. Nevertheless,
this implementation should have feature parity with the "loopback interface"
zero conf VE we've been shipping since 1.35.
Bug: T305108
Change-Id: I7b5b4a6d16b07914f947cbaf498ad1d3cf2447a5
This patch fixes a bug which causes long parameter descriptions to
be to non-collapsible when adding them from the sidebar-only view on
smaller screens.
Change-Id: If373587a9b2c3841ad6814f74bfcbf0c0f013488
This is done in preparation for Iac6205f to make it easier to review.
This patch here is meant to be a no-op that doesn't change anything,
just moves existing code around.
Bug: T307986
Change-Id: Ie6ccd9528e5799ba340fed344e1f47a443c2c51f
This is currently only handled in DesktopArticleTarget in teardown,
which happens after we've wasted time trying to update the page.
Also ensure we always reload on non-view pages on MobileArticleTarget
for other types of teardown (e.g. quitting the editor).
Change-Id: I7fb352fcacc8727bb113115e98af38a3940a8f9c
Follow-up for what was done in I37505af. I don't fully understand why
these two extras are sometimes needed and sometimes not. But this exact
combination of 3 properties is used in multiple places already, so
let's just do the same here.
Bug: T300008
Change-Id: I1eba5fc378475d365111add58a141c3114dc0118
This focuses on some scenarios that are
a) complex enough to be worth a test,
b) but simple enough so I don't need to spend hours on comming up
with a test setup. ;-)
This patch also simplifies the ARIA related code in
MWTransclusionOutlinePartWidget a bit.
* Check 1 of the 3 ARIA configs only. Only having one is already
helpful and should not be skipped.
* No need for the large conditional. setAriaDescribedBy() works fine
with undefined.
Bug: T291157
Change-Id: I142782ec9b96147de64497f4f6a373eae05b9c8e
The idea of the code under test is that it combines the results from
2 different API requests in a specific way. This is a first basic test
where both search results are small.
Bug: T291158
Change-Id: Ic4de57fb6b85afb952ea604769fddd06d44814c0
Will implicitly set a max width for the button due to the margin.
Long words will break in the middle of the word.
Also includes a shorter label.
Bug: T300008
Change-Id: I37505af8383d8c0c2bd4af3987ec5e2a3049688a
Will be removed when parameters are added. Needs different margins
depending on beeing shown in the single transclusion mode without
header or on multiple transclusions.
Bug: T300710
Change-Id: Ieb95d7276aa4d4b0fcbb74f87ab734e4a393dc21
Requires switchToFallbackWikitextEditor to return a promise.
We can now pass dataPromise to the progress bar shown when
switching editors, so it hides if the switch fails.
Also fix logic for when a failed load is not retried.
Bug: T306763
Change-Id: I752ca505e7957b392202d44455b1e21b6e50fa63
If links get pasted into VE and they lack a "//" in the `href`, they
are automatically considered to be "internal", thus being converted into
`[[...]]` wikitext links.
In case of pseudo protocols like `mailto:` this should not be the case.
This patch uses MediaWiki core settings to check if a `href` value is an
external protocol known to the application.
Bug: T297575
Depends-On: I2e584f6d5adc6b2d735e79cea64f2beeb5f2c36d
Change-Id: I2b383106450e02cc6bcc1b99d547ff2ed7832b4c
Before, the fallback algorithm was somewhat adaptive, trying harder and
harder the fewer CirrusSearch results have been found. This updated
algorithm guarantees that 10 results are shown.
Warning: You might see only 9 results. The reason is a bogus, unrelated
behavior in the mw.widgets.TitleWidget in core that's used as a base
class here. There is a "showMissing" option that's apparently enabled
by default, and prepends a non-existing title from the main namespace,
ignoring the "namespace" option. This extra result from the wrong
namespace is later dropped by the very same widget.
This code here sees 10 results before the bogus one is dropped.
Disabling "showMissing" causes other issues. We would need a series (?)
of custom hacks to work around all this, but this seems inappropriate.
Let's live with 9 for the moment.
Bug: T303524
Change-Id: I2c577c9ef2752b6c6cd360f4023e151e9272fcd5
The main advantage of this change is that it drops the assumption
that the index starts with 1. This is not necessarily the case when
we prepend extra search results. Dropping this assumption here allows
to simplify such code.
* The incoming list of pages is guaranteed to be an array.
* There is no point (any more) that could cause the array to become
sparse.
* Note we still make a copy of the `origPages` array at some point,
e.g. on `.filter()`.
Bug: T303524
Change-Id: Ifbd92bb052155c613d2ca21ab6d54a0b3ef28c0c
New changes:
72bd71dbc Localisation updates from https://translatewiki.net.
b7f38d993 Re-apply "Fix for showing "invisible icon" when root node is hidden""
Local changes:
* Ensure templates are attached to DOM before rendering invisible
icon in converter hack.
Bug: T305110
Change-Id: I0e4c02619b2a06b9932f214ae482093fdb0cb22c
This option is not only buggy (it just doesn't work when the namespace
option is set the same time), it is not useful in this context even
if it would work. It doesn't make much sense to suggest non-existing
templates in the context of the template dialog. If adding a
non-existing template really is what the user wants, they can still do
this by simply typing the name of the template and submitting the form.
We never need this to show up in the suggester below the input field.
The main advantage of this change is that is saves 1 useless API
request that's potentially done every time a key is pressed.
Bug: T303524
Change-Id: I903340a06d6e6490bb58f628f41903aa044ccb21
This separates the two steps:
1. See if items in the list of `origPages` miss their `.index`
property, and add it if possible.
2. Later code doesn't need to care about redirects any more.
Note that `origPages` is not used for anything else. And even if,
it's not wrong to have the index for each search result on both the
redirect and the redirect target.
Change-Id: I12135f0430c944b4e33c49ece7779d7c3bb6c211
This is not a pageid, but a simple numeric index in an array. Luckily
it doesn't make a practical difference for this particluar way of
iterating something.
Change-Id: I7ec9ace00d4fba7adde17670058a0365b30f5617
Such comments don't add any new information. The method signature
alone already tells the full story.
We did this already to a lot of the template related code we touched.
This is just a bit of cleanup to make it consistent.
Change-Id: I932b620910924a16dc0d31d6c8a3ab11818316fe
The numeric part of these ids is never used on it's own. There is no
need to expose it.
Note we renamed the method not long ago in I6eeab8b to reflect better
what it does. This is the next step. We just forgot it back then.
Change-Id: I5da82855e99ea3a42a5d91379c6974ae9c154518
The result is guaranteed to be in formatversion=2, where the list of
pages is an array, not an object.
Change-Id: Ic73a68c3e249a70108a6a19a89f4ff6c475794ed
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
