* "visualeditor-dialog-transclusion-options" was added in 2013 via
I3bcf924. It was used as the label for multiple FieldsetLayouts in
ve.ui.MWTransclusionDialog.js. In 2013 a larger rewrite was done via
I51e74b3. The FieldsetLayouts with this message don't exist any more
since then.
* "visualeditor-dialogbutton-meta-tooltip" was added in 2013 via
Ibf63329. It was used as the button label in
ve.ui.MWMetaButtonTool.js. This file was deleted in 2013 via
I3bb61d5. That patch added a new message "visualeditor-meta-tool"
that says the same as the old message". The old message is unused
since then.
* "visualeditor-savedialog-label-create" is a new key for a message
that existed before. The old key was "visualeditor-create-page". It
was used in ve.init.mw.ViewPageTarget.js as a button label. This
usage was removed in 2012 via I5f59482. The renamed message was
never used.
* "visualeditor-savedialog-label-report" was added in 2012 via
I5f59482. It was used as a button label in
ve.init.mw.ViewPageTarget.js. The feature was removed in 2013 with
no replacement, see I8a5e0ab. Some of the messages that became
unused got removed in the same patch, but not all of them.
* "visualeditor-savedialog-warning-dirty" was added in 2013 via
I3daf631. It was used for a confirmation popup in
ve.init.mw.ViewPageTarget.js. I8c0db01 moved the code to
ve.ui.MWSaveDialog.js. In 2015 the confirmation popup was removed
with no replacement, see I9091534.
Change-Id: Iae7961612d5b5be9cdd294a67a9ce40ee8cb9b4d
The message "visualeditor-dialog-template-insert" was added in 2021
via I5da4003. It was used as a dialog title in
ve.ui.MWTemplateDialog.js. In 2021 we introduced three new messages
via Ib9b76ca. One of them still says the same as the old message, but
got a new key assigned. It appears like we forgot to remove the old
message.
Change-Id: Ie3854114197e3f36b48bb7efd8dd96a1f9651198
Log a client error when VisualEditor cannot load because of an
incompatible skin (which is not supposed to happen in practice).
Bug: T312632
Change-Id: I2ccfaa584d7a05e10170a66d446bd4e476dcc775
Depending on the order in which this code executed, sometimes the
dialog initialization would overwrite the readonly state set by item
initialization.
They should simply all check both conditions.
Change-Id: I6a18f1e074f118423438c017b3e4e34e75579e5d
This code was for when the dialog had a trash can icon for every
parameter, and parameters could actually be deleted. It's unreachable
now.
We missed this when removing the old workflow.
Change-Id: Ic94df506ea84009a1e1863a4e9847a70498df448
OOUI support for multiple modal window managers is hacky, and only
works correctly when the managers are attached directly to <body>.
Remove the wrapper that doesn't seem to be necessary.
Bug: T313690
Change-Id: I4134c0f50d28a364dcf15b426bd9b59a4f7a985d
The dialog is unusable when there is no outline. See T313489 for a
longer explanation.
Bug: T313489
Change-Id: Ib2cc9c363d3596a16f6f1c4aef03ca216abf6b1f
Apparently this can be undefined when Esc is pressed. Note this code
cleanup related to but does not fix T313690.
Bug: T313690
Change-Id: Ia4658f8e00a68ed4cc3a6ddb0a932b3218b813dc
The need for something like this was anticipated in
I2bf43c7e83283f43e047229eb53c244918fcbb0c.
As of version 2.5.0 of Parsoid's output, if alternate text is missing
for an image but a caption is present and image isn't displaying the
caption (ie. it isn't a thumb or frame), then the text content of the
caption will be set as the alt attribute. Parsoid will then drop the
alt attribute when serializing if it matches the caption text, since
it's unnecessary.
However, if the caption is modified and the alt text isn't, the alt will
be serialized. This is likely to be unexpected to editor. They may
have missed that the both the caption and alt are populated in VE and
only edited one place.
Since all of the above is happening only for images where the caption
isn't visible, it doesn't appear to be a much used feature since, at
least for inline images, the experience of caption editing was already
less than optimal.
However, because of a quirk in how galleries are rendered in Parsoid,
this affects gallery caption editing, which is visible and presumably
used more often. See T268250 for a discussion on an improved gallery
structure. But for now, gallery images are effectively inline and set
the alternate text, thus subject to the above.
Here we add a checkbox so that the default is to ignore the alt if it's
the same as the caption. And only make use of it if it differed
originally or was explicitly unchecked to modify.
Bug: T311677
Change-Id: Idf297d8a98995971c5835b0cea56c3317a3626e2
Turns out we have two concepts, now represented by two methods:
1. A top-level part can only be moved or removed when it is actually
selected. This is relevant for the toolbar buttons and for the
keyboard shortcuts/hotkeys. We intentionally block the buttons
and hotkeys when a parameter is selected.
2. Adding a new part or parameter is always possible, no matter if a
top-level part or parameter is selected. This is again relevant
for the toolbar buttons and hotkeys.
Bug: T313388
Change-Id: I17caf8fce9d8f1ebe21660cf8c6d91ace8423490
Same issue as in the previous patch, but less intrusive. It was always
possible to add a new part, but it was often inserted at the wrong
position. It worked only as intended when a top-level part was
selected. When a parameter was selected, the new part was always
appended to the very end of the transclusion, not after the selected
template.
This is now a little bit of duplicate code. We might extract this to
a method in a later patch.
Bug: T313388
Change-Id: I1327222969d1d315bdacf3998f366d88c4c26bd5
The hotkey was only working when a top-level part was selected, not
when a parameter in a template was selected.
Some outdated helper methods are now marked as deprecated. They will
be replaced and removed in later patches.
Bug: T313388
Change-Id: I5ffe45fd00c36b97ee36dc0ba6831db5a941c731
This is a partial revert of Iaf089f4. It restores the old behavior:
* In case there is already a highlight in the parameter list, just
keep that. Usually there is no highlight at this point, but better
have this check in place to be sure.
* Otherwise always start at the top.
Jumping to the selection is confusing, esp. for keyboard-only users.
The argument goes like this:
* Let's say I'm in the middle of editing values on the right side of
the dialog.
* I want to navigate to the sidebar. How do I do this with the
keyboard? I use the tab key.
* Pressing tab also implies I move the selection to the next
parameter. And the next. Until I reach the end of the parameter
list. Then the selection stays there.
* When I finally reach the sidebar and tab into the parameter list,
the last parameter is selected. But this was merely a side-effect
of me navigating the dialog.
Such a "selection becomes highlighting" behavior was not specified
in T311204.
This patch is requested and approved by PM.
Bug: T312647
Bug: T311204
Change-Id: Ie5b5dfd4fca132050815e6182845ca23adb5f805
Before, permission editnotices didn't have access to the page titles, so
magic words like {{PAGENAME}} would give a subpage of Special:Badtitle. This
formats the message in the appropriate context.
Bug: T313372
Change-Id: I93894a4fc129de9da4b120c084b1d343b4021cdd
This should make zero difference in most situations. Except you
navigate a list of parameters with the keyboard. In this case the
SelectWidget gets a dark blue outline which overlaps with the light
blue selection bar, but the outline disappears behind the bar. This
looks odd. Making the color transparent fixes this without the need
to fiddle with z-index or such.
Bug: T311204
Change-Id: I7049eb60dc0ea72c2c4620f4351525fe447e0f46
