Significant change is that footnote marker numbers are changed from
being a CSS-rendered marker to using the rendered "fallback" text.
This could be avoided using the same trick as is implemented for the
reflist: send an inline style variable with the marker content; but
let's only do this if really necessary for user experience.
Template-produced refs are still wrong, but this patch continues to
render them as they come from Parsoid, in the content script.
TODO in later patches:
* reuse of a subref is rendered as '3.2.1' in reader view but '3.0'
and '3.1' in the editor.
* subref numbering is backwards in RTL languages
Bug: T247921
Change-Id: Ieff73769f8ebbc3724f6a9b498487c4e7d09aa2e
Citoid uses placeholder refs to preview where a new/re-used ref
would be added. This also influences the counting and preview in
the reference list for the moment the placeholder is visible.
I can image this that this might become a feature in the future
but for the moment it's a distraction IMO.
Bug: T247921
Change-Id: I5c5e84ae4b183f99530fda0736a58139e9e25d1a
A change to the citoid error message referencing the manual tab is
breaking this test.
Bug: T364595
Change-Id: Ie79be1dbc1b7469cffc380478cf2d24bbe06f470
Also introducing a line break to make the difference a bit more
clear what's part of the message.
We still probably want parsed content and not only text here.
Bug: T247922
Change-Id: If545ab2fe1d807a6bcbcdfc0c3b7de83817554e6
We have a use case in which the client needs to be able to use
language utilities in the content language (footnote markers), so the
data must be wired through. This will only be done in VE, and in the
special case that the interface language != the content language.
Bug: T369613
Change-Id: I2c10e1e36ba594da98e0efa433dd9e1a25aae6fe
I believe this makes the code less brittle, and also makes it a bit
more obvious what these strings are meant to represent.
Change-Id: I0c5cdaa0b94b525ad3e65278ca9bf088f480df40
This is motivated by T367749 where we probably need this code to be
separated. This minor refactoring just moves existing code around
without changing anything. The idea is just to make the concepts more
visible in the code.
Bug: T367749
Change-Id: I765d19fa9cb43a6f8492b707a7ae46ddffe43897
We want it to be possible to turn a <ref> into an extended one after
it was re-used for the first time, not knowing if it later turns out
to be an extended ref.
This should work: <ref name=x/> is a short re-use of a ref that later
turns out to be a <ref extends=… name=x>…</ref>.
<ref name=x></ref> is just another syntax that should behave
identical.
However, it should probably not be possible to turn
<ref name=x>foo</ref> into a subref later because it really, really
looks like a normal ref. Even if the content matches with a later
<ref extends=… name=x>foo</ref> and we usually ignore identical
content, I suggest to block this with a dedicated error message. But
this is for a later patch. This patch here just documents the status
quo.
This patch also contains minor code cleanups that will be useful in
Ia752a7d.
Bug: T367749
Change-Id: Ie38769b36e5c476b96e7af7f03b0fc800b32ba97
This isn't the ideal solution since it doesn't exactly match the
rendered reader view, but it's a reasonable workaround and an
improvement on "undefined" numbering.
Bug: T247921
Change-Id: Ic0d88123d50e2fcb7f25e897280dbfdb6d494501
MVP implementation for adding a warning when editing a reference
that's the extension of another. In the current approach we're
just using the elements .text() like we do when you create an
extended reference.
Bug: T247922
Change-Id: I2fc574152059937b4aa3fc25ee486d363cc809d5
We only need to set some values that are needed by the `insert`
action triggered that then handles the insertion of the ref.
The form to edit or add a reference will never be visible
in the re-use workflow. No need to update that message then.
Change-Id: I710862bdc1bde6a8ce663d863d721cbf075494f0
Includes renaming the method so it's more clear what it's doing.
As preparation for adding the extends warning to the edit pane and
to allow easier identification of parts belonging to the edit
workflow.
Change-Id: If84c5dbdee19c0ebc0a28b50dda93fef3f558c6e
With this patch, we show reflists in a hierarchical view with subrefs
listed under their parent.
TODO in follow-up patch: numbering of subrefs is still incorrect.
Change-Id: Ia82658af72caebd29241b9bd329d236ddc3f1e6d
Pure refactor which shouldn't change output in production. Switches
to interfacing with MWDocumentReferences to get refs in index order.
Temporarily suppresses any subrefs, we only show top-level refs.
Bug: T247921
Change-Id: I9c8347b064173027f436722c87e15e0381c958bd
I could just remove the getElementById replacement that was
failing the tests. In the Popups extension there really is a
renderer test that mocks this function call but that test is not
part of this file.
Also it seems that tracking is never triggered here. I think that
the beacon overwrite was only added to avoid tracking.
See I2638611ba67b785338f7e98a1c4b08a5e829812d
Change-Id: Ic3540f6f73783e79c81e2b693d2bf96cfc7fc66b
Identify both parent and child reference (reference and extended
reference) and display them in the reference preview popup.
This is a very simple basic implementation so at least avoid that
the sub referenc content is shown without context.
Bug: T239228
Change-Id: I857e1be32db9fd72073015cbba1b1bd37e32085f
The Citoid dialog won't be available when the .json configuration
is missing. That's why test always failed here when triggered
from the Citoid CI.
Bug: T366383
Change-Id: I88ad478250328896c504ccbc95a973d4a0100dd7
In some cases the click on the save button did not trigger the
save dialog. After playing around with this, it seems that the
only thing helping here is a little pause.
Even if we wait for the button to change the state to `enabled`
the click sometimes does not trigger the dialog.
Bug: T366383
Change-Id: I2754fd5a0e9b439e9e0378f3597f67e743a6d0c1
I could identify and fix the issue in
I3224c6131a6e959821bc36e4525889e5088777a2
stress test run fine see
I8e38e8cc533065998f91794a9e490d38d77ad21a
Bug: T368267
Change-Id: Ib7db6c39988ef45404817b8c7a68132572f16e36
This was never working it seems. The result of the check needs to
be wrapped in an expect() call.
Bug: T368267
Change-Id: I3224c6131a6e959821bc36e4525889e5088777a2
C&P mistake in the original implementation. Otherwise we end up
with an undefined in the name.
Bug: T362347
Change-Id: I5c6957ca9fc81e6a5211aab050025eea5d0addbe
