Activity Comments Conflicts with FBSS & FBSL

its actually a core bug: #671184: AJAX form can submit inappropriately to system/ajax after failed validation

the form action gets all mixed up. The issue title doesn't do it complete justice.

subscribing

Looks like the core issue might not be 'backportable'. Might have to come up with a way to handle this in the module by passing the $form_state['old_action'] via the AHAH menu callback and then form_altering that bad boy into the form when it comes back.

That might not fix it though since its another module thats mixing up the form actions.

Subscribing, interested in the same integration..greetings, Martijn

Thats not it at all. Its a core bug thats ugly and complicated. To much AHAH makes drupal confused. Its a complicated problem that I don't have a clear pattern on how to fix.

Hi Scott, couldn't somebody else from the coreteam may be help you?
Just to help you in the think process...

greetings,
Martijn

Subscribing. I'm the maintainer of FBSS.

This is indeed a very complicated issue. I've struggled with related issues before, unaware that this was rooted in a core bug.

I'm also experiencing this to some extent with my Facebook-style Statuses Comments module. This issue is probably also related to #710684: "Form in form" problem causes status updates to fail.

Whatever publicmind fixed, it was probably not this issue. I don't see any changes in FBSL 1.1 that would affect this.

For some reason though I can hit enter on Activity comments and the page reloads with the comment properly in place

If the page reloads instead of doing AJAX stuff then the AHAH properties were just removed. And if that is the case, thats not really a fix.

Hi,

sorry to hit in late, as ICY mentioned I did nothing specific to fix the issue in FBSL 1.1.

But I would like to mention of this issue: #757770: Apostrophes don't work in browsers, I don't know if its related to it in any way but I was using apostrophe instead of quote somewhere to theme the image.

regards,

I would be rather shocked if you were able to solve this problem without fixing #710684: "Form in form" problem causes status updates to fail as well. Fixing that issue requires some fundamental changes to the way FBSS currently renders Views.

Fundamental changes don't necessarily mean that it will be really difficult or take a long time. Basically all that's required here is moving views_embed_view() out of facebook_status_box() and triggering a custom event in the AHAH success handler (which is already overridden in dev), then adding a listener for that event attached to the view that re-loads the view using AJAX.

Sounds complicated, but it's probably only around 4-12 hours' work. I just have to find those 4-12 hours and the motivation to do it.

Subscribing. Thanks

Hi IceCreamYou,
For what's it worth I really appreciate your efforts!!!
Greetings, Martijn

Subscribing. Many thanks

I tried to fix the issue as described by IceCreamYou on base of facebook_status-6.x-2.x-dev.

Unfortunately I only got it for the settings "no page refresh via ahah" (fbss_without_ahah.patch).

The second (independent) patch for the ahah-part (fbss_ahah_dev.patch) works fine for insertion of new status messages, meaning the comment view get refrehes via ajax. But a second problem appeared: if you wan't to insert any new comment after updating the status message, a similar failure to the inital one of this issue shows up. When you want to insert a new comment after(!) status message update, a new pageload is required to avod the failure.

Since there is always a new pageload after status insertion without ahah enabled, the problem does not appeare with this setting.

Remark: ahah-patch only works for view "facebook_status" atm (hard coded in .js file), since I stopped working on it after I recognized the new problem.

master-of-magic, thanks for your efforts. But first of all, you diff'd your patches backwards, from the new to the old instead of old to new. :-P

Second of all, as noted in the issue where the problem you attempted to tackle is actually being discussed, I'm already working on this. You have the right idea, but you missed some key parts. Also the approach I'm taking more generically (and cleanly) allows anything on the page to be refreshed when a status is submitted, not just a single view. I'm fairly close to finished with my implementation.

This issue exists separately from the "form-in-form" bug because there are probably deeper issues in Drupal core FAPI-with-AHAH. So even when the "form-in-form" bug is solved, FBSSC and Activity Comments still might not work completely as expected. I'm not familiar with the exact problems, but Scott apparently is, and they are discussed here.

I encourage you to continue helping with patches. Once I fix (what I hope is just) one last problem I will commit or post a patch with my progress on the "form-in-form" issue and we can build from there.

Although I forgot to update this issue, the form-in-form problem is fixed. I have had no problem with Facebook-style Statuses Comments due to the very generic approach I took with fixing the form-in-form problem, so if there is still an issue with Activity Comments, it can very likely be fixed without a core patch (and also probably isn't related to FBSS).

In addition, FBSL is deprecated in favor of FBSMP.

This bug is hard, but its fixable with a little form magic. It shouldn't take that much time its just finding time to devote to this.

I'm finding a different problem with the latest alpha version.

On my production site, im using an old dev version which works fine, I can add comments via ajax, i can add status updates and the fbss updates the view via ajax, still fine. If i add a comment after adding a status update then the page needs to refresh which isnt ideal but at least it works.

However with the latest alpha, i can add a comment, i can add a status update but if i try to add a comment after an update then nothing at all happens.

I can see in FF console that the 'POST' isnt being sent from the comment form.

Just had another look at this and it seems clear that its because after a fbss update the activity view is reloaded via Ajax, this means the new dom elements are not having the comment jquery attached to them. If you were using the latest version of jQuery then the event bindings could be replaced with 'live' but i'm sure this is not likely to be common.

So I think it would be good to go back to the earlier version with the standard form submit which isn't ideal but at least it worked.

If Activity's JS is compliant with Drupal standards, it will automatically be attached to the new DOM after an AHAH update. And it looks to me like this is the case, although there is a related bug which may or may not solve this problem.

As an example, take the first part of activity_comments.js:

  Drupal.behaviors.activityCommentsShowAll = function (context) {
    $('.activity-comment-show-all:not(.activity-comment-show-all-processed)').each(function (i) {
      $(this).click(function() {
        // remove the hide comments class so everything is shown below.
        $(this).parents('.activity-comments-hide-comments').removeClass('activity-comments-hide-comments');
        return false;
      });
    }).addClass('activity-comment-show-all-processed');
  };

When a form is submitted via AHAH, this code is run again. Because the binding selectors are applied with $(), they work on the whole document; so every time a form is submitted via AHAH the behaviors get re-attached to everything that matches the selector on the entire page. This problem is mitigated by toggling "processed" classes on the processed elements.

Instead, it should be better to use $(context).find(), which will only process the new DOM (in the case of a full page load, context will be document).

I've also since realised that this isn't exactly the problem too.

The jQuery is being attached and is being triggered as you can follow the execution in firebug.

After pressing enter or clicking 'add', the js runs through activity_comments.js and at line 37

$(this).parents('form').find('input[type=submit]').mousedown();

this is where the form should be submitted but it just skips over it without doing anything.

D6 reached its EOL back in February 2016, and there is no active release for D6 for this module anymore.
Development or support is not planned for D6. All D6-related issues are marked as outdated in a bunch.

If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.

Thanks!