* 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
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
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
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
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
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
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
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
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
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
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
