Page MenuHomePhabricator

Print/export default state is now indeterminate: *Settings.php problem?
Closed, DeclinedPublic

Description

print/export and expand/collapse issues

This may be a result of https://gerrit.wikimedia.org/r/#/c/83591/

Seen on beta labs as of Oct 2.

See browsers in screenshot displaying from left to right:

  • Print/export collapsed on initial page load
  • Print/export expanded on initial page load
  • Expand/collapse navigation controls not loaded in page

Version: 1.22.0
Severity: major

Attached:

print_export_issues.png (582×910 px, 157 KB)

Details

Reference
bz54886

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:34 AM
bzimport set Reference to bz54886.
bzimport added a subscriber: Unknown Object (MLST).

The screenshot has me a little confused.. what exactly is wrong? When I visit http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&mobileaction=toggle_view_desktop I see the collapsed print/export section.
If I open it and refresh page it remains open.

I'm not seeing what exactly is the bug here? Does it effect a certain browser only?

I just reproduced the issue manually in Firefox by doing this:

Some of the resulting pages have the Print/export dialog open, some have them closed.

When doing this with automated tests in particular, I also often see a case where the expand/collapse styling is not loaded at all. We have broken this before in similar ways.

I just tried this various times and it always seems to work for me...
If they are not collapsed at all that sounds like the JavaScript isn't executing for some reason - either due to a JavaScript exception somewhere or the JavaScript not running.

You will get inconsistent behaviour with the print/export between tabs if in any of those tabs a menu is toggled open or closed as the menu's are supposed to be sticky.

See screen shot at bottom of the page from the end of the automated test: https://saucelabs.com/jobs/160816806c254073ad48cca43849400d. The expand/collapse javascript is not in the page.

This test with the result above ran today in beta labs for Firefox: https://wmf.ci.cloudbees.com/job/browsertests-en.wikipedia.beta.wmflabs.org-linux-firefox/360/testReport/(root)/Print_Export%20menu%20Expand%20and%20Collapse/Print_export_section_collapses_after_it_is_expanded/

At no time in any of these screen shots or repros has the user clicked on Print/export. I can reproduce this manually, and in the automated tests, and we have a history of breaking the expand/collapse functions.

Change 87198 had a related patch set uploaded by Cmcmahon:
Print/export open by default on test2wiki. see Bug 54886 for beta

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

Change 87198 merged by Zfilipin:
Print/export open by default on test2wiki. see Bug 54886 for beta

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

I was able to reproduce this on my machine.

I have executed this test 5 times:

$ bundle exec cucumber features/print_export_menu.feature:4

4/5 times it broke because the print/export menu was collapsed.

$ bundle exec cucumber features/print_export_menu.feature:4
Using the default profile...
.F

(::) failed steps (::)

expected visible? to return true, got false (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/print_export_menu_steps.rb:13:in `block (2 levels) in <top (required)>'
./features/step_definitions/print_export_menu_steps.rb:11:in `/^Print\/export section should be expanded$/'
features/print_export_menu.feature:6:in `Then Print/export section should be expanded'

Failing Scenarios:
cucumber features/print_export_menu.feature:4 # Scenario: Check for Print/export section Expanded

1 scenario (1 failed)
2 steps (1 failed, 1 passed)
0m7.363s

1/5 times it passed, because print/export menu was expanded:

$ bundle exec cucumber features/print_export_menu.feature:4
Using the default profile...
..

1 scenario (1 passed)
2 steps (2 passed)
0m8.831s

I will post the results from the javascript console.

Created attachment 13453
firefox javascript console log when the test passes - print/export is expanded

Attached:

Created attachment 13454
firefox javascript console log when the test fails - print/export is collapsed

Attached:

I have uploaded two firefox javascript console logs, when the test passes and when the test fails. Let me know if anything else would be useful.

(patched linked was 'just' a browsertest change)

Jon: Do Zeljko's javascript console logs help you diagnose this?

One theory - is the Vector extension still deployed on that server? If so it should probably be removed as the functionality was removed from it to here and if this code exists twice it in the instance you are testing against it will indeed break.

I'm still unable to replicate this and nope the console logs shed no light...

do the Settings.php files need updating?

/config/mediawiki-config/wmf-config$ grep -r 'Vector' *
CommonSettings.php: require( "$IP/extensions/Vector/Vector.php" );
CommonSettings.php: $wgVectorFeatures['collapsiblenav'] =
CommonSettings.php: $wgVectorFeatures['simplesearch'] = array( 'global' => true, 'user' => false );
CommonSettings.php: $wgVectorFeatures['expandablesearch'] = array( 'global' => false, 'user' => false );
CommonSettings.php: $wgVectorUseSimpleSearch = true;
CommonSettings.php: if ( $wmgVectorSectionEditLinks ) {
CommonSettings.php: $wgVectorFeatures['sectioneditlinks'] = array( 'global' => false, 'user' => true );
CommonSettings.php: $wgVectorSectionEditLinksBucketTest = true;
CommonSettings.php: $wgVectorSectionEditLinksLotteryOdds = 1;
CommonSettings.php: $wgVectorSectionEditLinksExperiment = 2;
CommonSettings.php:if ( !$wmgEnableVector ) {
CommonSettings.php:if ( $wmgUseMicroDesign || $wmgUseVectorFooterCleanup ) {
CommonSettings.php: $wgVectorFeatures['footercleanup']['global'] = true;
extension-list:$IP/extensions/Vector/Vector.php
InitialiseSettings.php:'wmgEnableVector' => array(
InitialiseSettings.php:'wgVectorUseIconWatch' => array(
InitialiseSettings.php:'wgVectorShowVariantName' => array(
InitialiseSettings.php:'wmgVectorSectionEditLinks' => array(
InitialiseSettings.php:'wmgUseVectorFooterCleanup' => array(

They should not need updating (but I submitted a patch to clean them up a few days ago at https://gerrit.wikimedia.org/r/#/c/87731/).

Change 90547 had a related patch set uploaded by Cmcmahon:
only run on test2 until Bug 54886 resolved

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

Change 90547 merged by Zfilipin:
only run on test2 until Bug 54886 resolved

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

(In reply to comment #19)

Is this still happening?

a cursory glance shows that the Print/export menu is (for me as anon at least)

  • expanded on test2wiki
  • collapsed on mediawiki.org
  • expanded on beta labs

I haven't really investigated what controls this, or why Print/export is different than other left-side nav menus.

I can't reproduce. Are you visiting these pages with cleared cookies? (Or in private browsing mode?)

The behavior should be the same on all sites:

  • First portlet has no header, is always expanded and non-collapsible
  • Second portlet is collapsible, but expanded by default
  • The remaining portlets are collapsible and collapsed

(And the collapse state is remembered across page visits in cookies.)