It looks like $wgVectorTableOfContents = true; is the culprit. Turn it on, and everything's fine with the above patch; turn it off, and the error we're seeing appears. That config var is enabled for Beta.

This is strange: I'm getting that same error (the overlapping of the taps) on my local with both Vector and WikiEditor at current master (i.e. it's not related to this patch). But I can't replicate it on Beta.

Thanks! And sorry for the extra work.

Oh, I didn't know that! I've created T308087 to get it moved.

I've created a Phab project for the tool: tool-docs

Great idea!

This doesn't mean that we should give up on VE support, of course! But for now, these other bugs are more pressing.

Yes, I must admit the shortcut feature was a bit ill-defined and added without much design oversight. Sorry everyone! :-)

@nayoub good point, but yep we caught that one. Actually, it was a bug from T296447, in that the new section's groups never had their side border switched.

Moving this back to dev for the last bits.

Do we want the edit page to always be wide, or only if the Realtime Preview beta feature is turned on, or only if the preview pane is enabled? There was a comment in Slack about "the transition" being important, which makes me think there might be an animation involved.

That'd be great!

@nayoub don't forget to create a task for "Visual adjustments on handlebars". I think that's the last part of this ticket (the other bits now have their own tasks, for easier tracking).

@TheresNoTime thanks for reviewing and merging this! I actually forgot to update the commit message with this (new) task number (the one on it is for the parent task), so here it is for posterity: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiEditor/+/784084

I think the shortcut on Mac is Control+⌥ Option (you mentioned Command+Option above). Does that work?

I think that's the correct behaviour. T294977 is about making the preview pane automatically scroll to match the current editing position (which I think is what you're expecting there?).

I think I've figured this out. We're hiding the error message whenever entering manual mode, but actually should be doing so only on successful preview. i.e. I'd been thinking that we wouldn't want the error and manual bar to show at the same time, but that's actually valid.

It sounds like our approach here is going to be to scroll the preview area to the same percentage as the editing box. This can be inaccurate where there's a big discrepancy between wikitext height and rendered HTML height (e.g. large list of infobox parameters, only one of which is rendered; or a tall image, which requires only a single line in wikitext).

This is working now. No code changes required.

How often are users opening and closing the Preview window inside the Wikitext code editor?

What we're wanting to do here is to use this project as the triaging place: so that any Wikisource-related project can be added here, but after triaging it'll be moved to the correct other projects. There's no point in having this board be only for tasks that effect every Wikisource, because those tasks already have more specific projects to which they belong.

Thanks for your patience. We're really keen to try to sort out the actual problems with WS Export.

Okay, let's call this fine, and chase any new bugs separately. Thanks!

Since we've switched to OpenSeadragon for the image viewer, has this issue been resolved?

We'll talk about this task at the Wikisource Triage Meeting later today: https://meta.wikimedia.org/wiki/Wikisource_Triage_meetings#April_2022_meeting

All issues with scoring should be fixed now, with the new version of the tool.

We've switched to Symfony!

I'm afraid that's the problem this such generic project tags, no matter how these project tags are called. The more generic, the more it can become a dump ground for anything and nothing experienced on some Wikisource.

All follow-up patches are done for this task.

The #wikisource-api Phabricator project was poorly named. It's not about general API access to Wikisource. I've updated it and given it a better title of PHP-API-for-Wikisource.

@nayoub @NRodriguez Should the whole bar be dimmed during loading, or just the "Reload" blue text? The blue snake is not dimmed, and (at the moment) appears below the bar:

I'm happy to just merge this and keep an eye on things, if no one's got time to review it thoroughly.

Moving to current sprint as this is work from an existing task.

Hey @Samwilson where are we keeping track of these changes?

Sounds good.

i. Preview button in the Editor toolbar

My understanding is that no events are logged from Beta wikis. The four events logged so far are from testwiki.

I agree that we should be removed as maintainers from all those. Access to jarry-common was I think because the old svgtranslate code used something from there.

Ah great, looks good!

In addition to what @MusikAnimal says above, you can also test the timeouts by trying to preview a huge page (I find on my local environment previewing something big copied from Wikipedia works, especially if there are lots of images and InstantCommons is turned on). Also, adding a sleep(11) to ApiParse::execute() can help test a quick connection with a slow parse. The inverse can be done with browser tools for slowing the connection down.