I have moved this block of code to the wrong place in change
13675e4a81. As a result,
`this.loaded` was being set early, so the dialog was treating
all of the pre-existing transclusion parts as newly inserted,
and the "Apply" button was therefore always enabled.
Bug: T209661
Change-Id: I3c1b45f91738ab6fc4a6f6d61ae5bf925c9a1bb5
Undoing the changes to an image caption or alt text, or to the gallery
caption, or to the order of images, or removing a previously added
image, will now disable the "Apply" button again.
The following cases will *not* disable the button again, and it is not
feasible to implement them:
* Re-adding a previously removed image with identical options
* Changing any caption to the old value by other means than "Undo"
* Changing image caption or alt text to the old value after switching
to a different image and then back
Bug: T206534
Change-Id: I7c19600e741211a6ba61837513497facbafc5cef
Use 'change' event instead of 'reorder' to respond to this event.
This also covers removing images now, so delete that code.
Bug: T206534
Bug: T209451
Change-Id: I9eda383be2ca7f02b42814d43e6b42961b9b96e7
Enable the Apply changes/Done action if (i) the current contents
of the dialog inputs would change the gallery node or (ii) if the
user has interacted with inputs that alter the gallery caption or
images (including dragging/dropping or removing an image).
Bug: T206534
Change-Id: Ia6c1cc60d4f32ac66778e6973e2d400491f74128
Extracted extractValue to a separate method
Added checkValidRedirect method to MWSettingsPage
Added errors when redirect address is invalid
Added 1 error message to localisation strings
Added 1 TODO (more precise error messages)
Bug: T74971
Change-Id: I8bcf16e97e5211671759acdf0846243df2c03fc2
Now when using the MonoBook skin, the text size for headings inside the dropdown is the same as their size on the page.
Bug: T72559
Change-Id: Ie0c30369021f8022b788730a6de90e44a288b13b
This way users can rearrange/edit current name without exiting VE and/or copying it from somewhere else
Bug: T145339
Change-Id: I80690cdf344c2ccbdd8be486642afcf841f36c10
This reverts commit be628a5b7e.
87b20f9b Revert "[BREAKING CHANGE] Do not cache document model data in DM selections"
Change-Id: I47bbf757a4ad227346d3734f6e50d928a2de1409
The initial value for the categories field is set asynchronously
(after potentially querying the MediaWiki API about the categories).
This caused the existing categories to "pop in" after the dialog was
opened (if you were on a slow network and it took more than 250ms to
query their information).
Additionally, it caused the "Apply" button to always be enabled if the
page had any categories on it (since the categories field was still
empty when extractSettings() was executed).
Bug: T207719
Change-Id: I46475a1eead91707edb8efe8cb7221a734818e16
Added 5 methods for MetaDialog (documented in code comments)
extractSettings
compareSettings
getAllWidgets
assignEvents
updateActions
Added 2 fields to MetaDialog
oldSettings
widgetList
Apply changes button now is only enabled when there are new changes
Added getFieldsets method to all subpages
Bug: T207719
Change-Id: Id51acf6c754d9a2572811775d83983e6ab9395b7
New changes:
ccb4de82c [BREAKING CHANGE] Do not cache document model data in DM selections
Bug: T208228
Change-Id: I564399ad864751d1690077b45a06e098b5509a93
I am surprised this was disabled. I investigated this after reviewing
some code by a new contributor which I was certain should have failed
the lint check, but passed.
Change-Id: I5b3c837b8ca3292f6e268b3922443bd9587eadbe
Reasons why these files should not be in a directory named "themes/":
* They are specific to MediaWiki skins, not OOUI themes
* They are specific to one module, rather than affecting many widgets
The new locations/filenames are consistent with other modules that
have skin-specific styles.
Note that we have one more themes/ directory elsewhere in this repo
(and another in VE core) and that is okay.
Bug: T96704
Change-Id: I70bb61e339aeccb3afea657f665785ceaa091777
Map nodes with an empty body don't have a body property on their
'mw' attribute; so don't add one when checking if the node has
been modified.
Bug: T206473
Change-Id: I24fb8d5f012c417996c8d420fa25af9d13528d18
In the "advanced settings" tab, make sure widgets are wrapped in
field layouts, then fieldset layouts.
Bug: T205615
Change-Id: I141f9954e482f9d5afd84bfa63384b90a2911d00
This rule was being overridden by a more specific rule from OOUI with
the selector `.oo-ui-fieldLayout.oo-ui-labelElement`. I don't think
the margin tweak would be useful.
Change-Id: If6321ba7ea1cfad83f65f137b2a440957bf2fea6
* visualeditor-dialog-media-size-originalsize-error
Unused since 37b3c07b26.
* visualeditor-dialog-media-originaldimensions
Never used (introduced in 4947420650).
Change-Id: I22f37b457cc6fbac03593fece003e97f4f5a2ccf
Also make improvements to the layout, so that the dialog works
in desktop and mobile - most importantly, change from booklet
to index layout.
Bug: T190885
Bug: T118710
Change-Id: I1915d06c9b0e4b7907136e645f60be96e30cc287
I ran Closure Compiler over the codebase just to see what would happen,
and it printed some useful warnings.
Change-Id: I56d40b11e6d1dd7ce68a5e59da511f66e928647f
TemplateData doesn't always match up with the way the template is being used.
If a field has the `line` type, but is provided with newlines, we should avoid
mangling it by forcing it into a single-line field. As-is, any edit to the
template, even if the user only thinks they touched unrelated parameters,
would cause this.
Bug: T190191
Change-Id: I4f2a0b6c46532dcc268288cb209d0260b18f3ad7
New changes:
3b62827b8 Remove negative margin from mobile context action buttons
694705894 Implement a simple notification system to fill in for mw.notify
461283560 Validate history start when applying/unapplying change
Bug: T202514
Change-Id: I203dc5101bc31988df2d3986da4300a318e5e889
New changes:
fa5d35054 Only re-use session token if docname matches
58d7cd280 Localisation updates from https://translatewiki.net.
d0716d8e7 Update files generated with new l10n language 'my'
2cc7a4423 Create unit tests for sequences
873fdd01e Upstream horizontalRule sequence and fix command
Local changes:
* Register unit test file for sequences
* Remove duplicate horizontal rule sequence
Change-Id: Ibc65cf5c086428bb0d13c8e2f2de5819e1e23d43
While all of the following are valid in the model:
1. <mwBlockImage></mwBlockImage>
Image with no caption. Must use the media dialog to insert one.
2. <mwBlockImage><mwImageCaption></mwImageCaption></mwBlockImage>
Image with empty caption. There is a slug to insert a paragraph.
3. <mwBlockImage><mwImageCaption><paragraph></paragraph></mwImageCaption></mwBlockImage>
Image with caption with empty paragraph. Nice and intuitive!
(Same for <mwGalleryImage> / <mwGalleryImageCaption>.)
The third option is the most convenient for the user. We should always
generate that when converting documents from HTML and from the editing
tools (MWGalleryDialog, MWMediaDialog/MWImageModel).
Previously, the editing tools generated option 2 if no caption text
was entered, and the converter generated option 2 if there was no
caption node or if it was empty. Curiously, option 1 was never used.
Wikitext for manual testing:
```
[[File:Foo.png|thumb]]
[[File:Foo.png|thumb|]]
[[File:Foo.png|thumb|Caption]]
<gallery mode="packed">
File:Foo.png
File:Foo.png|
File:Foo.png|Caption
</gallery>
```
Bug: T200387
Change-Id: Ie82fb339f6bd8ae1b289235bf5402490722d9a7c
* When ve.ui.MWLinkAnnotationInspector is being initialized,
internal and external annotation inspectors are hardcoded to
new ve.ui.MWInternalLinkAnnotationWidget and
new ve.ui.MWExternalLinkAnnotationWidget. Make this creation
more flexible by creating these inspectors through a method,
which inheriting classes can override.
* In ve.ui.MWLinkAnnotationInspector.getAnnotationFromFragment,
factor out the creation of link annotations, so overriding
classes have the ability to provide different internal and
external annotations.
* In newFromTitle, static method of MWInternalLinkAnnotation,
creation of `element` isn't flexible for reusability with
slight changes to attributes passed to the constructor. By
factoring out the creation of attributes, inheriting classes
can reuse the existing structure and alter the attributes if
needed.
Bug: T195064
Change-Id: I2037464a7be77783837e9810691c8e372c8197c6
This is similar to the hack in ve.ui.MWMetaDialog, except uglier :(
We already explicitly focus the right field in the ready process.
I am not really sure why the focus change causes the issue, but
preventing it definitely fixes it. It would make sense if we changed
the value of the field after focussing it (as setValue() restores the
validity flag cleared by onFocus()), but we don't seem to do it.
Bug: T199838
Change-Id: Ia602551ee0b0885cefbd4cb2fc00d569ff42da67
The #getReadyProcess method should be used pretty much only to focus
a field inside the dialog after it is opened. It runs after the window
opening animation finishes, so if you add stuff to the window here,
that will be visibly delayed.
The #getSetupProcess method should be used pretty much for everything
else that depends on the opening `data`. It runs before the window
opening animation, so if you add stuff to the window here, it will be
visible while animating it.
Bug: T185944
Change-Id: I71ea5b6e1e1947c1cf8fd749100e854953a8ef3c
We relied on some white space baked into the background-image
to "reserve the space" for the text. If we tried to make the image
smnaller, the text would start overlapping it.
Remove 100px of vertical white space from the image files, adjust
the styles so that text is displayed below the image rather than
overlapping it.
Bug: T191095
Change-Id: I2f19128a2044b3505cdea93c3f587fe62553071d
There is something about ActionFieldLayouts with `align: 'left'` (the
default) and no label that causes Firefox to render them differently
than we expect. I am not sure if the bug is in OOUI or Firefox, but it
is easily avoided by just using `align: 'top'` instead (it looks the
same, since there is no label, and it avoids the issue).
Bug: T198274
Change-Id: Ic6077e576b504e7a0cd761c8bac24d4079ae6702
This way the tooltip is shown on the entire button, rather than only
on the icon. One should only use 'iconTitle' to display a different
tooltip on the icon than on the rest of the widget.
I think this was caused by bad documentation in OOUI, which I'm fixing
in I967d9b78014b3754720e80da9c4785124fffc2ba.
Change-Id: I8cc99bcfca56b80a8c8aff609ba48eb3f9c5ed7f
