Page MenuHomePhabricator

Need to reduce nsPage body edit box height in horizontal view
Closed, ResolvedPublic

Description

When toggling from lateral to horizontal edit form in Proofreadpage environment (nsPage into wikisource), #wpTextbox1 keeps its default height; this behaviour is unconfortable, since often the last part of text needs scrolling of the page to be edited, and image of the page scrolls on and disappears from screen.

I added a simple personal patch to reduce #wpTextbox1 height when choosing horizontal view, and to restore default height when returning into lateral view, but I think that this behaviour should be automatized.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 17 2016, 6:22 AM
Alex_brollo renamed this task from Need to reduce nsPage body edit box in horizontal view to Need to reduce nsPage body edit box height in horizontal view.Sep 17 2016, 6:23 AM
Alex_brollo updated the task description. (Show Details)
Alex_brollo updated the task description. (Show Details)Sep 17 2016, 8:21 AM
AuFCL added a subscriber: AuFCL.Sep 17 2016, 8:51 AM

@Alex_brollo Presumably you are aware that the default height is set (for both horizontal and vertical layouts) in Preference setting [[Special:Preferences#mw-input-wprows]]? Are you suggesting there ought to be two independent configuration values?

Yes, two independent settings would be a great solution IMHO. In the meantime, I'm using a patch: my global.js, but it's just a javascript exercise.

When switching to horizontal layout, the image height is currently set to $( window ).height() / 3 pixels; would the same height be suitable for the edit box? I guess the idea is to still leave 1/3 of the screen for the toolbar and other nearby controls. On my current screen that's about 230px, which is pretty close to what you're using @Alex_brollo.

Change 311929 had a related patch set uploaded (by Samwilson):
Reduce main edit box height when editin in vertical mode

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

Samwilson moved this task from Backlog to In progress on the ProofreadPage board.Sep 21 2016, 7:33 AM

@Samwilson @Candalua This interesting statement doesn't seem to run into it.source. Perhaps is some local javascript into it.source that kills it? Where is that statement writte, at extension level, or into some central javascript?

@Alex_brollo: It's in the ProoreadPage extension's code at /extensions/ProofreadPage/modules/page/ext.proofreadpage.page.edit.js

@Samwilson Since 2 days ago, when switching to the horizontal layout, the image becomes extremely big. Is it related to this change?
Tested on it.ws and en.ws, same behaviour.

@Candalua: no, this change is (partly) an attempt to rectify that situation. It has not yet been deployed.

Please, consider (or suggest developers to consider) to test much more deeply into wikisource new mediawiki releases.... these "attempts" are very frustrating.

Thibaut120094 triaged this task as High priority.
Thibaut120094 added a project: Wikisource.
Yann awarded a token.Sep 26 2016, 1:02 PM
Samwilson added a subscriber: Tpt.Sep 29 2016, 3:16 AM

@Tpt: Can you have a look at https://gerrit.wikimedia.org/r/311929 and see why the tests are failing? It doesn't seem to be related to this change.

Thanks!

AuFCL added a comment.Sep 29 2016, 4:16 AM

@Samwilson: If you are getting concerned over things like this then compare with this which occurred long before your changes.

@AuFCL yep, that's what I was thinking of. Can those errors just be ignored then? This patch can be merged, in that case.

AuFCL added a comment.Sep 29 2016, 5:25 AM

@Samwilson: technically Yes, as Change 311769 was incorporated into both 1.28.0-wmf.18 and 1.28.0-wmf.20 via (still open) T145724. Clearly this process has occurred in reality.

However politically and ethically I am not the person to ask. That would be either @Tpt or his nominee.

Tpt added a comment.Sep 29 2016, 8:55 AM

@Tpt: Can you have a look at https://gerrit.wikimedia.org/r/311929 and see why the tests are failing? It doesn't seem to be related to this change.

It happent during the refactoring of parser tests done in MediaWiki core two weeks ago (see T145724). I've a pending change that should fix this issue but the tests still fails on jenkins (I'm not able to reproduce these failures on local install). Change https://gerrit.wikimedia.org/r/#/c/313184/ may fix this issue.

@AuFCL yep, that's what I was thinking of. Can those errors just be ignored then? This patch can be merged, in that case.

While C.I. is not fixed I'm not able to merge other changes (gerrit prevents me from doing so). So I have to ask WMF staff to do merges (and it's time consuming...). If you want to see this change merged, please ask WMF staff

@AuFCL yep, that's what I was thinking of. Can those errors just be ignored then? This patch can be merged, in that case.

While C.I. is not fixed I'm not able to merge other changes (gerrit prevents me from doing so). So I have to ask WMF staff to do merges (and it's time consuming...). If you want to see this change merged, please ask WMF staff

WMF staff don't get any extra rights when it comes to submissions. Are you not able to do that yourself? If so we should fix that.

Change 311929 merged by Tpt:
Reduce main edit box height when editin in vertical mode

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

Finally fixed, thank you so much.

AuFCL closed this task as Resolved.Oct 14 2016, 12:18 AM
AuFCL claimed this task.

Thanks echoed. (Now please take care in case T146160 repeats this saga.)

AuFCL removed a subscriber: AuFCL.Nov 21 2016, 7:41 PM