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
Note these are more meant as regression test to better cover what's
done in other patches. Everybody should feel free to delete a test
when it gets in the way. I marked a few especially fragile places
with respective comments.
Bug: T358652
Change-Id: I7844907fe3ef4f3439717381b4ecdac9e2d0a825
Please don't reenable until we have some confidence that these aren't
flapping.
Bug: T360026
Bug: T360361
Change-Id: I54f80e31b4fca4c1c4632af1d43e22a88ae5f218
We don't need to setup a fresh page on every test when we're not
manipulating the page during the tests. This will make test run
faster overall.
Change-Id: I4f41f0bf7b01f5a8498fda4827b90c9976cbd528
When the tests run into an issue and are re-run only beforeEach
will be executed. Also cookies are not kept for the re-run.
This patch makes sure that steps needed to have a clean re-run are
split to the beforeEach
Change-Id: I47cba7f6ec240fefa09a4484bca0a621b99f2bcb
We need to wait for the UI to be finished loading before we can
interact with it. Here I implemented how it's done in the VE
selenium tests. They seemed to have similar issues with flaky
tests before they introduced what I use here now.
See I321b4114ca03ebd02a79d8bd3863ea0e68494dc2
Bug: T360026
Change-Id: I91bc104ef7af4c74765c2c354eeadeacef162309
Might help in some edge cases where elements need just a bit longer
to load and be available.
Bug: T360026
Change-Id: I60176435963c708d13ce7fd3e0691cb6e7a35fb1
There is currently no test coverage for recursively parsing the
contents of a <ref>…</ref> together with an incomplete follow="…".
This is critical because that's an entirely separate, special code
path (the one that creates a <p> instead of an <li>). Without this
test we could return unparsed wikitext and never notice.
I discovered this while playing with I0b0e358.
Bug: T245549
Change-Id: Ie65c6bf6bf75db26e0fff733c93cfa28ee7bd228
This does the exact same as the previously used generic stdClass
object, just strictly typed. Turned out to be surprisingly
straightforward, as proven by the small size of this patch.
I'm intentionally not adding anything new in this patch. For
example, the new class is perfect to write longer documentation
for every field. But this is for a later patch.
Change-Id: Ibf696f6b5ef1bfdbe846b571fb7e9ded96693351
The main change here is the "enabled". Don't try to click the button
as long as it is disabled. This is critical because VisualEditor
takes a while to boot. The toolbar is already visible, but disabled.
Warning, untested! It makes sense in my head but I'm not sure if it
works.
Bug: T360026
Change-Id: Ib46d420a56effd4b4a0e48e2121106a830e5f51c
The ext.cite.referencePreviews module will transparently replace the
ext.popups.referencePreviews module after this patch. Configuration
stays in Popups for now, we can migrate it in later work.
CSS classes may be renamed in the future but this will be handled
separately since it could be a breaking change for on-wiki
customizations.
A lot of fancy footwork happens in this patch to emulate a soft
dependency on Popups. This mechanism doesn't exist explicitly in
either ResourceLoader or QUnit, so lots of workarounds are used, to
conditionally load the module and to dynamically skip dependent tests.
renderer.test.js is fully skipped for now, but can be wired up in
later work.
Bug: T355194
Change-Id: I0dc47abb59a40d4e41e7dda0eb7b415a2e1ae508
This CSS exists since I2ab47e7 from August 2014. The original idea
was to dim the default "General references" when you edit a <ref> or
<references> list in VisualEditor.
Steps to reproduce:
* Start VisualEditor.
* Edit a <ref> or <references> list.
* Edit the group.
* You will see the dimmed text "General references". This is not the
CSS in this patch, but the default styling for OOUI placeholders.
* Open the dropdown. The list will show a "General references" item.
It's not dimmed. This is where the CSS was meant to be.
The CSS class name in the OOUI mixin was actually changed from
"oo-ui-flaggableElement-…" to "oo-ui-flaggedElement-…" via I1abecd8,
just a few days later.
In addition the selector wouldn't work anyway for other reasons.
The dropdown is not inside the `.ve-ui-mwReferenceGroupInputWidget`
container any more but placed outside by the OOUI window manager.
And the selector's specifity is to low, at least since Ic57b3ff.
I argue it's not worth fixing it. Nobody missed it for 10 years.
Light gray text would be illegible anyway on the light gray/light
blue backgrounds used in the dropdown menu. Let's consider it dead
code and just remove it.
The class name doesn't appear anywhere else (any more):
https://codesearch.wmcloud.org/search/?q=flaggableElement
Change-Id: Ia802303737ba35cd4b14fae924b7227472f905fd
This can be quite confusing:
* A node does have attributes. One of the attributes is called
"refGroup", another one "mw".
* mw contains a JSON structure with just a few elements, most
notably a "body" and an "attrs" element. These reflect what was
originally written in the wikitext.
* mw.attrs reflects the original properties a.k.a. attributes from
the <ref …> or <references …> tag.
Deleting mw.refGroup doesn't do anything because the attribute is
called <ref group="…"> in the wikitext, not <ref refGroup="…">.
You can actually see this bug in action on all wikis: Go to a page
that uses references in non-standard groups, e.g.
https://en.wikipedia.org/wiki/Historic_Cherokee_settlements
Start VisualEditor. Find e.g. the [notes 1] reference. Edit it
and change the group from "notes" to "General references". Click
"Publish…" and "Review" your changes. The visual diff works because
it apparently uses other information. The wikitext diff is empty.
This is also what's saved: nothing. The edit is lost.
Bug: T359943
Change-Id: I798605d2fd60a6b8f317ec85a4e4d08fd245e084
* Include the README in generated JS docs.
* Tweak stray top-level files to explain their role. Note that the
wmf template forces these files to appear on the docs home page...
Bug: T358641
Change-Id: If421414340903991f50a06a76551bd7cd2904c5e
