To make it clearer that setEnabled(true) enables the feature, and
setEnabled(false) disables it, invert the function of the first
parameter. Also improve jsDoc parameter documentation.
Follow-up: I4615f629a0c97fb325721bbddee5c9eb074c3a5c
Change-Id: Icb84bcf0624774b9a7002110f1fac31bf48ebd1d
When the error layout is shown, hide the hover reload button,
and only re-show it if the preview is successful.
Bug: T306866
Change-Id: I5e72295069ee9e8279c5786c3959db5902da0e25
* Add hover and active styles to match normal toolbar state styling.
* Move border from right to left on `.section-secondary .group`.
* Add a skinStyle for MonoBook so it doesn't get the button style,
because it provides its own.
Bug: T303991
Change-Id: I6f08906156a9768729d779b6c50c9e804f51fb98
The CSS was already unused when the extension was created in 2010.
A comment that still mentioned the CSS class was removed via
I0798864 in 2022.
The message is unused since I9fb7e66, that was in 2021.
Change-Id: I25cd31efc4ee61ff3f857c280b5cd18c3ae4bd00
Make the reloadButton into a class member so that it's
accessible in doRealtimePreview().
Bug: T304568
Change-Id: I81c1870becd81884894353921f878653cd690d7a
Decode local page names after the "looks like internal" dialog,
to avoid invalid page names. If it can't be decoded, use the full
page title string.
This doesn't decode text in the ArticlePath, but that sounds like it's
much rarer and could perhaps create other issues.
Bug: T25789
Change-Id: Iac03573515affbc509f674db155767a81bad8b9f
After three slow preview requests, switch to showing a bar at the
top of the preview area that contains a manual 'reload' button.
The manual bar will be hidden when an error message is show, but
re-shown again after the error is dismissed. Closing and
re-opening the preview pane doesn't reset the manual mode.
Bug: T304568
Change-Id: Ia72bd1ceab68fdaed5de53137bd8ac5961db4714
Add a 'reload' button to the right-side preview pane (that shows
on hover, and stays in the same place when the preview is
scrolled), and also an accesskey to trigger the preview. If the
preview is not open when the accesskey is pressed, it'll be
opened.
Bug: T303532
Change-Id: Ifa77ad7cf6d2ed6a8b955f9a324986d1c6f9a993
Change from a pseudoelement ::before the left pane, to its own
element. This is so that when we introduce the top manual-reload
bar the blue bouncing loading bar can be shifted down below it.
Also moves the CSS out of TwoPaneLayout.less and into
RealtimePreview.less where it more properly belongs.
Bug: T304568
Change-Id: I540f68d528d92b7db8594d729985e5dad3d90ac1
For MW installations where BetaFeatures is not available, Realtime
Preview is enabled solely with the $wgWikiEditorRealtimePreview
configuration setting.
Bug: T304596
Change-Id: I880022883bf526a2aef237f4a75e790b0f9bd4e5
Instead of exposing a way of adding event listeners, just expose
the event handler and let consumers (i.e. CodeMirror) add it
to whatever events it wants.
Bug: T303767
Follow-Up: I8c8c25fe56be55a61f4b8d1d2ef8cf74483aa241
Change-Id: Iee4c885f92dd9ec985a3f9fd92a2fafc00f2e9ff
Add two new actions for the 'preview' feature:
* preview-realtime-on – The WikiEditor 'Preview' toolbar button
was clicked to turn the preview panel on.
* preview-realtime-off – The WikiEditor 'Preview' toolbar button
was clicked to turn the preview panel off.
* preview-realtime-inuse – Fired without user interaction when the
WikiEditor preview feature is already on when the editing form is
opened.
This also adds a new hook for the last of these to use and to match
the enable/disable hooks.
Bug: T298218
Change-Id: I1a2545c2b0491c1d07f9508fab70967d03d61594
Store the current state (enabled/disabled) of Realtime Preview in
a new user preference `wikieditor-realtimepreview` and set it
when enabling or disabling the preview pane.
Bug: T294599
Change-Id: Id5f51c6d77ed0077906d5d5178cbfa785cc04dcf
$wgWikiEditorRealtimeDisableDuration is introduced which allows
sysadmins to control the average time after which Realtime Preview
should be disabled. For now, this shows a simple error message that is
intentionally not localized. In a future patch, we will force the
user into a 'manual preview' workflow. See T304568 for more.
Bug: T302282
Change-Id: I2f01eef19fe81c19efedcc0073a28884f0055359
Change the sign (positive/negative) of the change amount (in pixels)
depending on whether the text direction is LTR or RTL.
Bug: T304487
Change-Id: I8f01a92e5e1094c9602d2ff334c730241193cedc
The mistake here was that these are two different fields, but with
variable names that look very similar. Only 2 characters differ. :(
insertLinkLinkTextField.…
insertLinkLinkTypeField.…
Bug: T304476
Change-Id: I459133d3ba5c327e34c689ad0d3c046116f438a9
If a preview is requested before one finishes, one final request is
fired off to ensure the preview is up-to-date.
Bug: T302282
Change-Id: I2399fc7cc08cd0987d2d689ca9f297db1ec5edf0
In “Insert table” dialog, when checking/unchecking “Add header row”,
Example preview first row switches between preview-hidden and
preview-header. Previously, preview-hidden contained 3 TD cells
(while preview-header contains 3 TH cells).
This commit removes the 3 TD to hide the TH instead of replacing with
TD, since, in the generated wikitext, the header row is not included in
row count.
Bug: T303690
Change-Id: I38c1bb081a30e25875de8beaadccc075189ad397
* Toolbar button to toggle a two-pane layout on and off.
* Resizable bar for the width of the two panes.
* Resizable bar for the edit box height, even when realtime preview is off.
* Only enabled when $wgWikiEditorRealtimePreview = true.
* Fires JS hooks when enabled, resized, and disabled.
Bug: T293347
Change-Id: Id09d44519249c0b7f5c33d48d524b7c92a5a9106
The main idea is to make the code shorter and easier to read.
One notable change is to use .test() for boolean tests instead of the
actual .match() function.
Change-Id: Ic43442b75f839906b644d4586c907601f4d5d521
Has sat there since the first commit in 2010 (r73055), but not used.
I imagine it was was a design prototype at some point.
Also fix a few minor eslint warnings about line length, and remove the
one-off "ext-" prefix and capitilised "WikiEditor" CSS class name that
the rest of the repo doesn't use.
Change-Id: Id0eeb456fffdb490a6a86974288e57099e53ce71
It looks like `wikieditor-loading` was already commented out in 2010:
9d278e8dee%5E!/#F114
and I couldn't find any usage of `wikieditor-toolbar-loading`.
Change-Id: I07988643ca502dcbd7c3208fb803a84003947d5e
This adds support for the new 'element' tool type to be a function
which returns the HTML for the toolbar widget. It means that it's
possible for the element to access the WikiEditor context object.
Bug: T286759
Change-Id: I6af12075b96d480639f2fc0d97333a6142480c02
Logic under LinkTypeField.setIsExternal() wouldn't emit events about
selection changes, at the mean time TitleInputField.setUrlMode() would
call setIsExternal() and handle everything correctly.
setTouched() is moved forward to actually prevent value being overwritten.
Bug: T302196
Bug: T302201
Change-Id: I5662556394a539073ebf0a17743a260a9d8b0c8c
For some reason, even though jQuery UI dialogs know about their
own buttons, they don't know if the buttons are disabled. This
means that it's still possible to submit the dialog when a button
is disabled.
This change (which is mostly whitespace) adds a check in the click
handler to return early if the 'insert link' button is disabled.
It also gives this button a class name, and so simplifies the other
place that refers to the button.
Bug: T298596
Change-Id: I39fea13b1874f851a68cf08243b3e7ccd355d775
Make sure it works on pages which don't trigger DT, such as full-page
wikitext editing.
Bug: T301497
Change-Id: I244381ee9e47bd3119e341cddb42e2ab38add4a8
The alert text is now added as a red message under the form field
for the link target text, and there's no need to have an additional
alert because the dialog's insert-link button can't be clicked
while there's an invalid internal link anyway.
Bug: T298596
Change-Id: Ib536b51baae24a6cfe7a7426d039fdf11c4cb150
In addition to button, toggle, and select, add an element type of
tool which can be used to insert any HTML content.
Bug: T286759
Change-Id: Ia193308a076a7eaa010269ea0dd7b707c774561d
Use jQuery UI's proper button disabling system, rather than trying
to set attributes manually.
Also remove the alert which used to show when trying to insert a
blank link target, as it now has no use. The functionality was
removed in I3541f438fad9b7e0bf23ead2f2e164e84565d254
when the insert-link button was changed to always disable when an invalid
link was being attempted, but the alert was not noticed at that point
(and nor was this disabling bug).
Bug: T298596
Change-Id: I17c454d6ba336abd0b4eeee0d7166fdf81d25734
When closing the alert that appears when a link looks like an
internal URL, the link target text was changed but the radio
button was not. This patch rectifies this.
Bug: T295517
Change-Id: Ie0339f3aac8ccfd118c604602ce638539ff67e03
When the insert-link dialog is opened, a change event is manually
fired in order to get the system in sync. This is not optimum,
but until we refactor jquery.wikiEditor.dialogs.config.js it's
a simple way to do it.
The issue was that this manual event was being given an empty string
as the title value, but it should've been the actual current field
value. The reason it's not the same is that when the dialog is
closed with the cancel button, the state of all the fields is not
reset (this is a long-standing design feature of the dialog).
Bug: T293167
Change-Id: I8e2a0a5169b5d2a6d706623dc0c879469acd9afa
Also capitalize them and don't keep them in an array.
The data values for the radio buttons are also removed, because
they're not used for anything.
This is a follow-up to Ie40e8bdebe6f1330fc75ea1861f120e51ad58224.
Bug: T293168
Change-Id: I2f6de07f6f82e9e59ab67c771fcd60a68ad577dc
* When the link target text is changed, only change the URL mode if the user
hasn't explicitely set the type (internal/external).
* Improve the conditions for the display of the 'external' and 'exists'
link-target messages.
* Validate the link target (i.e. show messages) not only when the text is
changed but also when the target type radio is changed.
* Rename the TitleInputWidget.isExternalLink() method to
looksLikeExternalLink(), to make its purpose clearer.
Bug: T293168
Change-Id: Ie40e8bdebe6f1330fc75ea1861f120e51ad58224
Add a new top-level section to the right side of the toolbar,
containing a single (empty) 'default' group.
Bug: T296447
Change-Id: If88789f20420f02c729122392e16509bbc5ae7d0
Set the opening state of the insertion button (in the insert-link
dialog) to disabled, and also disable it whenever the target field
is empty. This makes it unneccessary to show an alert when trying
to insert a blank target so that code is removed.
Bug: T293167
Change-Id: I3541f438fad9b7e0bf23ead2f2e164e84565d254
Refactor the code for selecting the first match, so it can also
be called from the look-like button method — this will be changed
once the whole link-inserter dialog is OOUI.
Bug: T295517
Change-Id: I56b289dbf07707b0391b263464bdfd6307142574
Log on every click (by any means, including accesskey) of the
main editing preview button.
Bug: T290521
Change-Id: I67d821445c5e39034bcb121beccf17a765a311ed
* #wikieditor-toolbar-link-int-text was removed in I17f34a8cbf72b80f3916581867e5828d9b129789
* .wikiEditor-template-dialog-fields was removed in I47119d6cfdde4b40ff5b07be0c7d327b80598142
Change-Id: If669eb3fa8e1401d640c879f808c097682c30f31
The HTML template is no longer required, as all three fields are
now OOUI and so provide their own HTML.
Bug: T289214
Change-Id: Id7e02119f00e30244b8dc2048c1f694500151b25
Added in https://phabricator.wikimedia.org/rSVN56198 in 2009
It seems to have no user-visible effect, and resizing is still working
as expected for the dialogs that use it.
OTOH, this logic is broken, since it doesn't account for elements hidden
via classes or anything other than inline style. For instance, if there
are OOUI text fields inside the dialog, the logic in resize() will add
style="display:inline"
to the empty icon elements, which would then cover part of the input
field.
Bug: T293065
Change-Id: If53937dd9e80835774ef936c5aa19f78c7266ca7
Following-up on I9fb7e66bf925eb9a8260d6245d2a7db54a7a2fec
this converts the link-text field to OOUI.
Bug: T289214
Change-Id: I17f34a8cbf72b80f3916581867e5828d9b129789
In order to get a better look-up experience (images, description,
redirects, and disambigutation pages listed last), swich from
a custom title-autocomplete input (that used jquery.suggestions)
to OOUI's standard one (which is used in a bunch of other places
in MediaWiki).
This means a fair bit of code can be deleted from
jquery.wikiEditor.dialogs.config.js, and some of it moved to
the new OOUI classes.
This patch aims to be the minimum required, and so leaves a few
things for subsequent patches (such as converting the other parts
of the insert-link dialog to OOUI).
Bug: T289214
Change-Id: I9fb7e66bf925eb9a8260d6245d2a7db54a7a2fec
When adding characters to the WikiEditor toolbar, it's possible to set
titleMsg, but it's not possible to set a free-form string title. This is
rather limiting for personal or site-local scripts which might wish to
use a title tooltip but not be able to set a MediaWiki message.
This commit adds the ability to pass a 'title' field of a character
definition object. If both 'title' and 'titleMsg' are defined, 'titleMsg'
is used.
Bug: T292434
Change-Id: I00775d5e4690c0fd45c20639a122c39dc756135e
This commit adds bidirectional support for prefixed colons in
internal link targets, such as the ones required by links to files
and categories. It automatically adds a colon to links targeting
pages in the File and Category namespaces (as determined by mw.Title)
and allows an optional colon prefix for all internal links after
the optional whitespace.
Bug: T38227
Change-Id: Ie2801c42da4238555ad7c6544a8412610a528597
The var 'module' got renamed to 'm' in
I57b11c6b4c6e67bb38bb67a93b06d6d1d3009933. This patch fixes the
call to it.
Bug: T284716
Change-Id: I57b7a5fd4a8f2fe2fa98ab5fc41c5bd2500f3a67
Adds a hidden field to the edit page form, with JS that will set its
value. Server-side then checks for that value and logs whether it was
correctly set.
Bug: T263505
Change-Id: I8be06385aa6d97e5536cfc252d34297e1c000a32
After looking more closely at the code, I noticed that
dialogaction is set to e.target or this which is a
DOMElement, not a jQuery Object, thus it doesn't have
the trigger method which explains the error.
Follow up to 760f023f2
Bug: T261529
Change-Id: Ie5f58e33ad385f2abae19264bb2c3cd34a721788
This error is generating a large amount of logspam.
Add a check to avoid it, and DRY up.
The issue is caused by line 1182 setting dialogaction to false when
a dialog is closed. Presumably references to this data attribute
remain.
Bug: T261529
Change-Id: Ie75f737980dfcbcc4829def1e5a6894262d73b31
If someone is enrolled the DT a/b test, we want to know about their
editing here as well.
Bug: T273096
Change-Id: If2bb04011c8ca54e8c7ffd073e21bec45e92460c
In some languages, image options like 'alt' or 'thumb' can have
multiple synonyms. They were only handled for English (and were
hard-coded).
Change-Id: Ib03932d3d85a5540bea325f2717da3365756a90e
We were already using it for almost all interactions with the editing
area, except for this code which restores the selection after closing
a dialog.
Bug: T254612
Change-Id: I26d22d9c5d64fe8c861405e65cd4464c349aeac9
Data tables should always include a caption for accessibility reasons.
So add a placeholder caption when using the "insert table" button.
Bug: T252350
Change-Id: I6773e2274007946de516ae34e841f66ad20ebc0c
Using an event introduces a race condition where the extension
adding the listener has to do so before WikiEditor finishes loading.
Change-Id: I5a8dc6f8fd1b1939b5d98307b20ef1fd355cee99
Remove use of mw.loader.getVersion, which I'm planning to remove
from the public API. The only valid use case I found of it (not
in WMF repos) is to check if a module exists, for which one can
use mw.loader.getState() already.
The code path here handles with the 'icon' property of a
WikiEditor "toolbar group tool". In other words, the buttons
you can click in the toolbar to open a dialog or insert markup.
I found two ways to reach this code path:
* For the built-in tools and icons that are part of WikiEditor.
These are all based on OOUI now and no longer use inline styles
with background-image etc., they are class-based instead, with
the URLs and language variants handled server-side by RL.
* For user scripts that register a custom tool and icon.
To try this, copy snippets to the console on an edit page from
<https://meta.wikimedia.org/wiki/User:Krinkle/Scripts/InsertWikiEditorButton>
These pass urls as the 'icon' property and thus don't satisfy
the hasOwn condition in this code. And even if they did, there'd
be no reason for the module version to be helpful to the thumbnail
url the user would have passed.
This line of code has existed with the mw.loader.getVersion() call
since the repository's very first commit in 2010 (9d278e8dee).
The worst that can happen is if there are stil some internal icons
hitting this path, they'll be cached for 1 hour instead of 7 days
(per /w/static.php rules in production). For third parties, there
would be no difference and such static paths have no caching by
default either way (outside WMF).
Change-Id: I6ec29abde0085d04b662b56b5ebcc2bd7fa267f8
This commit localizes numbers before passing to mw.msg. This occurs
in two places, the successful replacement count and the error message
where too many cells are used in the table tool. The comment above the
second call was not correct, as the existing message used a substitution.
Bug: T244812
Change-Id: I00f83bd478bc42cb536edceba2bcc9daf0b13b3d
* Allows us to briefly animate the transition between
expanded and collapsed
* Remove the left/right-arrows, and just use a single
down-arrow with rotations.
* Remove the up-arrow used by the dropdown, we don't
use that elsewhere in WMUI.
* Remove PNG fallback as `transform` works only with IE 9+
and we're not supporting WikiEditor on Grade C browsers.
Change-Id: I29ab0c35b890689bdea8de5f6bbeef0948483fa5
Fixing aria-* attributes to the Heading menu and roles property to
the menu dropdown items in order to make the element function like an
ideal menu to screen readers.
Adding aria-expanded attribute to Expandable panes(Advanced,
Special Characters and Help) widgets to allow
screen readers announces of the state expandable buttons.
Bug: T244426
Change-Id: I0cb47afd7f3622ed83a57410086984d9abc9acfd
This reduces the initial loaded modules.
Also add the dependency on module 'oojs-ui-widgets' because
jquery.wikiEditor.toolbar.js uses OO.ui.ToggleButtonWidget.
Change-Id: I03d0f73fb77bb389dd4e5ad2aa15b3ff5a97e5f5
e75284e528 escapes a few messages too
eagerly but 1fc00749fb only fixes one
of such mistakes.
Without this change, the labels of some toolbar buttons (e.g. Italian
'Redirect', Welsh 'Numbered list') display ''' where apostrophes
should be.
Change-Id: I3265631512c5d22ecc3dafb9d56acecc7d50ad1d
Also separate out Apex-specific styling into a separate file.
The current toolbar is already supposed to be aligned with Apex
so the visual changes here are minimal.
Bug: T223155
Change-Id: I7a0a21809018e0094d50992054523d20be3c5473
An <a href="#"> element
* shows a status line with a URL on hover and
* opens a new tab on middle click.
For still supporting keyboard navigation the replacement uses
* tabindex="0" to have the normal tab order and
* .on( 'keydown' ) to catch the Enter key.
The image example in the help does not need a link or a keyboard
navigation.
Change-Id: I6d75f75871bb29bdd878451f282f2055ed3f4f5c
This was used for setting incremental tabindex attributes
on the <button> elements of the "Find and replace" dialog
as opened from the "Advanced" toolbar section. I was unable to
find a difference in behaviour with and without this code running.
Both with and without this, when tabbing from the first input
field in the dialog, the buttons are in the tab order after
the input fields (matching the visual rendering). Unclear
what this was doing.
This re-applies commit 81b08daa48, which was reverted (5f356b1a),
because I forgot to remove the calls in dialogs.config.js.
Bug: T234581
Bug: T235701
Change-Id: Ic51074c3d2b2e9b9b050c9f42862519a3e78af16
This was used for setting incremental tabindex attributes
on the <button> elements of the "Find and replace" dialog
as opened from the "Advanced" toolbar section.
I was unable to find a difference in behaviour with and without
this code running.
Both with and without this, when tabbing from the first input
field in the dialog, the buttons are in the tab order after
the input fields (matching the visual rendering). Unclear
what this was doing.
Bug: T234581
Change-Id: I5de97733091d0e123913f272b00784205d69267f
