Use MediaWiki core helpers to provide intro messages (including edit
notices), initial page content, and CSS classes for the edit area.
The following intro messages were previously unimplemented,
and will be shown now:
* 'sharedupload-desc-create'
* 'sharedupload-desc-edit'
The following intro messages were previously unimplemented,
but they only apply to pages where VE should never be available,
and will be shown now when editing those pages with 2017WTE:
* 'code-editing-intro'
* 'talkpagetext'
The following intro messages were previously unimplemented,
and are now explicitly skipped:
* 'editpage-head-copy-warn'
The following intro messages were previously unimplemented,
but they only apply to pages where neither VE nor 2017WTE should
ever be available:
* 'userinvalidconfigtitle'
* 'usercssyoucanpreview'
* 'userjsonyoucanpreview'
* 'userjsyoucanpreview'
Depends-On: If0b05710cb52a977bf4e85947d72d68683a0a29e
Bug: T201613
Change-Id: If26e39e383b983f7ee834ed6dd73b80e0545b068
Target#actionsToolbar and Target#toolbar refer to the same object
since change dfaed62d3632d381db9682c603b3ddbeed182292 in VE/VE
(barring bugs like T335469). Once we no longer use the old name,
we'll be able to remove this backwards-compatibility alias.
Bug: T335469
Change-Id: I577e8ae6a857519eb0e8181543ca0a96b515e019
It appears like this was never tested.
Now that it is covered it's much easier to play around with the
implementation and compact it a bit.
Change-Id: Ie9cc14082f69e7240380d352fb362d0a3fa4d341
Parsoid will start populating the link content with the alt text if it's
available before falling back to the filename. Preserving what's there
is needed to avoid dirty diffs during the transition and for cached
content. In the future, we can remove errorText and replicate Parsoid's
new behaviour..
Bug: T273014
Needed-By: Iddf3e204d6e489cc8a33034da0d9e540efe65553
Change-Id: I7ab3d141b1df92d4447f7e3d6164082844d5bd10
This reverts commit a92dce4999.
A workaround for the previous problem was added in ContentTranslation
in I945897a27db479986855002b389034a745bf9bef.
Bug: T325249
Bug: T325566
Bug: T327779
Change-Id: I2d9c330dc4328468a65315ec6bed1d0f53ebd1f6
At first I was going for a more minimal replacement of mw.Uri with URL,
until I discovered that this code depends on a mw.Uri bug that would be
difficult to replicate:
// Expected: Relative URLs are accepted
new mw.Uri( '/foo' ).toString() // => 'https://localhost/foo'
// Expected: Protocol is optional
new mw.Uri( 'example.com/foo' ).toString() // => 'https://example.com/foo'
// Unexpected: Treated as empty domain with no protocol rather than relative URL
new mw.Uri( './foo' ).toString() // => 'https://./foo'
So I went for a bigger rewrite to preserve the intent rather than the
exact logic.
I had to change some test cases to use more realistic fake data. They
previously relied on bugs in our URL handling to pass despite the base
URLs being incorrect, particularly for non-short URLs (see T270219).
In my testing non-short URLs behave the same as before in practice.
Depends-On: I07a8c097dba0f5572c0aedf4febdf1434063ea6f
Bug: T325249
Change-Id: I232361266c1dda795b88018c3aaa3d9ecbe42b93
New changes:
2201b350c Localisation updates from https://translatewiki.net.
da74736c1 Remove unused test code
d1b016e90 Minor test tweaks
551de4f0c Specify document base URLs in more test cases
Local changes:
* Specify document base URLs in more test cases
Change-Id: I0e301bef38d97fa2234aa901c787360d9fbde8a3
Our encoding for the hrefs like "./Foo" that we send to Parsoid
differed slightly from how Parsoid outputs them, so to avoid dirty
diffs, we had to store the original ones we received from Parsoid
and send them back if they were unchanged.
Change the encoding to match Parsoid's exactly (by referring to the
Parsoid source code), and then remove 'rawTitle'/'origTitle'.
On a historical note, 'rawTitle'/'origTitle' were originally added to
fix other issues with links, which I hope are long behind us:
* bb45d984ca (T145978)
* fda2e6c1b5 (T44140)
Follow-up to 362df66b47, which removed
some other old stuff from the handling of Parsoid links.
Bug: T325766
Change-Id: I0ad0a655380eb2fb29b5ac01e2e399ac550ce34a
For external links, `.title` and `.rawTitle` properties previously
contained the external link corrupted with some normalization intended
for MediaWiki titles.
This was useless, and in fact no caller actually uses this value:
they all check `.isInternal` first before accessing `.title` or
`.rawTitle`.
Also, correct other parameter documentation.
Change-Id: Ieeab56548f0a3b2f81a90f0d3ae0f81d744aa67b
The dialog is unusable when there is no outline. See T313489 for a
longer explanation.
Bug: T313489
Change-Id: Ib2cc9c363d3596a16f6f1c4aef03ca216abf6b1f
The need for something like this was anticipated in
I2bf43c7e83283f43e047229eb53c244918fcbb0c.
As of version 2.5.0 of Parsoid's output, if alternate text is missing
for an image but a caption is present and image isn't displaying the
caption (ie. it isn't a thumb or frame), then the text content of the
caption will be set as the alt attribute. Parsoid will then drop the
alt attribute when serializing if it matches the caption text, since
it's unnecessary.
However, if the caption is modified and the alt text isn't, the alt will
be serialized. This is likely to be unexpected to editor. They may
have missed that the both the caption and alt are populated in VE and
only edited one place.
Since all of the above is happening only for images where the caption
isn't visible, it doesn't appear to be a much used feature since, at
least for inline images, the experience of caption editing was already
less than optimal.
However, because of a quirk in how galleries are rendered in Parsoid,
this affects gallery caption editing, which is visible and presumably
used more often. See T268250 for a discussion on an improved gallery
structure. But for now, gallery images are effectively inline and set
the alternate text, thus subject to the above.
Here we add a checkbox so that the default is to ignore the alt if it's
the same as the caption. And only make use of it if it differed
originally or was explicitly unchecked to modify.
Bug: T311677
Change-Id: Idf297d8a98995971c5835b0cea56c3317a3626e2
Introducing a set method to have a different state for a set
parameter and a highlighted one in the selection.
Allows us to remove a lot of workarounds for missusing the
highlight state and fixes several issues with these workarounds.
Main implications:
- Keyboard navigation and mouse hover now sets the grey highlight
- If a parameter is set (blue highlight) keyboard navigation returns
when focusing the SelectWidget
- If nothing is set keyboard navigation starts at the top after focus
- Unchecking a parameter using space will not influence the keyboard
focus in the list
- Highlighting a parameter with the mouse lets keyboard navigation
continue from there.
Bug: T312647
Bug: T311204
Bug: T312213
Depends-On: I385dca1d95033961d3844e888521750443e49c95
Change-Id: Iaf089f4b271fd853b17c1aa7f5938510ea8f5431
Technically the old BookletLayout sidebar is still there. But it's
never visible, effectively dead, and meant to be removed. This patch
just empties the OutlineItems of all template dialog related pages
without actually disabling the old sidebar.
Note this partly reverts Ie57f462.
Bug: T310859
Bug: T310866
Change-Id: Ic0b7d703f369045ed342426563f8eeb3e47046db
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
