After clicking once on the notifications box, to add or remove people, the cursor will always be brought back to it. It happens in any case where the notifications widget appears and is clicked on, and makes the UI pretty unusable as soon as one clicks on the box.

I tried this on Open Atrium instances installed in BOA and I am unsure if it applies in other situations. Changing jQuery versions (tried 1.7, 1.8 and 1.10), using CDN, etc. did not contribute to improve the situation.

Comments

gandhiano created an issue. See original summary.

mpotter’s picture

mpotter CreditAttribution: mpotter at Phase2 commented
Category: Bug report » Support request
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

This is not "Major". Also, I cannot reproduce any problem with this. You'll need to give a step-by-step procedure for reproducing the problem. Might depend on exactly what page you are on and what kind of user and what permissions they have.

gandhiano’s picture

gandhiano CreditAttribution: gandhiano commented

Here is a step-by-step description on how to come to this problem.

1. Deploy OA site (2.68 currently, but previous versions already suffered this issue)
2. Create a space
3. Create any content (e.g. discussion post)
4. When creating the content, click on the notifications box
5. Click on any other form on the page - the notifications box will always grab the cursor back, making the whole remaining form unusable.

This was tested on multiple Atrium instances created from a single OA platform. The platform includes custom modules on sites/all, but these are not activated on new deployments.

I would appreciate if someone tries to reproduce this on other settings. I will nevertheless continue exploring if there are any specifics of our deployment - or of BOA - which may be breaking the JS/AJAX behavior.

mpotter’s picture

mpotter CreditAttribution: mpotter at Phase2 commented

I cannot reproduce this on any of our systems here, or on a free Pantheon test site. Tried it in the latest Chrome, Firefox, and Safari.

Ensure your site has Clean URLs enabled. Also open the browser console to see if you are getting any javascript errors.

gandhiano’s picture

gandhiano CreditAttribution: gandhiano commented
Status: Postponed (maintainer needs more info) » Active

I have identified that the issue resides on optimizations/customizations enforced by BOA itself. In particular, the core linked in as part of the BOA stack is 7.50, while for OA 2.68 it is still 7.44.

I have opened an issue on the BOA issue tracker. It may be that this will be solved as soon as a new release of OA comes out with the latest core.

mpotter’s picture

mpotter CreditAttribution: mpotter at Phase2 commented
Status: Active » Fixed

You might also want to open an issue in the Panopoly issue queue (if there isn't already one) for the Drupal core update. Atrium relies on Panopoly for core and other modules and I believe there is an issue with 7.5x that is failing their tests for the update.

The BOA stack should not be enforcing 7.50 because it is not a security update. Site policies should normally only force a minimum version when there are security issues.

Thanks for debugging this and discovering the cause. But I'm going to close this issue as "answered" and we can wait for the Panopoly update and patches that will allow us to work with Drupal 7.5x.

gandhiano’s picture

gandhiano CreditAttribution: gandhiano commented
Status: Fixed » Closed (fixed)

The omega8cc team seems to have fixed this now on BOA and change the OA distro to use its own provided core (which I understand from your reply to be the one of Panopoly): https://github.com/omega8cc/boa/issues/1083