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
* Show the warning in the context menu (on desktop only) in addition
to the reference dialog.
* Add more details to the warning in reference dialog, and adjust
spacing around it to make it more noticeable.
Bug: T208981
Bug: T212609
Depends-On: I6ca605ddd580d6259952c8799ecdca08da07474a
Change-Id: I23cc02f651c15b3276613d32a0c2537032f731c2
* This initialization lets us do a git log --follow and follow
git history for that file across the js -> php port boundary.
This works because git uses content hashes for objects and
the copied code in the new .php file will have the same content
hash as the .js file.
* The following directories were skipped
- ./lib/config/baseconfig
- ./tests
* The following JS files were skipped
- ./lib/utils/promise.js
- ./lib/config/wmf.sitematrix.json
- ./tools/sync-baseconfig.js
- ./tools/sync-parserTests.js
- ./tools/fetch_ve_nowiki_edits.js
- ./tools/fetch-parserTests.txt.js
- ./tools/fetch-wmf-sitematrix.js
- ./tools/compare.linter.results.js
- ./tools/fetch-revision-data.js
- ./tools/fetch-wt.js
- ./tools/regression-testing.js
- ./tools/build-langconv-fst.js
- ./bin/server.js
Change-Id: I0b22057c23b72795aebbd66e3abcb627c6858ef3
* Extensions only need config info (env) and potentially abstract
parsing context (frame).
* Added some FIXMEs about potential future improvements.
Change-Id: Ib4cec4a77ecb96c855798eeb06f7742c5efb0729
This ensures that each repository's "npm test" command is fully
independent of wherever it might be in the filesystem.
Bug: T206485
Change-Id: I54d052bed4ceed175a938896154fd6ad5c89f964
We can resolve this bug by either replacing the bogus "return false"
with the intended "return [ false, … ]". Or rely on the code a few
lines below that also bails out with a "return [ false, … ]" when to
many parameters ($cnt is not 0 then) are present. The tests prove both
solutions are equally valid.
Bug: T211576
Change-Id: Iadd55c134dede7042cfd152c69bc8f27b59d8912
The biggest issue with this code was that it was tracking the exact
same state in two ways: Processed array elements got removed from the
$argv array, *and* the $cnt was decremented the same time. This is not
necessary and a potential source of confusion and errors.
I carefully transformed the code. I'm sure it still does exactly what
it did before. The tests should prove this.
Change-Id: I642d38e7944aa3e2239179fa58e1e231b4698263
This gives the code a little more structure without changing anything
it does. A section is extracted as a named function, and some lines
are moved and bundled where it made sense.
Change-Id: I51909517021bee9dc618efe5fbe40adfc29dc6af
This is split from I642d38e and does nothing but adding test cases
that document the current (broken) behavior.
Bug: T211576
Change-Id: Iee313d26e7bed6deb34101e37736a1c697947905