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
We were scrolling to the edited section when we saved the page, and otherwise
reverting scroll position to the top if we just abandoned the edit. This
unifies these cases, so any section-edit which leaves the editor will scroll
to the section being edited. (If section==new and the edit is abandoned, it'll
scroll to the last section on the page.)
Bug: T194631
Change-Id: Ic2aca68b3127c435545644912b96212bcfa6648d
If the mediawiki Api pass redirects as true, the response will have
redirect data. ApiResponseCache ignores it now. This commit adds
support for processing that and set in the cache.
Change-Id: If4f8c9b6719c123b31d852eb71f06a79cc0f7917
Cite's a08febb0afa2d changed the rules for adding the Cite button to the
toolbar – it now requires a placeholder slot in the toolbar, rather than
finding the link tool and adding itself after that. As ve.init.mw.Target
was updated for this it kept working on desktop, but MobileArticleTarget
completely overrides the toolbar, and was missed.
Bug: T195191
Change-Id: I55c9de9e736bb83f5f05028f2fc07af0ad996050
Throw a dialog box up to ask whether to convert something with formatting to
wikitext, or downconvert it to plain text.
This logically depends on Ie9aaaa59e9dfa138d394051fe491573253df1805.
Bug: T190079
Change-Id: I6afbbe303d1506426109e75c95f6be546ec48536
Depends-On: Ie9aaaa59e9dfa138d394051fe491573253df1805
Pressing escape will close toolbar dialogs (find/symbols/etc) if they're open
instead of trying to teardown the editing surface.
Bug: T190068
Change-Id: I27080649392f17344c901269029368fa0b3c2963
T190570 (I54d75ab6061de0de79b7a8112eb859a4c8a5e22a) changed old editor's
display of the limit to only show when there's <= 99 remaining. Bring same
behavior into this dialog.
Bug: T194458
Change-Id: I7f6fd7ee95348c39b107131a7e297d158a07c00e
It was failing to properly ignore the fragment if it contained a ?. This
resulted in such fragment-selflinks being considered a link to a wikipage with
a title of their full URL. As such, only consider the pre-# section for ?s.
Bug: T194463
Change-Id: I205f86d2b4abcf91dd6a84e3013e899e953a6842
New changes:
3a6d868bf Separate (Comment/Link)InspectorTools into separate files
cb5d36e32 Localisation updates from https://translatewiki.net.
c75491b16 build: Extend 'svgmin' options and amend
ddef270d9 Genericise activeLink behaviour to any annotation
d13d44e12 Create simple comment annotation type for rebaser.
7e49a1f33 Add getters for author properties
1d341ca7d Follow-up I16942623d: Only filter inactive models if they are 'canBeActive'
Local changes:
Change .ve-ce-linkAnnotation-active > .ve-ce-linkAnnotation.ve-ce-annotation-active
Bug: T185596
Change-Id: I2a49315d01aa075373f9b5f0d8802a7e7dd4dca3
Override #addSurface instead of #getSurfaceConfig, so that the
$overlayContainer option only applies to the "main" surface of the
Target rather than all of the surfaces (including those in
TargetWidgets).
Bug: T194433
Change-Id: I61c609e2d52814b4547fb5292a0bfb237c4c218f
Adds support for align=none.
Also don't show changes from class names.
Change-Id: Ia00a51dd52af73183e98c8a87f4c60ee5380d81f
Depends-On: Ic668454c4b4b069dab46a608530c85a5bb7e7ad8
Just generate the standard wiki skin markup for categories. Adjust linkcache to always know
whether links are hidden categories. (It previously knew *sometimes*,
depending on whether a MWCategoryWidget had interacted with that category.)
Make the save dialog preview use the same method as the bottom-of-editor preview.
Bug: T194092
Change-Id: I37fea15eaef0a5847f27ce41dd92370a4bf353b6
New changes:
14bcc9256 Give toolbars groups names
Local changes:
Give toolbars groups names
Also create an empty placeholder group for reference tools.
This allows targets to specify if they should show them.
Depends-On: Iccaf35cf941cb47ad55e8d98373461f5eaff5fed
Change-Id: I0bace5e5fe05f9c214d57a74c478b48a7dcaec3b
Also allow preview elements to existing with an mw-body-content
area withouth the font size being applied twice.
Depends-On: Ibbf989dcebf2d21fd2ac481f17062f366ff29e41
Change-Id: I284bcd5dd25cdbb883427ebacb41af1bbf50b60f
jQuery.makeCollapsible styles now display "fake" expand/collapse
toggles. This is nice, but some bits and pieces clashed with our
styles, this fixes it.
Also ensure that the styles are loaded if the page previously had no
collapsible elements on it.
Bug: T194323
Change-Id: If8f0869e6677811147f272337da7d96286792fe0
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
When the user is viewing the last stable revision of a page which has
newer unreviewed revisions, FlaggedRevs wants us to open the latest
(unreviewed) revision of the page for editing.
Use the JS config variable 'wgFlaggedRevsEditLatestRevision', provided
by FlaggedRevs since change I4c9804fe2c4924e28770807881379ddca4fd8b76.
Also add an extra comment about loading latest revisions in general.
Bug: T165283
Depends-On: I4c9804fe2c4924e28770807881379ddca4fd8b76
Change-Id: Ic47491e690153d0ad87ce64bfc9e7a28a06fc6e2
New changes:
a8e0eef6d Simplify usage of dummy target
Local changes:
Simplify usage of dummy target, ceating an MWDummyTarget, extending
DummyTarget instead of mw.ArticleTarget.
Depends-On: I01a6860387087db8149c73793e9bd4294d33aea8
Change-Id: I227486159fe416c219e2c37a1d054201084fe285
The duplicate header, especially the duplicate elements with identical
IDs, were difficult to handle for other scripts.
Now instead of hiding the entire wikitext diff, we only hide the
"content" rows but keep the header, and adjust our attributes on the
header back-and-forth when switching diff modes.
Bug: T192755
Change-Id: I3a6bb4730fefd81f533b786ec3b20241c4cb8d13
When we set up the new section title input and possibly set its value
(preloading from URL query, or from autosave), the "Save" button on
the toolbar must already exist, because we try to enable it.
Bug: T192901
Change-Id: I3bba86a8c8a9b81014d425db256ff49f06bdaea6
Equivalent to some existing copy-code in inspectors which handle raw wikitext.
Lets us shortcut content-sniffing with html/text content onPaste.
Change-Id: I27ded82a9675abdb3ee98ee29390e7079d11cf05
Ensures that auto-save data is cleared after
creating a new article, or restoring a revision.
Bug: T192770
Change-Id: I348b8522c1a935d7db1243ba8fcbd5b24e3383a2
This allows plain text pasting into source mode without interfering with the
possible-conversion that should happen when it's pasted into visual mode.
Bug: T190590
Bug: T192320
Depends-On: I47a5bf321fb64d4a631ec6fd728bee269d4cdae0
Change-Id: I71db368c683a6a846569d7627f4cc73e907a61d2
New changes:
aee32648a Allow access to a fragment's async state
a64ba1cc6 Add extra copy/paste tests for <span> clipboard keys
Local changes:
* Fix signature of runSurfacePasteTest
Change-Id: Idbc2f2c25eaf0606c51d9dff8ec23562f5244c08
Add label to indicate the function of the input field underneath the
categories label in the options dialog. The <label> element is
preferred for screen readers and users with visual disabilities.
Bug: T146966
Change-Id: Ib300ca7a1fd55d320c1a1a8c8c7fd01ab8b0b9c5
