I believe this is fixed in HEAD of master now. Let us know if you're still seeing issues after upgrading.

oh, sorry. i saw it as " I had fix it a few hours before..."

Oh, sorry, maybe you misread? I said "I think I'll have it fixed in a few hours", meaning that I don't expect it to be fixed until later today. Unless you can pull changes from the future, it won't work yet. I'll update this task once things are fixed.

No, sir. i just upgrade to latest git commits. still can not do it.

This is related to changes in T11114. I think I'll have it fixed in a few hours.

Using arc diff is ok. but using the web form is not working at all

I think this is fixed now -- let us know if you're still seeing issues. Thanks for the very thorough report!

Using Chrome's network tab + disable cache, loading a page from the effected system shows that some rsrc requests take 55s each, during which chrome is "loading". Since they're static resources, I guess it's hard to notice when cache is on. Also, I don't think secure-dot is effected.

I wasn't able to reproduce any hangs or bad behavior from curl locally, but I think D17045 should cause us to select either compression or Content-Length, which is a reasonable thing to expect us to do.

I can see this too with an unknown version of Apache (Probably 2.2.15) over HTTPS, PHP 5.3.3 (built: Aug 11 2016 17:13:57) (w/o explicitly setting the header) :

curl -v 'https://..../res/defaultX/phabricator/e18bf0da/core.pkg.css'  --compressed > /dev/null
...
curl: (18) transfer closed with 170238 bytes remaining to read

Okay, thanks!

Oh, I think the issue is this:

I also can't reproduce this:

It's fine to consider it not a bug. Mainly I wanted to provide the info that it doesn't work for documentation purposes, in case anyone else runs into the same situation in the future. (We ran into this by trying to transition from a very old Phabricator installation to a new one with hosted repos, but with a legacy deployment setup that needs a non-bare repo copy, and didn't realize that Phabricator didn't fully support hosted non-bare repos.)

Why do you consider this to be a bug, then?

No.

Do we tell you to do this in the documentation anywhere?

This isn't a bug. Diff properties are not intended to be an arbitrary key-value datastore for API consumers.

When this is in stable and we upgrade I will have a reminder to keep an eye on logs and come back here

Although it's still a little early to be sure, we appear to have fixed the policy issue with unit test failures (D17029). Not sure if that actually impacted this or not.

D17037 should fix the documentation, it definitely wasn't very clear as written. That should land some time today and the docs should be updated in about 24 hours.

Omg. I feel so stupid now. In the guide I read, that should be interpreted as 8MB, but I guess it wasn't... Works fine now, thanks a bunch!
This can be closed..

In the first row of that table, it appears that you have configured a storage.mysql-engine.max-size of 8 ("8 bytes"). Try using 8388608 ("8 megabytes") instead?

Sure, here goes:

Can you browse to https://your.install.com/applications/view/PhabricatorFilesApplication/ and post a screenshot of the "Storage Engines" panel on that page? It should look a little bit like this (example from this install), although your settings are presumably different:

@epriestley I can confirm it works fine both on Mac and Linux for me. Thanks a lot for the finding and quick fix!

That Chrome change seems at least plausible as a root cause to me, but I definitely don't know enough about the Chrome internals to really hazard a guess.

See also https://code.google.com/p/chromium/issues/detail?id=473657 for earlier adventures in Chrome.

Here's my upstream report:

Chromez

@chad was that for me or for Chrome? 😄

@epriestley could it be related to this change? https://chromium.googlesource.com/chromium/src/+/a67debf9a9b78f60e7b10b5574ae4ceab49af31b%5E%21/#F2

Here's my reduced test case for Chome 55:

Hah, I was on Chrome 54, and my report above works. But after updating to 55, it no longer works. Something changed in Chrome. Not sure what though.

@chad I was replying but saw now your last comments, thanks @epriestley for narrowing it down. Interesting that I can repro on Chrome 55/Mac while you can't.

Basically, I've found:

Oh, it reproduces for me.

This appears to be a bug in Chrome, because this fixes it:

This doesn't reproduce for me on this install in Chrome 55/Mac, or any other browser. I'm assuming the issue you saw on this server was T11998 which was a local configuration issue.

Oh, I think the edit to the title here is actually misleading, and the author in this scenario never used "Request Review" (this action is only available if the author has previously used "Plan Changes", which they did not appear to in this scenario).

We have an identical ticket we plan to fix, definitely agree it's a bad experience.

Okay then, I thought this was a bug as it didn't seem to make sense for me as a user. Sorry for taking up your time.

This is expected behavior. We want to show an error instead of just vanishing the widget.

Thanks!

Thanks! Yeah, this was just some editing/testing slop on my part. Your suggested fix is correct.

I tried the following, specifically:

Please read Contributing Bug Reports and fill in all required information for a bug report. Thanks!

Yeah, seems to be a bug in Chrome. I would follow up with them. There is no correct means to style it in Ubuntu, just some hacks.

(Feel free to follow up with reproduction steps once you've sorted everything out)

You have to be up to date and you must provide reproduction information in order to file a bug report. Please use Ponder otherwise. Thanks!

Unclear if I can globally style these consistently across all browsers / OSs. But no one complained about my select styles yet.

Ubuntu - Mac

The bug seems to be with Chrome/Ubuntu, as it's inconsistent with their other platforms. Did you file a task in their upstream?

Does it reproduce here as well? We don't take bug reports from that install from non-admins. It's a forked install and not up to date.

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

outline: 4px solid red;

yeehaw

@tgr can we get confirmation on the browser, please?

@chad, it looks like we're just using the browser's default outline for buttons.

It's somewhat invisible in Chrome on Windows too (Behold my powers of image editing! And on a Windows machine too!):