This is probably the fix:

It looks like the existing test cases in master fail on PHP 7.1, presumably because of T10929, so that needs to be fixed before I can fix this.

This rule is constructed very awkwardly and I'd sort of prefer to remove it entirely, but I think we can technically fix this without really disrupting things.

fails for my MacBook:

Thank you for replay.
Umm..., Reproduce with the same procedure on my environment.
It may depend on the client environment.

No problem, thanks for the report!

Thanks for a fast response!

Adding the file should fix this error, but we'll almost certainly break it again when we go to 800x800 without a test.

Basically, we routinely double the size of transforms. When we do, we also need to replace default-111x111.png with default-222x222.png so we have a fallback. We have failed to do this ~every time we've doubled things since it's impossible to know/remember, so getting test coverage seems like a good idea.

oh i see... so I just make one for now?

In D17295, we changed the "profile" transform to generate 400x400px images instead of 200x200px images. When we add or change a transform, we need to include a default result file for that transform which can be used as a fallback if the transform fails (most often because an install does not have gd, but possibly because of a corrupt image, inaccessible file storage, etc). That change didn't update the default result file, resources/builtin/image-200x200.png, so we were left with a 400x400px transform but a 200x200px unused default image that were not linked to one another.

Er, sorry, what mistake did we make again? I can’t find 400x400 ever
existing?

I think the upstream actions are probably:

I don't see a 400x400.png anywhere in builtin history.

I suspect the reproduction steps are something like:

How can we reproduce this locally?

I can't reproduce this:

I agree, pagination way below the fold is rather inconspicuous

hahaha, thanks... really easy to miss those

Bystander input: try page 3: https://phabricator.kde.org/source/krita/browse/master/libs/ui/?offset=200

I patched this and deployed it. I'll follow up on the internal report with details.

Thanks, this is fallout from an incident last night. The particulars involved instance and user details so the discussion was kept private. I'll fix this shortly.

(there are some other wierd issues in IE11, so I expect I'll clean up some of the UI issues I see).

We require reporters file complete steps to reproduce the issue. If we can't based on the information provided, it's still on you to provide an updated, more specific set of steps. Also, we don't support third party extenstions like sprint. Feel free to reproduce against a clean install on phacility.com

is there something I can do to help you? or some suggestions regarding the browser that better supports the tool?

I can't reproduce this.

On the 26th we will update the version to the new one, I have been told.

TEST:
Version Information

For my own reference, T12570 isn't exactly related but can probably be tested/fixed at the same time.

Stealing this since I think it's session/auth related, not profile picture related: I think the user has a legitimate picture, they just aren't allowed to download it since they have a partial session.

T8918 is related.

Please read and follow Contributing Bug Reports. Specifically this does not state which version of Phabricator you are running.

Is Arcanist saving information about files somewhere? or is it just a problem with the utf8 validator?

Please read and follow Contributing Bug Reports and Providing Reproduction Steps.

Bug reports require reproduction steps. See Contributing Bug Reports and Providing Reproduction Steps.

This is happening because my project directory not contains .jshintrc file

my .arclint file

The attached patch seems to fix the issue ... hopefully with no drawbacks. We gonna test that for few weeks.

It should give me warning if i am using string value for my id part.

i am trying this command
./bin/mail show-outbound --id <my-email-id>

Please provide complete steps to reproduce the error. Based on the information above I cannot reproduce anything.

Hmm ok. I think that I'm not usually listed explicitly as a reviewer, which means that Reviewers: #some_project_that_i_am_a_member_of doesn't include me. Would you be in favor of adding a new [Differential was reviewed by] field to Herald?

I don't think this behavior has changed. This has always meant "reviewers", not "reviewers who accepted the revision".

@chad Like I said I'm aware you guys don't support prototype apps, figured I'd just make someone aware of it, not looking to make it work right now.

Oh, Calendar is a prototype. :/

Do you mind verifying the bug on an up-to-date version of Phabricator?

You are now officially Pay2Win.

Yeah I just wanted to buy myself a badge.

Alright, I'm going to assume this was cache/ghosts until it happens to someone else since it seems like no reproduction case exists anywhere anymore.

No nothing like that but FWIW, it just worked when I tried to reproduce it again.

Maybe a simpler empirical test is, on the "Add Payment Method" page, does this work in the developer console?

(Also, do you run some browser extension like "disable all external Javascript so ads don't work"?)

Yeah.