* 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
As per RoanKattouw's suggestions, changed the loading position to top
and changed CSS loading to static (addModuleStyles).
Bug: 48185
Change-Id: I319285d23a4f0a0522cc793f1a6661cda31a1ebf
This is a quick-fix to support proper rendering of <sup>[1]</sup> elements
when the sentence contains a right-to-left word.
Amended: Changed from working through jQuery 'wrap' to CSS unicode-bidi.
Amended: Dos2Unix conversion to get rid of pesky hidden characters, also
corrected all of Amire80's comments.
Bug: 36032
Change-Id: If85efe5ff1e0a3c57ee2523656702db89df07145
'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
The cloned Cite object in the ParserCloned hook must be cleared, even if
the clone occurs inside a <ref> or <references> tag. The simple way to
do this is to set mInCite and mInReferences to false before calling
clearState().
While Cite could probably use a major cleanup, let's fix this bug now
instead of waiting for someone to get around to it.
Bug: 47291
Change-Id: Id3e91c41dc33a703b5326961fd57e1fe8ac61f5b
* 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
Tokenization
------------
* Fixed tokenizer to correctly parse extension tags in different
contexts: with start and end tags, in self-closing tag mode,
and to correctly handle scenarios when the exension end-tag is
followed by a '#' (the special char used to skip over extension
content).
* Removed the distinction in the tokenizer between installed
extensions and natively supported extension tags (<ref> and
<references> for ex.). They all tokenize and get processed
identically and get handled by different paths in the extension
handler.
* Template and TemplateArg tokens now carry tpl. transclusion
source alongwith them since tsr information will not be
accurate when they show up in extension contexts that in turn
showed up in template context that were expanded by the php
preprocessor.
Ex: {{echo|<ref>{{echo|foo}}</ref>}}
The tsr for the ref-tag will correspond to the
template-source of the echo-template, NOT the original top-level
page. So, env.page.src.substring(..) will return incorrect
source for the innermost {{echo|foo}}. This fix of carrying
along tpl transclusion source in the token itself eliminates
this problem.
Knowledge of native extensions
------------------------------
* Natively implemented extension tags (<ref> and <references>)
are hardcoded in env.conf.parsoid. At some point, it would
be good to have a registration mechanism for parsoid-native
extensions.
Extension handling
------------------
* Extracted extension handling out of the template handler into
its own handler class. Right now, this class inherits from the
template handler in order to be able to reuse a lot of the
expansion and encapsulation functionality currently in the
Template Handler.
* This handler now handles extensions that are:
(a) natively implemented and registered with Parsoid.
(b) implemented as a PHP extension and expanded by relying on
the PHP preprocessor.
For (a), it uses information from env.conf.parsoid to find
ext-handlers for natively implemented ext-tags. However, this
can be cleaned up at some point by making available a registration
mechanism.
Cite/Ref/References
-------------------
* Reworked the cite handler to split up ref-token processing
and references token processing.
* The handler now processes ref-tokens, parses content all
the way to html output and encapsulates the html in an
attribute of a meta-token that serves as a placeholder for
where the ref-token occured.
* References are handled as a DOM post-pass where these meta
placeholder tokens are collected, content extracted from
the attribute and spit out at the site of a references tag.
The DOM walking is in DOMPostProcessor.js, but the actual
processing is part of the Cite.js to keep all cite extension
handling code in one place.
Parser pipeline
---------------
* Restructured parser pipeline recipes based on changes to Cite,
TemplateHandler, and ExtensionHandler.
* Added a couple functions to the parser pipeline:
1. resetState to reset state before starting a new top-level parse
when pipelines are reused across top-level parses (ex: parser
tests)
2. setSourceOffsets to set start/end offsets of the source being
handled by the pipeline. This is required to correctly set tsr
values when extension content (which is a substring of original
top-level text) is parsed in its own pipeline.
Other fixes
-----------
* Removed env parameter from the Params object since it was not
being used and seemed like unnecessary state propagation.
* Removed a FIXME in DOMUtils.buildTokensFromDOM by reusing code
in the tokenizer that converts "\n" in text to NlTks.
* Cleanup of Util.shiftTokenTSR.
* ext.util.TokenCollection is now no longer used by anything.
Added a FIXME and left around in case we are able to improve
tokenizing and handling of *include* tags that can eliminate the
need for the messy TokenAndAttrCollector.
Test results
------------
* No change in parser tests results.
* Tested with a few different files.
- en:BO page seems to be parsed about 10% faster than before
(needs verification).
- Referencs on the en:BO page seem to be more accurate than
before.
Change-Id: I8a095fa9fa976c7b3a2a4bd968dc9db4270b105f
* A references tag for a group can appear multiple times on a page.
Ex: en:List_of_number-one_albums_from_the_1960s_%28UK%29 uses
{{Reflist|group=lower-alpha}} more than once, and each reflist
tag emits references accumulated since the previous references
output. This requires clearing the refs for the group after it
is emitted.
* Parsoid wasn't clearing the group's refs. This resulted in
duplicate ref output which in turn crashed template encapsulation
code that relies on template ids being unique.
* This patch fixes it which fixes the crasher on
en:List_of_number-one_albums_from_the_1960s_%28UK%29
* No change in parser test results.
Change-Id: I48ba9c3fe2249c6ef1c1bf068c22c7985fa16e8f
If the parser is cloned, we need to clone our data object and
reassociate the hooks. Otherwise references may be lost when the clone
has ParserClearState called.
Change-Id: Ic1d75850e8d610ea890e34c38d062a358fd55178
Depends-On: Ieec65c908d71e89b9a66f83b9a626f842aadacbb
* When named-ref-tags are used multiple times in a document, the
Cite.onReferences function was outputting the ref-content once
for each use in the references section. While this is "harmless"
for regular ref-content, when the ref-content has templates
(ex: {[cite .. }}), that template content is duplicated several
times -- this also means that template expansions seen in the
output no longer has unique ids. Occasionally, this trips up
DOM passes (template encapsulation) which make the reasonable
assumption that template ids are unique. It introduced an
infinite loop in the code that detects template range nestings
and overlaps. This is not triggered always, but only in certain
scenarios. en:Euphoria (Enrique Iglesias album) was a page that
sent the parser into an infinite loop.
* Now fixed by outputting ref-content once.
* In addition, added an error-check in the DOM post-pass that might
get stuck in an infinite loop to output an error message.
* No change in parser test results.
* en:Euphoria (Enrique Iglesias album) now parses and rts without
getting stuck in an infinite loop. Possibly other pages as well.
Change-Id: I81a055999eefe3ca36dfb8a9cda3fee538ae6c65
