Page MenuHomePhabricator

Cannot edit header or footer of a WS Page ns page in Chromium based browsers
Closed, ResolvedPublic

Description

In the latest Vivaldi and Chromium browsers, a Wikisource Page ns page in edit mode, the header and footer is visible but not accessible. However, it works fine in Firefox 64. Please see the image in this link which shows the appearance of these two areas.
https://en.wikisource.org/wiki/File:Page_ns_cannot_edit_header_%26_footer_in_Vivaldi_and_Chromium.jpg
This issue is the same in the Windows and Linux versions of these browsers.

Event Timeline

Aklapper changed the task status from Open to Stalled.Jan 5 2019, 3:17 PM

When filing tasks, please always provide a link that allows someone else to try reproduce, provide a list of steps, expected outcome, and actual outcome. See https://www.mediawiki.org/wiki/How_to_report_a_bug . Thanks!

I had to google some text shown in your screenshot in order to find https://en.wikisource.org/w/index.php?title=Page:Houses_and_House-Life_of_the_American_Aborigines.djvu/141&action=edit

Cannot reproduce in Chromium 70:

Screenshot from 2019-01-05 16-21-28.png (1×961 px, 466 KB)

Please try in safemode (see https://www.mediawiki.org/wiki/Help:Locating_broken_scripts ) if the problem still happens.
If the problem still happens, please share your settings of https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-gadgets to get your page layout.

@Aklapper, I must have used a simple bug report form because the fields indicated in the tutorial did not exist.

This problem appears in the following versions: Vivaldi 2.2 and 2.3, Chromium 71 and 72. and it was confirmed by Vivaldi where they tried both browsers because Vivaldi is Chromium based.

The problem is the same in either Linux Mint or Windows 10.

I normally work in Firefox (v64.0 currently) where this is not a problem in either OS.

Also used the &safemode in edit mode and the problem remains the same.

Searched the gadgets and there is no option that deals with headers and footers unless you are referring to the the page edit options, where my settings are to display the headers and footers when opening a page for edit.

Aklapper changed the task status from Stalled to Open.Jan 6 2019, 4:23 PM

I must have used a simple bug report form because the fields indicated in the tutorial did not exist.

There are no "fields"; https://www.mediawiki.org/wiki/How_to_report_a_bug only explains what should be in a Description field.

Searched the gadgets and there is no option that deals with headers and footers unless you are referring to the the page edit options, where my settings are to display the headers and footers when opening a page for edit.

Ah, I found a setting called Horizontal layout when editing in the Page: namespace under "Editing" in the Preferences, in order to get your page layout and in order to reproduce the problem. Please include such things in your steps to reproduce in the future. :)

Alright, let's summarize:

Steps to reproduce:

  1. Use Chromium 71/72 or Vivaldi 2.2/2.3 browser
  2. Make sure to enable "Horizontal layout when editing in the Page: namespace" on https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-editing
  3. Go to https://en.wikisource.org/w/index.php?title=Page:Houses_and_House-Life_of_the_American_Aborigines.djvu/141&action=edit&debug=true (note the debug=true)

Expected outcome:

  • "Header (noinclude)" textarea field is shown in an appropriate size and can be edited.
  • This is possible when using Firefox.
  • This is also possible in Chromium and Vivaldi when not using "Horizontal layout when editing in the Page: namespace".

Actual outcome:

jquery.js?6a07d:3818 jQuery.Deferred exception: Cannot read property 'target' of undefined TypeError: Cannot read property 'target' of undefined
    at https://en.wikisource.org/w/extensions/VisualEditor/modules/ve-mw/init/ve.init.MWEditingTabDialog.js?025b1:65:12
    at https://en.wikisource.org/w/resources/lib/ooui/oojs-ui-windows.js?b395c:755:28
    at mightThrow (https://en.wikisource.org/w/resources/lib/jquery/jquery.js?6a07d:3534:29)
    at process (https://en.wikisource.org/w/resources/lib/jquery/jquery.js?6a07d:3602:12) undefined

Adding ProofreadPage project tag, as the textarea above is inside prp-page-container in the HTML source (feel free to correct me).

I'm wondering if T209939 is actually the underlying culprit here. Didn't think of that earlier.

@Aklapper It seems very likely. Chromium is a fork of WebKit (the Safari engine) which exhibits the same problem (cf. the comments in the other task), and the timing (at least roughly) of this problem appearing coincides with the deployment of the changes there.

PS. The 404 image is not related to those changes, I don't think. That's been an issue for a lot longer (I never reported it because it seemed just cosmetic). It may be a contributor in terms of making some javascript blow up with attendant run-on effects, but otherwise a separate issue.

AKlapper, thanks for your instructions. Will do so with future bug reports.

Just to note for future reference, there have now been reports of this happening also in the browsers PaleMoon and WaterFox, who both seem to be Mozilla/Firefox forks, as well as Internet Explorer (unspecified version). My own tests suggest the "Horizontal layout" option has no effect either way on this (turned it off, no change), except in so far as it probably enables the "Show header and footer fields" option just above it (not sure what the default is for that). And if the header and footer fields aren't displayed at all you will of course not be able to reproduce any problems with them.

Crossing fingers that this really is another side effect of the above linked Flex Box issue and will go away with the rollback of that.

Quick update from enWS: 1.33/wmf.12 is now live there and a quick check suggests it fixes the disappearing header and footer fields. IOW this probably confirms this was caused by T209939.

The bug is corrected and the ruler displays correctly in the footer. Thanks to all.

@Ineuw: For future reference, feel free to do so yourself by setting the status of this report to "Resolved" via the Add Action...Change Status dropdown.