It returned to function again. Not sure why it wasn't working but good to see it working again.

In T15979#20270, @avivey wrote:

@Cigaryno which browser/OS are you using?

(I cannot reproduce anymore, now I see the very - ugly - native desktop notification of my environment lol; but it's difficult to note since I've configured my computer to disappear after 0.5 seconds - also maybe a common problem I guess)

The "Grant permission" button works for me on Chrome/Windows.

You are totally right, I've never seen native browser notifications too. For some reasons I've always confused Phorge's popup with these since they are quite similar in my environment

In T15979#20265, @valerio.bozzolan wrote:

Is there a possibility that you have a browser extension privacy-focused that automatically denies this permission?

Is there a possibility that you have a browser extension privacy-focused that automatically denies this permission?

Any error in your browser console?

Clicking on Send Test Notification, a notification shows up on the bottom of the screen, but this is totally unrelated to browser notifications.
After clicking on the Grant Permission button:

Can you share a screenshot after you click on that button?

Another related bug is that also referenced/attached files are kept on the old page. Maybe different bug report under same umbrella.

Let's promote to bug :D

The current workaround I'm proposing is just:

@taavi: Uhm, thanks! If you have a chance to test D25839 that would be great. :)

Digging deeper, the problem is specific to ProjectRemarkupRule::getObjectIDPattern. That returns:

Step 2: Remove irrelevant character class exclusions:

Disentangling that monster regex, step 1:

Indeed https://devina.io/redos-checker says the aformentioned regex is exponential time worst-case

I monkeypatched the code to print preg_last_error when the problematic preg_match returns null. The error is "Backtrack limit exhausted".

Thanks :)

Yep. I'm up-to-date with master as of filing the issue^^.
This textbox isn't a Remarkup field (it's actually a ConpherenceDurableColumnView, which doesn't even have a metadata field in the first place)
In normal Conpherence views, the "Upload file" button works just fine. (except as mentioned in Z1, where reloading the page erases the metadata field)

Thanks. Can you reproduce with "Upload file" button too? If yes, maybe sub-task of: T15106: "Upload file" in remarkup text fields should attach by default

This exception happens once $rule in the loop foreach ($this->getMarkupRules() as $rule) in PhutilRemarkupBlockRule::applyRules($text) becomes ProjectRemarkupRule. That's where it blows up.

This is becoming quite frustrating in my workplace in Torino. Let's start immersion mode.

The solution was to take direct children project and call $child->setParentProjectPHID($my_parent_phid).

Finally in my Phorge I can kill these milestones \o/

This is an issue in https://we.phorge.it/source/phorge/browse/master/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php . In getObjectEmbedPattern(), preg_quote($prefix) returns \# and the method finally returns (\B{\#([^.\s?!,:;{}#\(\)"'\*/~]+(?:[^\s?!,:;{}#\(\)"'\*/~]*[^.\s?!,:;{}#\(\)"'\*/~]+)*)([,\s](?:[^}\\]|\\.)*)?}\B)u.
Within apply($text), $text becomes null after that first preg_replace_callback, so the second call barks.

Yep. In all cases it's at least a full-table-scan on file_attachment. Probably a bit more RAM-efficient with the NOT EXISTS thing since it does not need to have all file PHIDs in memory.

My userbase is stellar in relentlessly clicking every button you provide them :P

(Wow. I've never clicked on that button in my life, also when working)

Thanks :) Interesting weird transaction.

I'd be worried about DB performance running such a query as our DB has dozens of millions of files... (This is basically SELECT COUNT(*) FROM file_attachment fa WHERE fa.filePHID NOT IN (SELECT f.phid FROM file); in my understanding?)

Unrelated but @aklapper I'm curious about the situation in WMF. If you can maybe report something like this:

I haven't looked at Phorge's internals much yet, but perhaps the user could unmark a task as duplicate, or have the "Close As Duplicate" box be prefilled with the task that closed it and let the user deselect that and choose another one?

Once we remove this, we'll need to handle this edge-case:

• I've closed a ticket as "duplicate of T1", but I was wrong and want to mark it as "duplicate of T2" instead (and say it's not a dup of T1).

Partially related to T15822: When a phriction page is moved, history should follow the page move

OK. Well, thaanks \o/

In T15872#18251, @valerio.bozzolan wrote:

About this:

unset LC_ALL + LC_MESSAGES=C

I think it's not safe since other LC_STUFF can still be read 🤔

About this:

This [LANG=C] is supposed to be the default for missing LC_stuff