* 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
* Use this.getElementWindow
* Use this.surface.padding to avoid race condition
when the toolbar hasn't fully rendered yet.
Change-Id: I055b1d9458d73e435ede6096941a3e72c9c1ce74
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
I tried to review all of them. Some of the changes I did:
* Make sure the `config` parameter is not marked as optional
when it is not.
* Make sure default values are mentioned.
* List individual `@cfg` options when it makes sense.
Note I don't list all options a class could accept (e.g. via all
its parent classes and mixins). That's too much. Instead I checked
how a class is actually used and list only these options.
Even then I don't list everything, e.g. unspecific options
like "classes" that can be used pretty much everywhere.
Change-Id: Idf4fbe1dc3608ace277df9e385f2f140df3a2f50
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
* Create getSurfaceClasses method.
* Pass surfaceClasses to target widgets.
This ensures that the 'content' class is passed to mobile
target widgets, and the 'mw-body-content' class is added
in a less hacky way.
Change-Id: Ibce6d1a1d0fda63cca354761f1b91f808858e95b
VisualEditor recreates the mw-body-content element. The element
with mw-parser-output already exists as a child. All skins now
consistently follow this pattern.
To limit the impact to the editor, we use ArticleTarget and add the class
to the surface, which corresponds to the mw-body-content element of a skin.
This avoids unrelated regressions in experiences such as DiscussionTools.
Bug: T283014
Change-Id: I4833d1ca9fda4fc0bd433760e47fe7010f00db05
The regex that removes the wikilinks to create the initial edit summary
should have the global flag since it was taken from preg_replace which
replaces globally implicitly.
Bug: T276722
Change-Id: I21e3cdfe752657ad37d9a6bd473a7e7dbb6e4cd6
We need the whole DM doc to show reference diffs
correctly. We can filter down to the active section
after the conversion like we do with the editor.
Bug: T272813
Change-Id: I2081dd520ff414caadaed2efda955d600953c957
New changes:
c17816c5f Diff sidebar: Make font size slightly smaller
f8439f4cc Deep-freeze linear data
a8919f78e Deep-freeze linear data added by transactions
Local changes:
Fixes for deep-frozen linear model
Bug: T119236
Change-Id: Iae4362c8dab0f2bd335e24498f3e0522b8b1d4fc
This was used when we used to pass API errors to showMessage, but
is now unused by the two remaining users (missing edit summary, and
"press ctrl+enter to submit").
Change-Id: I8a6b4db78d4e451cf3ec85fcdfd8293328aaaa3c
* Remove custom internal events in ArticleTarget for every error type.
The indirection was just making it harder to figure out what data
goes where.
* Centralize the actual logging in ArticleTarget, instead of doing it
in a dozen methods.
* Directly use the error code from the API for 'save_failure_message'.
Previously we'd lose the original error code and generate a new one
in the event indirection stuff, except for 'responseUnknown'.
* Update 'save_failure_type' map. Remove unused error codes, update
the ones that changed, and sort in the order in which the types are
listed on the schema page.
Bug: T272162
Change-Id: Ied602c456f4b0e7e9bb135e3200bec5ce65641ba
originalDmDocPromise is dervied from target.doc, so if that changes
ensure the promise is cleared.
Change-Id: I51219e06109b0ccf1a17c920131b764862be85e1
Rebuild the category list from the data we got from the API. This makes
it work regardless of whether we came here from activating on an
existing page, switching from source mode, or loading via an edit URL.
Because Parsoid doesn't include redlink status on the <link>s it
represents the categories as, we do have to manually update those
styles.
Bug: T251398
Change-Id: Iaaef3223816269bba1371fbb07956119a120c1ca
There used to be similar code here, but it was removed in 2015 in
85b745666f because it wasn't correct in
some cases. Restore it and instead separately check for those cases.
Bug: T257124
Change-Id: Id4a17266111d064805aa0ca865182bb2f4b019eb
This reverts commit e5c1ef651b.
This change caused an error where templates failed to be inserted
into wikitext in the 2017 wikitext editor.
Bug: T255785
Change-Id: Ie57c49e68e594be22af2b1b479840f29e46131db
mw.Target doesn't know about revid and etag, so move that logic
to ArticleTarget, where the param can still just be a boolean.
Change-Id: Idf4632cd28554aaf5bbf5f2b44ded047c0c4b182
This handles the minor edit and watch checkboxes, as well as any added
by extensions (e.g. FlaggedRevs).
Switching in the other direction already works fine, that is
implemented in ArticleTarget#getSaveFields.
It doesn't seem ideal to put this code into the constructor of
ve.init.mw.DesktopArticleTarget, but that's where we already have
similar logic for the edit summary. I filed T253696 about this.
Bug: T250388
Change-Id: Ia6a9c0465ed215e8f74b9fff4590593383e9a1e6
Previously we didn't deactivate them, so if you opened VE, then
switched to NWE, then exited the editor, all three tabs would appear
active.
Change-Id: I904d6daf2896ceadf004f5e57a88c2359f33fd44
The base class doesn't use it, it only defines it, and
DesktopArticleTarget is the only subclass that uses it.
MobileArticleTarget calls it, but also overrides it to be a no-op.
Change-Id: Ib3feea94844f4e1ed71dccece7657450516cac89
Factor out the logic for whether the WelcomeDialog should be shown into
its own method, and write it in a less confusing way. Do the same thing
with the logic for setting the preference/storage/cookie for hiding the
WelcomeDialog.
This makes maybeShowWelcomeDialog() much simpler, and removes duplicated
code in DesktopArticleTarget.
There is one minor change in behavior: if the WelcomeDialog is
suppressed using the URL parameter, that no longer causes the preference
to be updated as if the dialog had been shown.
Change-Id: I1d4f912c5f6bd7a2bbad2b209b97c3ec1f250a07
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
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
This code path is triggered when saving a new section in NWE causes an
edit conflict, which should be impossible, but apparently does happen.
Add some TODOs for parameters being added to the API calls in weird
places, instead of the dedicated methods.
Bug: T248364
Change-Id: I0686671e86e35f9ba503d0dd84e9074dde72dc10
