Change #1227868 merged by jenkins-bot:

[mediawiki/extensions/CodeEditor@master] Make compatible with ResizingDragBar, remove jquery.ui

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

Change #1227790 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] jquery.wikiEditor: enable resizing drag bar without RTP

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

@Bhsd Is this working correctly for you with ProofreadPage Page NS pages? I'm sorry I didn't check properly earlier, but it looks like it might be a bit of a bug.

I think I've got a patch ready, but yeah I think it should be reverted to give us time. Sorry! I totally thought to test PRP but then failed to.

Change #1229438 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@master] Support WikiEditor's resizing drag bar for Page editing

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

Change #1229446 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Revert^2 "jquery.wikiEditor: enable resizing drag bar without RTP"

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

The above PRP patch I think should be okay without the WikiEditor one, although if both are merged for the same train that'd be best. (If it is a good patch, of course!)

I take it we want the resizing bar to be present even if the usebetatoolbar preference is false?

Change #1229438 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Support WikiEditor's resizing drag bar for Page editing

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

Change #1229446 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Revert^2 "jquery.wikiEditor: enable resizing drag bar without RTP"

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

In T393231#11544522, @Samwilson wrote:

I take it we want the resizing bar to be present even if the usebetatoolbar preference is false?

The plain <textarea> is resizable by default, so I don't think the drag bar adds value. The issue is only if CodeMirror 6 is used with usebetatoolbar=false. Not sure if that use case is worth the trouble to support.

In T393231#11544947, @SD0001 wrote:

The issue is only if CodeMirror 6 is used with usebetatoolbar=false. Not sure if that use case is worth the trouble to support.

How about adding CSS resize: vertical to .cm-editor when the WikiEditor toolbar is not available, just like the plain <textarea>?

Yes, you're right the browser resizing is fine. I'm not sure about making it vertical-only, maybe people like stretching it out to the side? (I know I've done that sometimes, and it feels like a lack with the WikiEditor resizing! But that's a separate issue.)

I think a fix is needed for the ProofreadPage case though, because I didn't properly test without WikiEditor enabled. I'll make a patch.

There seems to be a race condition when enabling CM6 without WikiEditor on a PRP page.

Change #1232093 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@master] Add resize bars between Page header, body, and footer

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

I've had a quick go at adding resize bars between the header, body, and footer, but it's not working yet.

I wonder if we should remove the resize bar again from Page content type? It's not simple getting it all working, and best case as things stand seems to be that we've removed the resizability for the header and footer.

The above patch is ready if anyone could have a look at it, but @Bhsd I'm not sure what the best approach is when toggling CodeMirror.

Could you include some method to prevent adding the drag bar and setting height?

WikiEditor is used in Convenient-Discussions and section editing tools (@Iniquity) together with MultilineTextInputWidget + autosize. This change completely breaks autosize (T415958) once .wikiEditor() is run for the input. I had to add a very cumbersome monkey patch to fix this. Yeah, we still treat WikiEditor for some reason as though it's only for ?action=edit pages or used everywhere uniformly, but see T362356: Make WikiEditor officially support use outside action=edit pages.

In T393231#11556360, @Samwilson wrote:

I wonder if we should remove the resize bar again from Page content type? It's not simple getting it all working, and best case as things stand seems to be that we've removed the resizability for the header and footer.

Sorry, I am quite unfamiliar with ProofreadPage. Do you mean that the header and the footer were resizable but now they are not because of the recently added resizing bar?

In T393231#11568976, @Jack_who_built_the_house wrote:

Could you include some method to prevent the addition of the drag bar and setting height?

How about treating the resizing drag bar as a WikiEditor module and only load it from mw.addWikiEditor() just like other modules (toolbars, dialogs, etc.)?

@Samwilson The changes introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/1229438 to modules/page/ext.proofreadpage.page.edit.js, and more specifically

		// Initialize the height of the text UI to match what the resizing bar has stored.
		mw.hook( 'ext.WikiEditor.resize' ).add( ( resizingBar ) => {
			$editForm.find( '.wikiEditor-ui-text' ).css( 'height', resizingBar.getResizedPane().height() );
		} );

are breaking proofreadpage editing layout in at least some situations. It adds a very low height constraint (in my case 448px), which makes it impossible to see the whole image:

I don't know for sure why it does that; I can't repeat logged-out, but it happens consistently to me including in safemode, if the account in question has recently edited a page with a horizontal editing layout. The height constraint appears to be directly related to the height of the text box in that layout.

I hope the intent was not to synchronise height in all editing layouts: this would be rather a bad idea given eg proofreadpage is made to work with a vertical layout.

(On FF 142.0, linux.)

@Alien333 You can resize the edit area using the dragging bar below, and the browser will remember the change next time.We are aware of some incompatibility between ProofreadPage and CodeMirror, but just need someone to work it out.

Do you mean that the header and the footer were resizable but now they are not because of the recently added resizing bar?

Yep, they previously had browser resize handles, and resizing them would move the whole lower part of the form down.

How about treating the resizing drag bar as a WikiEditor module and only load it from mw.addWikiEditor() just like other modules (toolbars, dialogs, etc.)?

Yes, that's what I've come around to thinking too. Then ProofreadPage can opt in if it wants to.

The patch r1232093 that I've started adds resize bars between the header and footer and body, but I'm having some trouble making it behave properly. I wonder if there's any point in having the bottom resize bar if we were to add three (to each of the form fields).

I'm so sorry that we didn't do enough testing before deploying this.

I hope the intent was not to synchronise height in all editing layouts: this would be rather a bad idea given eg proofreadpage is made to work with a vertical layout.

It does currently store the same height for use in all content types, but you're right that this is probably not the best. I think we should update the localStorage key to include the content type name (or perhaps only if it's not wikitext, so existing values are maintained).

For those of us who normally work without the editing toolbar (2010) in Wikisource, there is no handle to drag. In the Page: namespace, I've got 1 line of text in the header and footer boxes and four lines in the Page body box and the amount of the page image that's visible is a few lines from the middle of the page with no way of scrolling it, as the scroll function increases or decreases size.

This is unusable, and this patch needs to be pulled out of production and thoroughly tested before re-deployment.

@Samwilson Okay, then let's just (temporarily) disable the resizing drag bar in the Page namespace before next week's deployment and think of better solutions later.

Change #1235450 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/WikiEditor@master] jquery.wikiEditor.js: disable resizing bar on proofread-page

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

Yep, that sounds good, thanks for making the patches!

Change #1235450 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] jquery.wikiEditor.js: disable resizing bar on proofread-page

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

Change #1235477 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/WikiEditor@master] ResizingDragBar: convert to WikiEditor module

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

Change #1235477 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] ResizingDragBar: convert to WikiEditor module

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

Hello, I am very out of my element with all this code &c., to the point that I can't even tell if what I am complaining about has already been addressed in this thread lol so apologies if I am wasting time. Before being directed to this discussion, I described the issue(s) in detail here: https://www.mediawiki.org/wiki/User_talk:Samwilson#c-Psephos-20260129194000-Proofread_Page_window_adjustment_thing (I don't know what screenshots would do, especially since I don't have any "before pictures," but anyway.)

The thing I wanted to raise cause it seems to me to be likely the source of my mobile troubles (but I don't have the technical knowledge to test this theory) is: it's not only the addition of the resize bar that causes an issue; it is the changing of the default height of the edit window. So if you're undoing the resize bar while you keep working on this, Please put that back the way it was as well. Maybe that was already implied, part of the same change, idk. Thanks!!

The fix has already been merged and will be deployed this week. However, @Samwilson, maybe we should consider a backport given so many concerns arising?

Yes, sorry I didn't do so yesterday! And as the train is blocked (T413805) for a little while longer, backporting r1235450 to .13 makes sense I think. [Edited: fixed patch number.]

Change #1236862 had a related patch set uploaded (by Samwilson; author: Bhsd):

[mediawiki/extensions/WikiEditor@wmf/1.46.0-wmf.13] jquery.wikiEditor.js: disable resizing bar on proofread-page

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

Change #1236862 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@wmf/1.46.0-wmf.13] jquery.wikiEditor.js: disable resizing bar on proofread-page

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

Mentioned in SAL (#wikimedia-operations) [2026-02-05T00:57:56Z] <samwilson@deploy2002> Started scap sync-world: Backport for [[gerrit:1236862|jquery.wikiEditor.js: disable resizing bar on proofread-page (T393231)]]

Mentioned in SAL (#wikimedia-operations) [2026-02-05T01:00:07Z] <samwilson@deploy2002> samwilson: Backport for [[gerrit:1236862|jquery.wikiEditor.js: disable resizing bar on proofread-page (T393231)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-02-05T01:06:17Z] <samwilson@deploy2002> Finished scap sync-world: Backport for [[gerrit:1236862|jquery.wikiEditor.js: disable resizing bar on proofread-page (T393231)]] (duration: 08m 21s)

In T393231#11585692, @Samwilson wrote:

Yes, sorry I didn't do so yesterday! And as the train is blocked (T413805) for a little while longer, backporting r1235450 to .13 makes sense I think. [Edited: fixed patch number.]

Thanks! But I think we also want to backport r1235451 especially for users not enabling WikiEditor.

I just figured out how to create a backporting patch and have submitted it.

Change #1236865 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.13] Revert "Support WikiEditor's resizing drag bar for Page editing"

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

Change #1236866 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.13] Revert "Support WikiEditor's resizing drag bar for Page editing"

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

Change #1236865 abandoned by Bhsd:

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.13] Revert "Support WikiEditor's resizing drag bar for Page editing"

Reason:

wrong change id

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

Oops, yes good point! Thanks for creating the patch.

Change #1236866 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.13] Revert "Support WikiEditor's resizing drag bar for Page editing"

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

Mentioned in SAL (#wikimedia-operations) [2026-02-05T02:33:34Z] <samwilson@deploy2002> Started scap sync-world: Backport for [[gerrit:1236866|Revert "Support WikiEditor's resizing drag bar for Page editing" (T393231)]]

Mentioned in SAL (#wikimedia-operations) [2026-02-05T02:35:46Z] <samwilson@deploy2002> samwilson, bhsd: Backport for [[gerrit:1236866|Revert "Support WikiEditor's resizing drag bar for Page editing" (T393231)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-02-05T02:40:54Z] <samwilson@deploy2002> Finished scap sync-world: Backport for [[gerrit:1236866|Revert "Support WikiEditor's resizing drag bar for Page editing" (T393231)]] (duration: 07m 20s)

(thank you @Bhsd, as it turns out that is the thing I was trying to make sure was remembered but didn't know how to say)

Note: some users are still reporting major usability issues with editing window height, though it doesn't happen to me and I don't understand exactly what has been done. From this:

Something new has just lost my ability to resize the edit window in the Page namespace. I will have to stop editing until this is fixed, since I cannot see enough of the text at one time to be able to proofread. I had a properly sized window until a few minutes ago, when I started a new page without window resizing. This problem exists on other Wikisource projects in their Page namespace equivalent as well, not just here.

In T393231#11586089, @Alien333 wrote:

Note: some users are still reporting major usability issues with editing window height, though it doesn't happen to me and I don't understand exactly what has been done. From this:

The comment was left right after we backported the first patch but before we backported the second patch. I believe it should be fixed now.

The window itself is larger now, but I have not regained any ability to resize my editing windows. The corner tabs to resize them flash briefly when the edit page is first loaded, but then disappear, making them inaccessible.

The new jquery.wikiEditor.resizingdragbar module added in this change has a small problem: It assigns an ID for the resize bar, but it isn't necessarily true that there can only be one such bar in the entire document. Pinging @Bhsd as the owner of the change.

In T393231#11588636, @EncycloPetey wrote:

The window itself is larger now, but I have not regained any ability to resize my editing windows. The corner tabs to resize them flash briefly when the edit page is first loaded, but then disappear, making them inaccessible.

Are you using the WikiEditor toolbar? The textboxes have been unresizable if the WikiEditor toolbar is enabled since 5 years ago.

In T393231#11590352, @NguoiDungKhongDinhDanh wrote:

The new jquery.wikiEditor.resizingdragbar module added in this change has a small problem: It assigns an ID for the resize bar, but it isn't necessarily true that there can only be one such bar in the entire document. Pinging @Bhsd as the owner of the change.

Could you give an example? And what is the problem caused by this ID? The bottom resizing bar was assigned the same ID in previous versions too.

@Bhsd I have a script that makes use of the CodeMirror extension's API. it might add more than one editor to the same document. That's beside the point, however. The problem is that there must not be any two elements with the same ID. That is, IDs must be unique.

Not your fault though, now that I took a better look at the change. Sorry for the unnecessary ping.

By the way, I have another question regarding this note in the change message:

It is still automatically included in mw.addWikiEditor() on edit pages, but user scripts (such as Convenient Discussion) may decide to prevent it by directly calling $.wikiEditor().

Could you give an example? How to replicate mw.addWikiEditor's functionality without the if ( mw.config.get( 'wgPageContentModel' ) !== 'proofread-page' ) part?

Here is an example. If it would be helpful, I can also submit a patch to add an optional configuration object to mw.addWikiEditor() so people can opt out some WikiEditor modules.

@Bhsd Allowing configuring the behaviour of mw.addWikiEditor sounds good. Please do.

Change #1237500 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/WikiEditor@master] ext.wikiEditor.js: optional argument to manage modules

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

can this change be reverted, please? the content still cascades downwards with codemirror on. it was working fine before.

In T393231#11607649, @lettherebedarklight wrote:

can this change be reverted, please?

It has already been reverted in the Page namespace. We are aware that CodeMirror 6 is not fully compatible with ProofreadPage, and that is tracked in T380262.

In T393231#11607649, @lettherebedarklight wrote:

the content still cascades downwards with codemirror on. it was working fine before.

By the way, could you provide steps to reproduce your problem?

Change #1238988 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/WikiEditor@master] ResizingDragBar.less: only apply to resizable conditions

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

In T393231#11609686, @Bhsd wrote:

In T393231#11607649, @lettherebedarklight wrote:

the content still cascades downwards with codemirror on. it was working fine before.

By the way, could you provide steps to reproduce your problem?

just edit a page in the page namespace with codemirror on.

Change #1238991 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@master] Fix CodeMirror layout of header/body/footer fields

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

The resize bar appears on mobile, but it doesn't seem to do anything. Dragging the bar just scrolls up and down as it would with any non-interactive content.

To be clear, I don't think I will ever want to change the size of the edit window on mobile. I personally would prefer it to be removed than to have it actually resize the window.