Aligning instances of `progressive` color to WCAG 2.0 level AA compliant
color palette similar to changes in
I6fdb90af8b9dc5e5e026eb0c1bd13138c73da4cd
Change-Id: I2eda190f0a68de6dc8aa33724f2c8975327a061f
transformPage() makes significant changes to the DOM, so measuring the
scroll position synchronously right after that results in a slow forced reflow.
Instead, measure the scroll position before reorganizing half the DOM.
Change-Id: I3baee5c11ca228696ddbfb30789745f5f0faa20a
The tests are failing with RSpec::Expectations::ExpectationNotMetError
for 2-3 days in a row.
Bug: T145861
Change-Id: Ieec2a67857b90033cdd0ddf63025d2af9de504a5
This was supposed to be removed in 7f02824ec4 except it got missed
somehow...
There was nothing registering it in extension.json, so it was entirely
unused.
Change-Id: I991c464ef0b60543a0ecd4cb1f9dda62e9d73dd4
New changes:
7a06bb7 Fix 'new ve.dm.Transaction.newFromDocumentInsertion' typo
db9b7a7 Make ve.dm.Transaction plain data by removing the .doc property
62c662c Localisation updates from https://translatewiki.net.
455e949 TableKeyDownHandler: return early if any modifier other than shift is used
9440e38 Localisation updates from https://translatewiki.net.
ed76839 Update OOjs UI to v0.17.9
Change-Id: I70a6387e6ea6d986ed132998df592f12274adf1a
This gets us the variants (which we need for OOUI 0.17.9); note that I've
cheated and used 0.17.9's colour for the MediaWiki theme's progressive flag
rather than 0.17.8's value of 347bff.
Change-Id: Ic436970e9298ea31f48c6cfdd04b80847aaebbee
These aren't in the Parsoid HTML spec., so there's no valid way that they would
be in the original document from upstream, and we don't—at least intentionally—
allow users to insert them, so we can safely assume that they're resulting from
browser extensions and other items inserting content into anything that sort-of
looks like an HTML page.
Bug: T144891
Change-Id: I330ae05cd53eee5c18b18ad744ea0ec7b2eb09cc
For example, MWWikitextTransferRegistry (in .mwcore) expects
ve.init.platform to exist (in .mediawiki).
In normal operation this isn't a problem, but it appears
in some cases (switching to VE from edit source) it can be.
Bug: T144881
Change-Id: Id1a5367472a3f837e7563330dd5220e61adb1889
New changes:
aacd653 Deprecate IndexValueStore#clone in favour of slice()
90b1003 ce.TableRowNode: check we're still attached before setupMissingCell
c0ffae7 Allow users to pass in LinearData objects to cloneWithData
da9961b Localisation updates from https://translatewiki.net.
5467054 Un-break build from i18n-bot-added language
50f2e84 Allow progress dialog items to be non-cancellable
26dd5ad Don't render cursor holders outside of active node
38b5572 Fix bad serialization of DOM elements in cloneElement
Change-Id: I07e0c9b150897a6d3023845930b2dd9554d9c74e
Instead of getting wikitext from the HTML, which is probably
slower and leads to issues with the whitespace stripping hack,
override getDocToSave and get text from the linmod directly.
Bug: T144621
Change-Id: I6b6cf16ee8f3720398ba8f5c85e7715c2e68329f
