Page MenuHomePhabricator

Selenium test "User should be able to log in @daily" fails with Quibble 0.0.37
Closed, ResolvedPublic


Quibble 0.0.37 changed some MediaWiki settings, notably setting $wgSecretKey.

The Selenium test User should be able to log in @daily now fails. After login and heading back to the Main_Page, the user is not logged in.

Can't call getText on element with selector "#pt-userpage" because element wasn't found

Can be reproduced with --run=selenium. And I have the same issue when running Quibble directly.

The test is straight forward:


it( 'should be able to log in @daily', function () {
    // create async () => {
        await Api.createAccount( bot, username, password );
    } );

    // log in
    UserLoginPage.login( username, password );

    // check
    assert.strictEqual( UserLoginPage.userPage.getText(), username );
} );

I suspect it is related to the introduction of $wgSecretKey :-\

Event Timeline

To track the root cause I have setup a dummy environment:

quibble --skip=all

Then deleted specs in tests/selenium/specs and amending user.js to just keep the failing test. I then ran git bisect against 0.0.35..0.037 using:

rm src/LocalSettings.php; quibble --skip-zuul --skip-deps --run=selenium

Which eventually leads to 2fbe953ef071885084d40104624e3f4cfb05c81b for T233140

2fbe953ef071885084d40104624e3f4cfb05c81b is the first bad commit
commit 2fbe953ef071885084d40104624e3f4cfb05c81b
Author: Antoine Musso <>
Date:   Mon Sep 23 11:33:01 2019 +0200

    Set $wgServer when installing
    CLI can not automatically detect the port the server listens on and thus
    need to be hinted by setting $wgServer. MediaWiki is also going to drop
    support for run-time detection of $wgServer (T232931).
    install.php is a maintenance script and as such supports '--server'
    which is then recognized to set $wgServer in the generated
    LocalSettings.php (confirmed up to REL1_31).
    Bug: T233140
    Change-Id: I5a3388cf8092d2a9baebfada813340cb99fc499d

Grabbed the mw-debug-www.log for two sessions, I have edited them to remove some variance making diffs slightly easier.



The Start request POST /index.php/Special:UserLogin are identical with:


With session cookie etc.

Then the test heads back to the Main_Page which is where we have a difference:

--- log/mw-debug-www.log
+++ log-bad/mw-debug-www.log
 Start request GET /index.php/Main_Page
+HOST: localhost:9412
 CONNECTION: keep-alive
 CACHE-CONTROL: max-age=0
 USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36
 SEC-FETCH-MODE: navigate
 ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
-SEC-FETCH-SITE: same-origin
+SEC-FETCH-SITE: cross-site
 ACCEPT-ENCODING: gzip, deflate, br
 ACCEPT-LANGUAGE: en-US,en;q=0.9
-COOKIE: wikidb_session=SESSION_5; wikidbUserID=2; wikidbUserName=User-0.11630502306183077-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n
 [localisation] LocalisationCache: using store LCStoreStaticArray
+[session] SessionBackend "ggjb0m8ithihk6q8tf5kf7r4peo90fqe" is unsaved, marking dirty in constructor
+[session] SessionBackend "ggjb0m8ithihk6q8tf5kf7r4peo90fqe" save: dataDirty=1 metaDirty=1 forcePersist=0
+[cookie] already deleted setcookie: "wikidb_session", "", "1539077208", "/", "", "", "1"
+[cookie] already deleted setcookie: "wikidbUserID", "", "1539077208", "/", "", "", "1"
+[cookie] already deleted setcookie: "wikidbToken", "", "1539077208", "/", "", "", "1"
+[cookie] already deleted setcookie: "forceHTTPS", "", "1539077208", "/", "", "", "1"

In both logs, the requests are made to But in the bad case, $wgServer is set to localhos tand Special:UserLogin redirects the user to localhost:9412. sec-fetch-site thus change from same-origin to cross-site, the cookie that has been set for is not recognized on localhost and a new session (anonymous) is created.

That is caused by install.php being invoked with: --server=http://localhost:9412 and the test suite being pointed to by MW_SERVER=

Thus Quibble should constantly use the same server.

Change 541769 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/quibble@master] Fix $wgServer to match MW_SERVER

Change 541769 merged by jenkins-bot:
[integration/quibble@master] Fix $wgServer to match MW_SERVER

Change 541811 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] docker: bump quibble to 0.0.38

hashar claimed this task.

Fixed in Quibble 0.0.38.

Change 541811 merged by jenkins-bot:
[integration/config@master] docker: bump quibble to 0.0.38

Mentioned in SAL (#wikimedia-releng) [2019-10-09T17:52:12Z] <hashar> Tagged Quibble 0.0.38 @ d22e0f55b earlier today to fix $wgServer # T235023

Change 544192 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/quibble@master] Release Quibble 0.0.39

Change 544192 merged by jenkins-bot:
[integration/quibble@master] Release Quibble 0.0.39