Significant change is that footnote marker numbers are changed from
being a CSS-rendered marker to using the rendered "fallback" text.
This could be avoided using the same trick as is implemented for the
reflist: send an inline style variable with the marker content; but
let's only do this if really necessary for user experience.
Template-produced refs are still wrong, but this patch continues to
render them as they come from Parsoid, in the content script.
TODO in later patches:
* reuse of a subref is rendered as '3.2.1' in reader view but '3.0'
and '3.1' in the editor.
* subref numbering is backwards in RTL languages
Bug: T247921
Change-Id: Ieff73769f8ebbc3724f6a9b498487c4e7d09aa2e
With this patch, we show reflists in a hierarchical view with subrefs
listed under their parent.
TODO in follow-up patch: numbering of subrefs is still incorrect.
Change-Id: Ia82658af72caebd29241b9bd329d236ddc3f1e6d
Pure refactor which shouldn't change output in production. Switches
to interfacing with MWDocumentReferences to get refs in index order.
Temporarily suppresses any subrefs, we only show top-level refs.
Bug: T247921
Change-Id: I9c8347b064173027f436722c87e15e0381c958bd
Some of the annotations were used in a way that confused jsdoc. This
cleans up redundant annotations and uses more canonical tags.
These changes cause all classes to now appear in the generated pages.
Includes linking to external docs.
Bug: T358641
Change-Id: Iaee1dadcc19a70c27839d0d27dfa6a07a70fb46b
These tags are 10 years old. Current documentation generators don't
need them.
Tagging something explicitely as being a @method can be useful in
an interface where the elements are initialized with e.g. `= null;`
instead of having an implementation. But we have implementations
here. Sure these are methods. No need to say that in the
documentation.
Also removing a comment that's obviously a copy-paste mistake from
what was the ve.ui.MWMediaSearchWidget back then. See Ib244ff6 and
before.
Change-Id: I7df6c789d10fd89e7fe97d56c942fd22c56d8458
This means the reference list is always in sync with the model's
understanding of which references are available to edit.
An exception is left in if there are no references in the model
at all, as will be the case on he.wiki, as all references are
template generated. In this case we continue to use the Parsoid
DOM, so that there is a static rendering of the reference list.
Bug: T336865
Change-Id: Iaf1089c9de532e7749c9cb70a9e697917955dca8
Minimal test case:
<ref name=a>a</ref>
<ref name=a/>
<references/>
This renders as "1. ↑ 1.0 1.1 a" in both the legacy parser as well
as Parsoid. The moment you start editing this in VisualEditor the
space before "a" disappears. This patch fixes this inconsistency.
Change-Id: Idfea1a445fc98a0433640b4f706fafcc4e236c18
This patch also updates a second place that does almost the same.
That other place also excludes placeholders. We intentionally don't
do this in this new place.
Bug: T241885
Change-Id: Ib003b8a7bbe247db6f7da0a4efcfd4e5967fd033
This original use case at T187495 is for he.wiki, where it is likely
that all the references are defined in templates, so the model
will always be empty, even though $originalRefList is populated.
Change-Id: Ia2785a20bf82ab97466276a57936bc9299e1cabe
The message was only shown when a new reflist was inserted, or when
any references were changed.
Bug: T284472
Change-Id: I7c1e981c93bf7e163f9fb747aad30a24e9a497f1
The first code snippet in this while already covers this case. The loop
will end the moment it can't find another parent any more.
This was found via
https://sonarcloud.io/project/issues?id=mediawiki-extensions-Cite&types=BUG
as a potential bug. After looking at the code I'm sure it's not one.
Change-Id: Id914252c88b27420dfa47dcc918fc58d9ee2a65d
Also "unwrap" paragraphs using CSS instead of DOM manipulation.
Change-Id: I5565c2c43580d5d47bc65ee06d9d14fccace90c6
Depends-On: Ibbf989dcebf2d21fd2ac481f17062f366ff29e41
Depends-On: I284bcd5dd25cdbb883427ebacb41af1bbf50b60f
Also use ve.dm.nodeFactory.createFromElement
Depends-On: I259face33154b795143c8820abdfb6b4a495f141
Depends-On: I7fc539f75a1c9d672efc139b7884ecdfdff5f301
Change-Id: I032182616c409e65138b16fe7b238e7f7b3a8710
Message indicates that a preview of the reference is missing,
instead of implying that the user was trying to edit it.
Bug: T188682
Change-Id: I5f5f8d5d0910ab2608696bbed380d4592cb6c7f1
This helps on wikis where there are no real refs because they
are template-generated, and is a performance improvement elsewhere
as re-rendering long ref lists can be slow.
Bug: T187495
Change-Id: I47a9206ff7ee61f8fd716dc7658b8bfad927f656
Ideally update wouldn't be called multiple times
for simple transactions, but this should prevent
unnecessary updates if that does happen.
Bug: T176066
Change-Id: I1e7a21c19cee7d50ca160749f243c57f2fb08bab
Probably as fallout from the jQuery 3 update and associated promise-async
changes, `viewNode.destroy()` in the reflist preview caused problems when
adding a new reference with the generated content nodes which were actually
having to make an API call for their contents. New functions for waiting for
content generation to finish were added to core, and will defer the
destruction of the placeholder view until after it's done rendering.
Bug: T168932
Change-Id: I700bff9979a3356626aa311bfdf030da686f5878
Depends-On: Ic12973c0b46af50e0f1933137282a142f32e7de2
This code has been developed over three years now in the repo of MediaWiki's
integration of VisualEditor. It has grown and developed significantly during
that time, but now is pretty stable. A number of hacks inside the MediaWiki-
VisualEditor code base have been used to prevent this code from being loaded
on wikis where the Cite extension is not deployed, but this state of affairs
is and always was meant to be temporary.
This code is under the MIT licence which is a tad messy, but not impossible.
It's clearly labelled as such. The list of authors has been updated to take
into account the influx of new functionality.
Bug: T41621
Bug: T104928
Change-Id: I39936ed83d5a60471a0a75da753f498e80aef234
