Have you fully read Contributing Bug Reports? This ticket is missing most of what is required for a handling, primarily reproduction steps, as highlighted there.

Specifically, if you are using Bitnami, we cannot help you, as you've already seen in T10120.

@avivey - I have added the Steps to reproduce the issue.

I *also* tried Bitnami as a test but that is not my ticket. The issue is that this happens NOT only in Bitnami as described in the linked ticket but seems to be a problem with any other installation process too.

The reason I raised this ticket and specifically linking the other closed ticket is that, the previous one was closed as possible Bitnami stack issue and from the description it seems to be affecting only the Object selection modal.

Whereas I have run into this issue in more than one place, with just a vanilla apache2 server without Bitnami or any other additions.

These steps don't reproduce for me here, on Phacility, nor in multiple development environments.

https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#reproducibility

We believe you're seeing a bug, but we can't reproduce it as described, knowing what you are doing differently than us is important. Reproduction steps should be thorough enough that we can follow them, step by step, and see the exact same issue as you are. Without being able to see the bug locally, we'll have no idea if we've fixed it or not.

What operating system, browser, and browser plugins are you using?

@chad I understand your insistence on the Steps to Reproduce for a public project like Phab. The reason I am vague ( can also be said about T10120 ) is that this is a very hard issue to reproduce reliably.

I have chased this down to the way resources are loaded in the modal. ( I am not familiar with the codebase so I could be wrong ).

It seems that every time there is a modal application, Phab seems to load the required resources through javelin. This seems to be sent from the server as a list of javelin_resources.
Also everytime such an app is loaded, core.pkg.js is loaded and that seems to re-initliaze the behavior list

JX.behavior._behaviors = {};
JX.behavior._statics = {};
JX.behavior._initialized = {};

Now the behavior required for say Merge Diffs In is present in the differential.js. If differential.js is loaded first and the core.js is loaded next, the above code will wipe out installed behavior from differential and re-initialize with the core.js behaviors.

For Merge Diffs In or in Reorder columns modal, the modal specific JS seems to be loaded first through Resource.load. I could not trace the code that generates that with grep/find so I modified javelin/lib/Resource.js : load() to reverse() the passed in list param. This seems to fix the problem and validates the above diagnosis because the list.reverse() will force core/init.js to be loaded first.

From T10120 and the other ticket on the same topic, you will notice that users talk about being able to get this to work reliably for a few mins after 'Empty Cache and Hard Reload` in Chrome. This because it makes the browser actually fetch the JS files and they *might* load in the order needed.

I also noticed that for the Bitnami instance vs Secure.Phab , the last modified header was set the current date every time there is a hard reload. Since these resources don't seem static, I assume the last modified is generated in code or could be how apache2 ( bitnami ) vs nginix ( secure. ) handles last modified headers for such dynamic resources.

@cspeckmim - I am on a Mac/Chrome. No plugins.

The problem is that the current code works for almost everybody; Adding reverse() will likely break it for everyone except for you...

I am not suggesting that as a fix, far from it. That was hack I made to get it to work for me.

I am just trying to help narrow down the problem and point at that fact that this doesn't seem to be related to "setup".
The above is just my 2c from reading some minified code for 60 mins.

I'm reproducing this issue on a standard installation. As I said, here is our configuration

Distro:

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)

We are able to reproduce it on firefox and chrome. Clearing the browser cache seems to have some effects sine the modal dialog rework one time.
Is there anything I can do to help you narrowing the problem ?

Edit, to add more information the error is the following:

core.pkg.js:193 Uncaught Error: JX.initBehavior(map): behavior(s) not registered: phabricator-object-selectorJX.$E 
@ core.pkg.js:2JX.initBehaviors 
@ core.pkg.js:178(anonymous function) 
@ core.pkg.js:235_complete 
@ core.pkg.js:193_poll 
@ core.pkg.js:189

Clearing the cache does not resolve the problem every time. Could this probably due to some loading race condition problem ?

Chrome Version 41.0.2272.89 (64-bit)

This seems pretty old, what system/os are you testing specifically? Is the offending install available for us to test from here?

We really, truly need reproduction instructions that let us reproduce the problem in an environment we control. We're happy to accept this bug report and fix the underlying issue as soon as we're able to reproduce it.

If you want us to go back and forth with you to get to the bottom of things, we're happy to do that too, but this is almost always very time consuming and is usually fruitless (it most often identifies an environmental or configuration problem, not a problem with Phabricator), so we simply can't offer this kind of support for free. It would be unfair to our paying customers and other Phabricator users if we prioritized these issues above almost anything else we could be spending time on. If we did offer this kind of support for free (as we once did, long ago), you would be at the very far end of a very, very long queue (for example, see T11505, T11486, ) that would probably be filling up faster than it was emptying. See Consulting if you'd like to pay us for this kind of support.

We try to make this context as clear as possible in Support Resources, Contributing Bug Reports, Providing Reproduction Steps, and the hint text on the "New Bug Report" form. If those documents are in any way misleading, present a different picture than this, or could be rewritten to be more clear, please let us know.

I know this can be frustrating, but if you can reproduce the issue in a reliable way locally, you should just be able to describe to us what you've done to set things up, and then we'll follow the same steps to reproduce the issue and fix the bug. This is more work upfront, but will almost certainly take less time overall than going back and forth, since going back and forth tends to be very inefficient and often takes hours and hours over the course of many days.

Is anyone encountering this on a https:// protocol install? I was plagued by this issue for a while and switched to https:// and it seemingly disappeared. Although I can't reproduce today on the http:// protocol either.

I switched to https:// because I didn't trust that there wasn't a local network caching/firewall appliance that was serving pages for my host or mucking with responses somehow. I don't know if this is a race condition (since the appliance may return a http 304(?) faster than the server serves other content)

If it isn't a network appliance of some kind mucking with this, this probably involves having a very low latency server, and maybe only over http:// which will make reproduction difficult on a Phacility instance but could possibly happen on a development instance.

Also, one thing I noticed was that enabling "disable cache" in Chrome developer tools would sometimes make the problem go away as well.

I think the most common bit of JS to hit this race condition was the Aphlict notification status (connected/disconnected) bit that loads when you click on notifications. Although I used to be able to hit it on the modal dialogs as well. I can reproduce there today on http:// but it works fine on https://, but I also don't get the console error message for Javelin either for the Aphlict status.

I'm not suggesting that these are good reproduction steps for Phacility to use especially since I can't reproduce this well today but might help @ramprabhuj or @clemvangelis get closer to reproduction steps. I also disabled mod_pagespeed on my install to try and avoid this and I don't think that fixed it since I still went ahead with the trouble of getting a HTTPS certificate after that.

@epriestley - I want to be as clear as possible that this is NOT a support request. I have a perfectly working hack ( something I think actually addresses the root issue of JS dependencies at some level ). So I am just trying to help and I don't have a sense of how critical this issue is to the overall Phab roadmap. So I will perfectly happy with Phab eveb if this gets thrown at the bottom of the list and will be happy to stop updating this specific issue if its distracting.

Now for the real issue, I find it confusing what Phacility considers to be a "vanilla" install. I have reproduced this with Amazon Linux AMI with out of the box Apache 2.4 installation, with a Bitnami installation which is just Apache 2.4 + mod_pagespeed ( disabling this didn't matter ). @clemvangelis has described a fairly vanilla setup above. The reason I am asking this is because, the 30 min response I got from @avivey was that, Phacility doesn't support Bitnami and I see that you have responded with fairly the same in the other tickets. This is a perfectly fine response but when I look at Phab Instal Guide, it talks about grabbing any non obscure setup and following the install guide.

This being a non reliable issue to reproduce and secure.phab seems to run on Nginx ( Unknown OS ), will the ticket only be accepted only a Nginx install so it can be a Apples to Apples comparison to secure.phab ? I would urge you to consider a stronger guideline for cases like these which are seemingly "setup" issues by clearly stating a recommended setup. I saw a ticket about a Docker install which you rightly marked as not important, may be re-consider that ;-) ?

This is not a bug report until it has reproduction instructions. If we don't get reproduction instructions, we will not send this to the bottom of the list -- instead, we will close the report as "Invalid" and ignore the problem: we can not move forward without reproduction instructions.

It is perfectly acceptable for your reproduction instructions to begin "launch an instance with Amazon Linux AMI ami-6869aa05". But we need reproduction instructions that work, and which allow us to reproduce the issue.

Reproduction instructions must not involve third-party packages. We do not support them. See Contributing Bug Reports:

We do NOT support third-party packages or instructions. If you installed Phabricator (or configured some aspect of it) using a third-party package or by following a third-party guide (like a blog post), we can not help you. Phabricator changes quickly and third-party information is unreliable and often falls out of date. Contact the maintainer of the package or guide you used, or reinstall following the upstream instructions.

It sounds like you consider this issue very easy to reproduce following reasonable steps -- just tell us what those steps are so we can reproduce the issue.

@epriestley - Find the steps below. If the below seems insufficient, please close the ticket. I have a workaround which works and I have attempted to substitute any other extra reproduction steps with a diagnosis.

Launch an EC2 instance with ami-31490d51
sudo yum install -y httpd24 php56
sudo yum install -y git
sudo yum install -y php56-mbstring

Clone the Phab repos mentioned in the install guide
Add the VirtualHost entry from the install guide to the httpd.conf

Configure Phab to an existing Phab MySQL db with 100s/1000s of Maniphest tickets.
Click on any maniphest and click on Merge Duplicates In. Ensure the modal displays the list of available Maniphests. Repeat this a dozen times and in between click around Maniphest.

After a few attempts the modal will not load with any Maniphest tasks.

Phab Commit: b521f2349e46888514ce55d06ace1d8c5fa6df03
libphutil Commit: 237549280f08feb8852857b1d109dfb0aba345f0
arcanist Commit: 89e8b48523844cc3eff8b775f8fae49e85f8fc22

My local config which I was using to point at an existing install excluding my MySQL credentials.

"config.ignore-issues": {
    "config.PATH.85d2b528": true,
    "config.PATH.73ac2df0": true,
    "config.PATH.daf58c1f": true,
    "mysql.mode": true,
    "mysql.ft_stopword_file": true,
    "mysql.ft_min_word_len": true,
    "mysql.innodb_buffer_pool_size": true,
    "mysql.utf8mb4": true,
    "extension.apc.stat-enabled": true,
    "mysql.ft_boolean_syntax": true,
    "mysql.max_allowed_packet": true,
    "pygments.noenabled": true,
    "extension.apcu": true,
    "extension.opcache.production": true
  },
  "storage.mysql-engine.max-size": 0,
  "metamta.mail-adapter": "PhabricatorMailImplementationMailgunAdapter"
}

Thanks! I still can't reproduce this. Here's the install I brought up, following your instructions as closely as possible:

http://t11507.epriestley.com/

You can login with:

Username: admin
Password: qwerqwer1

I've clicked "Merge Duplicates In..." approximately 30 times in Chrome, browsing between pages in Maniphest between clicks. It has worked correctly every time.

[ec2-user@ip-172-30-0-13 phabricator]$ uname -a
Linux ip-172-30-0-13 4.4.11-23.53.amzn1.x86_64 #1 SMP Wed Jun 1 22:22:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

<Directory "/var/devtools/phabricator/webroot">
  Require all granted
</Directory>

<VirtualHost *>
  ServerName t11507.epriestley.com
  DocumentRoot /var/devtools/phabricator/webroot

  RewriteEngine on
  RewriteRule ^/rsrc/(.*)     -                       [L,QSA]
  RewriteRule ^/favicon.ico   -                       [L,QSA]
  RewriteRule ^(.*)$          /index.php?__path__=$1  [B,L,QSA]
</VirtualHost>

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd

max_allowed_packet=33554432
sql_mode=STRICT_ALL_TABLES
ft_stopword_file=/var/devtools/phabricator/resources/sql/stopwords.txt
ft_min_word_len=3
ft_boolean_syntax=' |-><()~*:""&^'
innodb_buffer_pool_size=256M

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

{
  "phabricator.base-uri": "http://t11507.epriestley.com/"
}

Host in AWS:

$ yum list installed | grep php
php56.x86_64                          5.6.24-1.126.amzn1           @amzn-updates
php56-cli.x86_64                      5.6.24-1.126.amzn1           @amzn-updates
php56-common.x86_64                   5.6.24-1.126.amzn1           @amzn-updates
php56-jsonc.x86_64                    1.3.6-1.19.amzn1             @amzn-main   
php56-mbstring.x86_64                 5.6.24-1.126.amzn1           @amzn-updates
php56-mysqlnd.x86_64                  5.6.24-1.126.amzn1           @amzn-updates
php56-pdo.x86_64                      5.6.24-1.126.amzn1           @amzn-updates
php56-process.x86_64                  5.6.24-1.126.amzn1           @amzn-updates
php56-xml.x86_64                      5.6.24-1.126.amzn1           @amzn-updates

@epriestley - I did the same on your setup and can't reproduce!

I will capture a couple more discrepancies.

My original Phab install was from Bitnami but essentially the only thing left from that is the MySQL DB.

Your sandbox don't have any projects. Tried creating one but it crashed. In my install, I did click around to the project workboards and tried to reorder the columns once. Not sure if that affected the issue itself.

You can close the ticket as non reproducible, not sure what else I can do to help.

Note: this is only to log informations and try to reproduce the issue, with other user who see this bug, is it okay if I keep using this ticket ?

Non working dialogs javascript loading:

Working dialog javascript loading:

I need help:>>> UNRECOVERABLE FATAL ERROR <<<

Call to a member function setRequest() on a non-object

/usr/www/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:248