* The current fix is a hack to fix dsr issues right away.
Meanwhile, will invesitigate a fix that will involve processing
<references> in its own subpipeline and persisting state into
the top-level page.
* Fixes a known selser failure from bug 62025.
Change-Id: I0f80d68e927f500939a44af401cc73c07e24721f
* Renamed buildDOMFragmentForTokenStream --> buildDOMFragmentTokens
and made env. the first arg.
* Added documentation to buildDOMFragmentTokens and encapsulateHTML
Change-Id: I7eccfd3f4dc5b4b91d20d1d24d98ec514df6dfbc
* Removed manager and passed in env and parent-frame to all
utilities that process content in new pipelines.
* Added more documentation to mediawiki.Util.js.
* Renamed processAttributeToDOM to a more appropriate name.
* Added pipelineFactory property to env and used that to
construct parsing pipelines everywhere.
Change-Id: Ic612e5630d19d4e3f5d6388bc5cd117d337fd799
* This patch adds a flag to DOM fragment unpacking to update
fragment DSR in cases where the fragment needs it (references
block + reused template/extension/images content). In other
cases of dom-fragment use, the DSR should not be updated.
Ex: All cases where fragments are used to implement parsing
scopes (all A-tag content currently) since DSR computation
is set up with offsets in the top-level source.
This is not just an optimization, but a correctness issue
since the fragment unwrapper always sets the fragment DSR
on the first node which would be incorrect in scenarios where
the fragment DOM has multiple top-level nodes.
* Parser test runs now have better DSR values in certain cases.
Change-Id: If1f5bf98dab246a3c8a1869b38335e90268cb5c5
This reads better than manually testing the constructor, and often
leads to terser code since we don't have to check whether the argument
is an non-null object before querying the constructor field.
Change-Id: I53ec87d6e80d658aa3d26dc2b613dc6c58e2d026
In particular, use `Array.isArray` instead of `$.isArray`, and
`Object.assign` instead of `$.extend`. `Object.assign` operates only on own
properties, so use `Object.create` on the prototype where necessary to
get inherited properties. `Object.assign` does a simple assignment and
is appropriate in most places, but be careful if we ever install
getters/setters on a prototype.
Implement `Util.clone()` from scratch to have a jquery-compatible deep
clone operation. In particular, this needs to ignore objects which
aren't "plain objects", so we don't try to clone DOM nodes. Our
definition of a "plain object" is compatible with jquery/zepto.js, and
is thus something of a hack. We should eventually replace this with a
`console.assert()` and remove/rewrite the places where we try to clone
objects which contain DOM trees and other cruft.
Change-Id: I88c8fe41a9be84c167d5a0ea1187fd258f077968
* For now it stores in .dataobject, freeing up .data to
handle <object> elements.
* Adds a test that crashes master.
Bug: 57394
Change-Id: I4207d76ad9dab660e890008b2ee5014554ce52c8
* Adds an index of all the references on a page in order to avoid
repeating attrs when multiple <references /> tags are present.
* Update tests to reflect the new behaviour.
Bug: 59782
Change-Id: Ia44bf59a9304788aca170041d3b85f53557151fc
- Make sure void element attributes are sanitized
- Drop attributes on end tags
- Fix Cite to use data-parsoid instead of invalid attributes to pass
information from the token stream to the DOM
Change-Id: If236d4c9197b12ff86a607763f25ed7677623bc4
* isForeignContent now flags content that is not originally
present in the top-level page => transclusion and extension
content. During DOM fragment unpacking, top-level children
of the fragment are always re-assigned the fragment wrapper's
about-id.
* For content that is not flagged isForeignContent (figures that
are reused from cache, and all other users of dom-fragment
including scoped parsing), the fragment DOM is walked and all
about-ids are reassigned fresh about ids.
* From an earlier patchset (now unrelated to the bug fixes here)
* Renamed older badly named isEncapsulatedElt helper
to isFirstEncapsulationWrapperNode.
* Left behind helper to recognize when a node is an
encapsulation wrapper (in case it comes handy later on).
* No change in parser tests.
TODO: We need a parser test with extensions in them.
{{echo|<div>foo</div> <math>1+2</math> <div>bar</div>}} would
not RT properly before this patch because the inner <math> node
did not have the about-id as the surrounding <div>s. This patch
fixes this.
This should also fix a lot of the <timeline> regressions seen
in latest RT testing.
Change-Id: I595e9f46d8ce789a05e4b7dd8b58e443e4c02f98
* Smaller data-mw with adaptive quoting.
* Updated parserTests with new output
* Also add a serializeChildren method that works similar to innerHTML.
* Move HTML normalization to DOMUtils to avoid cyclic dependencies
* Disable non-IE WS to space normalization pass, needs to be improved. See bug
55588. This leads to some new passes and some new fails.
Change-Id: I392881bd8a0cfd9f116e70e9a52d1ef14bbd568b
* Got rid of unnecessary/buggy concat of EOFTk in ext.Cite.js
to wikitext string (concat is only required when processing
a token array from stage 2 onwards).
* Moved temporary node.data.parsoid.wrapper flag to a tmp object
which is then stripped in the cleanup pass. Other temporary
flags from other passes could also be moved here.
* Added a helper to test if a typeOf has a parsoid-generated
value.
Change-Id: I2024c575b5293e5155fc8e2915a34b5fb8394671
* Added mechanism to parse a set of tokens in its own parsing
scope all the way to DOM (which in turn restricts token
transformations to just that scope). This is equivalent to
enforcing well-balanced requirements in restricted contexts
(Ex: link content, image captions for starters). This also
provides an option of enforcing balanced templates in certain
contexts.
This patch applies it to link content and image captions.
Deleted the hacky closeUnclosedBlockTags code for dealing
with bad HTML in captions.
* Refactored common/duplicate code out of Cite handler and
Template handler.
* Updated DSR handling for dom-fragments which eliminates the
warnings about cs/s dsr mismatches seen on image reuse.
it:Dalmine used to get a bunch of DSR inconsistency warnings
when dom-fragments were reused (reported in bug 53071) and
are now fixed with this patch.
* There is still one big hole in DOM fragment unpacking that
has to be fixed. This pertains to improper tag nesting that
will be broken up by the tree builder. The DOM fragment unpacker
has to recognize these scenarios and fix up the DOM (either
by fixing up the final DOM or by stripping mis-nested tags
in the DOM fragment being unpacked).
This patch has an incomplete hack for this that addresses
the common-use case of nested a-tags generated by wikitext
of this form: "[http://foo.bar a [[Wikilink] here]".
Bug: 54454
Bug: 49942
Bug: 44476
Bug: 47326
Change-Id: I33ee38bc43743125b705ac821b339586593dbef7
* This eliminates repetitive code from a few places and might be
useful for future patches as well.
Change-Id: I383ed253a2fa20c1b7429689d17cde176751e29a
* The initialization of nestedRefCollectionMap[references-id]
in handleReferences was the wrong place to initialize it since
on pages with multiple <references /> tags, the map can get
reset after a references tag is processed. So, for later
references tags, the entry for those will get cleared which
led to crashes.
Ex: es:Abderramán_I and couple others found in RT testing.
* This patch fixes the crasher.
* Added a new parser test with multiple references tags that
captures this scenario. Regenerated selser changes file.
Change-Id: I64402e77996486b099acda114f2e250258b0048e
* Track <ref>s birthed in <references> tags and capture their
HTML and set <references>.data-mw.body.html to the concatenated
HTML for all those child <ref> tags.
* No change in parser-tests because our test normalization code
strips data-mw before comparing results. Since this patch
only changes data-mw output for "References: 5. ..." test,
there is no change. In any case, this patch updates the
data-mw output for the test in question so that if we do
modify our normalization routines, the test will still pass.
Change-Id: Iaea752dec03e5e7f0d36baf3b7a9973f1b85e8a5
* This patch now supports any template that generates nested refs
where the top-level token is just a single-ref.
Ex: {{efn|New timetable{{sfn|Vallance|1991|p=31}}}}
* The solution in this patch removes the hack from the previous
version (53bbcbb3). As documented in the bug report, this
solution essentially "trusts" template authors and lets
nested refs through when they come from templates.
But, top-level nested refs are still not allowed.
<ref>foo<ref>bar</ref>baz</ref> in the toplevel page
will still generate a single reference with content
"foo<ref>bar</ref>baz"
* Updated the nested ref test output
- Regenerated selser changes because of the changed output.
- Regenerated blacklist because of the changed selser changes.
* This now handles:
- https://en.wikipedia.org/wiki/User:Edgepedia/VE/GNoSR
- https://en.wikipedia.org/wiki/Phellinus ellipsoideus
Change-Id: I627955f0be1c5e2bafc49647c94c2be68ce711a8
* There is another unrelated issue on that page ==> It has
a couple instances of <ref>text<ref> which slurps the entire
rest of the page into a 10K string (on which the regexp failed).
Change-Id: Ia4c498b28042de5bfe9b0945c0efaa8c6cb81ea0
* source and group attributes were being added as HTML attrs.
on the ol-node which is invalid. Plus, after refererences
generation, source attr was being deleted which causes crashers
in production if references output is reused from cache.
* Moved both attributes to data.parsoid
* Removed group="" from parserTests that I erroneously added
in that previous commit.
* Minor cleanup in DOMPostProcessor.
Change-Id: I85f4ad0a311d653d7ba3e010c7a5db028b643e9f
* So far, references wikitext was being replaced with a meta marker
token that participated as an inline token in p-wrapping. As a
result, in some cases, a p-tag was wrapping the references ol-node
which is buggy HTML. When VE loaded this DOM, the p-node was split
around the ol-node and duplicated DSR which led to duplicated
output when selser ran on this.
* One way of fixing this would have been to add a special case in
the paragraph wrapper to treat the mw:Extensions/References/Marker
meta tag as a block token.
* A better solution with an eye towards the longer-term is to emit
mw:DOMFragment wrapper for the references tag with the content
being an ol-node. The dom-fragment unpacking code then takes care
of p-wrapping issues for the ol-node. This fixes the bug in this
case.
* Also fixed parser tests output where group attribute was missing
on some tests (which indicated that the older code was not emitting
the group attribute on references tag).
* No change in parser tests.
Change-Id: I073b2e68667d577c75cad07d19cea2b19d0e89fe
* After trying various hacks, came up with a relatively simple
fix/hack to support nested refs.
The fix looks for {{#tag:ref..}} and short-circuits full
pipeline expansion and converts that to an extension tag
in place.
* Tested with the following wikitext which parses and RTs correctly
A <ref name='foo' />
B {{#tag:ref|nested ref <ref>bar</ref> |name=foo}}
<references />
* Also tested on en:Fomitiporia_ellipsoidea from the bug report
and verified correct parse and round tripping.
* Verified that the nested ref in <ref> foo <ref>bar</ref> </ref>
continues to be parsed as plain text.
* No change in parser test results -- have to make another
round of updates to parser tests.
Change-Id: I43bb8b710bd10a9ddbea27818ff8aaf97ddb3fdc
* See example below that clarifies the problem before this patch
-------------------
$ echo "{{#tag:ref|foo}} {{echo|<references />}}" | node parse --extensions ref,references --wt2wt --editMode true
<ref>foo</ref> <references />
-------------------
* The problem is that references are generated after dom fragments
are unpacked in the DOM which lost the mw:Transclusion typeof and
data-mw that had been set on the ref and references tags.
* This is a quick fix to prevent some dirty diffs with #tag:ref being
reported on en-wp. Longer term, we do have a plan to use DOMFragment
encapsulation for refs and references as well and splitting up
references processing differently than is being done currently.
Change-Id: I4186cae93b9882d367c7d4efecc092607fe17c61
* While debugging reports of dirty diffs on some pages (en:Bleak House
specifically), it took me a while to notice that some mw:Transclusion
had about="mwt5" style ids (introduced during template expansion reuse)
whereas all other about ids had about="#mwt5" (note the # char) style ids.
While this by itself shouldn't cause dirty diffs since DOM-diff ignores
about ids, this could potentially introduce introduce other bugs elsewhere
if we start using/comparing about ids.
Fixed all uses of "#" + env.newObjectId() with env.newAboutId and let
env prefix the "#" key.
Change-Id: I74d50ae155f5d24af95c07da15b14eb990cf2891
* Nested ref tags are not supported anymore.
* Turned off pre and p-wrap handlers on ref content since the native
cite extension seems to not do any of this on ref content.
* No change in parser test results (because there are no tests yet).
Other cleanup:
* Removed the 'inBlockToken' hack from Cite since this is not
necessary anymore.
TODO: The use of this flag in TemplateHandler may not be needed
either. Verify and get rid of it.
* Leading whitespace in ref-content is still removed but this may
not be strictly necessary.
Change-Id: I3406236032abe36099a1e420f443277a95fe597b
* The page in question "es:Estadio_Deportivo_Cali" had a ref
with name "constructor", and this name was used as an object
property key and this clashed with the predefined property
constructor.
* The reliable solution here is to prefix ref-name and ref-group
with a string and use it to prevent clashes.
Change-Id: Ib5cf7cce6fa4acd88e3d49ca9d4390a61bfddd7e
* Temporarily hacked sanitizer to pass through typeof attribute
so that mw:DOMFragment wrapper for extension tags can get to
the DOM post processor and get unwrapped.
* Implemented getArgDict for the extension handler since data-mw
for extensions has a different form than that for templates.
* Extracted common functionality into Util.js and used it in Cite.js
and ExtensionHandler.js
* Tested with timeline extension (test snippet below) and verified
that it parses and RTs both with editMode true and false.
TODO: Long overdue. Extension testing.
--------
<timeline>
ImageSize = width:250 height:200
PlotArea = left:40 right:10 top:10 bottom:20
TimeAxis = orientation:horizontal
AlignBars = justify
Colors =
id:gray1 value:gray(0.9)
DateFormat = yyyy
Period = from:1960 till:2010
ScaleMajor = unit:year increment:10 start:1960
PlotData =
bar:3000 color:gray1 width:1
from:start till:end
bar:2000 color:gray1
from:start till:end
bar:1000 color:gray1
from:start till:end
bar:0 color:gray1
LineData =
layer:front
points:(48,96)(84,111) color:blue width:2 #1962 tot 1968. Inwonertal 1962: 1348 1968: 1610
points:(84,111)(100,112) color:blue width:2 #1975: 1627
points:(100,112)(128,116) color:blue width:2 #1982: 1699
points:(128,116)(160,135) color:blue width:2 #1990: 2036
points:(160,135)(196,146) color:blue width:2 #1999: 2217
points:(196,146)(228,158) color:blue width:2 #2004/5
</timeline>
--------
Change-Id: Ia8d2f82e893047e2447cf809e04cc7f508f5899b
* data-mw wasn't being emitted for references -- there was a FIXME
for it.
* Tested fixes on example from 3c88b310.
* Removed meta-placeholder that was being emitted for <references />
tags without any refs to emit since VE might add references and
this wont be valid anymore. Serializer can also handle references
output without any content. So, no need for that hack anymore.
Verified by testing with "<references />" input
Change-Id: I3d2852f2c6a88bf22145add9b2173fd99d152775
* Serializer was complaining about missing source for these tags.
Tweaked code to serialize these back to self-closed tag form.
* Tested with which rts this with the regular serializer in edit mode.
echo "one <ref name='foo'>bar</ref> two<ref name='foo' />\n<references/>" | node parse --extensions ref,references --wt2wt
Change-Id: Iaac63b26660d8b03af937d00d04540c3b8c0c86c
This patch adds the capability to expand individual transclusions all the way
to DOM, which enforces properly nested templates. This is also needed for
DOM-based template re-expansion, which the VE folks would like to use for
template editing.
In normal parsing, DOM-based expansion is currently disabled by default for
transclusions, and enabled by default for extensions. The decision whether to
balance a particular transclusion can be based on a statistics-based
classification of templates into balanced and unbalanced ones. The advantage
of this approach is consistency in behavior for old revisions. Another
alternative is to wrap unbalanced transclusions into <domparse> tags which
disable DOM-based parsing for all transclusions in its content. This has the
advantage that all special cases can be handled after tag insertion, and that
balancing could also be enforced in the PHP parser using an extension.
Other major changes:
* Renamed transclusion content typeof from mw:Object/Template to
mw:Transclusion
* Renamed extension typeof from mw:Object/Extensions/foo to mw:Extension/foo
and switched Cite to use lower-case ref/references too
Other minor changes:
* Only apply template encapsulation algorithm on DOM to mw:Transclusion and
mw:Param objects, and no longer to all mw:Object/* elements. We should
probably switch to a more explicit encapsulation type instead. Maybe
something like mw:EncapStart/Transclusion and mw:EncapEnd/Transclusion
instead of the current mw:Transclusion and mw:Transclusion/End, so that
stripping those metas out selectively is easy?
* Changed the DOMTraverser logic to let handlers explicitly return the next
element to handle. Useful when several siblings are handled, as is the case
for the fragment unwrapper for example, and avoids some cases where deleted
nodes were still being processed.
* Changed Cite to use mw:Extension/Ref{,erences} as all other extensions.
* Make sure we round-trip gallery when the PHP preprocessor is not used
Five parsoid-specific wt2html tests are failing due to the typeof change.
They will be fine once those tests are adjusted. For now, adding them
to parser tests blacklist.
TODO:
* Switch the Cite extension to the generic DOMFragment mechanism instead of
marker tokens.
Change-Id: I64b560a12695256915d2196d0646347381400e80
* PHP parser normalizes whitespace in attribute values of all
extension tags. This patch mimics that behavior.
* Removed special case whitespace stripping for references.group
attribute since that is now handled by the general case.
* As a result, <ref name='foo' /> and <ref name=' foo ' /> are
and treated as being identical.
Change-Id: I34009ab6662d05453fe46379c58d6e989f296958
* Extensions were being serialized back to original wikitext src.
* This patch now uses data-mw content to serialize to extension
wikitext.
* Fixed Cite to add attributes for ref to data-mw so that attributes
roundtrip back (WS and quotes are normalized).
* TODO:
1. add data-mw for <references> in Cite.js
2. add data-mw for all other extensions in the extension handler
Change-Id: If3c35398a409f4775204407b3dcf2442ec2fb4e5
* Updated references output DOM to match spec better.
* Also refactored some repetitive DOM code into helper functions.
* Turned on tpl encapsulation inside extensions.
* Verified output on the example in the spec and the example in
commit 3c88b310.
Change-Id: I1b894759d2cd89b6453156e6b0246f6cc8f0d60b
'jshint --show-non-errors' shows unused variables. Some of these are unused
function arguments, which are rarely bugs. But try to fix the ones which
are forgotten/dead code and unnecessary require()s.
Change-Id: I685ccd8e388fd3acf75053a07e2f729398fa2855
* When I last fixed Cite in commit 0164b846, I didn't take it
all the way through. I was assigning ref indexes in the
async pipeline which is incorrect since ref-tokens and
references-tokens should be processed in the same order
as they show up in the input.
* I now moved ref-index assignment to the DOM post processor
phase where they always belonged.
* Fixed references and cite reset functions to only reset a
specific group, if necessary.
* Pipelines processing template transclusions should propagate
the extension tag if the transclusion showed up in the context of
extension source so that any extension-specific constraints are
respected. (Ex: ref-tags in reference-extension context are handled
differently -- and this should continue to be true even when the
tags show up via transcluded content)
* These fixes were tested on the following snippet from 0164b846.
Where this snippet was generating buggy output earlier, it is now
being handled correctly.
---------------------------
X1<ref name="x" /> X2<ref name="x" />
<references>
<ref name="x">x</ref>
</references>
Y<ref name="y">{{echo|y}}</ref>
Z<ref name="z" />
<references>
{{echo|<ref name="z">z</ref>}}
</references>
A<ref name="a">a</ref>
B<ref name="b" />
<references>
{{echo|<ref name="b">b</ref>}}
</references>
C<ref name="c">c</ref>
D<ref name="d" />
<references>
<ref name="d">{{echo|d}}</ref>
</references>
---------------------------
X1<ref name="x" /> X2<ref name="x" />
Change-Id: I838d188c90b526878a72e4baf1e54cac644aadfc
This code is being run on:
<meta property="mw:PageProp/categorydefaultsort" content="0 126">
which doesn't have a 'typeof' attribute, and so the match is crashing
with a null pointer dereference.
Turn the expression around. RegExp.test is more efficient, and it handles
a null argument with no problems. Add start/end anchors to the regexp
while we're at it.
Change-Id: I11bc9fdc902a21ce0bc1c05f08d3b615d5483e2e
Most of these warnings are globals defined in mediawiki.parser.defines.js,
which we turn into proper local variables. But there are a grab page of
other use-before-def, missing semicolon, bad line break, and other minor
warnings.
No tricky stuff attempted in this patch, this should be safe obvious
fixes only... although there is a nasty circular dependency between
Util and parser.defines which had to be broken.
Change-Id: I8810da3a5ec287d7ae9078463ba01472a87a492e
* Updated native implementations of the <ref> and <references>
tag implementations of the cite extension.
* <references> tag was not being processed properly by Parsoid.
This led to lost references on the BO page. This patch fixes
it which fills out references and more closely matches output
en:WP.
* Extracted extension content processing code into a helper and
reused it for both <ref> and <references> handler.
- Leading ws-only lines are unconditionally stripped. Is this
accurate or is this extension-specific? Given that this code
is right now tied to <ref> and <references> tag, this is not
yet a problem, but if made more generic, this issue has to
be addressed.
* PreHandler should not run when processing the refs-tag. Right
now, this is a hard check in the pre-handler. Probably worth
making this more generic by letting every stage in the pipeline
get a chance at turning themselves on/off based on the extension
being processed by the pipeline (can use the _applyToStage fn.
on ParserPipeline). TO BE DONE.
* <ref> extension needs to be reset after each <references> tag
is processed to duplicate behavior of existing cite extension.
TO BE DONE.
* Updated refs group index to start at 1.
* No change in parser tests. References section output on the
en:Barack Obama page now more closely matches the refs output
on enwp.
* In addition to the en:BO page, the following wikitext was used to
fix bugs and test the implementation.
CMD: "node parse --extensions ref,references < /tmp/test"
----------------------------------------------
X1<ref name="x" /> X2<ref name="x" />
<references>
<ref name="x">x</ref>
</references>
Y<ref name="y">{{echo|y}}</ref>
Z<ref name="z" />
<references>
{{echo|<ref name="z">z</ref>}}
</references>
A<ref name="a">a</ref>
B<ref name="b" />
<references>
{{echo|<ref name="b">b</ref>}}
</references>
C<ref name="c">c</ref>
D<ref name="d" />
<references>
<ref name="d">{{echo|d}}</ref>
</references>
----------------------------------------------
Change-Id: I2d243656e9e903d8dadb55ee7c0630824c65cc01
