Papa Beaver's Storytime done. Thanks

Well, to be honest, feel free to generalize the description and commit message to include both changes, since they are the very same thing

(Do you need a little help to split the changes in two diffs?)

Fix file attachment in Conpherence

Per https://caniuse.com/?search=-webkit-transform, transform without a vendor prefix has been supported since Chrome 36 in 2014.
Personally I'd prefer to simply remove old vendor prefixed CSS definitions but that would first require a shared understanding which dates (and/or which browser versions) are "too old" for Phorge code.
See "List of changes, most recent first" on https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix for a random example.

Thanks again. I've found this interesting, so, added in the code itself:

improvement thanks to dear @l2dy

Update after comments

Updates after comments

Thanks again @20after4 for the efforts.

This documentation is nice but unfortunately the feature introduced in 4d12d014fd9d never worked :( So documenting this as-is may create confusion, at the moment. Next steps:

Updates after comments

Wow 😍 looks promising (untested from my side)

A day later this turns out to be a rather stupid patch. Things should remain as is as javascript:void(0) nowadays may trigger CSP errors.

what will this do?

Also run ./bin/celerity map because it's JS

@Wikivu: Why?

are a bit esoteric

it works indeed for editing Maniphest tasks but not for Phriction documents.
I have been analyzing this "attach code" but it's too complex for me.
It seems that the content_metadata (with the attachedFilePHIDs) is correctly sent by the javascript, but it's not processed in the PHP, which makes it not attach the file object to the wiki page.

About the cursor: pointer;, yep it would be super-nice, but no need to create distinctions between mobile and desktop for that probably 🤔 let's always show it.

Premising that as web developer I'm really super surprised to have never seen in my life a native <summary> + <detail>, even in demos 🤔 I've never seen it in basic online courses for beginners ( https://www.w3schools.com/howto/howto_js_collapsible.asp ) - and that's surprising since there it would be nice; not in online forums with super-basic "spoiler" features (e.g. https://www.minecraftforum.net/forums/forums/forum-discussion-info/514283-how-do-i-make-spoilers-on-the-forum ) and there it would be nice, not in Bootstrap and not in MaterializeCSS (and it would be nice to have examples there to save some JavaScript); not in MediaWiki (because there, "esoteric" tags are disabled; so, since the beginning, every single wiki in the planet has 10 lines of JavaScript in their Common.js), etc.

we should probably toggle visibility by JavaScript

(About my "like Wikipedia" I mean https://en.wikipedia.org/wiki/Template:Hidden )

To have this a bit more flexible we should probably toggle visibility by JavaScript. (So, we can keep divs, and this makes the change also a bit more backward compatible probably)

In D25672#19381, @valerio.bozzolan wrote:

I love this collapsible on mobile since it saves a lot of scrolls, but I think the collapsible on desktop can just add confusion without clear benefits (since the desktop layout is not vertical, and saving vertical space does not help in showing more information). Probably this should only apply on .device-tablet and .device-phone, but not .device-desktop

I do not understand if we have some race conditions, or, if the __destruct() is not properly called because of a bug in PHP 8.3.8, which is possible but unlikely

I've seen this occasionally when trying to log in via a /bin/auth recover link with same stacktrace as above, PHP 8.3.8 on a Fedora 40 machine:

Visually marking this as "ongoing discussion for code changes" to keep historically nice error messages

I love this collapsible on mobile since it saves a lot of scrolls, but I think the collapsible on desktop can just add confusion without clear benefits (since the desktop layout is not vertical, and saving vertical space does not help in showing more information). Probably this should only apply on .device-tablet and .device-phone, but not .device-desktop

It makes sense since these are Phorge stuff, not Arcanist stuff. Thanks.

Agree with your considerations and tested 🌈

I'm assuming you're talking about dropping a file in the text area when editing the page, right? Not just dropping it when viewing a wiki page?

Presumably resolved by D25134.

Maybe in the future. At the moment it's just an extra unnecessary configuration.

I see you marked this question as Resolved. Was it?

It seems that the function PHUIDiffTableOfContentsItemView.php::render() is not called anymore as rPf21f1d8ab9e909b3e2c4dc07af7a358a8336902c removed $rows[] = $item->render();. I cannot spot another direct render() call anywhere else in the files instantiating a PHUIDiffTableOfContentsItemView.
However, PHUIDiffTableOfContentsItemView must define render() as it's defined as an abstract method in parent AphrontView.
After emptying render(), renderChangesetMetadata() does not have any other callers either, thus also removing it.

In D25658#19351, @avivey wrote:

grep for PHUIDiffTableOfContentsItemView in the codebase to see where we might be using this class.

❤️

somewhere before the this

maybe just add if ($value === null) { continue; } somewhere before the this?

grep for PHUIDiffTableOfContentsItemView in the codebase to see where we might be using this class.

If we can't find the problem, that probably means we have some dead code here that should be removed.

The called method renderChangesetLink() is not defined anywhere so static code analysis complains.
UI-wise I could not spot anything obviously broken in the "Paths" sidebar under ToC for a merged commit, though.

Is there something that's not working here?