As described in T326169, when editing a (manually created) cross-wiki redirect,
VisualEditor will throw a null dereference exception causing it to fail to load
in the browser (looking like it is just taking forever to load).
This patch prevents the exception from occurring by not attempting to write to
the null object.
Bug: T326169
Change-Id: I50fa803c7b4ce65dac1fe345431d8b8f9d0b3d61
(cherry picked from commit a9278f654b)
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
Preserve the place of annotation meta tags; adds information for the
users about annotation and, if necessary, annotation range extension.
The messages and individual handling of annotations for the annotation
range can be defined by the extensions: see I0b58a418 for an example
of how that can look like.
The structure of this patch closely follows the one from I104e7abbd
(handling of <noinclude> et al.).
Bug: T261181
Change-Id: I39029e4a63d22b37107edec066006557bcff34bf
The difference is that metaitems are not visible on the editing
surface, and their exact position is not preserved when the paragraph
containing them is edited.
This behavior is desirable for e.g. categories, but not for
<noinclude> and related tags, which are intentionally placed in
specific places in the text.
Note that we don't really have any editing interface for these nodes
yet. But you can see them (and they come with descriptions and links
to documentation pages), and delete or copy-paste them.
Bug: T250937
Change-Id: I104e7abbd650567df0e59813653c46a66d955d58
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
Parsoid does not use relative links anywhere anymore (T72743). There
is no reason for us to support this. And previous code allowed
"hrefPrefix" to be empty '' sometimes, which is scary, as it could
lead to XSS vulnerabilities if titles starting with 'JavaScript:' are
not handled correctly elsewhere.
Bug: T206357
Depends-On: I8728f63084902c76d1c61193be4367939b069f1a
Change-Id: I99be18877aae2b505cf261bd7cdef6cf0d7a8670
New changes:
71baf1c02 Create an 'htmlMsg' function for HTML messages with HTML or DOM arguments
9a7af223e Use ve.htmlMsg to highlight values in attribute changes
a1fd90540 DiffElement: Refactor describeChanges tests
Local changes:
Implement getHtmlMessage in mw.Platform and use for DiffElement
Bug: T195243
Depends-On: Ib4ad16858e4241d33d018830dbcfded63ff703af
Change-Id: Ib5fa39e4f2f529948354b03a141542e23d169fe0
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
We're getting rid of meta item grouping, so we need to prepare.
Merged:
* ve.dm.MWIndexMetaItem
from ve.dm.MWIndexDisableMetaItem and ve.dm.MWIndexForceMetaItem
* ve.dm.MWNewSectionEditMetaItem
from ve.dm.MWNewSectionEditDisableMetaItem and ve.dm.MWNewSectionEditForceMetaItem
* ve.dm.MWTOCMetaItem
from ve.dm.MWTOCDisableMetaItem and ve.dm.MWTOCForceMetaItem
These three now inherit from ve.dm.MWFlaggedMetaItem to avoid code duplication.
Change-Id: Ic8a9cdb1226dccac2c27e7f4b965c1590a7387c0
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
Since all transclusion nodes can be interacted with (including the
'hidden' ones,) there is no need for MWTransclusionMetaNodes.
Change-Id: I23d37e3d82029b7475ec68ebb04883c7e05370cc
We normalize underscores to spaces in sortkeys in toDataElement,
but when toDomElements recomputes the normalization to decide
if the sortkey really changed, it doesn't normalize underscores.
This is broken, both code paths need to use the same normalization;
we do this correctly for the category name.
This bug appears to date back to the introduction of category
support in March 2013 :(
Spotted in https://it.wikipedia.org/?diff=67220927
Change-Id: Ie3257fa335f3bd24a36c8654f3f5a24e89d7a9b9
Some parts of this are heavily based on how the existing defaultsort stuff works.
Relies on I9bb80b01 and Iba2fff95
Bug: 56868
Change-Id: I5f0ce2ec36e82b04d9e1357b14046867c1dd3b60
Also fixes some errors in I752705f6
And while we're there, clean up some mostly duplicate functions
Bug: 57169
Bug: 57170
Bug: 57171
Bug: 57172
Change-Id: I1e3dca3868a267e91bccb0ae277012c26ca82174
Add meta items for the four remaining mwPageProp behavioural flags from Parsoid
that are added by MediaWiki core. These are each waiting for UX implementation,
based on the lack of context information in MWMetaDialog about the page, or
about the wiki:
* __NOGALLERY__
* __HIDDENCAT__
— These only make sense in a Category: page.
* __NOTITLECONVERT__ // __NOTC__
* __NOCONTENTCONVERT__ // __NOCC__
— These only make sense on wikis that have content or title conversion.
Change-Id: I752705f65cfbd79c7f3f71270659793996868aff
Add a trinary option to the page settings pane of the meta dialog that
lets users set the page to have __NEWEDITSECTION__, __NONEWEDITSECTION__,
or neither (and so have default behaviour).
Bug: 57168
Change-Id: I3198409c6aaa4cbce7e26fd56d390ffc91e91eef
Add a trinary option to the page settings pane of the meta dialog that
lets users set the page to have __INDEX__, __NOINDEX__ or neither (and so
have the default behaviour).
Bug: 57167
Change-Id: I30d483b5b6c3df7ee56a52c744bbdc610a01873d
Done as a hack by just calling into the MWInternalLinkAnnotation code
which understands all of this stuff already.
Bug: 61570
Change-Id: If5962e1616087064f319a50a2c466724f6925d52
Adds setting and unsetting the #REDIRECT status of the page from the page
settings pane of the meta dialog, and toggle whether this is a static
redirect (i.e., it is not automatically changed when its target is moved).
If the page has a redirect set, the meta dialog will be shown on opening
the page so that users can adjust the redirect more swiftly.
Bug: 47328
Bug: 50878
Bug: 57173
Change-Id: Ibd89cf04486799f292b9fd045dae5bc23fcf6fd4
Adds a checkbox to the page settings pane of the meta dialog that lets
users set or unset the __NOEDITSECTION__ flag on the page.
Change-Id: If1eca58e28d214021f5f5582856e595d4d0fbc43
This creates a new panel in the meta dialog, "Page settings", where page-
level settings will be, err, set. For now, this exposes just the
behavioural switches for the presence/absence of the Table Of Contents –
__NOTOC__ and __FORCETOC__.
As part of this change, the meta dialog is renamed to "Options" to be
less confusing, and the icon for the meta dialog is changed to the
generic one for dialogs, which was previously unused. The page settings
pane is provided first in this list, given that the categories pane
(amongst others) is now directly accessible through the toolbar menu.
Bug: 56866
Bug: 56867
Change-Id: I33ce05c19d2e19b249e1cefd26fd0e3697d0085d
