The diff mode selector is now also being returned in the HTML
from the VisualEditorEdit API, but is already implemented
separately. This change just removes the element from the API's
HTML; it is perhaps not the cleanest, but it's not too far off
what is already being done for action=diff, and we want to get
a fix out for this bug as soon as we can.
Bug: T324759
Change-Id: I830b623963111f430640dd4d9a94639f753e4cda
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
Target#actionsToolbar and Target#toolbar refer to the same object
since change dfaed62d3632d381db9682c603b3ddbeed182292 in VE/VE
(barring bugs like T335469). Once we no longer use the old name,
we'll be able to remove this backwards-compatibility alias.
Bug: T335469
Change-Id: I577e8ae6a857519eb0e8181543ca0a96b515e019
It appears like this was never tested.
Now that it is covered it's much easier to play around with the
implementation and compact it a bit.
Change-Id: Ie9cc14082f69e7240380d352fb362d0a3fa4d341
Since this was written, the specificity of the selector it was
overriding has increased, so isn't required any more.
Bug: T335292
Change-Id: Ib3494524f6ddfc2ea59d6d3d13a1a90138cd84af
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
Reported as happening when a gadget was triggering some calls early in
initialization, presumably before the surface had reached the point
where it had been focused.
Bug: T334930
Change-Id: Idebc31ef042d45acf59d8dceaa7566744233f426
It's possible to specify a parameter with no name via TemplateData.
This confuses the template dialog because the empty string is a
reserved, internal value for parameters that are in the process of
being named.
Fixing TemplateData is not so easy. Therefor this workaround here.
See T333826 for a detailed description.
Bug: T333826
Change-Id: I5f4efd7069e71ba51138a23f3c3cb40e1b50d339
* 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
New changes:
1b912ce6b ve.ui.DiffElement: Don't override margin on added/removed block elements
a43720b34 [BREAKING CHANGE] Move ve.dm.MetaList to ve.dm.Document
e7d6d2317 ve.dm.VisualDiff: Include metadata in diff
Local changes:
* Use new ve.dm.MetaList API
Bug: T331925
Change-Id: Id21c122d48519013a5c3325cc4bc316cedcb63f6
Discussed in todays story time. The blue "active" color is mostly a
"reminder with which parameter I interacted last". It's more a
secondary, passive information. In contrast, the gray
highlighting/hover effect that appears when navigating the sidebar
with keyboard or mouse is an active, primary information ("this is
where you are right now"). It's really confusing when the keyboard
navigation indicator disappears behind the blue box.
This patch changes this for both top-level elements as well as
template parameters. The blue text color "shines through" the gray
highlight so we can still see both information.
Bug: T289043
Bug: T311204
Change-Id: Ief6a023d8fde4f6ca0c4b2ea2e831b66e1ea8c83
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
Parsoid will start populating the link content with the alt text if it's
available before falling back to the filename. Preserving what's there
is needed to avoid dirty diffs during the transition and for cached
content. In the future, we can remove errorText and replicate Parsoid's
new behaviour..
Bug: T273014
Needed-By: Iddf3e204d6e489cc8a33034da0d9e540efe65553
Change-Id: I7ab3d141b1df92d4447f7e3d6164082844d5bd10
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
onWatchToggle didn't cope with the case where there was already an event
in the hook-queue when it was registered during setup
Bug: T328955
Change-Id: Ic80f707e86ba3c9f88097cac8aec8c6b3cc32cee
New changes:
0cf02db3a [BREAKING CHANGE] Pass Target to UI Surface and use instead of ve.init.target
Local changes:
* Pass target to surface
Bug: T305762
Change-Id: I3412c53cc70346c8ba4b8b76976ba9c7535e945f
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
New changes:
2201b350c Localisation updates from https://translatewiki.net.
da74736c1 Remove unused test code
d1b016e90 Minor test tweaks
551de4f0c Specify document base URLs in more test cases
Local changes:
* Specify document base URLs in more test cases
Change-Id: I0e301bef38d97fa2234aa901c787360d9fbde8a3
New changes:
4355d697a Replace ListStorage with ConflictableStorage
978061f86 Update SafeStorage and ConflictableStorage with expiry functionality
79019ed88 ve.dm.Surface: Support storage expiry
Local changes:
* Pull through conflictable storage
Bug: T218663
Change-Id: I36e49c01e9f2ddb7d362d539b72a4beca925bcb7
Before the `height: 2.5em` was applied to _both_ the visible
<textarea> and the $clone. While this shouldn't make a difference –
one of the first things .adjustSize() does is setting the $clones
height to 0 – it somehow triggered that Firefox bug.
With this patch we remove the `height: 2.5em` before handing over to
OOUI's .adjustSize(). It looks like this fixes the issue. We might
be able to revert I7560ceb then.
Bug: T317369
Change-Id: I96c2d7d7bf359ff0373d478b2b7e97c8833ba5b6
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
Adding the polyfill as dependency to everything using mediawiki.Uri,
so that we can change the code in separate commits without thinking
about this.
Bug: T325249
Change-Id: I8a7d2e6c7f98ed6187a85a88f2b4a0a4a5ecfc56
I've never liked how this looked, it feels so 1995. Let's just use
multiple paragraphs instead of a <hr> to separate the text, similar to
what we do in ve.ui.MWParameterPage. The second paragraph is already
emphasized with italics.
Change-Id: I324cd1d81e61cf8a23095b4f8aed68040eb1bd8d
By using OOUI 'label' instead of 'help', the label is associated with
the input using <label for=...> in HTML.
The result looks almost the same, except for font size. I like the
change, and I don't think it was intentional to make the font smaller
here.
Bug: T277028
Change-Id: If178ca8feb9970c9287ab6dfe51fdf0a81df1c45
Use distinct messages for section heading, button label and input
aria-label, to allow a potentially better localization.
Bug: T304121
Change-Id: I3e3b06a035e2f11f5f32face789b934e22916e49
The ARIA label was added via Ieeb29de. It was reusing an existing
message.
Later we added a placeholder to the same input field via I07c6e60.
Since then screenreaders possibly read two texts: "Find template" and
"Add template".
Bug: T296465
Change-Id: Icb8d5419b4a4e34a224744873c557cb873e17c40
While at it, also fix a few broken uses of `@see` where `@link` was
intended or for full names, there is no syntax needed, as JSDuck
already links those.
Change-Id: Iaeb46b05c6f2e6f00198bc2ae773c895935b4cea
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
I discovered recently that I had 64 KB of text stored in the
'visualeditor-findAndReplace-findText' preference.
I must have accidentally copy-pasted a whole page into the "Find"
field, the JSON that VisualEditor tried to save became invalid after
MySQL chopped off the string after 64 KB, and since then VisualEditor
was unable to update the find-and-replace dialog preferences.
Change-Id: Ib1d853263d873d969c7b015b3842524e1f7fc351
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
We need to strip the protocol on both sides. This might have been broken
by Ic00b38b04ce78178c64c13bab7f1b2e4b6c5b803 in MediaWiki core.
Bug: T321437
Change-Id: I11903b767aebfdb189a8d54fbf6fb7f8ce9ffb6a
The VisualEditorFeatureUsage instrument is a candidate for migration to
the Metrics Platform [0]. The first step of the migration is to log
events both using the Event Platform directly (i.e. via
mw.eventLog.submit()) and using the Metrics Platform client (i.e. via
mw.eventLog.dispatch()).
The Metrics Platform Client can mix in additional information -
so-called context attributes [1] - based on the stream configuration.
The majority of the default values mixed into each event are already
known to the Metrics Platform Client.
Note well that the Metrics Platform client will not log an event without
one or more streams being configured to receive that event. Therefore,
this change is a NOP.
An example stream configuration is given in [2].
[0] https://wikitech.wikimedia.org/wiki/Metrics_Platform
[1] https://gerrit.wikimedia.org/g/mediawiki/libs/metrics-platform/
+/aed6738b845/js/src/StreamConfig.d.ts#31
[2] https://phabricator.wikimedia.org/T309602#7973206
Bug: T309602
Change-Id: If40fcc6cae371788b98365953218300a5c0b3ca1
... for the sampling rate for the VisualEditorFeatureUse schema.
Bug: T312016
Depends-On: I259757db0c4441a3fcfce505d5bc82dcf2acf58c
Change-Id: I4e03b442568ed695a14d280b0e8dd92e22616426
The previous implementation tried to do this, but looked
at the query string which can be set to action=edit by VE.
Bug: T318772
Change-Id: I4f0f8d52488a6b259033232afb8ea616458275de
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
A lot of this just repeats what is already set by some other rule,
e.g. because it is the OOUI default anyway. Warning. This patch is a
little more agressive. I tested it on desktop and mobile, even with
MonoBook, and could not spot a different. Please do some more tests.
Change-Id: I0ee6e70f4f14c20d431643c53031d6d5b8df1aa2
$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 means if you load the editor on a single edit tab wiki,
then press back then forward, the editor will re-open.
Bug: T316869
Change-Id: I1ea33de7d7324a53399be9155c474a14ae21dfe8
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 fixes two issues:
1. .initializeAllStickyHeaderHeights() is now executed after the
.ve-ui-mwTransclusionDialog-single-transclusion CSS class is set.
This is critical because in this mode the sticky header does
have a different height.
2. We get rid of 2 references to .sidebar that should not have been
in this class in the first place.
Also bring some more calls in an order that makes sense. This does
not make a difference and is only for readability.
Bug: T315292
Change-Id: I22f6c11de8f693edb03485adcaa186bd4b283b2f
I'm pretty sure this extra call is just pointless. This "choose"
event is triggered every time a new parameter is added to the list of
parameters. But there is another code path that is triggered in the
exact same situations: the onReplacePart event handler.
As far as I remember this "choose" handler was added very early when
the other events haven't been implemented yet.
This should be fairly easy to test. The only situation where this
could make a difference is:
1. When you have a template with 3 parameters and you add a 4th
parameter.
2. When you edit an existing multi-part transclusion that contains a
lot of parameters, but the parameters are initially hidden. The
widgets are only created when you click "show all" or start
searching.
Change-Id: I59e3873a4fe6fa5a01d681fce89fbe00756ae815
This was missing when you:
* Insert a new template and select a template with a lot of
parameters.
* Same when you edit an existing multi-part template and add a new
part (Ctrl+D) with many parameters.
Bug: T315292
Change-Id: Icd281c21a1b40d8e29343fa4975e27e8d927cd15
This is only an issue when a long parameter description is collapsed.
The float is a left over from a time when there was a delete button
on the right side of each parameter label. This is gone.
Bug: T310137
Change-Id: I249f0592de9c73a07af22bd7f86241caf0207770
This makes it possible to click on "(undocumented parameter)"
to focus the input field – the same effect as when clicking the
parameter name.
This also lower-cases the initual "(U…". This is not the beginning of
a sentence.
Change-Id: Ibfa5bbaee39c2b3a4fefbcee33102b85ca3ba9c0
On mobile, tapping anything in the sidebar should only scroll the
corresponding element into view, but not focus the input field. The
reasoning is that an on-screen keyboard should only pop up when the
input field is actually tapped.
By the way, the "jump" issue in T312768 was because of the same
reason. In that case an onFocus happens before we have a chance to
scroll. Unfortunately there is no way to reverse the execution order
of these. Which is why we disabled the animation there.
Bug: T289043
Change-Id: I1c18802b8ff776fa8d9c17e3df8020354690d29f
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
This is split off from the unfinished patch I039d6f6. This only moves
existing code around, makes use of chaining and such to make code
more compact and hopefully more readable. Methods are renamed to
reflect better what they actually do. No behavior should change.
Change-Id: I3ba538c8c77ad4455bf0f0aa821ca14feadef7cc
Note this implementation introduces some technical debt: It adds a
little bit of knowledge about what "part widgets" and the toolbar are
to the parameter SelectWidget. I think this is acceptable.
A "cleaner" implementation is probably so complicated that we don't
want it in the code, for such a minor benefit. However, alternative
patches are very much welcome.
Bug: T313703
Change-Id: I957698d58a7622cbe54bcc2ba454388ba9f09537
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
The .selected class does nothing on mobile, nor are the tabs visible
under the full screen overlay.
Change-Id: I14a6747f4a3274d71b7aa16b2c9b76b62a5253c2
Generally the default button margin on the parts is 24px. The only
exception are the placeholder and wikitext when they are the last
parts in the outline.
Bug: T312644
Change-Id: Ie513bf1c022b2696cc92aacbbca59ddf6e55043e
In Iebfe2e2 we already tweaked this by 1px. Turns out this was not
enough in all relevant situations. I still get random scroll events
just because I move the mouse around. Setting: Firefox, 120% zoom,
multi-part transclusion.
Bug: T312926
Change-Id: I475c1ef029e9721cc663881e40547730389cd26d
* Rename method because it turns out it is not only about the sticky
header, but also relevant when there is no header.
* Move some code to more appropriate places.
* Use 0 as documented in OOUI, not null.
* Set the padding back to 0 when the sticky header is not visible.
As of now this is an unreachable state because the filters never go
away after they have been made visible. Still this code was always
written with this possibility in mind to make it future-proof.
* Performance optimization for the boolean "show filters?" check.
Bug: T312926
Change-Id: Iaba08ccd8bf00360fd26f9268d5be43df4f4fbd8
This is a partial revert of Ide45141. Now the scrolling always
happens (again), but properly considers the presence of the sticky
header. It was also not correctly initialized on construction time.
This is a candidate for a backport. The patch is intentionally as
small as possible because of this. Code cleanup will be done in a
later patch.
Bug: T312926
Change-Id: I06425b42566bfb2087846636055ee75e98a05029
The message was also shown when a documented template appears as
part of a multi-part transclusion but with zero parameters being
used. You see the filters in this case and can click "show all".
The message is just wrong in this situation.
Bug: T312926
Change-Id: I8d26ceec483e05fd1f69013e506fa1eb4e4c29ed
Currently the sticky size is exactly 114px. With 115px you also can
see an auto scroll effect on multi part transclusions when you hit
that 1px sweat spot at the top of the list.
Bug: T312926
Change-Id: Iebfe2e2c6360c650755cd985157949a26a5287a4
Introduced via Ibc56abf. But the OOUI SelectWidget does have some
methods for this already.
This patch also updates some @mixins documentation.
Bug: T302965
Change-Id: Iffbb44d41586786a2165f8d7916f94a52ad19122
The rename in I5a16ab4 was done the exact same time a new usage was
introduced via Ibb717ca. Neither patch shows a conflict. Still there
is one.
I remove the extra `|| null` line because it is just not needed. We
don't need to set the property to null when it was already null.
Bug: T312213
Change-Id: Id3f025786c9412e8c1946434113c41356da08098
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
Instead of the template that's currently selected. That's confusing,
e.g. when you click one of the search fields, search for a parameter,
can't fine it, and press ctrl+shift+d to add an undocumented
parameter. Or you navigate the list of parameters with the cursor
keys, can't find the parameter you are looking for, and press
ctrl+shift+d to add it.
Still falls back to the selection when the focus is outside of the
sidebar.
We suggest to merge this before UX review, and review it later in
demo time. It's easy to undo if necessary.
Bug: T313388
Change-Id: I9848dd0af4fe821526dafc18bbd7cb1ab0e68cfc
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
Depending on the order in which this code executed, sometimes the
dialog initialization would overwrite the readonly state set by item
initialization.
They should simply all check both conditions.
Change-Id: I6a18f1e074f118423438c017b3e4e34e75579e5d
This code was for when the dialog had a trash can icon for every
parameter, and parameters could actually be deleted. It's unreachable
now.
We missed this when removing the old workflow.
Change-Id: Ic94df506ea84009a1e1863a4e9847a70498df448
OOUI support for multiple modal window managers is hacky, and only
works correctly when the managers are attached directly to <body>.
Remove the wrapper that doesn't seem to be necessary.
Bug: T313690
Change-Id: I4134c0f50d28a364dcf15b426bd9b59a4f7a985d
The dialog is unusable when there is no outline. See T313489 for a
longer explanation.
Bug: T313489
Change-Id: Ib2cc9c363d3596a16f6f1c4aef03ca216abf6b1f
Apparently this can be undefined when Esc is pressed. Note this code
cleanup related to but does not fix T313690.
Bug: T313690
Change-Id: Ia4658f8e00a68ed4cc3a6ddb0a932b3218b813dc
The need for something like this was anticipated in
I2bf43c7e83283f43e047229eb53c244918fcbb0c.
As of version 2.5.0 of Parsoid's output, if alternate text is missing
for an image but a caption is present and image isn't displaying the
caption (ie. it isn't a thumb or frame), then the text content of the
caption will be set as the alt attribute. Parsoid will then drop the
alt attribute when serializing if it matches the caption text, since
it's unnecessary.
However, if the caption is modified and the alt text isn't, the alt will
be serialized. This is likely to be unexpected to editor. They may
have missed that the both the caption and alt are populated in VE and
only edited one place.
Since all of the above is happening only for images where the caption
isn't visible, it doesn't appear to be a much used feature since, at
least for inline images, the experience of caption editing was already
less than optimal.
However, because of a quirk in how galleries are rendered in Parsoid,
this affects gallery caption editing, which is visible and presumably
used more often. See T268250 for a discussion on an improved gallery
structure. But for now, gallery images are effectively inline and set
the alternate text, thus subject to the above.
Here we add a checkbox so that the default is to ignore the alt if it's
the same as the caption. And only make use of it if it differed
originally or was explicitly unchecked to modify.
Bug: T311677
Change-Id: Idf297d8a98995971c5835b0cea56c3317a3626e2
Turns out we have two concepts, now represented by two methods:
1. A top-level part can only be moved or removed when it is actually
selected. This is relevant for the toolbar buttons and for the
keyboard shortcuts/hotkeys. We intentionally block the buttons
and hotkeys when a parameter is selected.
2. Adding a new part or parameter is always possible, no matter if a
top-level part or parameter is selected. This is again relevant
for the toolbar buttons and hotkeys.
Bug: T313388
Change-Id: I17caf8fce9d8f1ebe21660cf8c6d91ace8423490
Same issue as in the previous patch, but less intrusive. It was always
possible to add a new part, but it was often inserted at the wrong
position. It worked only as intended when a top-level part was
selected. When a parameter was selected, the new part was always
appended to the very end of the transclusion, not after the selected
template.
This is now a little bit of duplicate code. We might extract this to
a method in a later patch.
Bug: T313388
Change-Id: I1327222969d1d315bdacf3998f366d88c4c26bd5
The hotkey was only working when a top-level part was selected, not
when a parameter in a template was selected.
Some outdated helper methods are now marked as deprecated. They will
be replaced and removed in later patches.
Bug: T313388
Change-Id: I5ffe45fd00c36b97ee36dc0ba6831db5a941c731
This is a partial revert of Iaf089f4. It restores the old behavior:
* In case there is already a highlight in the parameter list, just
keep that. Usually there is no highlight at this point, but better
have this check in place to be sure.
* Otherwise always start at the top.
Jumping to the selection is confusing, esp. for keyboard-only users.
The argument goes like this:
* Let's say I'm in the middle of editing values on the right side of
the dialog.
* I want to navigate to the sidebar. How do I do this with the
keyboard? I use the tab key.
* Pressing tab also implies I move the selection to the next
parameter. And the next. Until I reach the end of the parameter
list. Then the selection stays there.
* When I finally reach the sidebar and tab into the parameter list,
the last parameter is selected. But this was merely a side-effect
of me navigating the dialog.
Such a "selection becomes highlighting" behavior was not specified
in T311204.
This patch is requested and approved by PM.
Bug: T312647
Bug: T311204
Change-Id: Ie5b5dfd4fca132050815e6182845ca23adb5f805
This should make zero difference in most situations. Except you
navigate a list of parameters with the keyboard. In this case the
SelectWidget gets a dark blue outline which overlaps with the light
blue selection bar, but the outline disappears behind the bar. This
looks odd. Making the color transparent fixes this without the need
to fiddle with z-index or such.
Bug: T311204
Change-Id: I7049eb60dc0ea72c2c4620f4351525fe447e0f46
The main motivation is to get rid of the vague method name
"setParameter" that was previously used for three different methods
in three different classes. Now the three methods have three
different names.
Change-Id: I938de30b368daf6ce3385b2ed2bca98f316593e1
We would love to name this state "selected", but that term is already
used for a template parameter that is checked/used. The idea of "set"
was to have a list of parameters where one is "set". But the word is
confusing. I suggest "active page" because the entire purpose of the
blue selection is to highlight the currently active page (i.e. the
one you currently interact with on the right side of the dialog) in
the sidebar.
Change-Id: I5a16ab4c193ea05c21bb3bf89ada2ef550d8d6bc
I hope this makes it a little more readable. The two steps done in
the loop are mostly independent:
a) Find pages that should be removed.
b) Find next best top-level page when the current one is removed.
Change-Id: I600253fb206a31ef5851865e733b66c336d5014d
This does not have much of an effect, but can cause visual glitches
in rare situations. One goes like this: Use the keyboard and tab key
to navigate to a list of parameters in the template dialog. Press
space to enable the checkbox. The parameter gets a blue background
(= it's now the active a.k.a. "set" item). Press space again. Blue
disappears, as it should. Press space again. Blue is now missing.
Bug: T312213
Change-Id: I3071ec4d0a05e3505ec5216acc5a97b8eaf6f5d5
1. Before, removePages() was calling setPage() with null. This makes
sense for removed top-level parts because these are really removed
from both sides of the dialog. Template parameters are never removed.
Only unchecked (and removed from the right side of the dialog, but
this is not what this code is about). When I navigate a parameter
list and uncheck a parameter I need the focus and highlighting to
stay.
2. We have a dedicated method when a parameter is unchecked. This
can check if the removed parameter is also the selected one (called
"set" in this code) and can reset this state. Without losing the
highlighting or anything else.
Bug: T312213
Change-Id: Ibb717ca49cae805617ebee196937c79daa72f1c1
There are many errors that are temporary in some way, and treating
them as unrecoverable is a poor experience.
Even for errors that really are unrecoverable, our interface works
poorly, because you need to hide the error message first to do
anything else, and you need to close the dialog to see it again.
This distinction is not really helpful, let's get rid of it.
Bug: T307330
Change-Id: I9680cc416da5b27881aeb3502f506dcb5d4bb71f
Optimization: Don't search for a checkbox that represents a not yet
named parameter placeholder. There is never one.
Fix: Store null, not undefined.
Bug: T312213
Change-Id: I395008f15d13133ad456d0a77571b7aa1c7a7fc9
Steps to reproduce:
* Set a breakpoint or debug.log() at the start of
TransclusionOutlineWidget.setSelectionByPageName()
* Edit a multi-part template.
* Use the keyboard to navigate to a template name in the sidebar.
* Press space.
This is currently triggered twice. Let's get rid of the more obscure
one. It was introduced as part of Ic4ee673. I don't really know why.
Bug: T313207
Change-Id: I3ddc072f5d42c17249abc82026e0bf1a4be1dc6e
This also means we have to move the declaration/documentation of the
event up one level into the generic "part" widget.
Change-Id: I1b803201f8955b58136ee7f37c04c01edcd47395
The code that receives this event does not need to know that the
source is a "parameter". It's just some "item" in the sidebar. The
idea is to reuse the event for both top-level parts as well as
parameters. This will be done in the next patch.
Change-Id: I858040f5adf8e156b6013caaa527b3237b7bac0f
What I found is a single `$container.animate( animations )` that's
responsible for the misbehavior described in T312768.
This method is called from a few places. I think none of these places
benefits from making this an animation. This is often more distracting
than helpful, especially when navigating with the keyboard.
Bug: T312768
Change-Id: I90a80d6ae8c1b47ee22297d2520255cad890b90e
Fix setParameter() and let it (un)highlight parameters independent
from a selection (called "set" here).
Bug: T312925
Change-Id: Ie4e9ba94659f4f70160193ca6bec804f8a4473e4
These comments just repeat what the code says. Most of them are
copied from OOUI. Some talk about BookletLayout – a class name we
don't use any more.
Change-Id: I7ce354dfe059657395103ffef767eb8f6d37bfb7
Note how the two-pane layout was already handling the two events
identical:
sidebarPartSelected: 'onSidebarItemSelected',
templateParameterSelected: 'onSidebarItemSelected'
We move this knowledge up one level into the sidebar. Both actions
now trigger the same event.
This implies that we are now using the event formerly known as
"sidebarPartSelected" to act on both top-level parts as well as
parameters. We reflect this by renaming it to "sidebarItemSelected".
Change-Id: I9a2c95f91f05de7312d38ec4c8b360141a0c447d
The optimization removed in this patch is done twice. The effect is
that the loop does not end when it finds a match but the match happens
to be the current page.
This doesn't change anything. It's really only about performance.
Change-Id: I5c2de101eb2f14f814f00cf7eacf46b70346f4c8
This is not only fired when a parameter is added. It's also fired
when pressing spacebar on a parameter that already exists.
Change-Id: I245aa9f5938eb38c3a3f224a4d642d57068cf23b
This is not only fired when a parameter is checked or unchecked.
It's also not only fired when another parameter in the parameter
SelectWidget is selected. It's always fired just because the
spacebar is pressed. This is so we can scroll that parameter into
view.
Change-Id: Id621405b7ca3116cd4a06f474e49776d0830dccc
This line was added as part of I0229b63. While what the comment says
is still true to some degree, the line stopped being helpful when
we introduced sticky headers. When scrolling the sidebar for a
multi-part template with many parameters the sticky header jumps up
and down by this 1 pixel.
TL;DR: This is one of these hacks where it's better to remove it and
look for a better solution when we notice the original issue again.
Bug: T312768
Change-Id: I2fedea4e1d4d6c95c74a63c522821a6ebc2ee2b2
250ms gaps are pretty common when typing at a normal speed, resulting
in a lot of (often expensive) API requests (e.g. T312319). For most
use cases this level of responsiveness in the preview is not necessary.
Change-Id: I6504567d4da02a66171ee35a9c4fd35c85136909
This patch contains a small cleanup that moves the scrollIntoView into onSidebarItemSelected.
Since all other places already have a focus call, scrollIntoView is not needed there.
Bug: T312850
Change-Id: I1a3cb3905faea2bd8a6bf8dc4cfd748813e1c875
This regression from Iaf089f4b271fd853b17c1aa7f5938510ea8f5431.
Not calling the parent here was is essential, because when clicking
the checkboxes this event will trigger the focus of the whole widget.
That's not what we want in this case though. Also it seems we don't
need any of the logic from the parent and can get rid of that
complexity.
Bug: T312855
Bug: T312856
Bug: T312924
Change-Id: Ib3a2eeeb6d519dfa1bb627049f6b3a4708017e86
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
Fixes a bug that crashes the interface when unsetting the focus after
another input was focused, because `page` is undefined in this case.
We were already calling `setPage` to unset focus, so document it.
Bug: T312017
Change-Id: I2926beffe23e0ee822f5690d4791534a5413886a
This can only happen when deleting the last part of a transclusion,
then we want to set the previous page as selected. This should never
be a parameter though.
Bug: T312221
Change-Id: I06700dcf37f6d4f7dd073f8f2bc1b8b0a17a62c4
Just putting this eslint auto fix out there. No hard feelings, but
a warning that pops up everytime.
Change-Id: I157e0338e5f5a6f27dbbd9ae116da0f922468586
Triggers scroll in all situations where highlighting changes.
Including keyboard navigation.
Bug: T312542
Change-Id: I849f64c5cefe0cac3fde6e848b23b7b0cfc489ce
Introducing a set method to have a different state for a set
parameter and a highlighted one in the selection.
Allows us to remove a lot of workarounds for missusing the
highlight state and fixes several issues with these workarounds.
Main implications:
- Keyboard navigation and mouse hover now sets the grey highlight
- If a parameter is set (blue highlight) keyboard navigation returns
when focusing the SelectWidget
- If nothing is set keyboard navigation starts at the top after focus
- Unchecking a parameter using space will not influence the keyboard
focus in the list
- Highlighting a parameter with the mouse lets keyboard navigation
continue from there.
Bug: T312647
Bug: T311204
Bug: T312213
Depends-On: I385dca1d95033961d3844e888521750443e49c95
Change-Id: Iaf089f4b271fd853b17c1aa7f5938510ea8f5431
It is no longer necessary to prepend a colon in Parsoid HTML
to ensure they are interpreted as links rather than an image
inclusion or categorization.
Instead, the colon causes Parsoid to generate piped links
when they could be unpiped, so remove it.
This code was added in 1e62e9f64c (2012),
the Parsoid bug was fixed in b62b93c678 (2013).
Bug: T312700
Change-Id: I3d71fd658b5dd627445e60b850f647081ef842e7
This prevents an invisible and unactionable focus target when the
parameter search field doesn't match anything.
Bug: T312547
Change-Id: Ib29913a547cd68649d29e28d921c4c1358bad7b8
The last checkbox in the entire sidebar should get the extra bottom
margin, but not the last checkbox in each template group.
Follow-up on I1edc5db98d16a4c0de8abd7f705776fb9eb65b97
Change-Id: I4ffade9c053191ce202340edadbd032c67bb39a4
Causes problems when we remove a parameter using the spacebar, for
example.
This partially reverts Id3843b2c7ad6.
Bug: T312524
Bug: T312205
Change-Id: I65d834bc0d2cc649803b536ecc65bdd1fa166a32
Using a certain amount of depth to make sure to override OOUI
specificity.
More can be done in follow ups.
Change-Id: I1edc5db98d16a4c0de8abd7f705776fb9eb65b97
Should be a noop. Also moving one rule further up to the set of
similar selectors.
Removing one rule that was disabled for some time now.
Optimizations follow.
Change-Id: I8da70a52c13afd8ac1c3ff43bae63a203c3bf86a
We don't want to restore selection. Instead, we'll remove all
parameter selections onFocus, in a later patch.
This reverts commit 787d44af66.
Bug: T312017
Change-Id: Ia1dc8061dfd1813a58befff5adc5c3882b54d8e2
Gets rid of some unused behaviors that we've already disconnected.
Brings the remaining styling into VE files.
Bug: T312524
Change-Id: Ie94472019ba41124831621c45713861297219594
Both parts are not relevant anymore:
- The first part is about focusing parameter placeholder pages.
These are added after load only when using the keyboard shortcut.
Focus will be done separately in that case.
- The second part is dead code since some time now. Also it is not
needed here. Scrolling to newly added parameters is done via the
setPage() method in the layout.
Bug: T289043
Change-Id: I928afef01b9e62a9da91db10340d9df78717e125
This should be safe because selection is only set from use cases
in which we do want the sidebar scrolled to the matching item.
Bug: T290975
Change-Id: Ib0c66bb048768d633d0f638c775eba24cd652db8
... except on mobile because the keyboard will expand.
Need to disable a spurious focus when the element isn't visible,
because this was making it impossible to focus later once it becomes
visible.
Bug: T290975
Change-Id: I0e6057d1cfbef24324a287e50e4988f935720c61
Instead of using a potentially weird fractional value like 3.2 lets
use the floor(ed) value, e.g. 3. Reasoning: These fractions are not
from text lines but optional margins between some of the lines. These
margins should not be counted.
Also increase the cut point from >=3 to >3. This is much closer to
the original specification that talked about "2 lines plus x
characters". See T273426. These "x characters" are the 3rd line.
Bug: T310775
Change-Id: Ib5d1642d7967593dd5f13e556c6244fc44677af4
When blurring out of keyboard parameter navigation, the
last-selected parameter will be highlighted again.
Bug: T312017
Change-Id: I8b0fb667b44b324529d4c45c39bf21573517f989
`OO.ui.PageLayout.prototype.setActive` explains that the "active"
state only makes sense for a case we don't support, when a booklet
layout is used in non-continuous mode.
Change-Id: Ib5ddd605f29e82ebc85b833ac96b70ff4c95e502
Most of setPage's side-effects are redundant and can be skipped when
reselecting an item which already the current selection—except for
scrolling, which is useful to perform every time, for example when
clicking on the already-selected sidebar item.
Bug: T294348
Change-Id: I90ba14817e5536ac018eb70102f657f29a29644d
This was using the currentPage from the StackLayout. It will not
be updated there anymore.
Also removing the line about focus after toggle. We do not want
that anymore afaik.
Bug: T312015
Bug: T289043
Change-Id: I8b6eedd580d49604014118171c6da62849752d53
Tabbing into the parameter select list should highlight the first
parameter, but focusing a checkbox by clicking it to uncheck should
not trigger this highlighting.
Copied from the superclass method.
Bug: T312014
Change-Id: Ia1fd450bad4861eb2815ca21eae69ee31e40ac08
Only works with changes in OOUI core. See https://gerrit.wikimedia.org/r/c/oojs/ui/+/753987
Depends-On: Ie822dc87bc5748985de5637cb35f1940837f64d3
Bug: T299036
Change-Id: Idaccc7c95d67abe14621eabb7725ba07e449ab1e
New sidebar events take a `soft` parameter allowing reuse between
"hard" and "soft" selection and parameter add. The "hard" variant
causes a content-pane focus.
Bug: T311987
Change-Id: Ic49718840ae56eb4cfab01ce964a2fbc2d8db63b
More idempotent approach to state change, using a common function
that has all the side-effects.
Bug: T311987
Change-Id: I13e64ff5262295a60c28572855cfe36da7c3ff41
This becomes the canonical method to call when we want to update the
template dialog to select a new item.
Bug: T311987
Change-Id: Ie7880bfde41b77f0e6367cc8e3a78edb299391ce
Call the handler directly. This avoids the `set` event handling for
add and remove parameters, causing minor behavior changes:
Moves the "reselect" logic after removing pages, from StackLayout to
the two-pane layout class.
Bug: T311987
Change-Id: I46454d184d4718bed45caf9f41487364611f1f44
Only 'altText' should be described, everything else
is computed or, in the case of `resource`, results in
nodes being incomparable.
Change-Id: I586b67a0cfa30fae10a86fe3791f7e532c0ed754
This event makes other calls redundant because it's always sent from
setPage and onReplacePart.
Bug: T311296
Change-Id: If214a713ed7299320d499c3e5687eda013fe0aab
In an important use case (spacebar selection of sidebar parts), the
content pane selection isn't updated. This patch switches to read
the sidebar selection rather than the content pane selection.
Bug: T311296
Change-Id: I684a9edf04b6615cc840bbb89e8c1d03a0ab8e94
If nothing has been selected, the action buttons should be
initialized in a disabled state.
Bug: T311608
Change-Id: I32fee0d73f6e13e09dc421c944df73b79e0260bb
No longer need to manage the connection between outline items and
content pane pages.
Bug: T310866
Change-Id: I8dae7efa18e97ce5e1c84d963f1a32f09dd7e7cb
It seems that the controls widget was the only side-effect we still
needed for maintaining existing behavior.
Bug: T310866
Change-Id: I507dacef4e56946b836b0fca31effce611260aec
This patch does a few closely related things:
* Replace a direct dialog → sidebar access with dialog → layout →
sidebar.
* Move the misplaced removeButton.toggle() to a more appropriate
place.
Bug: T311069
Change-Id: I5a2802aab587a6f7de4681bce4e9961a064ef8ee
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
We're not implementing a search widget with results anymore. It's
a leftover from the cleanup after feature flags got removed.
Bug: T310859
Change-Id: I9c177ae92a7d3e13a4fff248a6c86f1aab89f82c
The original intend of that rule was not clear to me and it seems
it got dragged along for some time. I checked the DOM in the
collapsed state to see where this could even apply in the new
interface and found no other place than the one where we overwrite
it again.
I guess it can go away.
Change-Id: I2886db33c5f06d1c49acc4743c9acc198339de36
These are internal to the two-pane layout and sidebar, so the dialog
doesn't need to be involved.
Bug: T310866
Change-Id: I5f05bc119dc213d8e31db62a3808a2fadaf35d99
This is a direct follow-up to I7f22e4b. I found that the way the
margins have been arranged became a little more complicated with
I7f22e4b. This patch tries to go back to the – I think – simpler way
it was done before.
It should look the same as before down to the pixel.
Bug: T311223
Change-Id: I2c7789922078fa98f15f0b65de4c0efdf878a13a
The one usage of this wasn't working. FIXME: maybe we want to
restore the behavior, to focus the first parameter in the dialog
after opening.
Bug: T310866
Change-Id: Ibe0151fbedb3a9716bb231b5d398c4ae670fd667
This defaults to false. It looks like this default is used in the
MWTemplateDialog base class. However, it also looks like this base
class is never used on it's own. All users we know use the subclass
MWTransclusionDialog where "editable" is true.
https://codesearch.wmcloud.org/search/?q=%2C%5Cs*ve%5C.ui%5C.MWT(emplate%7Cransclusion)Dialog&files=%5C.js%24
In the process I also remove some comments that literally repeat the
code and don't add any knowledge because of this.
Bug: T310867
Change-Id: Ie245aab80d1e77a8406f5591062e9cf49fd9613f
This code was meant to select the first parameter of a template the
moment it is added. It's at least partly broken because it doesn't
consider the so called "prompted" parameters that have been added
just a few lines above. It's a questionable feature anyway. We are
going to refine all focus-related behavior anyway. Let's remove this
broken stuff and reimplement it later (probably in a different place)
when we continue working on this.
The FIXME was added in I720ce1a.
Bug: T311223
Change-Id: I1801efe38387b5e7a1b76417c1e5d7db4e4b96d0
This was done in 3 rather "random" places:
1. Whenever a template is manually added. But rather late, after the
template was added, in an event handler that is about focus
behavior. It should not continue to manipulate the template that
was just added.
2. When the dialog opens with a template preloaded by name, as it is
done from the citation menu.
3. When the dialog is about to finish loading.
This patch fixes 2 issues:
* Get rid of a duplicate call (number 2 and 3) when using the
citation menu.
* Move number 1 to a place where it's executed much earlier, and
only when the user clicks "add template" in a template placeholder.
There is no other way to add a template to an existing transclusion,
but it's still a more appropriate place I feel.
Bug: T311069
Change-Id: I8a65ad703b95ba2092e9ef73493e9903e96b0dd6
This still works for a dialog with just the template placeholder,
because the page is already chosen as "current" in the stackLayout.
Bug: T310866
Change-Id: Ibc1d33b02d34f70548d9f7365e085847ef0b2a51
Includes moving CSS that already moved from the TemplateDialog CSS
file to the DialogLayout LESS file.
Width and height had no effect. Neither on desktop/mobile. I guess
the control's height covers for that. Float could be removed due to
the flex layout.
Some more specific rules could cover for the !important overrides.
Change-Id: I7f22e4be37c8f227845aed97281faefe26241091
Pre-parsing with $.parseHTML is not required as we
1) no longer modified the DOM before appending
2) trust the HTML coming from the API
Change-Id: If549a0e647ce830d4f5de2bb94c08a895e460667
This causes one small behavior change: when deleting one of several
wikitext transclusions or a part following a template without
parameters, the selection would previously be set to the *previous*
part, and now it's the *next* part. This is arguably more consistent
with the behavior when removing eg. templates with parameters, after
which the next part is selected.
Doesn't affect removing parameters.
TODO: We might want to restore the already-broken behavior to focus
the first parameter of a newly-inserted template.
Bug: T310866
Change-Id: Ic5f47e31512d1a3949caf60613bd05b9a3bdf478
This place is much better in so far that it much more obviously gives
us the guarantee that the sidebar and the content pane are always in
sync.
Bug: T311069
Change-Id: I01a7914fcba5d573abb957d0e34fa895874bd94e
According to my test one of the two places where this property was
used is impossible to reach with the property set to false. This is
the one I remove in this patch.
This also removes a related method that is entirely unused.
Bug: T310867
Change-Id: I9579a5d894d60560cec77dad7f1e796f8dfca06f
Includes adding a less file for minerva layout rules. To make best
use of the less shortcuts and avoid duplication, some selectors
have been slightly changed. Outcome should still be identical.
Change-Id: I92179ecf6045c938cace0e7e809b7ad4cf035727
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
