The "uneditable content" styles should not be applied if the page
title is outside of the editor, like on Vector 2022 since T310839.
Bug: T322725
Change-Id: I212e41e3770807d43b4c58377ce77f4521e6b489
When using DirectParsoidClient, switching should be lossless.
Depends-On: I86c611fa0b717ef619e5ffe550b6c2be49a28c99
Change-Id: Ie30ccbc8c12ce48f481b9f727f28e60d21ee37b9
Follow-up to 8101b6511e.
$toolbarPlaceholder.outerHeight() only needs to be added when not
using visual section editing.
Change-Id: Idc7d9d59dea9eacbb8ee584c69e6bc4798562ea1
There's nothing we can do about missing edit buttons - they are likely
being scrubbed by some script or gadget, so let's not report the error.
Bug: T314952
Change-Id: Icf778074026a24561c228cbf11e583062571d0cb
Follow up to Icd227fc54f3bc16d5ce84c419b69344ca0d21f28
Currently showing up in logs as "NaN" but logged elsewhere
so not needed.
Bug: T314952
Change-Id: I0bf0d428384aa35bd43be026d451d62a2c237267
Setting the config var then loading mediawiki.action.view.postEdit
will already trigger the notification code, so we can remove this
duplicated code now.
Bug: T240041
Change-Id: If0d1aa4e734dab7cca168e78216f229b9924bab7
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
$targetContainer was calculated at the top of the file,
but it's only guaranteed to be available after jQuery ready event.
Bug: T314952
Change-Id: Id5d0c71433bfc51cb7193ee1b931a7dd8a4324d9
Factor out getAvailableEditPageEditor from getEditModeFromUri
and use instead of getEditPageEditor everywhere.
Bug: T316776
Change-Id: I34bab092b829124c52f8bc0e262a9c3aa17f2c52
This code is supposed to be similar to the code in activatePageTarget()
however it was checking if the *link* URL looked like a veaction link,
not the view URL. It also then tried to push this.href as the new state
which was always undefined. This meant:
* If the section edit link was veaction= then nothing happened. The URL
in the address bar would get updated *after* the editor loaded by code
in DesktopArticleTarget.
* If the section edit link was edit= (single edit tab wikis) then the
view URL would get replaced with and edit URL, meaning if you browser-
backed out of the editor, the URL was stay as the edit URL.
Bug: T316771
Change-Id: Idb5e3c51a22361e0d9916d3c31444daeff310ed2
This patch follows the audit made on the extensions to check the usage
of the "rel" attribute and check that it's compatible with multi-values.
Bug: T315209
Change-Id: Ib323736d93ea96c86f9d56599e515c9e6d72a76e
The edit tab should be active as soon as the editor starts loading
(to indicate it doesn't need to be clicked again, and that the read
tab can now be clicked).
Change-Id: I450c53eef64c25e9520d3868b4ecc95204644138
Previously we could log a warning if the user had the editor enabled,
but the page did not support being edited as wikitext.
Bug: T312632
Bug: T314171
Change-Id: I647cb057ed44c155b4eba1b728d6908f8a7abb69
This is send as an associative array. Instead of adding elements that
are null we can just not add them.
Bug: T291729
Change-Id: I28d847941eec865cb255779534eca14ec88f588f
Log a client error when VisualEditor cannot load because of an
incompatible skin (which is not supposed to happen in practice).
Bug: T312632
Change-Id: I2ccfaa584d7a05e10170a66d446bd4e476dcc775
Using Parsoid HTML in the 2017WTE has enabled us to iron
out lots of rendering bugs over the past few years.
In that time Parsoid has been moved into PHP, and at some point
we also become the default parser.
Also more extensions have started to use content transform hooks,
which are only supported by the action API.
As a result it now seems like a good time to migrate back to the
content API instead of building the preview from Parsoid HTML.
Bug: T154844
Change-Id: I90d775dd71d5f5a61d651b63d946ab60a27e2ca3
With related changes to the DOM in the new Vector skin, most skin
styles are no longer necessary for Vector 2022.
This patch also fixes an issue with the font-size of the toolbar
when $wgVectorTitleAboveTabs = true.
Bug: T310197
Depends-On: Idae6755c90eacaab1a9daa88c6e28850d427810c
Change-Id: I6776f08b24f83cf4daeef70bfdeb73dfeafc785a
Follow-up to Idae6755c90eacaab1a9daa88c6e28850d427810c. These styles
still used #content instead of the new way of specifying the target
container.
Extra cleanup:
* Don't apply custom styles to #firstHeading when it's outside of
the target container
* Remove unnecessary rule (it was added in 6d8fbd8221 to support
an absolutely-positioned loading toolbar, but it is no longer
positioned that way)
Bug: T310839
Depends-On: Idb2a743c93316786d6d36e1989cf6620a6092281
Change-Id: Ib5e8f98eacf763e360fae79337d3f2733b1a101b
This data attribute, used to give skins the ability to position VE on the
page, should be prefixed with `data-mw` to prevent it being inserted on
the page by user generated content.
Bug: T310197
Change-Id: Ia6f87535f11ccc7aadb26b7dd9e1ac8a867c377c
Defines an HTML attribute, `data-ve-target-container` that gives skins
the ability to choose which element they want to act as VE's target.
This attribute addresses a need in the Vector 2022 skin, where the
default selector, `#content` was no longer suitable to act as VE's
content container and more flexible approach was needed, so that the
skin itself could define which element VE should use.
This selector falls back to `#content` as was the case previously.
Additional change:
Update modules/ve-mw/preinit/styles/ve.init.mw.DesktopArticleTarget.init-vector.less
to account for the planned change to retain line between tabs and
toolbar in new layout.
Bug: T310197
Change-Id: Idae6755c90eacaab1a9daa88c6e28850d427810c
Following the MediaWiki changes from T301203, we should use
the messages 'skin-view-edit' and 'skin-view-create' instead
of 'edit' and 'create'.
(Also remove redundant definitions in extension.json, we load
all messages listed in 'VisualEditorTabMessages'.)
Bug: T310529
Change-Id: If055fa2a4dc009be869425e6c2262c9b62056179
Visual Editor currently requests MediaWiki DOM version 2.0.0
when talking to Parsoid. Since Parsoid treats that as a request
for 2.4.0, its current version, and Parsoid doesn't have a
2.4.0->2.0.0 downgrade path, passing the latest Parsoid version
(2.4.0) should make no difference in practice -- but would better
match current reality.
Change-Id: Ia2bc0c1981db6f573a69fb1910cef4304c80ae00
Now that Parsoid's ServiceWorkers have been merged to core, this adds
support for "zero configuration Visual Editor" to the master branch.
Like earlier zero-conf work, this does not use RESTBase for stashing
or for reliable selective serialization. Future integration work
with ParserCache will reintroduce this functionality. Nevertheless,
this implementation should have feature parity with the "loopback interface"
zero conf VE we've been shipping since 1.35.
Bug: T305108
Change-Id: I7b5b4a6d16b07914f947cbaf498ad1d3cf2447a5
If links get pasted into VE and they lack a "//" in the `href`, they
are automatically considered to be "internal", thus being converted into
`[[...]]` wikitext links.
In case of pseudo protocols like `mailto:` this should not be the case.
This patch uses MediaWiki core settings to check if a `href` value is an
external protocol known to the application.
Bug: T297575
Depends-On: I2e584f6d5adc6b2d735e79cea64f2beeb5f2c36d
Change-Id: I2b383106450e02cc6bcc1b99d547ff2ed7832b4c
The refactor in I0eaeb987 broke this feature by moving
the call that modifies the response object to after it
is passed to the target.
Change-Id: Id98c1ccabde478540af34ed3356f319ae336590a
.test() is the dedicated syntax for a boolean "does match? yes/no?"
check. .match() returns an array of matches, or null. This is just not
needed in these situations.
Change-Id: Ibb996ab843d1a6c7d7af98d6a112990665d543b2
Once we determined a link is internal from the first regex, we don't to
check if it matches the wgScript path as well. This would cause
"/index.php/Article" style paths to be detected as external as they failed
this second check.
Change-Id: I560d8080c513c523c68f2750be332e9fd91de192
This logic has been moved to the relevant extensions which can
now disable VE using a hook.
Depends-On: I47880be15b6ce1a93f389a32aff304cc3b798bcb
Depends-On: If188e8fcceb248738fc625ddd5afec351c01c484
Bug: T174180
Change-Id: I245295373af3caffb1d4cbc288e8d2bd008520b7
Our theory is that browser plugin spam shouldn't reach
the DM document unless we've made a coding error like
I194ff1d57. Log future errors so if there is more plugin
spam in the future, we can investigate the cause.
Bug: T298147
Depends-On: I705195bc5d0f76a38da5d2cc09fab184a2c32401
Change-Id: I3403859906ceaa51be63b0d79f474f0289ab4408
Same random finds while working on something else. I carefully
checked and made sure these methods are actually called without the
optional parameter.
Change-Id: Iab36fd130258322985b5d6e7f8e1f7b4ee235ba2
These are only needed when we need to access a specific `this` from
within another `function () {}` context. This is not the case in the
situations here.
This is split from Ibf25d7e to make it smaller and easier to argue
about.
Change-Id: Ide1476de91fc343aa992ad92a1321d3a38b06dd0
Passing the useskin parameter ensures that output hooks are run
on the new page HTML. This already happens because we request
the 'subtitle' and 'categorieshtml' props which also trigger
skin mode (along with the 'headhtml' which we don't request).
However it is better for us to be explicit that we want the rendering
for a specific skin, rather than relying on these props to trigger
the correct mode.
Also pass through mobileformat param, which is added by a hook
in MobileFrontend.
Change-Id: I1cd2c5c5c13ae0b90cc32e441b453532343a434a
This ensures the full loading sequence is shown when the
user opens VE using history navigation.
Bug: T301843
Change-Id: Ia7a641c8bd5a036f23c9da94bc539d8cf66c5021
Previously we were adding an event listener every time the
target was opened, and not removing the old ones.
Change-Id: I0ce609f1d9e2d6fb00b605dcade6f27e7a887b9d
* Append the toolbar before starting the scroll
* If the toolbar is floating set the anchor to full height
immediately. This shouldn't cause the content to jump down
due to scroll anchoring:
(https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-anchor/Guide_to_scroll_anchoring)
But add our own logic for it for browsers which don't support that.
* Now the browser only has to deal with the scroll animation,
and not the height animation of the toolbar anchor at the
same time, making it smoother and less buggy.
Bug: T301773
Change-Id: I61d533d40758d559b03c858e0006ef2e4f0fcd16
Previous attempt in 005a8d24ef,
reverted in 3c1d167b33.
The deduplicateStyles() function lacked a check for fosterable
positions, which caused T299767. This is now fixed.
Also added tests.
Bug: T287675
Bug: T299251
Change-Id: I0d22be9b66d26d09373cee63dd6ce52c1659e62d
This prevents an unwanted scroll when the main edit link is used
and the first section is below the viewport.
Change-Id: Ib99ebe2dc5c105c3fcbd687ef5740166267f5536
This doesn't change the position of the loading bar, but it keeps it
still if any scrolling happens. Previously we expected the user probably
wouldn't scroll while VE is loading, but in subsequent commits we
will trigger automatic scrolling in section editing mode.
Change-Id: I1404ccd77583d808ef79291c6cb4f561e76bd41c
* Find the first section below the top of the viewport
(usually visible) and measure its offset.
* After loading the editor, ensure this heading is still
at the same position on the page.
Bug: T296910
Change-Id: I9a05ea74ba3c19a4a91ddc1bc0afe311851c53e6
This prevents your preference being changed if you just
followed a link with a diffmode parameter.
Change-Id: I755563bde285e95c0367119d49a40e1dd3c5e178
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
It should be possible for extensions/skins to trigger the click event
It should be possible to do $('#ca-edit').trigger('click') so that
Vector's sticky header can trigger the VisualEditor.
Bug: T293159
Change-Id: I58625ffca982edfbc4cdcb14a666d79093e1b89d
Most block-level things that can be interacted with by clicking have a
highlight. Categories don't, and that makes it harder to discover that
you can edit them.
Change-Id: I6be3824c34b36bd09bbae8cab9a9f36b6bcdb767
I tried to review all of them. Some of the changes I did:
* Make sure the `config` parameter is not marked as optional
when it is not.
* Make sure default values are mentioned.
* List individual `@cfg` options when it makes sense.
Note I don't list all options a class could accept (e.g. via all
its parent classes and mixins). That's too much. Instead I checked
how a class is actually used and list only these options.
Even then I don't list everything, e.g. unspecific options
like "classes" that can be used pretty much everywhere.
Change-Id: Idf4fbe1dc3608ace277df9e385f2f140df3a2f50
E.g. avoid calling the rather expensive method multiple times
in a row, if only 1 of the results is needed.
Change-Id: Iff1d2c0892367e927303f6f45d3231e04c045cab
The history.replaceState call in onReviewModeButtonSelectSelect() (1)
ignores any changes to the document URL made by external tools such as
RevisionSlider, (2) replaces with an empty string the history entry
state object if it was set by external tools such as, again,
RevisionSlider. Both 1 and 2 result in a wrong URL ending up in the
address bar at some point. This patch addresses these problems, (1)
creating a new mw.Uri() object every time
onReviewModeButtonSelectSelect() is called, (2) keeping the current
history.state object.
The original variable storing the URI object is renamed to avoid
shadowing (optionally can be replaced with its value as it's used only
once).
Bug: T288636
Change-Id: Ieb97b561a6c076aa28aae231fe286ac4d1051bbd
They both want to handle the same URLs. If we detect that
DiscussionTools new topic tool will open, then do not open 2017
wikitext editor.
Bug: T282204
Change-Id: Ic7dd677ea219938969f60bab91387c2e03ebdbe6
Reasoning:
* format=json must be the default. Nothing else makes sense in
the context of this code. This should not be a surprise.
* formatversion=2 is only a default when the custom
getContentApi() is used, but not when mw.Api is used. One
might argue that it's safer to always specify formatversion=2.
However, this is not done in other places in this codebase.
It should never be done or always.
* I find it confusing when the action=… is missing. Let's not
rely on this default.
Change-Id: I6ca29f76bffc0849103c5bcff4aaf28fcaaa4c52
These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
This reflects better what the widget actually does.
However, the config option `value` as well as the method
`getValue` are not renamed. These intentionally mirror a OOUI
convention.
Change-Id: I26e733b760501e57b3314d5da2d65bfdd4b38346
We have two preferences used for enabling/disabling VE:
'visualeditor-enable' and 'visualeditor-betatempdisable'.
(And 'visualeditor-autodisable', which sometimes overrides
them both, but it's not relevant here.)
The user can only set 'visualeditor-enable' when VE is Beta Feature,
and they can only set 'visualeditor-betatempdisable' when it is not.
However, when deciding if VE should be loaded, we always checked both
of the preferences. This gives incorrect results when the preference
that is not supposed to be settable actually exists, due to being set
in GlobalPreferences on another wiki where it's settable.
A similar issue could occur if VE configuration is changed from Beta
Feature to a normal preference (or the other way around), and the
preference values for the previous configuration still persist.
Bug: T271434
Change-Id: I7399b3c516f762429050a662ac85d1d392392323
Support the `url-new` mechanism so we can distinguish between
new/existing sections in direct navigation.
Also, mechanism will now correctly be `new` when clicking the "create"
tab on a previously empty page.
Bug: T272544
Change-Id: I667a1c45c3948ec6dfed8f348a1327bffaba58a5
Depends-On: I3cee7a3a4c4b646692dce4a1180c4ba18a61f4bc
Switching from visual editor to old wikitext editor results in a
page reload and loss of the mw.libs.ve.disableWelcomeDialog()
flag. Use an URL parameter to preserve the flag.
Bug: T235812
Change-Id: I3968e5b7ae536d45fd764a8b7c3ea1f6d616033f
This provides a consistent entry point for registering plugins on both
desktop and mobile, without needing to do strange things if the right
ResourceLoader module hasn't loaded yet.
Without this, registering a plugin module in JS requires ugly code,
and on mobile it wasn't possible at all.
Bug: T267692
Change-Id: Ie2c320c33ec2b064fba4fb45ba62545b9211439a
Reference images are moved to Cite and used by Citoid.
Bug: T170919
Bug: T171292
Depends-On: I02041246dda1b3d3ad1bcc0b014fa022e8259b62
Change-Id: Id97659ed1fa64a1223a8957fefaf2a149edd0e9c
Remove angle bracket from the url. The closing character is breaking
the hyperlinking and is not necessary anyway. Also bypass redirect.
Bug: T261126
Change-Id: Id9839623f5f77766042a0df0dfdd5f93d6faf625
DOM attributes are not arrays, and so don't have Array#forEach.
Fixed regression introduced in 4545f53245.
Change-Id: I1f0f44747a0f8a376c1fb7cbb8862c096a9d1dc9
The 'checkbox' part of the edit form is now allowed to contain
non-checkbox form widgets, but these are not yet supported
by VisualEditor. Until they are, this skips them entirely
in order that no broken form field be shown.
Bug: T259546
Change-Id: If62c11b174df235be611b9d32eb28e4759ba5f66
jquery.cookie is no longer maintained, and we're coming up on maybe
running into issues with sameSite which jquery.cookie doesn't support.
Moving to mw.cookie will let us centralize that fix.
Also, removed some dependencies on jquery.cookie in code that doesn't
seem to ever use it.
Bug: T252597
Change-Id: I8634cfd42c2a5ab3c9d712417a7d1a55508274fd
Calling the linter is very slow as the result is not
cached. Extensions needing this (DiscussionTools) should
just call the Linter extension API directly.
Bug: T253799
Change-Id: I994b52ca70c29a32900741a36087f10144396720
The first time we check, it's too early for any code that might have
wanted to call stopShowingWelcomeDialog() to have done so (because we
check synchronously after making that function available).
I'm not sure if checking twice like this is the best solution, or if it
would be better to defer the whole thing and only check once.
Change-Id: If5b88bb50c3becaa3d7931c8b8e4d0faed7b69d2
In 92c3055628 I changed `sectionId > 0`
to `sectionId !== '0'`. That was actually a mistake, as Parsoid's
section IDs can be negative, which indicates pseudo-sections, which
may not have headings.
https://www.mediawiki.org/wiki/Specs/HTML/2.1.0#Headings_and_Sections
Bug: T252238
Change-Id: I9133d4365a71d6db1fa58b69ae3b970166d15c1e
This is now consistent with all other events.
Needed for I9904e8af4a60b0f5e9a6e263cd4fd8e1e3fd1f98.
Change-Id: If52aa9d619eac08456874fc75c0f6e1adff01246
And factor out the common code for using a preference with a fallback to
localStorage or a cookie.
Bug: T235566
Change-Id: Ibb983319edcd2987225fe89677fd10e3ff8f9df6
This allows code in other extensions to suppress the welcome dialog
temporarily (just for that one page view), without touching the user's
preferences.
Bug: T235566
Change-Id: Ief6545289cf59fda851aa944b059994abd90253e
Move shouldShowWelcomeDialog() and stopShowingWelcomeDialog() from
DesktopArticleTarget to DesktopArticleTarget.init, and use them to
deduplicate code in init that manages the wikitext welcome dialog.
Look for both the vehidebetadialog and hidewelcomedialog URL params.
The code in DesktopArticleTarget used vehidebetadialog, but the code in
init for the wikitext welcome dialog used hidewelcomedialog.
Bug: T249954
Change-Id: I19f1a2da36bc65addb52811c3d3c73c1259bc8f5
Wrote code such that only redlinks and normal page urls
using the script path are treated as internal links.
Bug: T248076
Change-Id: Ie476bf7f4b389a659899eab4351c912fc6b24bee
This unbreaks the use of ?vehidebetadialog=1 on page views (i.e. without
action=edit) in single edit tab mode.
Bug: T249957
Change-Id: I0109f5d95cebbb3e585d25b7623764cc7350cda0
In MediaWiki, section numbers may be prefixed with 'T-' if they refer
to sections on a transcluded page, so they are not really numbers.
Change e2cb9ce93e caused us to treat them as strings most of the time,
but it looks like there are several places where we treated them as
integer numbers, which I missed when making that patch.
The first two changes in ArticleTarget#restoreEditSection fix T248795
and T248968/T249112, respectively. The other changes are cleanup.
Bug: T248795
Bug: T248968
Bug: T249112
Change-Id: I8373a7ab515595769ce6f3051a182c922415b643
Prevent JS from overwriting the contents of the "edit source" link
if the change is unnecessary as it can break third-party skins.
Bug: T248025
Change-Id: Ica1e45488813877583efadabc72526544e8943ac
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
When a page is preprocessed for transclusion, sections are numbered
differently, and the 'T-' prefix indicates this. It can't just be
removed.
It seems that all of our other code can handle section "numbers" like
"T-1" just fine.
Bug: T246164
Change-Id: If19a2d48f94411a89525fb605169c7f8dd4b1797
This line was added in 9eebfbcac5
and I can't tell what it was supposed to do (that commit's message
only says "Fix NWE-only edit tab", thanks a lot).
Since then the init code was refactored a lot, at some point this
line was moved to be a part of a completely different check (???),
and now it's causing visual mode to be disabled even though the
user only set their preferences to *prefer* wikitext mode.
Bug: T243723
Change-Id: I3c1f502c3cd079fc5eeb2e9587b22d854ae3a72c
This continues to take more effort than all other skins combined, but
still every time our overrides get less crazy. Maybe, and stay with me
here, maybe a year and five patches from now I'll remove the last one.
See 91f99ce78d for the last time.
Change-Id: Id880d1cd1ecef59635b347102dc2107204382fb2
Things I noticed while writing I37f8e89b6d92c419d1b6569891612256342f8139,
but which felt too messy to include in that commit.
* Use promise chaining
* Update documentation
* Remove redundant code
* Split a method that now handles two different errors
* Grumble about localisation messages
Change-Id: I81e28a03af4f6c3452679ef6bbcaa89bb1235122
Follow-up to 5f1c68945d, which renamed
these messages while moving them into MediaWiki core.
Also, parse HTML in them. This is consistent with real API error
messages, and with the behavior of mw.Api#getErrorMessage. (And also
fixes potential HTML escaping issues.)
Change-Id: I307ca9873e245169a0d4b43499317acbac69fb9b
It was already added for visual diffs inside the editor. This fixes
some minor styling issues, e.g. the arrow after external links is now
shown.
Bug: T244673
Change-Id: I3ea72930ee7822a7579ebe787654d716f5947224
