I can't reproduce this. Here's what I did:

• Launched Chrome (47.0.2526.106).
• Clicked "Edit Blocking Tasks" on this task, and several other tasks.

I got the expected result here and elsewhere.

I've also noticed this does not happen on every task (though it is certainly more than a few)

I am not able to reproduce this on this install or my local install. Can you provide more specific steps for us to reproduce. Or can you find a task on this server that produces the issue?

I don't know what about these tasks is unusual. The tasks I noticed this on were created two months ago and only today did I want to connect them together. From a user standpoint all I'm doing is opening the tasks and clicking on the edit blocking tasks link, and then I see only this in the javascript console:

Uncaught Error: JX.initBehavior(map): behavior(s) not registered: phabricator-object-selector
JX.$E @ core.pkg.js:2
JX.initBehaviors @ core.pkg.js:173
(anonymous function) @ core.pkg.js:230
JX.install.statics._complete @ core.pkg.js:188
JX.install.statics._poll @ core.pkg.js:184

I'll try some random bugs on your server to see if I can find one that's similar, but is there any other debugging information that I can collect? Does the js trace imply any possible odd values on the task that I can check for differences between tasks that work and tasks that don't?

I don't know offhand what debugging information you can collect. No one else is reporting it and we can't reproduce it. This generally points to something environmental on your server (not Phabricator itself).

Yes, the trace implies your entire environment is unsound. RocketLoader (T9716), mod_pagespeed (T4854) and other technologies which rewrite page content and Javascript can sometimes cause this, if you have any of that stuff enabled.

Oh, where does the trace say that?

Oh, sorry, I was agreeing with you ("points to something environmental").

The trace implies that resource delivery isn't working (the selector behavior isn't available). If this was actually true, we would expect all Javascript and CSS was completely broken.

Since resource delivery is broken for only one resource (and on only one install, and neither of us can reproduce it on multiple hosts) that points at an environmental issue. If this was a celerity/delivery issue, we'd expect widespread CSS/JS breakage; if this was a map issue, we'd expect it to reproduce easily; etc.

Ok, thought I missed some magic strings or a trace posted elsewhere.

The server side of this is a fairly boring RHEL 7 setup. It's doing nothing other than running Phabricator, and so it has no other server side modules installed in Apache other than the minimums required to run Phabricator. My browser is also pretty boring; nothing extra added except for Postman. I've set up some creative and full featured web stacks in my day, and this isn't one of them.

It sounds like the onus of debug is on me, and I honestly don't care that much since I can just bag the tasks and write new ones (seeing as this doesn't affect all my tasks). But perhaps you can save me some time by suggesting the right way to drive conduit to manually create the blocking task edges?

For posterity, opening the "Edit Blocking Tasks" link in a new tab did work, and that's good enough for me.

Sorry we don't have more ideas for you.

Also for posterity, I discovered that I was able to take a task in which this link works as expected and break it simply by assigning it to myself. Removing the assignment to myself and forcing uncached page refresh did not unbreak the task (so now I seem to have another one in permanent workaround state). This is still not a very detailed reproduction scenario, but maybe if someone hits this, it will help hone in on the problem.

Hi, I am also getting this issue on a relatively clean build of Phabiricator via bitnami image on Google Cloud VM, using Firefox and Safari. It happens whenever I choose any existing task and click on 'Edit Blocking Tasks'. There's only a few tasks in the system and I can replicate by creating a new task in the backlog and then clicking the 'Edit Blocking Task' button. What comes up is a dialog as per screenshot image:

We do not support the Bitnami image.

We'll be thrilled to fix this if anyone can come up with repro instructions we can follow to reproduce it in a supported environment (for example, on this install, or on a Phacility test instance).

Hello,

On a local install, we are also getting this error.
phab : f4d47d93fd8a56f918e4cfa72bf96d6997955a8d
libphutil: 0fa7efbf09d75b7803ef54bd6c72ee3c69a964e4

Uncaught Error: JX.initBehavior(map): behavior(s) not registered: phabricator-object-selector
core.pkg.js:2JX.$E
core.pkg.js:173JX.initBehaviors
core.pkg.js:230(anonymous function)
core.pkg.js:188JX.install.statics._complete

It happens on both firefox and chromium (lots of versions).
Note that the failure seems sporadic since it does not happens everytime.

f4d47d93fd8a56f918e4cfa72bf96d6997955a8d is not in the upstream. We do not support forked versions of Phabricator.

We'd love to fix this as soon as we're able to reproduce it in a supported environment (for example, on this install, or on a Phacility test instance). If you have reproduction instructions which work in such an environment, please let us know how to reproduce the issue. See Contributing Bug Reports.

My bad, the phabricator commit is the following one: f59ebf4c09598e5f02657a4037c822b64a306646.

Hi guys, I'm a bit confused re the commit hash message above, does this mean it's an issue which will be looked into as is happening on a local install also?

We have not been able to reproduce any issue. If someone can come up with a set of steps or environment that reproduces the issue, then we can look into it.

Ah, OK, I thought that message from clemvangelis about 6 up is a confirmation of local install issue? I'll see if I can do a local install and replicate...

Our current thinking still is that it's environmental, that is something between Phabricator and the browser is munging the JS (or the webserver itself). Generally anything this catastrophic would be (JS failure) we'd have multiple easy to reproduce reports, and we haven't seen that. It is concerning though that three people ran into this in short notice. It'd be good to know if there is any common infrastructure (web, php, server, etc).

@wakes, Yes I'm reproducing the issue on a local install.
Here is the configuration:
Distrib:

Centos7-64

HTTPD (Stock install, no exotic neither standard plugins enabled):

Server version: Apache/2.4.6 (CentOS)
Server built:   Nov 19 2015 21:43:13

Php:

PHP 5.4.16 (cli) (built: Jun 23 2015 21:17:27) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Navigator:

Chrome Version 41.0.2272.89 (64-bit)

After some trials, it seems that clearing the webbrowser cache (either firefox or chrome) restore the functionnality but after a few trials, the error happens again.