It is about time to implement a generic fix for T214994 which will
capture the Cite-specific scenario we are tackling here in bits
and pieces. We have fragments of a T214994 solution spread in
Utils/ and here while tackling shiftDSR and convertOffsets
for Parsoid/PHP. So, someone needs to take a look at all these
pieces and implement the necessary abstraction.
As part of that, maybe we also need to revisit our embedded HTML
data-* representation so there is a uniform way to inspect these
attributes rather than every semantic element (template, extensions,
lang variants, media) choosing their own custom embedding scheme
which makes discoverability harder and error-prone.
Change-Id: Ifd19d2d8d20dbd0dda0fa1cc338a07afb37c4213
* This is an instance of a bigger issue that we need to look closely
when we are integrating Parsoid with core parser.
Bug: T235656
Change-Id: I3d652727293461c7968e83be8994ba0572bae8e4
Passing srcOffsets which don't actually correspond to actual regions of
the source wikitext cause problems in the token offset conversion code.
Instead, parse the wikitext as itself, then adjust the TSRs in the DOM
tree.
Since Gallery isn't ported to PHP (yet), update the
automatically-generated Gallery/index.php. The newly-added
ContentUtils::shiftDSR() was ported, however.
Change-Id: I28f3d3398930733ae2bcf9759e49c45f93bc7190
- git grep is a wonderful thing to help catch identical errors.
- Saw this "bug" first in the cite extension port.
- Turns out this is only a bug on the PHP side since the PHP DOM
treats attributes in a case-sensitive manner but Domino.js
treats attributes in a case-insensitive manner.
- Better to use the correct attribute name everywhere.
Change-Id: I3735dc768a10a820b4816c211aa72291df9b1413
* unwrapFragment had a somewhat unusual behavior which could be
a source of bugs while reasoning with it.
If undefined, it's default value is true which is contrary
to how we think of undefined.
* Flipping the polarity of the flag to sealFragment makes the
semantics easier to reason with and where !empty(..) applies
more naturally to it.
Change-Id: Ia50cba345f37e815e5f5f95abb452c8eefcf9011
In PHP, DOMNode#getAttribute() return '' if the attribute is not present,
not null. Audit our uses and try to either explicitly use `|| ''` (which
will ensure that PHP behaves the same was as JS) or use `hasAttribute`
to explicitly test for the presence of the attribute.
Changes have also been ported to PHP from JS.
Also added src/Wt2Html/PP/Processors/AddMediaInfo.php which was missing.
Change-Id: Ie1ae1df88e4fca70daf97b6f720f28014ebc99ed
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
