wgPageParseReport is empty on preview / section preview
Closed, ResolvedPublic

Description

The new config var wgPageParseReport is empty on preview or section preview. The old new limit report inside the html as hidden comment was also added on preview or section preview.

This was helpful, if you try to get the counts down and just check if your changes help something by pressing preview instead of save the changes.

https://gerrit.wikimedia.org/r/#/c/299693

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 5 2016, 2:42 PM
Umherirrender added a subscriber: aaron.

Change 303309 had a related patch set uploaded (by Aaron Schulz):
Show wgPageParseReport on page previews too

https://gerrit.wikimedia.org/r/303309

Change 303309 merged by jenkins-bot:
Show wgPageParseReport on page previews too

https://gerrit.wikimedia.org/r/303309

Umherirrender closed this task as "Resolved".Aug 8 2016, 3:06 PM
Umherirrender assigned this task to aaron.

If I understand correctly, Parser profiling data is now a JavaScript variable that can be found within the HTML source of the page. Is there still a way to access this normally from a Page preview without cracking open the source?

(Also, it seems like this change was made too discreetly, as besides myself@Wiktionary I have found at least two other queries as to the whereabouts of Parser profiling data on Wikipedia: 1, 2)

Johan added a subscriber: Johan.Aug 18 2016, 4:42 AM

This has been marked for inclusion in Tech News. How would you best explain this in one to three sentences?

Johan moved this task from In current Tech/News draft to To Triage on the User-notice board.

Is anything happening with this? The parser profiling box also allowed the mw.log() feature in Lua to output from usage on actual pages via the regular page previewing function. This seems impossible now, making the debugging and development of Scribunto modules much more inconvenient.

I've also been asked about this and had to track down the code changes to reach here. I am very confused about why the human-readable limit report was removed. @aaron Was this actually intentional?

Apparently it was not intentional. Aaron committed one change (299693) which caused the limit report box to be empty, and then another one, referencing this bug (303309) which caused the box to be removed entirely. Neither change mentioned the removal of the limit report in the commit message or release notes. Legoktm, who merged the second change, confirms that he did not realise that the feature was totally broken. Aaron probably neglected to test it with the PerformanceInspector extension disabled (it is disabled in production).

Change 316207 had a related patch set uploaded (by Legoktm):
Re-add human readable parser limit report

https://gerrit.wikimedia.org/r/316207

Change 316207 merged by jenkins-bot:
Re-add human readable parser limit report

https://gerrit.wikimedia.org/r/316207

Zdzislaw added a subscriber: Zdzislaw.EditedOct 31 2016, 7:57 PM

thanks for re-adding the human readable parser limit report :)
unfortunately, in the restored version of the report, the scribunto(Lua) limit report is still missing, which are also written as a js variable, eg:

(window.RLQ=window.RLQ||[]).push(function(){mw.config.set( {
    "wgPageParseReport": {
        (...)
        "scribunto":{
            "limitreport-timeusage": {
                "value": "0.026",
                "limit": "10.000"
            },
            "limitreport-memusage": {
                "value": 626231,
                "limit": 52428800
            },
            "limitreport-logs": "'''æsthetic''' (''esthe′tyk'') estetyczny.\n"
        },
    }
} );});

is it possible to restore also the scribunto(Lua) report limits?? - This is very useful info.

Z.

Ankry awarded a token.Nov 2 2016, 8:30 PM

@aaron What is your plan for resolving this?

Change 320237 had a related patch set uploaded (by Bartosz Dziewoński):
Allow extensions to use ParserLimitReportPrepare/ParserLimitReportFormat again

https://gerrit.wikimedia.org/r/320237

Gilles reopened this task as "Open".

Change 320461 had a related patch set uploaded (by Bartosz Dziewoński):
Revert "Move NewPP limit report HTML comments to JS variables" and followups

https://gerrit.wikimedia.org/r/320461

Change 320237 abandoned by Bartosz Dziewoński:
Allow extensions to use ParserLimitReportPrepare/ParserLimitReportFormat again

Reason:
Reverting in https://gerrit.wikimedia.org/r/320461 instead.

https://gerrit.wikimedia.org/r/320237

matmarex added a subscriber: Ankry.Nov 8 2016, 9:45 PM

Change 320461 merged by Bartosz Dziewoński:
Revert "Move NewPP limit report HTML comments to JS variables" and followups

https://gerrit.wikimedia.org/r/320461

Change 320522 had a related patch set uploaded (by Bartosz Dziewoński):
Revert "Move NewPP limit report HTML comments to JS variables" and followups

https://gerrit.wikimedia.org/r/320522

Change 320522 merged by Bartosz Dziewoński:
Revert "Move NewPP limit report HTML comments to JS variables" and followups

https://gerrit.wikimedia.org/r/320522

matmarex closed this task as "Resolved".Nov 8 2016, 10:26 PM
matmarex removed a project: Patch-For-Review.

Reverted on master, and backported the revert to MW 1.28. I don't think that this loss of functionality is acceptable, especially caused by a patch aiming to add support for a new beta extension. I've reopened T110763 so that it will be reimplemented properly.

@Suzukaze-c @Njardarlogar @Zdzislaw @Ankry I am not working on a backport to wmf branches, because this is a non-trivial change, so this will be deployed to Wikimedia wikis per the usual schedule next week, 15-17 November 2016. In the meantime, please verify that the limit report behaves as expected again on https://en.wikipedia.beta.wmflabs.org/.

@matmarex I have done some tests on betawiki - the limit report is generated properly (with scribunto limits and logs ) - thank you!

Z.

Suzukaze-c awarded a token.