I work for or provide services to the Wikimedia Foundation, and this is the account I try to use for edits or statements I make in that role. However, the Foundation does not vet all my activity, so edits, statements, or other contributions made by this account may not reflect the views of the Foundation. For my personal account, see @Deskbanana.
This is potentially very bad wikitext corruption that needs urgent investigation.
@ssastry Thank you!
This is so, so old that it's definitely obsolete.
I absolutely love the video, by the way. <3
I can't reproduce this, so I assume it is fixed. Please reopen if reproduction of the bug is achieved.
These buttons are going to be the wrong way around for someone no matter which way around we put them. Changing it around won't solve any problem, it'll just change the people affected by it. For example, the standard for a Mac is to have the primary action on the right, and the standard for Windows is to have it on the left. We mitigate this by colouring the button and giving the primary action focus.
Tue, Jun 20
It would be best to edit complex things like this in the wikitext editor, rather than the visual editor.
This is likely a problem with that template that you're using, but it's hard for me to say for sure.
@Jdforrester-WMF thinks that gadgets are meant to be able to do this, but it doesn't seem to work.
This may be an issue with shortcuts on non-Macs. Needs investigation.
Based on the above, closing as declined.
I just tried this on the beta cluster and could not reproduce. Is it still an issue?
A larger, grander solution to this would be our work on T52355: VisualEditor: Add support for editing templates' parameters as DOM elements, including supporting nested templates. I don't think investing a lot of effort in a one-off solution is the best use of our resources in this case.
In principle this is simple, but it creates a lot of issues for mobile; if a message is super long, and it's not truncated, it could take up the entire screen. Needs a lot of thought.
This seems like an edge case.
Mon, Jun 19
Generally, the flow for adding media like audio seems pretty decent. There are a few things that are a little odd, such as the preview showing as incredibly stretched, or distorting the image of the speaker (see below), but it does display correctly once it's saved.
- I can't reproduce the core problem; my shortcuts are different from those in the description, with no duplication.
- There are weird behaviours and inconsistencies:
- ^⌥v does not seem to do anything in Firefox.
- ^⌥v asks me if I want to switch to VisualEditor in Chrome.
I tried testing this in Chrome first, and the shortcuts are not displayed, although they do work.
Fri, Jun 16
We should get rid of this shortcut. ⌘+M overrides the minimisation of the window if there's styling to remove, which is a bad interaction pattern.
This problem was occurring for me when I used vagrant enable-role visualeditor. I tried a lot of things to fix this. In the end, it took a lot of trial and error, but I managed to find a workaround. I've listed the steps I took below for those that are vagrant noobs like me. :-) Maybe someone more knowledgeable can tell me whether some of these steps can be pruned, or whether it was a total coincidence.
Thu, Jun 15
I guess my issue is to do with T166953: npm::install: Maximum call stack size exceeded.
I'm getting this problem even if I turn off nfs_shared as recommended above. :-(
I can't reproduce this, so I'm going to assume that this had the same root cause as T167438: Incorrect surface highlights on Math equations and is now resolved.
I still don't understand the description of the problem. There is a bunch of assumed knowledge in the description that I do not have, and it's not even clear to me where I could go to learn it. How this relates to a user problem or specific action is not described.
I can't reproduce this problem; when I go to the revision in the description, everything looks fine.
Wed, Jun 14
@Shizhao Hi! I'm afraid I don't understand. Can you give me some more context?
Tue, Jun 13
I'm going to assume that this worked correctly at some point, and call it a regression.
Mon, Jun 12
This is broken in production.
@FDMS I'm new at this, so it's not clear to me what's going on here. Please can you add to this bug:
- The specifics steps to reproduce the problem
- What you would expect to happen
- What actually happens
Fri, Jun 9
This is now consistently unreproducible. It must have been a transient problem... albeit a particularly prolonged one.
Thu, Jun 8
Well, I can't reproduce this anymore.
This needs fixing quickly.
@Esanders Do you have any recommendations on this? The deployment to beta is upcoming.
Copying over one of my comments from one of the merged tasks:
Wed, Jun 7
VisualEditor being this badly broken on our test infrastructure warrants urgent investigation.
I can't reproduce this on the beta cluster. Is it still a problem?
Thanks, @cscott ! I've put this at the top of the column, so we get to it sooner.
I thought null edits and purging the pages were equivalent in terms of effects. Is that true? If so, it seems better to tell people to purge rather than add this functionality in, for the reasons mentioned by @TheDJ above.
Since this seems to be specific to a single page, lowering priority.
I can reproduce this... but only on the specific page that @Ryasmeen linked in her example.
It's very debatable whether this is good behaviour or not. On the one hand, we're telling them "anyone can edit" when they can't actually edit that page. On the other hand, a welcoming friendly introduction the first time someone tries to edit could be appreciated even if they can't actually edit that specific page.
Tue, Jun 6
I tested this, and it seems to be working absolutely perfectly. Closing as invalid; please reopen if this is still happening for you.
That shouldn't be happening at all. Needs more investigation.