Commit graph

14 commits

Author SHA1 Message Date
Roan Kattouw de2baff16d DesktopArticleTarget.init: Also extend existing URL in SET mode
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
2020-04-14 17:01:23 -07:00
Akinwale Alagbe 3b7a567bfc Fix: Adding label to source editor switch editor tool
Change-Id: I7cd90bbbd0f65c0a5b0588fd337e922a63b618b5
2020-04-06 18:10:26 +00:00
jenkins-bot 443cb0fe55 Merge "Overwrite "edit source" link only when needed" 2020-04-01 21:51:56 +00:00
Bartosz Dziewoński 92c3055628 Fix issues with treating section "numbers" as integers
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
2020-04-01 21:41:17 +02:00
MtMNC fd0b145db3 Overwrite "edit source" link only when needed
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
2020-03-27 12:20:33 -07:00
Bartosz Dziewoński e2cb9ce93e Remove incorrect handling for 'T-' prefix in section numbers
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
2020-03-18 21:23:38 +01:00
Ed Sanders 71157aab76 NWE: Don't change editor preference if visual mode not available
Bug: T246259
Change-Id: I1513098be707ca5c1a40a061917487785f5100e8
2020-02-27 16:53:45 +00:00
Bartosz Dziewoński 387e0d3cb3 Remove incorrect init special case for wikitext single edit tab
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
2020-02-20 22:37:45 +01:00
Bartosz Dziewoński a0c603a137 ve.init.mw.DesktopArticleTarget.init: Update for Minerva changes yet again
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
2020-02-15 16:40:57 +01:00
Bartosz Dziewoński 3458d8a27e Don't offer switching to VE if it's disabled in preferences
In many places we check whether VE is available before doing things
(init.isVisualAvailable). This variable includes checks for whether
the page is wikitext, etc. Now it will also include checking whether
VE is enabled in user preferences.

In almost all places where init.isVisualAvailable is used, we were
already also checking if VE is enabled, so this doesn't affect the
behavior. But notably, we didn't do it when showing the option to
switch to VE in the welcome dialog and in the toolbar, causing T243723.

Changing init.isVisualAvailable this way makes it consistent with
init.isWikitextAvailable, which has always included a checking whether
NWE is enabled in user preferences.

Bug: T243723
Change-Id: Ie174bc3f16bceb29cb155b9223e0acef70167fd6
2020-01-28 16:26:03 -08:00
Bartosz Dziewoński 0791dd352d Fix tab initialization if NWE is enabled but VE is disabled
Bug: T178976
Change-Id: I16b7ef564e8c28c0c583c724ffb482b2c9fcbadb
2020-01-28 16:26:03 -08:00
James D. Forrester 2c77e88d2c doc: Bump copyright year for 2020
Change-Id: I30539877543dc2a57bd1428a00d10ac46d8fc294
2020-01-08 09:13:24 -08:00
Ed Sanders ffa3742ce1 build: Update linters
Change-Id: I03d1a8e63b730ad98ec07ad5f630ba82698de5be
2019-11-01 16:20:22 +00:00
Bartosz Dziewoński 3f0f302577 Enforce that some files must not use the ve global
Previously, the ve-mw/init/ directory contained two kinds of files:
those that were used when initializing VE, and those that may be
loaded even if VE is not going to be initialized at all. The latter
kind must not use the `ve` global variable.

After moving those files to ve-mw/preinit/ we can enforce this with
.eslintrc.json in that directory. This would have prevented T228684.

(Technically they merely must not use `ve.init`, and may use `ve`,
but that's harder to enforce. We should instead move the few non-init
methods out of `ve`: now, track, trackSubscribe, trackSubscribeAll).

Also, group some files under ve-mw/init/: targets/ now (only)
contains ve.init.mw.Target and its subclasses, apiresponsecache/
now contains ve.init.mw.ApiResponseCache and its subclasses.

Bug: T228684
Change-Id: I945249a27f6a0fa10a432d5c5dc57bc7e0461fd8
2019-10-10 15:15:40 +00:00
Renamed from modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js (Browse further)