This will ensure that media have the mw-file-element classes so that the
styling changes in I70c61493fe492445702f036e5b24ef87fc3bdf43 apply.
Older 2.7.0 content still in storage is missing the classes and doesn't
render correctly.
Note that I545ed75ed3c87e88b5e776696754e23c05645f81 made sure that
editing of both versions was always compatible.
Bug: T337596
Depends-On: Ia70f819df79fbb12a5b1dd6a98bfe0b968808d18
Change-Id: I40ed887e03f983e0737e1ee7cba5a4012fea31db
Use the new hook to add the diff-mode selector to the area directly before
the diff table.
Also toggles the new inline-diff legend, when the initial diff-type is 'inline'.
Depends-On: I2a3c67bcfa47313dee597e602a62073e4e298cd2
Bug: T324759
Change-Id: I1584a84b3caea9eb142afba976c6ff47650c3832
Support gadgets adding '&editintro=…' to the default edit link.
It was already supported when opening the link in a new window, or
following an external link, or when clicking a section edit link.
Also, clean up these parameters when leaving the editor. This also
applies to 'preload', 'preloadparams', 'preloadtitle', 'summary'.
KNOWN BUG: Only works the first time the editor is loaded on the page.
Afterwards, DesktopArticleTarget.init lets DesktopArticleTarget handle
initialization, and it ignores extra parameters. I made a few attempts
at fixing this, but I only broke it further. I don't understand why
the history handling code even works. Maybe I'll come back to this.
Bug: T56029
Change-Id: I38fcde573f728250aaa125b391815e7fac7df362
I prefer not having to think what type `link` is.
Just pass `linkUrl` everywhere.
Add and correct some related doc comments.
Change-Id: I5aa03149d7e1b32cd9ec19c589b16d03a9981857
As temporary users will not have access to user preferences (T330815),
use cookies or localStorage to save them, like we already do for
logged-out users.
Also add some comments to point out where we intentionally distinguish
logged-out and temp users.
Bug: T332435
Change-Id: Ic83dd8bc8bc107f603a9b0340bd9e2bcaad8ff5a
Use the new hook to add the diff-mode selector to the area directly before
the diff table.
Also toggles the new inline-diff legend, when the initial diff-type is 'inline'.
Depends-On: I6de30bf79eb5ac262285951792782b870d075e00
Bug: T324759
Change-Id: Ifc133856dd793693c3a2722a7b1319dfe74555a2
* Use the new mw.track() handlers from WikimediaEvents
* Ensure that 'integration' and 'mode' are set on init
events, since they're not guessed in the handler any more
* Remove the setting of 'editingStatsId' tracking parameter,
now happens in WikimediaEvents by setting an API AJAX option
* Replace ve.track with mw.track in VE-MW, so that we don't have
to copy the events manually here and in other extensions
This must be merged together with WikimediaEvents change
Iace4d53a972396ca5b8713000570cc47c9986034 (but we can't use
Depends-On, because CI requires code here to be removed first).
Bug: T332438
Change-Id: I0ef0a96aafdf89a4ebe32131a85b18c25744bb2c
Peel off some layers, remove some unused computation,
remove code from ve.init.mw.trackSubscriber.js (which
is to be removed in T332438).
Change-Id: I4073b9a2a4b2af06f30e603a9d2a1968203f3b6d
disableForAnons is used to present a single wikitext tab on
dual-edit-tab wikis, and/or default-wikitext red links.
Users who open the editor and then switch to VE should still
have that preference stored in a cookie when that happens.
Bug: T331462
Change-Id: If2a866cff7e54d2832f6aa22eb268eb125f2d1c2
These haven't been used for a while, and we usually enable experimental
features via BetaFeatures these days.
Change-Id: Iec3a7da3cc962d8ac9416b508780fcdc3ca58d3e
When checking for the presence of edit buttons, we should include
the VE edit button and the MinervaNeue page action link, but not
the "view source" button (which means the opposite: the user can't
edit).
Bug: T312632
Change-Id: I2eb6e833a0489c17cf8360aca61bd8b615e30461
Going through onEditSectionLinkClick() is not needed, and it confused
some code that actually expected a section edit link.
Bug: T328094
Change-Id: I8975ade38d9dd064272781fb9d4bd22bab4d65ce
This allows VE to support even more skins with minimal or no changes to the skins themselves.
Partially reverts 75ff121b29.
Change-Id: I7536610459b7401015d4a033cc516c5d9a0ca5f1
This reverts commit a92dce4999.
A workaround for the previous problem was added in ContentTranslation
in I945897a27db479986855002b389034a745bf9bef.
Bug: T325249
Bug: T325566
Bug: T327779
Change-Id: I2d9c330dc4328468a65315ec6bed1d0f53ebd1f6
We could do something more complex and compute the height of the
available space, but a fixed height is a reasonable solution with
a fraction of the complexity.
Bug: T328048
Change-Id: I0b7bfa55f23afc16be43b85270666ec6a480ca32
Accounts for the use of CSS Grid in Vector 2022, in
the 2017 Wikitext editor preview, by placing the heading and
content in named grid areas (`titlebar` and `content`).
Bug: T327778
Change-Id: I66a30e282e808559b4f375f5924ae0d945c058a9
At first I was going for a more minimal replacement of mw.Uri with URL,
until I discovered that this code depends on a mw.Uri bug that would be
difficult to replicate:
// Expected: Relative URLs are accepted
new mw.Uri( '/foo' ).toString() // => 'https://localhost/foo'
// Expected: Protocol is optional
new mw.Uri( 'example.com/foo' ).toString() // => 'https://example.com/foo'
// Unexpected: Treated as empty domain with no protocol rather than relative URL
new mw.Uri( './foo' ).toString() // => 'https://./foo'
So I went for a bigger rewrite to preserve the intent rather than the
exact logic.
I had to change some test cases to use more realistic fake data. They
previously relied on bugs in our URL handling to pass despite the base
URLs being incorrect, particularly for non-short URLs (see T270219).
In my testing non-short URLs behave the same as before in practice.
Depends-On: I07a8c097dba0f5572c0aedf4febdf1434063ea6f
Bug: T325249
Change-Id: I232361266c1dda795b88018c3aaa3d9ecbe42b93
Persistent global-ish properties in ArticleTarget and friends. A lot
of our own code re-uses them, and code elsewhere could refer to them
as well (although I didn't find any uses).
In one case we need to keep using mediawiki.Uri, to handle building
an array from query parameters exactly like PHP would handle it.
Bug: T325249
Change-Id: I57699ff9dd39179ca29a87b6e2d9b12c2b86eb7d
Our encoding for the hrefs like "./Foo" that we send to Parsoid
differed slightly from how Parsoid outputs them, so to avoid dirty
diffs, we had to store the original ones we received from Parsoid
and send them back if they were unchanged.
Change the encoding to match Parsoid's exactly (by referring to the
Parsoid source code), and then remove 'rawTitle'/'origTitle'.
On a historical note, 'rawTitle'/'origTitle' were originally added to
fix other issues with links, which I hope are long behind us:
* bb45d984ca (T145978)
* fda2e6c1b5 (T44140)
Follow-up to 362df66b47, which removed
some other old stuff from the handling of Parsoid links.
Bug: T325766
Change-Id: I0ad0a655380eb2fb29b5ac01e2e399ac550ce34a
Replacing one-off uses in various auxiliary features: only used
in function scope (or narrower), nothing else depends on them.
Some of them didn't even need to do any URL parsing or formatting.
Bug: T325249
Change-Id: Ia9a18656f67cb0a204c87605459abb9f5bbdc347
For external links, `.title` and `.rawTitle` properties previously
contained the external link corrupted with some normalization intended
for MediaWiki titles.
This was useless, and in fact no caller actually uses this value:
they all check `.isInternal` first before accessing `.title` or
`.rawTitle`.
Also, correct other parameter documentation.
Change-Id: Ieeab56548f0a3b2f81a90f0d3ae0f81d744aa67b
An incorrectly-encoded fragment is allowed-in-wikitext but will make
mw.Uri throw an error. e.g. `[[foo#1%bar]]`
Bug: T324976
Change-Id: I97cb85507d9ae3d648300245dd7e48cc239c4d90
Redlinks now come down with a `mw:LocalizedAttrs` typeof, and have the
display URL parameters rather than being bare titles.
Bug: T324352
Change-Id: Ia1776e6e1f171d227c7c402b39ca96d17fb56cdb
There are some known bugs that we probably will not investigate
(T313809, T317455). Do something better than an infinite loading bar.
Follow-up to ee7c5d9d1a.
Change-Id: I339de7662ff68c2ea9bb1a738bb4207d1c399e59
Hiding '.ve-init-mw-desktopArticleTarget-editableContent #toc' is not needed
when we already hide '.ve-init-mw-desktopArticleTarget-editableContent'.
Change-Id: I9f7dc5f64be1f392e846da5bcfcd0a5d17a65014
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
