Also adding some margin where it made sense looking at the mocks
in the message document.
Bug: T373876
Change-Id: I1165681521565d900b705a45579fd816fe625a8f
For unknown reasons, some of the event handlers in the reflist class
can be called when the model is already partially destroyed. I
removed some guard logic in I0809df9d3c24fdd5fe which turns out to be
necessary, so I'm adding it here explicitly.
To reproduce the bug, try deleting the reflist in VE.
Bug: T375049
Change-Id: I33e6526cdf535eddaaf8ae506243a5898bd15676
First step in streamlining the code to create sub-references.
Slightly renaming the class to fit the schema and avoid conflicts.
Bug: T373849
Change-Id: Iadbdbecbedf4d4aa3f0e0bade88ea020f2570926
Reverses the previous logic which traversed up from a fragment to get
the full document's refs. Much other code in VE isn't ready for this
behavior, for example we can see list-defined refs but not inline refs
defined outside of the fragment.
This patch will ensure that we're only looking at refs accessible from
the current fragment, and prevents caching on fragments because the
cache uses `persistentStorage`, which is shared between fragments and
their parent document.
Bug: T374068
Change-Id: Ia38098f8b3e5a9d24c2206e11edab37d60209225
Note this doesn't fully solve T374068. The issue is probably that the
reuse tab shouldn't be visible in the first place. Still I think this
is a useful safe-guard that cannot hurt. We are doing the same in
almost all other places already.
Bug: T374068
Change-Id: I9b91374dbda74af75d8c36e24ffe5b9448da1aa7
I could add some simplifications to reduce the complexity of the
tests a bit. I also fixed the test for the change handler. Seems
it did not work that way before.
Also some minor random doc fixes.
Change-Id: If1530a815ea126c38c3a55f3d52e3ca482059840
In a document without references, the default group doesn't exist.
Make sure that we don't assume any group's existence.
Bug: T373661
Change-Id: I1bfd41b0b61938f32219d61142cd576c8ca97ace
Looking for other references can (as of now) never work in source
mode. There are never other references or reference lists.
Bug: T373661
Change-Id: Icaad4e71a1538c5fad6a0f016b342a7cb7b9db2f
Patch I83434afaf1b76425bddb575dd724f462a247c83d was meant to be a
revert of I3749683d8a18e502bf16e5bd5f2fe385581625be, but left this
unused message behind.
While an unused message is harmless, it's of no use either. Even if
we are going to re-implement something like this again in the future,
we will certainly not be able to use this exact message (mostly
because of T373307). Starting with a new message is much easier then.
Bug: T373564
Change-Id: I241d44639ca7112e8398d095e7aa59cf8e275da1
This message was added via Icf9ea348cd97bdb09ddf18769f53c01ea5a8b7ef,
merged 2013-06-15.
The code of the ReferenceDialog class was later largely rewritten
and split into two separate "Edit" and "Insert" dialogs.
See Ib244ff6ad9b4cee1decfd9b9e1d3d4e9cdcfb78c, merged 2013-06-28.
Since then the message is unused. The commit message mentions the
related change. The patch just forgot to remove the message.
Note: The two separate dialog classes have been merged back into
the original ReferenceDialog class.
See I8265febf4fd8f64d2ac40470ff033bac68b24d99, merged 2013-07-18.
The message is already unused at this point. This just makes the
Git history extra confusing.
Bug: T373564
Change-Id: Ifb71a243fbdac43d2199ad40d84da14333d42599
This makes the dialog's behavior much more robust, especially when
confronted with overly long and complex references.
* Limit the height of list items to avoid the situation where a
single item overflows the dialog. This makes it especially hard
to navigate with the cursor keys. We can't see any more what's
going on. The proposed height is intentionally a very high upper
bound, equivalent to about 2/3 of the dialog's height.
* Limit the name on the right side to take up less than half of an
item. The left side is for the content. Usually the names are very
short anyway. But if a name is long it currently creates a mess
where the name is intertwined with the content.
* Break overly long words in references.
* Changing the opacity to use upstream values makes the dimmed names
a bit darker. I think this is good, even necessary for legibility.
Technical changes:
* Use LESS variables from upstream, where possible.
* Remove redundant `relative` already set upstream.
Bug: T372385
Change-Id: Ie59b7b7e4aa7eadc8f82b39884313f5aa8cfd950
I think that the message is more clear when it starts with the
subject we're describing. That also seems to be the case in other
messages here.
It also aligns with the wording in referenceslist-missing-parent:
"There are subreferences with a missing parent reference."
Bug: T372871
Change-Id: If9a49faccb6cbe2000b15a2d28bd66565cce0e90
Pushes per-group knowledge down into a structured object and give it
an interface, separated from the singleton cache across all groups.
Also changes the behavior of orphaned subrefs so that they're still
rendered as subrefs, with an error placeholder where the parent
should be.
Bug: T372871
Change-Id: I84e679a8365f3fbfabaf344d99f56f6d069c0776
The model is now fully owned by the edit panel and I could not find
any usages of this outside of that class using codesearch.
Bug: T369005
Change-Id: I911fee99d6c910e6e40e0b3cbdb4c7ab60b413c6
Making sure that change events form the fields are handled in the
panel and forwarded to the dialog with the information needed.
Also slighly moving some calls in the setup process that inits
the dialog and removing some duplication. Calling focus on the
edit panel only makes sense in the ready step. Not during setup.
Bug: T369005
Change-Id: I4f9a022a06ec6543b106620eae030235b8f6712b
That's another step to separate the editing form the dialog. The dialog should not know about internals of the edit panel.
And eventually the dialog can get rid of the referenceModel property.
Bug: T369005
Change-Id: I9cf3a68ef58bc5791497af362c0572734e4bcadd
I could not find any connect() was applied from this codebase to
the SurfaceModel. Looking back it seems that the code that connects
the event was removed in Icba13d84e10cf18a6c68e26448b2efe93b8c42b8
and the disconnect was never touched.
Bug: T369005
Change-Id: Ieab623751dd946ba43c42a1be144e6b3725abce3
There's no need to populate and use the form fields when we're
reusing a reference. The group and content are already stored
in the model and we can insert more directly.
I found that it's also not needed to update the internal item
because we're not changing the content or group. The same is done
in Citoid when reusing a reference.
Bug: T369003
Change-Id: I57315aafb73b0cd68a0d397d2f79833ac54a7c7f
Singleton always steps up to the original document from fragments, to
give absolute numbering.
Bug: T370874
Change-Id: I0353649289f6c8fe26fa6bdff5d2367b7b575bac
Mainly leaving out the event handling for the change detection to
still keep it simple.
Also the data flow back for editing the content is still somewhat
opaque because the relevant data is passed by reference. I might
change that in follow up patches so it's more clear.
Bug: T369005
Change-Id: I93b62791ef10bf318697905af8a0c5b5d438fdb5
This patch gives us the same number as will appear in the document,
even when subrefs are present.
Tests could be improved using sinon to check some call assertions
but should be fine for now.
Removed the test for placeholders, because these should be filtered
in MWDocumentReferences.getGroupRefsByParents()
Bug: T370874
Change-Id: I7543a6593308c529bcfbeb0835a7c0882cbf8621
Minor tweak to render the parent as HTML, without fixing anything
else about the layout.
Bug: T370873
Change-Id: I507acf7b86a20d1965bbb32fdc0132b41c929d0c
Some wikis such as eswiki and frwiki prefer to hide the square
brackets by default. Adding a selector-friendly DOM element around
the brackets supports this customization.
This makes it possible to hide the brackets with CSS:
.cite-bracket {
display: none;
}
And it also becomes possible to hide the brackets but make them
appear in copy-pasted article content:
.cite-bracket {
font-size: 0;
}
Bug: T370512
Depends-On: I56b52c399d2c76689fdcb0bc7fd50a8c0ced28fd
Change-Id: Id8684ccee2e6725af2c861da20fc31af1067e614
Some wikis prefer to use Western Arabic numerals rather than the
digit transformation table associated with the content language
script. For these, we should respect the existing
$wgTranslateNumerals configuration settings.
Bug: T370585
Change-Id: I663ae28c5b5d4fdd66b8590eb0b453ec25c2db84
