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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 appears to have been an oversight in the above change. Since the magic
words variable was no longer set, magicWordsI18N became null which broke
things, and caused whitespace info to not get recorded, which broke the
ability to handle the dialog being submitted too.
Bug: T230078
Change-Id: I5c44ed348de6ac2363d3d789b38053caa3935f62
This allows us to bundle the wgWikiEditorMagicWords and
mw.msg.wikiEditor(?!) config vars that were previously exported globally
in the startup module.
This code is old and crufty, so this is a somewhat minimal conversion:
* Use require() for jquery.wikiEditor.{dialogs,toolbar}.config.js,
and for jquery.wikiEditor.{dialogs,toolbar}.js
* Don't attempt to convert jquery.wikiEditor.js to something
require-based, instead just run it and let it set the $.wikiEditor and
$.fn.wikiEditor globals
* Consolidate ext.wikiEditor.{dialogs,toolbars}.js into
ext.wikiEditor.js
Bug: T222828
Change-Id: Ia75d685cbde786e8fceb6db36f2436b2beea1499
This commit adds a function to parse image syntax selected in the
editor and uses the parsed data to automatically fill the fields
of the WikiEditor image dialog. Surrounding whitespace in the
selected wikitext is now included in the result. This causes an
issue with the ownline option in line 840, which appends an extra
line regardless of the post text.
Bug: T40829
Change-Id: Ib117a2e6350400f9298d4892a00981ac41f3dbbf
