Possibly related: T6469: Make it more clear which Workboard Column is 'default'

This just sounds a lot like "I ran rm -rf /var/repo/X/ and all the data for rX vanished" to me, which is completely expected and should be predictable.

None of the repository replication code is even written, though. What behavior do you expect today?

When we migrate our repository hosting to Phabricator, I plan to setup multiple repository hosts for sufficient redundancy. In this case, I would expect the new hosts to clone the repositories from a read-only slave.

Suppose you have a hosted, active repository and do this:

Just a word to confirm the issue is solved in the new stable release.

Thanks! The moving of the host was I think my main point that clarified it for me.

The steps to reproduce are quite simple:

Well, specifically what you were doing, and what issues were caused after. Like moving tiers.

Ok, if you feel this is a bug report, can you list the steps to reproduce the core issue in the description?

If the repository is hosted elsewhere then Phabricator isn't the canonical source, and the other system would be responsible for data anyway.

The problem here is that things will mysteriously stop working. Let's say that I refer to rXabcdef in a comment and then later mark rX as archived and replace my repository tier. Anyone who later clicks on the rXabcdef reference will hit an error.

That's what I mean by "I must be missing something". What data is lost if it's hosted elsewhere?

Even if that means data loss?

My expectation is "archive" means "mark as deleted" in Phabricator.

I disagree that this is the expected behavior, especially if this occurs on hosted repositories (which I can't confirm because I don't have any). If this occurs with hosted repositories, then archived repositories will be forever lost when replacing the repository hosting tier.

I'm missing something I think, this sounds like expected behavior with a reasonable workaround. What's the bug?

test:

• test script:
  test.php490 BDownload
• dumped POST:
  test.txt.gz9 KBDownload
• run:

php test.php 31 && tail test.txt
php test.php 30 && tail test.txt

In T10264#160688, @epriestley wrote:

Does changing window to 31 actually fix it for you?

Does changing window to 31 actually fix it for you?

Still hang...
dumping decompressed result shows input was truncated.

Thanks for verifying the fix!

I can confirm it now works properly for me (5.6) at HEAD.

From IRC, I think it sounded like this wasn't really a bug so much as a confusing UI (expecting to type one thing when the UI wants something different), exacerbated by the lack of "Browse" working. I'm just going to realign this to be "make browse work".

I think this is now resolved for PHP 5.6 at HEAD of master.

I don't believe we've ever supported this.

For context, I'm trying to convert some projects over to use milestones. Previously we were just using several independent projects. What I'm trying to do is change the default column in the milestone, so I can bulk move tasks from a workboard column in the 'old' project, and have them land in the right place.

Never mind, that patch doesn't work.

Yeah, I'd like to avoid that "simple workaround" of 200 lines of spaghetti if I can, since I'd guess this task is going to go through 50 more rounds if I have to implement that.

This comment seem to indicate 5.6 indeed broke file_get_contents("compress.zlib://php://input"). I didn't delve much into the proposed workaround yet but it might give a hint of what's going on.

Alright, thanks. Both you and @ppggff have PHP 5.6, I'll see if I can reproduce with 5.6.

@epriestley yes, pretty much the same ones :

[Sat Feb 20 09:04:56.337247 2016] [:error] [pid 5801] [client 86.219.113.93:56185] PHP Warning:  file_get_contents(): cannot represent a stream of type Input as a File Descriptor in /home/w4w/domains/REDACTED/phabricator/support/PhabricatorStartup.php on line 144
[Sat Feb 20 09:04:56.350142 2016] [:error] [pid 5801] [client 86.219.113.93:56185] PHP Warning:  file_get_contents(compress.zlib://php://input): failed to open stream: operation failed in /home/w4w/domains/REDACTED/phabricator/support/PhabricatorStartup.php on line 144

Ubuntu 14.04
Apache : 2.4.16
Php : 5.6.12-1
Php being through mod_php

@dpatou Do you have errors in your error log similar to the ones @ppggff describes?

Oh, thanks for advise. I'll try to fix!

So your client is sending an HTTPS request, but $request->isHTTPS() is false?

I use nginx for reverse proxy in front.

To clarify, you are using HTTP for Phabricator but HTTPS for the notification server? If so, why have you made this (unusual) configuration choice?

@epriestley Reverting both 5e375482 and 8269fd6e make me able to clone normally again.

Ah cool, good to know. Thanks for the quick fix!

Yeah, I came to approximately the same conclusion. Save + restore on the scroll position appears to be a complete fix as far as I can tell.

Invalidating the cache is trivial, but I think <code> is used to style code blocks and has a bunch of different rules (e.g., block formatting) already associated with it.

Yeah, either closing other open menus or allowing menus to be stacked on top of each other.

Yeah closing anything else open seems to be what most other applications do.

Here's an example in Maniphest where menus will overlap if you open them all (up to three in this case):

What is your expectation of what should happen here? This doesn't seem like a Workboard issue, just an issue with menus in general. Should we just automatically close any open ones if you change your mind and open a different one?

So I looked into this and it is the call to area.focus() in the setSelectionRange method in https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/core/TextAreaUtils.js (unsure what line, my view of this file is plaintext here) that causes the scrolling. I removed this line and it seemed to have the expected behavior but who knows what other problems removing it may cause.

I'd be cool with moving to <code> semantically anyways, but imagine this is a bit harder since we'd have to invalidate all Remarkup cache?

Not that I'm aware of today. (Caveat: I've only used Phabricator in desktop webkit-based browsers.)

Does this cause any concrete problems in any user agent?

Thanks, I'll see if I can figure out what's going on in Chrome.

Yep, Chrome on Kubuntu.

@epriestley Thank you, sir!

On OSX, I can't reproduce this in Safari or Firefox, but it does reproduce in Chrome. Are you also using Chrome?

Presuming resolved, but yell if I missed anything.

Caches should be purged, let me know if you're still seeing issues? D15311 will fix the underlying problem, and should promote and deploy in the next 24 hours.

Great, thanks @epriestley!

¯\_(ツ)_/¯ @epriestley

I'll clear the caches on your install and disassociate the {icon} rule from the Macro app. I think the original idea was that {icon} is silly nonsense like Macro, but {icon} has proven to be both silly nonsense and a super serious useful business tool.

The icon syntax probably started as a "fun" feature, which would make sense to dump in Macro...

The existing thing issue is caching issue - for privately hosted installs I'd say "clear the caches", but you can'd do that on phacility (Needs db access).

Is this the only case of remarkup syntax that is tied to having an app enabled? This should really be documented in https://secure.phabricator.com/book/phabricator/article/remarkup/.

Yeah, I don't think it used to be like this ~1 year ago.

This came up in IRC a week or two ago, so I've looked.
It was always there.

Weird, whyyyyyyyyyyyyyyyyyyyyyyy.

the {icon foo} syntax is part of the Macro app, so it's disabled.

Our instance is "hyper" BTW if this helps.

Yes, Macro is uninstalled.