Whether the dynamic property is present or not, it should have a null
value when 'unset' -- and don't use `unset` to delete an *actual*
property when one is present!
Change-Id: Ifcb9492cc5c814d702c6e61e8231abfd8ea0647c
Implemented addition of 'extends' feature information to WikiEditor Help menu, under the extends feature flag
Bug: T361088
Change-Id: Ide15286527227f61a48386384b96ac965c5dec42
Note this is only a bandaid patch that avoids the failure in this
place, but doesn't solve the fundamental problem. It appears like
the data coming from Parsoid (in internalList.….firstNodes and
internalList.….indexOrder) is somehow out of sync, and one of the
numbers in the .indexOrder array points to an element in .firstNodes
that doesn't exist (any more?). I don't know why.
Bug: T351550
Change-Id: Iaa4c748462d90d7783edb89713b61ffff6d70765
The search index is really only used in a single place, in the
buildSearchResults method at the very bottom of the class. I find it
more obvious to understand what's going on when the places where the
search index is populated and used are as close together as possible.
This again really only moves existing code around without actually
changing anything.
We can also drop the extra "built" property and use a special null
value instead. This is possible because we know the only consumer of
the this.index property and can guarantee it can't get confused by
the null.
Bug: T356871
Change-Id: Iaddb3b16b3aa776f89fca2bf0350cce9b6bb1a23
This turns two methods with side-effects into more pure functions
with more obvious input and output. buildSearchIndex rebuilds the
internal search index from the internalList. buildSearchResults
filters and creates the result widgets the user will see.
This patch really only moves existing code around but doesn't change
anything. Except that this.built is set before onQueryChange is
called, not after. This avoids potential endless loops in case
onQueryChange happens to trigger buildIndex again.
Bug: T356871
Change-Id: Ib80a2dcb85779d64bec53caf90c49879d0ea2258
* Improve PHPDoc documentation.
* Add some missing language-level type declarations.
* Remove unused code.
* Avoid count() when the code doesn't care about the actual count.
* Use the short ??= operator where possible.
Change-Id: I79de49b65d32661b7efa67ecc350276968943e11
The default doesn’t seem to work well in CI. (Note that cypress/.cache
is already in the .gitignore.)
Bug: T361520
Change-Id: I7e56d102ac2252a23b49c68f9df8940d5c060aa9
Flaky parts have been fixed with the patches chained before. See
the stress test patch Ie32019ca65194e0ca94471d797b59b150d3334c4
Bug: T360026
Bug: T360361
Change-Id: I421a7718fcf77136a65bf8bd20f2c2fcd483fa3c
Introducing a little helper function that retries clicks until
some element becomes visible.
Bug: T360026
Change-Id: I45b7802c8009b9b552b41c1fcaf861f2a7afb495
I missed this spot in I321b4114ca03ebd02a79d8bd3863ea0e68494dc2
This should stabalize the remaining tests failing in the stress
test.
Bug: T360026
Depends-On: Idbf87178e9ee961e84a6e212dbadb0f36a1c8197
Change-Id: Ic41fbd9da24c3bba7eec3d1429731b2cc6665404
I find this particularly confusing because it makes it look like this is
an array. As a reminder, while empty arrays are false in PHP they are
not in JavaScript. An extra `if ( array && array.length )` is really
critical. But this is a string. Empty strings are false in JavaScript.
No problem.
This was originally written in 2013 via Ib244ff6 as a pure .length
check. The duplication was added a year later via Id401d97 for an
unknown reason.
Bug: T356871
Change-Id: Ied335f170a9a0a7bbc8c8fd12f95b6902f401bbf
This does two things:
* Some authors have used different email addresses over the years.
But it's the same person. Merging them makes e.g. git shortlog
much more useful.
* This also makes sure the author name before the email address is
always the same, and not listed multiple times because of e.g.
different capitalization.
Change-Id: Icdfd397a46369ffc40ac982a4382b19ad207957a
