|Declined||Jdlrobson||T111329 [GOAL] Page previews on mobileweb|
|Resolved||phuedx||T133947 [EPIC] Reduce bloat of Page Previews RL module(s)|
|Resolved||Jdlrobson||T144522 [EPIC] Hovercards technical debt and quality enhancements|
|Resolved||Jdlrobson||T67103 [EPIC] Hovercards: Test Coverage|
|Resolved||Jdlrobson||T133020 Unit test ext.popups.core.js|
|Invalid||None||T133055 Split ext.popups.settings.js in units|
|Resolved||phuedx||T133025 Unit test ext.popups.settings.js|
|Resolved||phuedx||T133054 Create browser test for add footer link in ext.popups.settings.js|
|Resolved||Jdlrobson||T133163 BetaFeatures test failure|
Merged the patch as this was blocking work and the test does seem wrong, but this needs following up.
- why did the tests for the core patch not fail? I thought we run the tests for all WMF-deployed extensions on core changes.
- it seems NewHTMLCheckField set the field data to null, which fails the isset test. That seems like wrong behavior from both NewHTMLCheckField (it should use booleans) and https://gerrit.wikimedia.org/r/#/c/280884 (it should not assume null is an impossible value)
So the real problem was that the test never called $form->loadData(). Before https://gerrit.wikimedia.org/r/#/c/280884/ that resulted in treating all field values as null, whether or not the field had a default value; after that patch the default value is used. (Not calling loadData is an error so the change does not affect correct uses of HTMLForm.) The assertions simply codified the wrong result.