Page MenuHomePhabricator

tgr (Tisza Gergő)



  • Clear sailing ahead.


  • Clear sailing ahead.


  • Clear sailing ahead.

User Details

User Since
Jul 5 2011, 9:11 AM (497 w, 3 d)

Recent Activity

Feb 15 2017

tgr added a comment to T4828: Suggest/propose possible duplicates when creating a new task.

Wikimedia ran a vote to find which problems are the most annoying to developers (not limited to problems with Phabricator) and this one was the most voted by far, with over one third of the participants voting on it.

Feb 15 2017, 9:27 AM · Maniphest, Wikimedia

Dec 10 2016

tgr added a comment to T11990: Outline is invisible on submit buttons.

Chrome 54 / Ubuntu 14.04. Tabbing through the comment edit form fields looks like this (screenshots are from

Dec 10 2016, 10:30 AM · Design, Bug Report

Dec 9 2016

tgr created T11990: Outline is invisible on submit buttons.
Dec 9 2016, 10:49 PM · Design, Bug Report

Nov 18 2016

tgr added a comment to T8345: Add task tabs for "Mentions" and "Merged".

@epriestley Tasks that are invisible to the user show up in Mentions as "Restricted Task". Is that intentional? In most other places such tasks are simply invisible. It is information leak (even if a very small one) and does not seem to provide any benefit.

Nov 18 2016, 2:18 AM · Restricted Project, FreeBSD, Maniphest

Mar 15 2016

tgr added a comment to T10584: Allow users to amend revisions they don't own, without commandeering them.

Here are a few use cases for experienced peers rebasing each other's commits:

  • I am reviewing a patch which is OK but I don't like some detail like naming or code organization. It is somewhat subjective and a nontrivial effort to change, so I don't want to force the patch author to do extra work because of my personal preferences, but I am sufficiently annoyed by it that I am willing to do the extra work myself, so I ask them if it's OK for me to change that, and do it. The real work in the patch is still theirs, and so is the responsibility, so 'commandeer' sounds inappropriate.
  • a patch needs some trivial change (easy rebase, comment typo fix etc), and the author is not immediately available (different timezone or maybe a volunteer who only has time on the weekends). Asking them to fix will cause unnecessary roundtrip delay and require the author to pay again the cost of resuming the context, setting up the developer environment etc. Also during the roundtrip time more code changes might be merged, requiring a less trivial rebase which might necessitate code review again. So it can be a lot of wasted time compared to just me doing the rebase/typo fix.
  • multiple developers working together on a complex patch which touches different parts of the system. This is typical enough in open-source software that the Co-Authored-By commit footer got invented, and would probably happen more at the WMF if support for it in Gerrit would not be so horrible.
Mar 15 2016, 5:43 AM · Differential

Feb 10 2016

tgr added a comment to T10262: Scramble file secrets when attached objects change their view policies.

Preventing images from being cached in public proxies/CDNs is a reasonable security precaution. I'm not sure what benefit Phabricator's URL randomization adds though. the standard approach would be to stream files through the application and require an authenticated session (with the appropriate permissions), and set something like Cache-control: private so that the browser will cache it but upstream proxies won't. That would fix all the issues enumerated here (except maybe the Safari one - not sure how that's related) while still keep the files unleakable. The only performance impact that would remain is that files cannot be cached in a CDN and they need to be streamed through a lightweight PHP process - that's nontrivial but not huge.

Feb 10 2016, 3:04 AM · Restricted Project, Restricted Project, Wikimedia, Files

Jan 3 2016

tgr added a comment to T5301: Inline Remarkup escaping.

Showing inline bash command snippets containing backticks seems like a pretty common usecase. The only workaround I found is to use the triple-backtick syntax but that takes up more space and breaks the flow of the text.

Jan 3 2016, 10:19 PM · Remarkup

Jun 29 2015

tgr created T8715: Removing blockers from a task with a lot of blockers is hard.
Jun 29 2015, 11:47 PM · Maniphest

Mar 25 2015

tgr added a comment to D11472: Replace the primary scrollbar with a fake one to prepare for a persistent chat column.

Shift+click on the scrollbar used to make the handle jump right there (Chrome/Linux but many other browsers/OSes too), that doesn't work anymore. Super annoying on very long pages.

Mar 25 2015, 4:05 AM

Feb 19 2015

tgr added a comment to T6884: Logging when a task has been marked as a blocker.

Not sure if this is related, but when adding T2 via the "Create subtask" link, not even T1 will show any notification. (example)

Feb 19 2015, 6:52 AM · Transactions, Maniphest

Dec 10 2014

tgr added a comment to T6700: Opening new tabs from search dropdown results.

A more specific use case: when I am adding a new task and am unsure whether it fits into a certain project, typing that project name in the search box and middle-clicking would be a convenient way of checking that project's description.

Dec 10 2014, 9:29 PM · PHUI, Search

Dec 9 2014

tgr added a comment to T6700: Opening new tabs from search dropdown results.

Project names, user names. Admittedly it's not something I would use often, but it did annoy me a few times.

Dec 9 2014, 11:15 AM · PHUI, Search

Nov 25 2014

tgr created T6640: [<number>] should not be interpreted as [X] in Remarkup.
Nov 25 2014, 7:26 PM · Remarkup
tgr added a comment to T4828: Suggest/propose possible duplicates when creating a new task.

For example, T397 is a duplicate here, but uses different words for everything -- "consider" instead of "suggest/propose", "dedupe" instead of "duplicates", "bugs" instead of "task": basic title-based search would not have found it. My experience was that this was the norm.

Nov 25 2014, 2:03 AM · Maniphest, Wikimedia

Oct 22 2014

tgr added a comment to T4863: Allow Workboard Cards to be customized for display.

One thing I was missing from Mingle and would be happy to see here is to assign CSS style changes to certain field values, e.g. have a "blocked" or a "taken" field and dim the card if it is set. (An alternative functionality to represent the same meaning in Mingle was rows, but as I understand Phabricator boards won't have that.)

Oct 22 2014, 2:45 PM · Projects, Wikimedia, Workboards
tgr added a comment to T4863: Allow Workboard Cards to be customized for display.
In T4863#80491, @qgil wrote:

The mockup in the description shows story points, and we have at least one team currently using Mingle that relies on story points being visible in workboards.

Oct 22 2014, 2:42 PM · Projects, Wikimedia, Workboards