As already noted we were affected by this margin-top: 0; that was making the TOC a bit too much attached to the button:

• sorry if I introduced an ID for just the label: now replace with a non-unique Javelin Sigil
• tried to fix the margin-top thing

I can also propose another small change to adopt a sigil for the button label, so we don't need an ID.

We need more help on this. Never approved anything similar, I don't have enough experience.

Tried to add a lovely icon but still keeping the label toggling and the whole button selectable

I'm a bit confused (!) I thought there were no PHP changes on Rev 1414 and I approved it, but instead I now see that we have again PHP changes. It's unclear to me whenever the Diff I approved was "updated to reflect changes", or maybe I'm just totally crazy because of real life. Please share your opinion.

Hoping to be useful we can self-document this joining this group:

(This was already approved but I wait for another "Yeah land" since I changed a thing)

To fix this error:

(I will immediately hard-approve this lovely change as soon as we share whatever ACK like "Yeah let's log the planet" or "Yeah let's just show a user message")

OK the situation is a bit more clear now.

Interesting. I think this specific crash was not caused by a specific document, but it was probably caused by a specific nonsense request with a nonsense encoding.

In T15667#14211, @Sten wrote:

how many people use Phabricator/Phorge :-(

I basically completely trust speck if they say this works with TLS, and I verified this works without TLS. Tried with / without this configuration.

(I share the same question from Sten)

I'm 5% scared by this since in 8 months we may discover that $author could be an object and so an user may report our well-known exception in some cases. But, the method name is getAuthorString() so I'm quite sure that Evan Priestley already choosen that name for a reason, and so, probably the getAuthor() is always a string or null and nothing else, so it's nice to report alien things with an exception, as proposed here.

In D25428#12247, @avivey wrote:

• We don't use document.querySelector - we use JX.DOM.find, you can see an example in line 43

I love your change. Simple and effective and without impact on other parts.

celerity

Hoping to be useful, proposing minor things. Feel free to say "AAAH NOPE" :D

I completely trust Speck and Evan Priestley that already reviewed this in secure dot. So...

Restoring original author :) Thanks speck

Hi @Cigaryno thanks for this change but we are causing some confusion since the mentioned commit 40b272fa is not in Phorge (as reported by the kind @jmeador from Mozilla). I will try editing a bit. Feel free to review then.

So I'm 99.99% sure that $old and $new always are PHID=>title array and always with count($that) === 1 - whenever you rename a single photo or multiple ones. So, I see this as totally OK.

Interestingly I was able to reproduce the issue with this nonsense patch, in the hope to emulate an email plain-text generation, even if it's not the case:

For interesting reasons, I cannot, in any way, get an email about somebody renaming a single Mockup photo. And, my email preferences are like "email me for everything from every application" and email delivery is "email me about myself".

I'm now quite sure that $old and $new always are array, and each one consists in a single element with key PHID and value => title.

(I also cannot see T15665)

Also, I'm OK with the change also because of GDPR's principle of minimization. I mean, Phorge avoids to collect unnecessary data, and this is nice.

As a side note, it's possible that somebody in the world was using the Phone number feature in a way that was then integrated with their custom management system, accessing this information via plain SQL.

I've adopted PhabricatorPeopleUserEmailQuery as suggested.

Apply review tips

(Hide all inline comments or this is unreadable)

Small improvement thanks to review tip

In D25467#13458, @l2dy wrote:

I have verified the fix on Firefox. Are you sure phabricator/c0bdb5b4/core.pkg.css is loaded?

Interestingly this CSS change only has effects on Chromium 119 and it does not change anything in my Mozilla Firefox 118. Can you give a quick look?

So, no PHP changes? Interesting.

I see this change as safe since:

Thaanks! Over-tested intensively with NULL, 'asd', objects, aliens, lizards etc.

Impressing test plan :D Tested intensively. No nuclear implosions. Yuppie yeah! ✨

Note that I cannot see Task T15663

I'm not able to find #conduit in Matrix mozilla.org homeserver btw

(It needs to be quoted just in we.phorge.it since indeed we have a Tag called Conduit :D Sorry for that)

Nice! Thanks

Maybe we can mention the upstream commit, and we can amend to set their author information.

I wonder if they are aware that Phorge exists and that we are open to contributions :)

I will keep this change in my production for a while:

In D25441#12816, @aklapper wrote:

Where to find the test plan?

5. for CSS classes, it seems Phorge would use .collapsible-content instead of camel case

Follow review tips

In D25459#13138, @speck wrote:

Would there be a bunch of these lying around?

Ah! Thanks! I was not aware that it was a common practice:

I've tested this locally with:

Premising that I love your new list of PHIDs: