In theory this could be a two-liner: Changing the last character of the $prefix, and in PhabricatorCursorPagedPolicyAwareQuery.php

- $map[$field->getFieldKey()] = $field->getValueForStorage();
+ $map[$field->getModernFieldKey()] = $field->getValueForStorage();

In practice that leads to: Unhandled Exception ("PhutilTypeExtraParametersException") - Got unexpected parameters: customfield, customfield.index.table, customfield.index.key

<tl;dr>: This is a mismatch between legacy field keys still used for paging, versus modern field keys.

Sorry, I mean this link:

I absolutely don't know what we are doing here since I don't know the supposed "Phabricator way" to interact with the DOM via JavaScript using its library.

@valerio.bozzolan I found the js section where with the listener for open/close the persistent chat. From there I can get element somehow (by ID I don't think it would be good, because it seems to be auto-generated (UQ3_0)) and remove the class "core-menu-item" and the invisible gear icon will no longer be clickable. If the chat is not minimized, we add the class back so we can see it and click it.

This is very probably a recent regression since I cannot reproduce on Wikimedia Phabricator.

This happens also with the Upload File dialog

Ah! I can reproduce exactly in this comment!

Got it! Nice catch!

In T15626#13393, @valerio.bozzolan wrote:

Thanks I'm trying to reproduce. Can you please help me in understanding "click to the left next to the up arrow icon"? I probably don't get "click the left"

Thanks I'm trying to reproduce. Can you please help me in understanding "click to the left next to the up arrow icon"? I probably don't get "click the left"

sometimes i can not reproduce the issue

Chrome 109 on Windows 7
No JS errors in console

Does not reproduce to me.
Which browser are you using? Are there any javascript errors?

FYI I proposed a partial patch in D25415 which makes the issue more contained at least.

I'm 99% sure that this only affects Phame and Legalpad. I tested in Audit, Maniphest, Paste, Pholio and Files without issues.

This situation could be improved even more doing:

I'm not able to reproduce anymore.

I think the problem here is that the command ./bin/cache purge --all does not reset the PhabricatorPeopleQuery cache.

Please share the output of this:

Probably, the "color change" should be handled as "expanded transaction" - whatever it means - so that it changes only after its related cause (status change to → archived) and not always as long as the current value is archived.

Thanks! Now the second step is, finding at least one file that is related to the generation of the above feeds / texts

I'm not able to provide a smart title for this Task :D Thanks for any help in this

We can continue the discussion in Task T15556 - thanks for reporting

• the setlocal isn't supposed to make a difference (it only applies the command string itself - ie if a file is named 🧆.txt.
• Setting E is more likely to cause this problem then to solve it...

I think these two are related here:

• https://secure.phabricator.com/T13060 (call setlocal in the master php process, so everything is always en_us)
• T15281 and https://secure.phabricator.com/T12071 (Env-vars are missing because of E)

(I'm able to reproduce. Had to apt-get install language-pack-hu for that...)

Is there a Task about this? if not, feel free to open that in Diffusion at least. I'm interested in seeing this fixed.

Ouch sorry renamed again since I forgot the discussion. Still an annoying bug and found your question.

I agree that non-string/null should be handled differently. I guess I don’t see the difference between null + strlen being used vs. the proposed nonempty_string/stringlike, and that making that change is explicitly acknowledging that casting is expected/intentional when it isn’t and instead the different types should be handled appropriately (your suggested long-term solution).

I'm pretty sure that any place where strlen is getting something that isn't a string (including int), that's actually a bug. In Phabricator code, strlen was only supposed to be used when expecting a string or null; All the places we now find aren't strings, are places where we were wrong about the type of the object.
Epriestley says something like that at https://secure.phabricator.com/T13588#257329 .

Honestly I do not love the idea of if(strlen($something)) to answer the question "Is this empty when casted to string?".

Wouldn’t this be better as a null + strlen check? It was originally a strlen I assume.

I don't think I intended to land this change.

Nice! I flagged you as Trusted Contributors. (and if a friend of yours is also able to create such beautiful bug reports, feel free to flag them as well by yourself :D)

Thanks for the quick reply. I updated the question with the backtrace and a shell reproducer

Thanks :) Please try to add more details in order to allow other people to reproduce this problem.