This test was leaving behind the black overlay, obscuring the test
results interface. Upon closer inspection, it appears not one part
of this test is doing anything that actually works.
* Assertion 1: `viewer.isOpen === false`
This is the initial and default state. Not essential for the test,
but so far so good.
* Prep for Assertion 2 & 3:
We call loadImageByTitle. One might think that this will set isOpen
to true, but, this isn't asserted. If one did, the test would fail,
because loadImageByTitle returns early from its first branch
in `!this.thumbs.length` and is thus a no-op, and adds nothing to
the test.
We set `location.hash = 'Foo'`.
* Assertion 2: `location.hash === '#Foo'`
Assertion 3: `viewer.isOpen === false`
Assertion 2 is meaningless because handling of hash changes appears
to be asynchronous. Perhaps not always, but at least the indirection
used in this codebase makes it async. Hence, the fact that it is
correctly normalised to '#Foo' is meaningless as the popstate
and hashchange event handler haven't been processed yet. If they
were, it would still be meaningless since viewer.isOpen was never
true in the first place and MMV's event handlers for popstate/hashchange
are guarded by `isOpen`.
* Prep for Assertion 4: location.hash = Bar
* Assertion 4: `location.hash === '#Bar'`
Idem.
* Prep for Assertion 5: Replace the viewer.loadImageByTitle function
with a function that performs a nested assertion.
This function is never called and its assertion never reached.
This is a textbook example why assertions should never be
nested. If you rewrite this in following with the advice from
<https://api.qunitjs.com/assert/verifySteps/>, we find that
the array is in fact empty by the end of the test() function.
```js
var seen = [];
viewer.loadImageByTitle = function ( title ) {
// assert.strictEqual( … );
seen.push( title.getPrefixedText() );
};
location.hash = …;
location.hash = …;
location.hash = …;
location.hash = …;
assert.deepEqual( seen, [ 'File:' + imageSrc' } );
// Actual: []
```
== Misc notes ==
The test ends with "#/media/File:Foo bar.jpg" set on location.hash,
and the black overlay covering the page. It seems that the hashchange
are async, and that the first in a given event loop tick "wins", with
later ones being ignored. Observing this with debugger/breakpoints is
hard given that each pause results in the effect not being observable.
console.log(location.href) at the end of the test shows hash='#',
but placing a debugger at the end of the test results in the hash
being "#/media/…" instead.
Exprienced in Firefox 117 on macOS.
Change-Id: Ib37bec1b3e67fcab1da89d23381a3adbb6312827
This makes the test report inaccessible in the browser. I'm adding
it at the module level given that nearly all test cases in this
file trigger it:
* "Progress"
* "Progress when switching images"
* "New image loaded while another one is loading"
* "Events are not trapped after the viewer is closed"
* "document.title"
```
- QUnit.module( 'mmv', QUnit.newMwEnvironment() );
+ QUnit.module( 'mmv', QUnit.newMwEnvironment( {
+ beforeEach: function () {
+ this.sandbox.stub( require( 'mediawiki.router' ), 'back', function () {
+ console.log( QUnit.config.current.testName );
+ console.trace();
+ } );
+ }
+ } ) );
```
Change-Id: I0cb7ed6c76d5547bcef9c183c9305b6fd08ec9eb
Avoid creating of Title object to get the "fixed special name" (which is
the localized name) and compare that against the local name of the
current page, just use the SpecialPageFactory to get the canonical name
(which is the english internal name, not the english visible name) and
compare against the list of canonical allowed pages (adjust the existing
list to the canonical names, that are "old" names in different cases)
Change-Id: Ia6f6574bf6e65c75f8977ff016feda6ecdca3776
The use of "HookHandlers" attribute in extension.json makes it possible
to inject services into hook handler classes in a future patch.
Bug: T271019
Change-Id: I57dac8d590b5afa7524000d93c8477a10148c052
Dots needs escaping
resources\mmv\model\mmv.model.Repo.js
129:11 warning Unsafe Regular Expression
security/detect-unsafe-regex
169:11 warning Unsafe Regular Expression
security/detect-unsafe-regex
The plugin does not like the backtracking for "https?", but that does
not looks like a performance problem when given long strings here.
Change-Id: Iac4c88b591c2e8ebb2ce037bbd99b774319a261c
Use localstorage to store MMV preference for anon and temp users,
use regular user preference for non-temp accounts only
For embed default to wikitext for temp and regular users, html
for anon users
Bug: T340534
Change-Id: Ic19e8a6b6fbdeb2c86be14a33a306dd0f3088b1b
On certain special pages, like Special:Search, MMV is
intended to launch anyway. The existing check, however,
assumes that those pages will actually be called that,
but in non-English languages, it's often something
different (e.g. Recherche or Pesquisar).
This then results in MMV not being present on those
pages in those languages, even though it was intended to.
The fix is to simply make sure to case both titles to
the local form and then compare them.
Bug: T323650
Change-Id: Iec01ddf4c1ea4ec5d9c42de5a6a3140470ad5052
