I can reproduce but the title is so generic that makes this not actionable.

That's because we applied D25415

Cannot reproduce anymore / fixed?

Thanks again :) Giving right credits

Can't reproduce either - 🤷🏻‍♂️

@avivey hi!
I cant reproduce it. Is the problem still there?

Yeah, that might help (like specifically in the case of the Clone dialog) even though it wouldn't help with dialogs containing writable inputs. (E.g. on the repository page, click Flag For Later instead and press Shift+Tab and Escape.) A better fix would lie at https://we.phorge.it/source/phorge/browse/master/webroot/rsrc/externals/javelin/lib/Workflow.js$413 where either the getSpecialKey would need improvement itself to return true for these non-modifying keys, or it would need to be amended with a custom check in that regard. However, I don't know where that function comes from.

Probably something here should be expanded to check if the form contains at least a visible input without read-only

done...

Yeah, probably. I'll try to do it tonight.

Can this (I mean rPb445e1d80df9 )be backported into stable?

I can reproduce this, on an hosted Subversion repository.

It might not happen on any other card, because we might not be rendering Remarkup on any other card. Interesting....

So this is quite an edge-case:

• PhabricatorMentionRemarkupRule wants to give the mention a different color, depending on if the user can view the "context object", in this case the Project.
• There's an automatic rule, saying a member of a project can always view the project
• When loading the project for the hovercard, we don't bother loading all the member list
• When loading the user for the mention, we don't bother loading all its projects
• so data is not available at the rendering point.

DisableUsernameEditEventListener.php is the root cause.

Premising that we may want to rollback 328aee033fbd, probably this line is broken:

Ouch. Probably partially my fault. Feel free to escalate this as Task under Bug Reports - close this as obsolete then

I can't immediately reproduce with that version either. I'll try again later.
In the meanwhile:

• Try clearing your browser's cache
• Try updating Phorge to the latest commit
• Try disabling this extension: assets/DisableUsernameEditEventListener.php

I can reproduce this on master with basically any string search.

https://we.phorge.it just works fine. :L

2. Phorge installation

I can't reproduce this.
Which version of phorge/arc do you have (git log -1)?
How did you install the new Instance?

Interesting. This cannot be reproduced here in this website https://we.phorge.it? isn't it? I think no

:p

(Please edit file Visibility to make them Public :D It's another bug ihih - thanks! <3)

The exception throw out when I search text in search bar:

Please also include your exact search. I think you are searching by https://foo and that is unfortunately not possible without "doing this"

Ouch

Also note that we have a similar PhabricatorDataNotAttachedException in PhabricatorRepositoryCommit (via getRepository()) in downstream https://phabricator.wikimedia.org/T360714. It's without reproduction steps but sounds a bit similar.

Yeah sorry. That exception also occurred to me, before this change: https://we.phorge.it/transactions/detail/PHID-XACT-TASK-tuchgj42nb2ujtc/

I could not even reproduce but get an informative error instead:

Thanks avivey. Added this:

Look into the "is creation xaction" - we had a similar diff recently about creating Revision from raw diff that had a similar behavior.

Maybe unrelated. But after we fix PhabricatorCursorPagedPolicyAwareQuery, maybe we will find a crash test also for the first two lines:

Interestingly I was able to reproduce, but only creating 101+ tasks manually and going to the next page. So after that ?after=100 is introduced.

Heck yeah, changing phutil_nonempty_string() to phutil_nonempty_stringlike() there fixed the issue I had mentioned in a comment in T15737: Include information for installing required PHP version in Diviner docs.

I'm triaging as "wishlist" for now, but realistically - I don't believe will ever reach a point where we'll try to fix this -- see https://secure.phabricator.com/T13154 for discussion.

can confirm, https://we.phorge.it/D25342?id=1111 does show an error for me in an incognito window.

Probably, something should "Attach" these files by default to that Diff, during the upload phase.

A workaround is to make all files as "Public". I fixed for example the diff D25079: Trigger: Add Sound "Coin" by setting the audio file F1271256 as public.

Old upstream WONTFIXed this in https://secure.phabricator.com/T13154

Note that at least for Phame, http://phorge.localhost/J1 seems to always redirect to http://phorge.localhost/phame/post/view/1/blogpost/ instead of keeping the monogram in the URI.
So the baseURI is already wrong (not being http://phorge.localhost/ only) before concatenating the $ref (monogram and anchor).
As an ugly workardound, could probably make "Quote Comment" work by calling getObjectNamePrefix() in PhamePostRemarkupRule and LegalpadDocumentRemarkupRule and then use them in a preg_match to remove the monogram from the $ref but function is protected and... still ugly.

Can you try changing this line in your local install?