Sat, Aug 10
Thank you, this indeed works!
This is done now (although I will probably have to deal with neverending MobileFrontend build failures). There are a few other cleanup commits related to this work, I didn't tag them all to avoid spamming the task: https://gerrit.wikimedia.org/r/q/topic:switch-transition-T228159
Fri, Aug 9
For comparison, expected behavior after the fix:
Looks like we just want to re-check the issues Rummana identified previously, which should now be fixed by David's patches.
I can reproduce it on that page, although it looks like the error message has been made shorter, so it fits now:
Jess, please have a look at the workflow I proposed: T208981#4868393
I checked myself that it works as expected again on https://cs.wikipedia.org/w/index.php?title=Za_%C4%BEud%C3%AD&oldid=17535284 (the fix is already live in production).
Several people from both teams checked this, and I just verified once again that the patch definitely fixes it.
@mobrovac Do you or anyone else from the team have any idea why this bug results in a blank page instead of redirecting?
T225936 has been fixed with a different approach, I don't think we're planning to work on this soon.
Another example from T230131:
Thu, Aug 8
To clarify, the problem wasn't with a stacking context, it was with using transform: …; to create it. The fix is to instead use position: relative; z-index: …;.
Just for a simpler test case, the problem also occurs on https://www.wikidata.org/wiki/Special:MyPage?action=edit&redlink=1
I am planning to work on this but can't promise when. If you're able to, feel free to send in a patch.
Somewhat related: in T229532 we're changing VE to also use the errors from the API (rather than our custom handling in some cases), which should help validate this approach.
Previously discussed in T162017, where we fixed handling of wiki markup for links, but not italic/bold. The italic/bold markup is much harder to handle, and we did not want to spend the effort into reimplementing parts of the wikitext parser just to create edit summaries.
|Before limit reached||After limit reached|
I asked to pull this into "Investigating" because I was very confused by the description. I think it was missing a "not", please check if that's right. Also, the issue is not reproducible at the given URL anymore, because Citoid was apparently enabled on the wiki. Is there another example?
This is apparently caused by the incorrect "rowspan" attributes on the last table row. I fixed them in this edit (https://cs.wikipedia.org/w/index.php?title=Speciální_čarodějnické_díly&diff=17549851&oldid=17549088&diffmode=source) and the table now works fine in VE. Of course it should have worked anyway, but I don't think we'll have time to debug this soon.
That's a different issue, T229734
Authors are returned in the wrong order by the API: https://en.wikipedia.org/api/rest_v1/data/citation/mediawiki/https%3A%2F%2Fwww.nature.com%2Farticles%2Fs41558-019-0527-4
Wed, Aug 7
Tue, Aug 6
Thank you for the detailed descriptions. I can reproduce the problems, and I recorded videos of them:
I updated the remaining "In progress" items to "Done" (almost all of them, although some are still waiting for QA/product approval) or "Not done" (T218545). Also changed the "Stalled" ones to "Not done" since I don't see us actually working on those.
Well, we did this, didn't we?
Mon, Aug 5
jQuery UI is still in use, for example in the Wikibase "Add links" inteface:
Sun, Aug 4
Thu, Aug 1
Ed suggested only changing the mobile wikitext header size to match mobile visual, and leaving everything else unchanged. I guess that's also an option.
The bug in Firefox causing that has apparently just been fixed: T224984: sticky Save button bar on Special:Preferences is jumping in Firefox
There is no longer a "Enable dialogs for inserting links, tables and more" preference, it has been merged into "Enable enhanced editing toolbar" (https://gerrit.wikimedia.org/r/351681).
Thanks. So the patch fixes this by making the links not be real clickable links. I must say I kind of liked them (for opening in a new tab when I wasn't sure if I found the right task), but losing them is definitely the lesser evil for me.
Sorry, but I don't understand if you're just documenting this behavior, or saying that it's wrong and should be changed?