The basic idea here is to generate the media structure in the token
stream using a stuffed span with a redlink, as in T169975, and
augmenting the nodes on the DOM once the media info has been fetched.
A redlink is justified as the canonical representation of the media
elements before info is fetched because it's the fallback if fetching
fails and the media type is unknown until the info is retrieved.
Most options are stored in data-mw until the media type is fetched and
it's determined that they're applicable. This is a bit of a reversion
of how things were done before where inapplicable options were removed
post-facto.
For consistency and styling's sake, figcaptions are now always added to
block figures.
The pass has to be run before generating headings anchor, since that
depends on the text content (ie. redlinks). This rearranges things in
the post-processor and adds another pass.
The post-processing pass to add media info is run on subpipelines as
well as the top level so that the media info is present in cases where
we embed HTML in data-mw (which is currently skipped by the top level
only passes, except for the cite extension, which has special handling,
see T214994) and to avoid an additional post-processing pass for the
gallery extension, which scales media of packed galleries. This comes
at the cost of making additional queries for each pipeline and requires
the add media pass to be idempotent.
Filed T214241 for figuring out what to do about data-mw info being
clobbered by template annotations.
The newly failing blacklisted tests are from roundtripping media options
in galleries, which requires a general refactor for support. See the
FIXMEs added there.
Performance should be expected to regress by the amount of work we're
able to overlap in the async phase of the pipeline while the media info
is being fetched. Considering a lot of that work is caught up waiting
for the batch to return (other async requests are found in the same
batch), this doesn't turn out to be much in practice in the average
case.
Bug: T153080
Bug: T169975
Change-Id: I856ee962b70cef1f8d49652396ea5264e11a8ade
* Extensions only need config info (env) and potentially abstract
parsing context (frame).
* Added some FIXMEs about potential future improvements.
Change-Id: Ib4cec4a77ecb96c855798eeb06f7742c5efb0729
It's only the extension content that needs the about ids. This matches
b241ac6 where span wrapping was only applied to extension content, and
goes hand-in-hand. The one necessitates the other.
Fragment wrappers don't need abouts since they don't have siblings and
are represented as a single node.
When we get to unpacking, it's now clear that if the wrapper has an
about id, it came from template encapsulation and would need to be
applied to the top-level nodes in the fragment. This being true of
all fragment, it lets use get rid of the `isForeignContent` option to
`encapsulateExpansionHTML`, since that no longer serves to distinguish
anything.
Change-Id: Id9faae3d4e3c8771c2de1fb42ba62a7d92d76673
* DOMUtils was perhaps the biggest kitchen sink utility class we had
with different classes of utilities.
* The split reflects a clear dependence hierarchy:
DOMUtils -> DOMDataUtils -> WTUtils -> ContentUtils
This also seems to reflect a bit in the use patterns.
Content helpers are not used as much in html2wt.
* DOMUtils now only has DOM utilities that are independent of Parsoid
and could be useful in another project.
* Moved a couple helpers into WTSUtils.js since they are very narrowly
scoped to html2wt functionality and are unlikely to be every useful
elsewhere.
* Moved diffing related utils to html2wt/DiffUtils.js
- There is still a dependency in development / debug mode when
doms have to be dumped. I couldn't think of an easy way of
removing this dependency.
- But otherwise, DiffUtils is scoped to html2wt use cases only.
* One more circular dependency eliminated.
* All tests pass.
Bug: T208360
Bug: T205333
Change-Id: I522e8b5c7d726706f994386282476102fe35e91e
The nowiki extension will want to override `isForeignContent` so that
about attributes are omitted on the contents.
Change-Id: Iea28d7a66a90d516226ba9dce4518be6b996d18e
It calls out to a slimmed down parseWikitextToDOM, since only a subset
of that functionality is needed in some extensions, like gallery.
Change-Id: I72e29c4b285fc8cae0207966cc2eddd0fe3ebcf3
* This patch doesn't do any actual work beyond adding the framework
in place for HTML preprocessing before actual serialization.
Change-Id: I2505f5937657813480abef8ec5da9d765a953e29
* Things to investigate as followups:
- Should this be part of the Token base class in parser.defines.js?
- Can we remove nowiki & cite usage of these helpers? Why do they
need to know about (parser internals) tokens?
Bug: T208360
Change-Id: Ib962b4acf9534852240fcb083ce67d696a997a83
* noPwrapping and noPre existed to reproduce the symptomatic
effects of other behavior / semantics in the parsing pipeline.
One of that semantic source was the fact that the content
being parsed in their own pipeline was being using in inline
contexts and p-wrapping and indent-pre generation doesn't
make sense in those contexts.
The other semantic source was the fact that when the content
being parsed in their own pipeline was embedded "inPHPBlock"
in the PHP Parser's doBlockLevels sense, i.e. inside a block
element that existed on the same wikitext source line.
* This patch introduces inPHPBlock and inlineContext as two
new parsing pipeline options and uses one or the other or both
where appropriate.
* No change in parser test results as expected.
Change-Id: I2c625456c6593e49b6a247fb9b2f2e3d6021155b
* This removes Cite leakage in html2wt code by adding PHP parser
side-effect leakage into the Cite extension configs.
This is a somewhat temporary solution which we hope to address
better as part of ongoing cleanup.
* After 4 years, 'a quick hack for now' introduced in 3301393515f
has been addressed.
* No change in parser test passes.
Change-Id: Ic5f8c160d4eedcc4236bce5f095344bd879188cd
* Cite-specific code has leaked in html2wt
* Other possible FIXMEs in Cite about generalizing or
adding new extension API functions.
Change-Id: I30712a3af81edfce0760f4a45ab694c798fb294a
* Make the dom part of extension registration / config more general
to allow for other kinds of dom processors.
* For example, we will probably be letting extensions define DOM
handlers that lets us take a document's subtree and convert it to
self-contained top-level document.
Change-Id: I0ddfe3bc677041cedf63e79faa9c5af939953419
Follow up to 53ae5aa
It's somewhat unclear which attributes belong on the representation for
the fragment, so don't rely on them unnecessarily.
Change-Id: Ib5ba0110291f0c02bd703482813b9567dab63cd6
* This now lets Cite distinguish between <ref></ref> and <ref />
Seen in improvement in blacklisted output of a parser test.
Bug: T130224
Change-Id: If9511498fe8f6d091f8a725b51810eb452db95de
* Use a generic extTagOpts that is opaque to the core parser
but the individual extension can inspect.
Change-Id: I4d1331604828d583b820084e00af68232ec767f8
* This still exposes and exploits some Parsoid internals, but
that can be fixed in the next round of updates.
* Cite (and any other extension) that want to manage fragments
on their own vs. running the default fragment unpacking routine
can now specify that they don't want the content unwrapped.
* Changes to parser tests are to rearrange the attrs and body
attributes which switched positions in data-mw.
* The blacklist changes show that there has actually been an
improvement in test failures.
Change-Id: I1e1a651e8f2d6d9456bb5849b0bce1f8a87c4446
The summary is the first sentence of the method/class description. In
some cases we're missing a period so our "summary" runs on and on.
Many of these were fixed up automatically by the
`jsdoc/require-description-complete-sentence` eslint rule, but
it has a few bugs yet (especially
https://github.com/gajus/eslint-plugin-jsdoc/issues/62 ) so we
can't yet turn it on by default.
Change-Id: I5163ed2c52b21090ce018573bb3ff06d50620d73
Lots of doc comment tweaks to better match JSDoc standards. Also use
the latest version of jsdoc-wmf-theme.
Change-Id: I9bf4f22b292b9cff0ad926f31005bccc7c89cbdb
Emit them earlier (before post-processing) so that attributes don't need
to be migrated.
Bug: T181408
Change-Id: I2b5c7ff552b3322be74f79a81936c41d58fecabc
This change was prompted by a request to follow the PHP Cite extensions
lead in using <sup> for linkbacks. Also, using superscript for
notations/citations is semantically appropriate and follows style guide
conventions.
Change-Id: I7c83d12dd900682799c124ddae1a8689969d5e8c
This better matches the behaviour of the php extension. An instructive
example is,
<ref>123 {{#tag:ref|321}}</ref>
{{#tag:ref|456 <ref>654</ref>}}
The php implementation only parses the ref contents when producing the
output for reference tags, at which point, nested refs will be ignored,
as in the former case. The "321" is dropped.
The latter is special, since the extension tag takes precedence over the
parser function, the inner ref will already have been processed when the
outer is added to the stack, and hence the nesting is permitted. This
is why the inner ref precedes the outer in the references list (has a
lower number). Unfortunately, Parsoid doesn't yet get that ordering
right.
Change-Id: Ieb0e418cca634605c2a9f1487139b15095f38d81
* <ref> content ends up in references section. The original <ref>
site only has a backlink to that references section.
* Given this, when the references tag itself comes from a template,
this throws off the linter attribution code. It assigns the
references template's DSR to the lints from the <ref> tags.
* A clean way of dealing with this would be to treat extension
content as its own independent document (which we are already doing
currently in our wt2html code path) and asking the extension to process
its content while giving it the handler for linting an individual node.
* This patch implements special handlers for <ref> and <references> content
in the Cite extension and registers them.
* Move cite-specific lint handling code to the Cite extension.
* New mocha tests spec this behavior.
Change-Id: Ib57f0303605a73408333e133f8051be0b8d45d69
The citation portion contains fixes for []-encoding in attributes,
based on Iec3439f76ecc2a3543b30b35f8735c92b0cfb711.
Fix some other no- or double-encoding issues with HTML entities in the
process, based on I88e8e2077e6f5eec2b232391f7818370894a62dc
(T103714/T104196).
Unrelated parsertest fix which needed an id fix -- incorrect id
added by the section-tag patches exposed here.
Bug: T152540
Bug: T103714
Change-Id: I12b2a148f7170d20bd9aacd3b5b8ee1965859592
* Follow up to f7594328
* Fixes the regression found in rt:
node bin/roundtrip-test.js --domain ru.wikipedia.org "Феодосия"
* Simple test case (do we really not have one!?):
test <ref>haha{{#tag:ref|ok}}</ref>
Change-Id: Ie0a53a8e885a6d94769034cce4ef432773635842
* The contents of "mw:dom-fragment-token"s was being serialized
after processing to the DOM and stored on the token to be
shuttled through tree building. Only to be reparsed in the
unpacking phase.
* Here we store a pointer to the contents in a fragment map.
* Doing less work results in a performance improvement, though
only slightly because the content still needs to be adopted
by the main document.
Change-Id: Ia0aec7de469101a2a93342ea89daac0f0e73cf1a
* Replace ref markers instead of waiting for cleanup to remove them
since that doesn't happen on embedded html.
Change-Id: Ied746f025a0ac7f14d922aff6640fef3aa4b55b0
* Also, change the input parameter of buildDOMFragmentTokens
to uniformly accepts a <body>, rather than a doc or string,
so that we can pass it nodes from our dummy document.
Change-Id: I4bb44573fe7203277d51e804a4a6423100a34f03
These calls force us to allocate a backing array for childNodes,
deoptimizing a linked list representation. Use the standard
Node#hasChildNodes() method instead, which can be efficiently
implemented without allocating a backing array.
Change-Id: I1706bfa15263564bc981d689947835a3d0d4a68f
