https://en.m.wikipedia.beta.wmflabs.org/wiki/File:Test_2018-10-18.png is now displaying the fetched file description, with no funky section edit links.
I fixed the messages on beta English Wikipedia so that it's more obvious where it's fetching files from: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Log?user=Yatu&wpdate=2018-10-18&limit=7
I think I see the issue: the beta Commons URL is protocol-relative. When asked to fetch it, MWHttpRequest expands it to a http:// URL, but we no longer serve the site over HTTP. There is a 'Location:' redirect, but MWHttpRequest doesn't follow redirects by default.
I think I was wrong, it is pulling from the right repo, but failing to pull the description (I don't know why). I was confused because all of the on-wiki messages are customized to link to ommons.wikimedia.org even when the file is pulled from elsewhere :/ But with uselang=qqx, it is more clear:
That is pulling the file and description from the production Commons (https://commons.wikimedia.org/wiki/File:Banana.jpg?action=render), which is not running the new code yet.
Sorry about that.
Looks perfect now.
@Jdlrobson It happens in FileRepo::getDescriptionRenderUrl(), but I don't think it's feasible to add useskin= there. We'd have to pass it through a few levels of function calls, but more importantly, the foreign description is cached in File::getDescriptionText(), and that cache would have to be split by skin.
Actually, I don't think product review is needed for this change, either :)
(No QA needed)
(Better diff link, with fewer unrelated changes: https://en.wikipedia.org/w/index.php?title=Nightwish&diff=836341923&oldid=836326809)
Also, I don't think this is a new issue. It seems that the bug has existed for years. The bug reporter must be the first person ever to use special page transclusion (fairly rare and unknown feature) while triggering a CAPTCHA (which mostly happens to newbie users). :)
Fascinating. So, a few things normally happen when a user tries to save the page (and gets rejected):
There is a limit on the amount of content that can be generated by transclusions (the "unstrip post‐expand size"), and this limit is 5 000 000 bytes. If your transclusions are exceeding it, I can only recommend making them smaller (e.g. lowering the number of days for the list of recent changes) or splitting the pagae. While I'm not an authority on this matter, I am pretty sure that we're not going to raise the limit.
Certainly seems like we should keep the checkbox but change its label.
Wed, Oct 17
Indeed, as @DanielFriesen says this is already possible (and @Catrope just fixed a bug that made it not work for some messages: rMW8d1844704ad6: jqueryMsg: Don't fall back to simple parser when jQuery params passed). I documented that you should pass jQuery/DOM objects to achieve this at https://www.mediawiki.org/wiki/Manual:Messages_API#Parameters_2.
We've talked about this task for about 30 seconds in the planning meeting today, and @Esanders reminded me of a different possible solution for the specific use case of discarding your autosaved edits: changing the notification popup about restored edit to have a button to discard it.
Mon, Oct 15
I spent a few hours investigating this today. The problem with TemplateData editor and the exception are actually two separate issues, but both are caused by the wikEd gadget. @DePiep I am guessing you're using it since you have some configuration for it in your vector.js page.
Current coverage report: https://doc.wikimedia.org/cover/visualeditor/src/ce/
Sat, Oct 13
Additional related issue I found when debugging this issue: on file description pages for files from Wikimedia Commons (e.g. https://en.wikipedia.org/wiki/File:A5_Aarebruecke.jpg), the edit tab normally says "Add local description", and clicking it changes it to "Edit this page". It should remain unchanged.
@alexhollender Thank you, that's very helpful. I was able to find where we use the incorrect localisation message ( 'edit' instead of 'vector-view-edit'). I filed T206892 with some more details about this. Let's make this task just about the 'Edit' vs 'Edit source' distinction.
Fri, Oct 12
I hope that helps. I added a link to this comment in https://translatewiki.net/wiki/MediaWiki:Visualeditor-debugbar-testsquasher/qqq.
Known issue with the patch:
Hm, yeah, please do.
I've looked at extensions using the EditFormPreloadText hook and it turns out this problem can be reproduced on Wikimedia projects as well, so asking for QA review.
There is no REL1_32 branch yet, as far as I can see. I don't think it has been cut yet, so the patch in master should be automatically included in it.
The custom interface also caused issues with GlobalPreferences, thus the patch (see the parent task I added).
Looks like there is a separate task requesting that the preference be standardized (and Erik's patch seems to resolve it): T203988: On Special:Preferences>Search page, the descriptive text for each options should have the same font as other descriptive texts on other tabs
Running with debug=true, webconsole message in Chrome: "Uncaught TypeError: Cannot read property 'accessKey' jquery.js[...]" (in Firefox: "jQuery.Deferred exception: element is undefined [...]"). Need more? -DePiep (talk) 16:17, 10 October 2018 (UTC)
Thu, Oct 11
The issue occurs because two handlers for the Window 'scroll' event are executed in the wrong order:
- A: ve.init.Target#onContainerScroll – Changes the toolbar between "floating" and normal mode
- B: OO.ui.mixin.FloatableElement#position – Positions the dropdown relative to the toolbar
Wed, Oct 10
Thanks, that helps. I can see some erratic behavior when scrolling now.
I'll investigate it.
The name may be incorrect, but it really is named shiv, so who are we to argue? https://github.com/aFarkas/html5shiv#why-is-it-called-a-shiv
Yeah, that sounds right.
Also… when Parsoid parses a bunch of newlines in wikitext and outputs a bunch of <p><br></p> structures for them, it should mark the <br> node somehow so that we can ignore it in VisualEditor. Currently VisualEditor treats it as any other <br> tag and allows inserting content on either side of it (essentially, rendering it as two empty lines instead of one).
If we need to output <p><br></p> instead of <p></p> in the HTML we send to Parsoid, then I suppose we can do that.
I think Prateek mostly solved the problem with rGOJUaa86508242c4: FieldLayout: Add 'for' attribute to inline help label.
I can still reproduce in visual mode.
wgMinervaUserBlockInfo is not generated for anon users at all, exactly because of caching (anon users share one HTML cache, but each of them can be blocked separately). There was some bug about it that I can't find right now.
Here's the relevant code:
isReadOnly = mw.config.get( 'wgMinervaReadOnly' ), isEditable = mw.config.get( 'wgIsProbablyEditable' ), blockInfo = user.isAnon() ? false : mw.config.get( 'wgMinervaUserBlockInfo', false ), canEdit = !isReadOnly && isEditable && !blockInfo;
I guess it's not broken…