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
New changes:
3d2ffae4e [BREAKING CHANGE] Have ve.htmlMsg return a node array instead of jQuery collection
Local changes:
* Have ve.init.mw.Platform#getHtmlMessage return a node array
Change-Id: Iabd823c851f94356f1902918278f88068dfe4d25
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
The schema itself is being renamed, many of the field names are
different, and two new fields were added (page_token and session_token).
Bug: T207803
Depends-On: I2949c9782669b75cf17978698c8cef21fdee6dea
Change-Id: I3ec11d74d71207acac130689bac93d5bf0c70715
New changes:
7c9fe89b8 Simplify ve.test.utils.runSurfaceHandleSpecialKeyTest API
0e3c75e66 Add more tests to LinearArrowKeyDownHandler
058362830 LinearArrowKeyDownHandler: Test Selection#extend fallback
8c6617d90 Keydown test refactor
91a909d63 Assert defaultPrevented state in KeyDown tests
003dacf3b LinearDeleteKeyDownHandler: Test shift+delete
1872158c5 LinearDeleteKeyDownHandler: Test delete next to link
b2af2a2c3 LinearEnterKeyDownHandler: Add more tests
4e5efa956 KeyDownTests: Remove unused constructor calls for all static classes
1cafb7328 KeyDown tests: Add tests for missing cases to cover tab/escape/enter
58af8d497 Add tests for ve.ce.AnnotationFactory/NodeFactory
617bc24a4 Delete unused ve.ce.modelChangeFromContentChange
50704fa1c Keydown tests: run asynchronously
af9a01b97 Use native promises instead of jQuery promises
df212669a Localisation updates from https://translatewiki.net.
f6af901dc Fix test in Chrome 70
9cc6dae7e Remove broken checks for DM code coverage
ce3a9199a LinearEnterKeyDownHandler: Add test for edge case
0a9dd3636 Remove false coverage of TableNode/TableSelection code
16679a3c0 Remove setupToolbar from DummyTarget to avoid false code coverage
7ac88df77 Basic tests for getClientRects in ve.ce.Selection and FocusableNode
78f14ac1f ve.ce.Selection: Add getDirection tests
7ec7efff0 KeyDown tests: Remove unnecessary setTimeout
26e022d23 KeyDown tests: Un-nest functions
df1e0af6c KeyDown tests: rename defer -> then
f03a9f90b Allow ES6 in tests
0ee55022b ES6 eslint follow-up
6c288b44f ve.ce.Surface tests: Trim when asserting expected text
Local changes.
Bug: T207077
Bug: T207078
Bug: T207079
Bug: T207080
Bug: T207083
Bug: T207654
Change-Id: I2e1f664d6f657e2ac26a271f401dc790c2a8b193
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
Respect the config var exported by WikimediaEvents that, if set to true,
forces oversampling. When oversampling, all events are logged even if
they would have been sampled out. The isOversample property is set to
true if the event was oversampled and would not otherwise have been
logged.
Bug: T206543
Depends-On: I5fdf5fdd2dc0d99a0a0d7eb7ab2e3dce4798009b
Change-Id: I314da47d7d250672f1a9b34edeeeb720850f8fac
Instead of hard-coding the 6.25% sampling rate, allow it to be
controlled by the config variable in the WikimediaEvents extension
(which also defines the RL module for the Edit schema).
Also use sampling code from EventLogging so we can configure the
sampling rate as a number, rather than using a hex-digit based strategy.
Bug: T206543
Depends-On: I00383cec62f6c2a0137b329565b0ca84bfbb223f
Change-Id: Ia3e9a0f93d5d3001f222a64f31e82a63db36d7ab
Rather than computing all the data then throwing it away 93.75% of the
time. Also use .charAt() for consistency with WikiEditor.
Change-Id: I6360b5c636e94db3483f542791d158f240c542f8
This won't really do anything until the patches to ve-core for the activity
events, and WikimediaEvents for the schema land.
Bug: T202148
Change-Id: Ie462a24f66240a1accfd0185c46273e60effbd64
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
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
aeb4f2f2b7 added a #wpTextbox1 to the wikitext surface, which confused our
existing teardown check. This confusion only became apparent in single-tab
mode, when using the wikitext editor.
Bug: T197615
Change-Id: I98e64e7135aaf6f8fda441a91e6cbc4bac6cea39
We already do it after save, but not if the editor is closed without
saving.
This behavior is a bit awkward for non-existent pages (redlinks),
since MediaWiki normally doesn't display them in view mode (all links
point to action=edit). But this seems less weird than not allowing the
editor to be closed.
Bug: T122388
Bug: T168338
Change-Id: Id9ee41356f011dfbfa6e8744b8d9076f8eacaf39
New changes:
71baf1c02 Create an 'htmlMsg' function for HTML messages with HTML or DOM arguments
9a7af223e Use ve.htmlMsg to highlight values in attribute changes
a1fd90540 DiffElement: Refactor describeChanges tests
Local changes:
Implement getHtmlMessage in mw.Platform and use for DiffElement
Bug: T195243
Depends-On: Ib4ad16858e4241d33d018830dbcfded63ff703af
Change-Id: Ib5fa39e4f2f529948354b03a141542e23d169fe0
Not checking this results in handlers blocking click actions for "read" after
the teardown of the target.
Bug: T197445
Change-Id: I3a962c66c82a0e48ca54bf2f0b822a9a005da54c
Previously, we changed it on every load, which also occurs when
switching editor modes. That caused it to not be restored when editor
was closed.
Bug: T197490
Change-Id: Icb20c38309fd440553d5245d865b05145542313f
Besides redirects, API can return from-to title pairs for normalized and
converted titles, as well.
Currently, doing an API query on eswiki for page info (prop='info' in params)
with titles='User:Title' returns normalized title 'Usuario:Title'.
processResult() method in ve.init.mw.ApiResponseCache.prototype.processQueue
sets page.title ('Usuario:Title') in cached results, and the promise for
actual queried title ('User:Title') gets rejected in rejectSubqueue() method.
Change-Id: I33fd4640b6eac8018e35c6fe21234f4c469dd97d
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
This adds in missing functionality, such as deactivating
the surface selection while the dialog is open.
Change-Id: I0d8652a989504a35e5c235224b0ef924b6dcbeed
This essentially creates a static debouncer, so if you have
multiple instances calling that method at the same time, only
one of them will fire.
Change-Id: I4c257b557e87f5638b459811655a14b8625de2e3
It doesn't have a "cancel and do nothing" route to fall back on, so pressing
escape does the non-progressive action, which is to paste-as-wikitext rather
than paste-as-plaintext. Neither of these is really an intuitive outcome.
Change-Id: I786b6fc87e3cdf3bb50898a070a15a353a242848
In Schema:Edit, all action timing durations (ready, loaded, saveAttempt etc.)
are defined as "time since the editor was initialised", which is internally
stored as the timestamp for the "init" action.
The 'init' action itself does not have a timing duratation, but the Edit schema
has a special case for it, definining it as "time since the page was loaded".
In actually, it isn't actually implemented as "time since the page loaded",
and I suspect that as such, this value is probably not used by EventLogging
consumers of the Edit schema. Or, it might be used, but doesn't represent
what the consumers think it does.
Presently, it uses the init time now() - mediaWikiLoadStart, which basically
means the time between the random point at which MediaWiki core JavaScript
finished executing which is quite variable in practice due to the race between
<script async> and browssing parsing/rendering of HTML. That is by design,
and is also why mediaWikiLoadStart is undocumented and internal, and actually
in the process of being removed.
After many iterations on this patch to try and approximate an alternative to
this undocumented variable, I came up with an alternative approach with DLynch
at the Hackathon, which is to simply not record this one timing value, but
preserve the behaviour of all the other timing values exactly as-is.
That is, keep the behaviour of storing `now()` as "init" when the editor
activates, and keep the behaviour of substracting "init" from all other action
times, but only don't report "init" itself to EventLogging (given its value
would be 0, which isn't useful).
Bug: T160315
Change-Id: I778234efe40dde8ff30333339335be1c3910a4e0
