I've tried to re-pull down to a new folder (and copy whole conf) content - the left padding bug still occurs on our browser (this is a super old installation of phabricator. we use phabricator internally since 1-2 years ago)

Sorry - not really sure how to describe the reproduction steps since it's a long deployment/upgrade steps. (in which I can mistake/skip the steps somewhere)

Offhand, I don't see any means of reproducing this. My guess is something was done/installed/updated/pulled incorrectly on your local install. Maybe delete phabricator and re-pull down.

Bug reports require reproduction steps.

T4752 is the detail on that.

When using local disk storage, the file is owned by the web-server user, not the daemon user.

All good now. Thanks.

Try that?

I get a new error when i run ./bin/storage upgrade:

Sorry everyone -- we don't actually read or write this table yet so I didn't add the schema, but the fact that bin/storage adjust would complain slipped my mind. D15744 will fix it and make sure bin/storage adjust is run as part of the test suite.

Revert to rPeef217216116 and wait for all this to blow over ;)

I get the same issue after upgrading:

Versions:
phabricator fbfe7304521464151986aee99d71fa07b20e0768 (Sun, Apr 17)
arcanist a2ab38df78a9d111459fab8d0d63e74d811edf29 (Sat, Apr 16)
phutil 1ea69b48e36d8411c329559b593772ae51a2e6f9 (Fri, Apr 15)

Actually, now that I think about it, the chunked representation overlays the underlying object storage system, so file.info by itself isn't enough - it needs to also extend file.querychunks.

Actually, now that I think about it, the chunked representation overlays the underlying object storage system, so file.info by itself isn't enough - it needs to also extend file.querychunks.

I think adding it to conduit is a good compromise; there's very little that's useful in the UI, and if anyone complains about something it should be easy enough to pin just using file.info. file.info already is very short anyway, so adding a fileHandle field should be relatively kosher, I think.

oh lovely, haha

Kicking this to the daemons should be like 20 lines of code, but we probably also need to flag the file as "queued for deletion" in the UI in the meantime and prevent you from interacting with it, which touches a few other interfaces, so this isn't completely trivial.

Turns out that because all spaces were archived, repositories did not get an space assigned to them, explaining the error. After I re-enabled S1, I saw a box for selecting the space appear.

Yeah we should fix that, for sure. Thanks for digging into this.

Ok, Whoops. I toyed with it a bit earlier and created a space, then had the balls to archive it. I unarchived it and everything starts working again: Repositories get shown again in the Diffusion menu, old broken repos stay broken, but new repos can be edited just fine.

Have you set up Spaces?

Forgot to add a piece of the log, this may help:

2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: [2016-04-16 19:52:16] EXCEPTION: (Exception) Transaction ("PHID-XACT-REPO-zsj42jcwxpqm2z5", of type "core:space") requires a handle ("") that it did not load. at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:310]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: arcanist(head=master, ref.master=737f5c0df976), phabricator(head=master, ref.master=dd1023e5a8f8), phutil(head=master, ref.master=1ea69b48e36d)
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #0 <#2> PhabricatorApplicationTransaction::getHandle(NULL) called at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:335]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #1 <#2> PhabricatorApplicationTransaction::renderHandleLink(NULL) called at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:806]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #2 <#2> PhabricatorApplicationTransaction::getTitle() called at [<phabricator>/src/applications/repository/storage/PhabricatorRepositoryTransaction.php:492]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #3 <#2> PhabricatorRepositoryTransaction::getTitle() called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:429]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #4 <#2> PhabricatorApplicationTransactionView::renderEvent(PhabricatorRepositoryTransaction, array) called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:173]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #5 <#2> PhabricatorApplicationTransactionView::buildEvents(boolean) called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:220]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #6 <#2> PhabricatorApplicationTransactionView::buildPHUITimelineView() called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:200]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #7 <#2> phutil_escape_html(array) called at [<phutil>/src/markup/render.php:157]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #8 <#2> phutil_escape_html(array) called at [<phutil>/src/markup/render.php:119]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #9 <#2> phutil_tag(string, array, array) called at [<phabricator>/src/view/phui/PHUITwoColumnView.php:167]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #10 <#2> PHUITwoColumnView::buildMainColumn() called at [<phabricator>/src/view/phui/PHUITwoColumnView.php:103]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #11 <#2> PHUITwoColumnView::getTagContent() called at [<phabricator>/src/view/AphrontTagView.php:152]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #12 <#2> AphrontTagView::render() called at [<phabricator>/src/view/AphrontView.php:222]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #13 <#2> AphrontView::producePhutilSafeHTML() called at [<phutil>/src/markup/render.php:133]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #14 <#2> phutil_escape_html(PHUITwoColumnView) called at [<phutil>/src/markup/render.php:189]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #15 <#2> phutil_implode_html(string, array) called at [<phabricator>/src/view/page/PhabricatorBarePageView.php:58]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #16 <#2> PhabricatorBarePageView::willRenderPage() called at [<phabricator>/src/view/page/PhabricatorStandardPageView.php:195]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #17 <#2> PhabricatorStandardPageView::willRenderPage() called at [<phabricator>/src/view/page/AphrontPageView.php:46]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #18 <#2> AphrontPageView::render() called at [<phabricator>/src/view/page/PhabricatorStandardPageView.php:841]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #19 <#2> PhabricatorStandardPageView::produceAphrontResponse() called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:615]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #20 <#2> AphrontApplicationConfiguration::produceResponse(AphrontRequest, PhabricatorStandardPageView) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:246]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #21 <#2> AphrontApplicationConfiguration::processRequest(AphrontRequest, PhutilDeferredLog, AphrontPHPHTTPSink, MultimeterControl) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:149]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #22 <#2> AphrontApplicationConfiguration::runHTTPRequest(AphrontPHPHTTPSink) called at [<phabricator>/webroot/index.php:17]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #23 phlog(Exception) called at [<phabricator>/src/aphront/response/AphrontUnhandledExceptionResponse.php:20]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr:   #24 AphrontUnhandledExceptionResponse::setException(Exception) called at [<phabricator>/webroot/index.php:21]

This stuff pops up after requesting a broken repositories config page. Also, the fact that a repository first needs to have a commit inside is not of influence, as is the fact that the initial visibility should be "Administrators only". You don't even need to change the value. I'll edit the task to provide a simpler reproduction step.

Looks like this was caused because my upgrade didn't upgrade all the way to HEAD (for some unknown reason :S ).

Yea, so I think the path forward is to check the version of WS and to add some docs about it in the aphlict changes, and just the general updating guide.

From IRC, this may be an issue with older ws (0.7.1) except that I also have 0.7.1 locally. But we should possibly upgrade / recommend upgrading / something like that.

I also tried swapping the ".key" and ".crt" but that gave me the same error as using a bogus file.

Other stuff I tried:

I can't immediately reproduce this...

A terrible workaround is to reload the page before editing.

FWIW, I briefly attempted to fix this while fixing T9348 and gave up.

From IRC, the HTTPS server didn't even start up (no port in netstat). So my first guess is that there's some 'error' handler we need to install, and that should tell us what the issue is (bad SSL key / weird Node stuff / who knows what).

Got it, thanks guys.

I'm 100% fine with that, I have no idea if there's some ugly interactions here, just wanted to chime in that we were affected too. The average skill level of users interacting with Phabricator makes the workarounds not a big deal in general (although I think an administrator can lock users out of the necessary IE settings to turn off compatibility mode)

T6547 was the other task, which points to a conversation on GH which no longer exists.

I vaguely remember these headers really not being very simple last time this came up, too, although maybe I'm misremembering and can't immediately find the discussion.

I think the incidence of this is so low (and should continue to fall in the future) that it's not worth bringing upstream.

Did you guys know that Microsoft is offering a FREE upgrade to Windows 10!
[ Schedule Upgrade NOW ] [ YES! ] [ W-o-w ] [ Reserve Your Windows 10 Today ]

I don't know if @epriestley thinks we should force the header at the PHP level or not. We get roughly 1 report of this per year. Win7 was EOL'd in Jan 2015, so I'm surprised people are still installing it fresh.

This only affects badges awarded before we began tracking who awarded them. Badges is a prototype application, and I don't think it's worthwhile to maintain code to do something nicer in this case, since the number of affected awards is maybe in the realm of 200 worldwide for all time, of which 80 are on this install.

The meta header causes all IE versions to re-render the page twice, incurring a performance penalty.

Yeah, we're also affected by this... it's mostly a non-issue since no one really uses IE but IE11 renders incorrectly in IE7 compatibility mode since the Phabricator server is determined to be in the intranet domain.

Thanks for looking into this @epriestley!

(@eadler's retitle of this bug is fine and I agree that [Merged] should be a stronger action than [Changed Subscribers], I'll make a note about this on T8952.)

When a group of transactions makes several changes, we guess at which change is most likely to be interesting and include that change as the action in the subject line.

The issue may be more general than the new title, but this is more actionable (I think).
Note that I don't work for Phacility.

You can either solve this by not sending such emails when a task is merged (but they you don't notified of merged tasks which is bad), or by having a dedicated subject / body for merged task notifications, which then:

1. solves this bug
2. improves the UX since you now get a notification email that actually reflects the action that happened

I really don't think this task should be closed. This is a user experience bug, independently of any underlying good reason there might be in the implementation.

T9412 might be helpful in understanding this in the future.

You're getting this cause a task was merged, not because of the changed subscribers. The logic roughly looks like if (get mail for any reason) { send entire email; }. If you look at the full headers you should see a list of 'mail-tags'. If you're notifications are set to email for any one of those tags you'll get the email.

It looks like the changed subscribers results from a merged task, so maybe this case is not handled?

Thanks for the report! I think D15719 should fix this; it should be available in master later today and stable in about 24 hours.

Yup, though I want to point out in this case the default IE 11 install on win7 forces compat mode on intranets. so it's more a case that your administrator needs to force it off, or you need to do it yourself to get phab working.

For completeness, see http://stackoverflow.com/questions/26346917/why-use-x-ua-compatible-ie-edge-anymore

IE7 and IE8 were end of lifed in January. I think most sites wouldn't work anymore with Compatibility Mode on. If a administrator forces it on, it's on. Not much we can do.

This comment was removed by the ghost of Christmas past.