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
This focuses on a few trivial cases where the syntax helps making
the code more readable. One level of indirection is gone with this.
Change-Id: Ibf25d7eaa06952e69b36bd5a78a48d04ac62890c
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
The `.` character class matches any character *except* line terminators,
but edit summaries can contain those. Use [^] to match truly everything
in the comment part. (In the section part, I assume `.` is okay.)
Bug: T302103
Change-Id: I29fcdd7489d118674bab5cfe5c0a15b8e4efac64
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
Found via Iaf989bc50363a (patch set 6):
> FAILED TESTS:
> ve.init.mw.DesktopArticleTarget
> ✖ init
> Died on test #1
> TypeError: Cannot set property 'pageLanguageCode' of null
> at Object.<anonymous>
Bug: T89434
Change-Id: I8ad2cc4c115224eb276d1488091b9518fde739f9
* 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
Previously, a toolbar with the extra tool could be shown for a moment
while the editor was loading.
Bug: T301626
Change-Id: I7f5d01ef6e64ef85141a38a236fe2a1d1ada00e8
When the editor is loading, and the browser window is narrow enough
that we should use the narrow toolbar, the wide toolbar would appear
for a moment. It was particularly jarring when it caused it to wrap
over two lines.
Bug: T301626
Change-Id: I551a66edab40235c4a26751eed163b5b30ef698f
Make sure it works on pages which don't trigger DT, such as full-page
wikitext editing.
Bug: T301497
Change-Id: Id3d46eef319f278ee71fbbedbddd16d5ffd540d8
* Pass 'noPrompt' to #tryTeardown
* #loadFail gets triggered by the data promise being aborted,
so if 'activating' has been cleared at this point, don't
prompt about there being load error.
* Retry/cancel dialog assumed you were coming from a wikitext
editor. Rewrite the logic to handle teardown the target if
the user is coming from read mode.
Change-Id: If9e5d1fbf00f8359f4d06fe7fc3064cc7e349bc9
I bit more logic was needed to make sure, the state of the widget
resets when all unused fields are added during search.
Bug: T299811
Change-Id: I3006c233fda5490e323bc3a3e631bf0c1199bda3
Covers the base functionality to hide the parameters. Performance
optimizations could be done in a follow up.
Bug: T300640
Change-Id: Ia99b5da392273f1445e475a0720a656460612dcf
The behavior is now consistant with what would happen when the
buttons are triggered.
Instead of emitting a button click I directly wired the methods
that will by triggerd by the click. This might make it easier to
remove the old sidbar later.
To avoid movement when the buttons should be disabled, an
additional check was added to the onMove method. It's not identical
to the more complex check in the outlineControlsWidget, but should
be enough for our use case. The onDelete method already just does
nothing if nothing is selected.
Bug: T300971
Change-Id: I8a278c9657c91fd648944b5a8c1204c9fff75b7e
This option was added in 0.43.0. Now that the close button is handled,
the remaining functionality (store a flag in local storage, and fixing
link targets) doesn't really justify a separate class, especially as
it's currently only used once.
Change-Id: I0fd81cadccc077dbf957302f9f41409c5a1f4f20
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
We introduced these methods in Idc0cccbe but didn't update this
logic in MW.
This prevents focus being put inside an image caption if the section
starts with a block image.
Change-Id: I4cc1a116c1dcc8e1c642359ea768b6f5265a061b
Parsing it in the RL module caused the module cache key to depend
on the parse, which is slow and makes ResourceLoader sad. The usual
approach for solving this (I206bb05d28) can't be used, because of
how EditPage generates this message.
Bonus #1:
Generate the message for the correct page title. MediaWiki allows
customizing it per-namespace or even per-title, which we haven't
supported before.
Bonus #2:
Pass the context for message localisation (depends on I5f7c77970d).
EditPage::getCopyrightWarning() was parsing messages without the
interface flag, causing some needless processing elsewhere.
Depends-On: I5f7c77970d0525c0ff394f8bd72c69dcb5d00623
Bug: T298822
Change-Id: Iaa626f0e6379a5a370f9c465cea8528bb5bde7f7
New changes:
e5963f084 DiffElement: Remove doc-child-change wrappers
90a359f79 Follow-up Ia593dad8: Use modifyData when sanitizing
f5c7f0f20 Localisation updates from https://translatewiki.net.
Local changes:
* Update tests for the removal of doc-child-change wrappers
Change-Id: Ib29f23625de9151d50e0f3b7796b15ca9ed89133
Do show a confirmation when editing templates without parameters,
but don't show the confirmation when you're only on the template search
page.
Bug: T299394
Change-Id: I8205bb6a0f92b7b535a80f7f6a43674f1aa5b51b
We were using addItems() incorrectly, and it stopped working after
change Ib1241f93d214e8a7d2f757a120f84de3879575af in OOUI.
Bug: T299818
Change-Id: I2d00cb929673a419789ca6f8bc308721373e1da8
