Something is causing the 'ETag' headers produced by the "public"
RESTBase (queried directly from the client) to be mangled or lost.
My theory is that some proxy or browser extension is doing that.
When we detect a bad etag when fetching the page contents, discard
the result and try querying the "private" RESTBase via the MediaWiki
API (similar to what we do on private wikis, except there we talk
directly to Parsoid instead of RESTBase). After I463a84de63, that
returns the etag as part of the payload rather than HTTP headers,
and should pass unharmed through whatever is mangling the data.
Also compare and log the two etags.
Bug: T233320
Change-Id: I2ef0ca872597566f74b650aea71bf3f15747a6d7
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
The ...target.wt property contains the wikitext used to generate
the template name. It can contain trailing newlines (T234817) and
all kinds of funny wikitext syntax. Instead, use ...target.href,
which is the title of the page that is actually transcluded. Compare
the new code to ve.dm.MWTransclusionNode.prototype.getPartsList.
Additionally, fix some confusion about namespaces (treating template
names as titles in the main namespace). The template names in the
configuration page (visualeditor-template-tools-definition.json)
now support overriding namespaces in the same way as in wikitext.
Bug: T234817
Change-Id: I7c557d28e961d0b9117fc0380c65cdd42035ae96
If you had an image thumbnail for a file 'Foo?.png' on the page,
ve.ui.MWMediaContextItem and ve.ui.MWMediaDialog did not escape
the '?' when linking to it, which resulted in incorrect links.
Similarly, if you had an internal link to the page 'Foo?',
ve.ui.MWInternalLinkContextItem did not escape it.
Additionally, the links were always generated as if the wiki was
using short URLs, even when it is not (T233628).
The approach using mw.Title is copied from ve.ui.MWGalleryDialog.
Bug: T233628
Change-Id: I10256ed6883dae0ea216de4c0719f03d7fd19ae4
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute, and parse 'resource' to keep it
identical to 'href' if they refer to the same page (including
same percent-encoding and space/underscore). This resolves Parsoid
generating |link= options for copy-pasted images (T193253).
* In gallery images stuff, prefix the 'resource' attribute with './',
same as normal images do. This causes no functional changes, but it
makes updating tests easier, and the consistency is probably good.
* Update test examples to also prefix 'resource' and relative 'href'
attributes with './', like the real Parsoid does.
Bug: T193253
Change-Id: If2d7f080d9d693568054f8311c1e1b15ca27ea5c
* Handle mw:MediaLinks pointing to to non-existent files, which come
with typeof="mw:Error" (similar to image nodes).
* Fix regression from c66f8e0547, which
caused all mw:MediaLinks to be treated as plain external links again.
* Add test cases.
Bug: T232754
Change-Id: I9ae5bcfc4e24e8c0d22ef77d6a4d03f817fc9768
In order to get the desired padding, the `em` values were pre-multiplied
by the parent font-size, which was assumed to be `0.875em` for normal
surfaces and `(13.3333/16)em` for wikitext surfaces. (That should have
been `(13/16em)`, by the way, but that's a negligible difference.)
Unfortunately, the font-size for wikitext surfaces is actually `13px`.
Unlike `em`, `px` values are not affected by custom browser font-size,
so when one was set, the final padding was all out of whack.
Use `rem` units instead to respect the custom browser font-size,
without getting problems due to the parent element font-size.
We don't need separate rules for .ve-ui-mwWikitextSurface now.
Bug: T222217
Change-Id: Ib7ffbf09d5aa23fddb894aa3b081ec993ddcee2d
This meant we were returning invalid documents with bare content outside
content branch nodes. Instead let ve.ce.Surface in VE core do the unwrapping.
Bug: T232944
Depends-On: I8799d51958b966c99307f4c70546ea326e67385c
Change-Id: I0479116b51cc3135a992fdf36b8edfb2c44916ba
The call to selectFirstContentOffset() below would re-activate the
surface and (attempt to) show the keyboard if the surface was
deactivated, but not shown as deactivated.
This might have worked correctly by accident before
I39fe44eee8eab7129340bcff796b6b9b3a59a398 in VE core.
Change-Id: I500309cc0aa8cd794175ae683a17c2614fd58cc9
Some post-save scrolling would try to access the view before the
handlers were cleaned up.
Bug: T232347
Change-Id: I30433ef027c52d541351972f8ebb09fe6d45e436
As of I6c043e039fbef62a56f475b0dc365e171ab7bf59, this method is never
called. It was previously used to update the size of the toolbar when
context menus were displayed inside it, but they are now displayed
elsewhere.
Change-Id: I53030de1203a7f0d75780ae796bbb10082d5ef7a
As of I2f2495ab6c10116a6660f4361e49272cb95b988a in MobileFrontend,
the overlay never uses the default spinner.
Change-Id: Ie0aa624e33a5bd21fc20459697cca175d9de5606
New changes:
d4cb2f03e Update OOUI to v0.34.0
b0b481693 jsduck: Stop listing OOjs in upstream, it's using JSDoc now
0b17a137b Update OOjs to v3.0.0
Change-Id: If29a97ce689523763431face5a13929a461735b4
The good thing is that every time our CSS overrides get less crazy.
See 75ff121b29 for the last time.
Change-Id: I9d81aff6a24ec28850563e00206e21c4a6593d2e
Context items can be created for specific template titles. Titles
are mapped to context items using an on-wiki message.
Bug: T211243
Change-Id: Icfc39e350452da238d0e0c17cb2305c60d9ca16a
Tapping the toolbar save button while the save dialog is open triggers a save
because of the accesskey. It shouldn't save on a double-tap, because that's
easy to accidentally do / trigger on a slow device.
Bug: T230816
Depends-On: I4c3afce9d57c9bca737272b40b9a4862b5794bac
Change-Id: I1925b1b97de6a811f73196b616ec09a2c30c336f
