In the "advanced settings" tab, make sure widgets are wrapped in
field layouts, then fieldset layouts.
Bug: T205615
Change-Id: I141f9954e482f9d5afd84bfa63384b90a2911d00
Split on regexp for whitespace instead of a single space. Avoids multiple-
spaces causing `'foo bar'` to become `['foo', '', 'bar']`.
See also: I1f467f51017e2deae30905163bf5e6b07048cecf
Change-Id: Id7a887a20fac99715b79045f01e861b4efe9f2c7
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
I suppose technically you don't need it if you're already on an
?action=edit page, since that will cause the editor to load as well.
At a glance nothing seems to break if it is missing (other than the
fact that there is no way to launch the editor, obviously).
Bug: T179427
Change-Id: I3c221ded302702b881857930da5dc41630680c02
Requires I28278449512ed1e5e8c4ac6ae390334a26d1bad6 in
mediawiki/skins/MinervaNeue to be merged at the same time.
There should be no visual change if both are merged.
Change-Id: Ia13f758a6870be2e6c89fd11f2ee3544ac61a1d7
In WikimediaUI theme, the height of the toolbar is defined with
'padding-top', but in Apex theme, it is defined with 'height'.
Set both properties to make this work with both themes.
Remove unused styles for the dropdown. It is now positioned by OOUI
(since T192505). This should have been done at the same time as
e1635fdc52.
Bug: T194120
Change-Id: I9cac0c9458ae8cc26c5f056bb26686f8ad50c493
New changes:
a273ba69c [BREAKING CHANGE] Implement a SourceConverter
Local changes:
* Use SourceConverter
* Handle `this.doc` being a string in source mode now
Bug: T203114
Bug: T203156
Change-Id: I7bce7b57668e0c1dd511803a54178ae69694a86d
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
ve.track tries to guess the platform, but it needs a loaded Target to do so,
and init happens before that.
Also, log a warning when this happens, in case it comes up again.
Bug: T203618
Change-Id: I35fa58a42cd247e01f3717c9ab3a10d8ea93a484
Re-enable tests, but disable setEditorPreference API calls in setup.
This reverts commit d5fe71fd6e.
Change-Id: Ib6f0f18acc1ccb40cb6c055609dc1484b381bc8f
Causes random failures in other unit tests due to API requests.
This reverts commit 031d2dd50e.
Bug: T203412
Change-Id: Ia94b090687ba8d6023060e6dbe10b6a45035e76a
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
Just call the method after surface init.
Also move all the post-dm building code into
an #addSurface override.
Change-Id: Ie40baadfa6cd826a92f8fb7d928f4d995286f69f
MWTransclusionNode will preserve TemplateData <style> in its generated content.
Disable TemplateStyles stylesheets in the original page content, and reenable
them when the surface deactivates.
Remaining TODO: if multiple copies of a template with deduplicated styles are
on the page, and the one containing the actual <style> is removed, all will
lose their styling.
Bug: T197563
Change-Id: Ibd8939eef7d8eb532719f4ee0ce200600449ef81
Depends-On: Ia9f2afcdba5456238e3ef444c202c9b0c78838bf
Many of the details of the behavior don't really matter, but
I suppose it doesn't hurt to document them.
We really want to test two things:
* When converting from DOM to model data, a <mwImageCaption>
or <mwGalleryImageCaption> is always generated, even if
DOM has no caption.
* Model data that doesn't have <mwImageCaption> or
<mwGalleryImageCaption> is nevertheless still valid and
converting it to DOM doesn't fail.
Follow-up to Ie82fb339f6bd8ae1b289235bf5402490722d9a7c.
Change-Id: I0a10351e9c1589afbee76d8a85f869987de3de22
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
This padding needs to come out to an exact integer pixel value (14px),
otherwise things are off by less than a pixel and look ugly: F24664180
1em = 16px
0.875em = (14/16)em = 14px
Bug: T190596
Change-Id: Ieb292ed14e0b9205d15254667e97613fbf339260
Refactoring in 92c4e23 didn't account for the case where there are multiple
tabs and source mode isn't NWE, which caused the "edit source" tab to just be
a page- navigation that always discarded changes. onEditTabClick handles this
case fine, so just always bind the handler.
Bug: T199655
Change-Id: I3dca87a7a3b0ea88ef0008be89cd1f6007167916
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
The linkCache fetch can push the categories out of order unless everything is
already in cache. As such, remember the initial order and enforce it after the
promises have resolved.
Bug: T197759
Change-Id: I9ea8d5e642f62c96475d0713f2c79258abb33b19
I.e. don't sort them, because they're provided in source order and that's all
we need.
Bug: T197759
Change-Id: I3b9508ff49233ccfbeba1d111a6df9f29f0fc318
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
They look like they should also apply to Flow, ContentTranslation, etc.
And apparently CollabTarget was already loading them separately.
Change-Id: I5c502f8e060968ecee67567747f29eb630cda718
If the wiki runs on a host that contains a port number, section edit
links would always reload the page, and the "Add section" tab would
not work.
As it happens, my local testing wiki runs on localhost:3080.
It is an unfortunate naming mishap:
* mw.Uri#host is equivalent to location.hostname
* mw.Uri#getHostPort is equivalent to location.host
In this case, we have to compare the port too, otherwise a setup (my
setup ;) ) where one starts up another wiki on localhost:3081 to test
cross-wiki features would fail.
Change-Id: Ib7de4ba3c3a84888f24186af03bd9dcced131051
It contains some rare options that we don't currently make editable,
and we don't set it when creating new image nodes.
We could change our code to always set it, and consider it required,
but that would theoretically be a break in backwards-compatibility.
Bug: T198660
Change-Id: I6e77cce257f733f0f8f6e896b967177ff01658c6
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
What happens when an edit tab is clicked is spread across handlers in
DesktopArticleTarget and DesktopArticleTarget.init. Consolidating the logic
into the handler in DesktopArticleTarget.init makes it easier to understand.
It could be moved further into DesktopArticleTarget, but the init handler has
to exist to activate the target in the first place.
This patches a hole where clicking "edit source" while in visual mode would
sometimes not switch to source mode, because it didn't think it was changing
the current section.
Also, fix a typo in the documentation.
Bug: T198272
Change-Id: I12d958b6af1b9fa9aca68b498eb2a1a2d76b5a82
