Publish/Save button not responding

[satrun77]

Module version(s) affected

2.3

Description

Note

This issue is only present in version 2.3. Version 2.2.14 works fine.

The save and publish buttons sometimes don't respond when they are clicked. In version 2.3.3 this changed to show the animated 3 dots. The animation does not stop and the button stops working. This change is related to #1865

How to reproduce

1. Install fresh CMS
2. Add Elemental module (https://github.com/silverstripe/silverstripe-elemental/)
3. Create a data object with version and more than one elemental area

use DNADesign\Elemental\Extensions\ElementalPageExtension;
use DNADesign\Elemental\Models\ElementalArea;
use SilverStripe\ORM\DataObject;
use SilverStripe\Versioned\Versioned;

class SomeObject extends DataObject
{
    private static string $table_name = 'SomeObject';

    private static array $db = [
        'Title' => 'Text',
    ];

    private static array $has_one = [
        'BlockArea' => ElementalArea::class,
        'BlockArea2' => ElementalArea::class,
    ];

    private static array $extensions = [
        Versioned::class,
        ElementalPageExtension::class,
    ];
}

6. Create a model admin for the data object.

use SilverStripe\Admin\ModelAdmin;

class SomeAdmin extends ModelAdmin
{
    private static string $url_segment = 'objects';

    private static string $menu_title = 'Objects';

    private static array $managed_models = [
        SomeObject::class,
    ];
}

8. Open browser console > Network tab
9. You will see multiple requests for /admin/graphql for each elemental area

10. Click publish just before all of the requests are completed, and you will see the pending ones changed to cancelled. The requests may load fast, which makes it hard to replicate. I edited the controller SilverStripe\GraphQL\Controller, and added sleep(1); to index method to slow down the request.

11. The buttons keep on animating and you can't click it again.

CMS user should be able to click the publish button even if the graphql requests in the background are not complete.

Possible Solution

Adding a check before the loop resolves the issue. With this change, componentDidUpdate is called multiple times until the publish request is complete. Not sure if this change is the correct fix or not!

if (!this.props.blocks && !prevProps.blocks) {
   return;
}

Additional Context

When the publish button is clicked before the graphql request is complete, there is a JS error from the elemental module related to the property being null https://github.com/silverstripe/silverstripe-elemental/pull/1214/files#diff-c39249a4fbdce6643c1a42ee2ba287a0a7b9ffd10720d3dfa6fa8bd19e9be81cR41

Validations

• Check that there isn't already an issue that reports the same bug
• Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

[GuySartorelli]

Sounds like the problem is ultimately that the button doesn't get disabled after you click it. You shouldn't be able to hit publish or save after having already hit publish or save until the previous submission has finished.

Edit: Ohhh wait no, you're saying you hit publish before the requests that populate the page have finished loading.
That's interesting.

[GuySartorelli]

Workaround for now: Just don't do that. :p

I'm not sure what a proper fix would look like. I don't think it's feasible to check for requests in progress and disable the buttons until the requests finish, for example.

[satrun77]

Sounds like the problem is ultimately that the button doesn't get disabled after you click it. You shouldn't be able to hit publish or save after having already hit publish or save until the previous submission has finished.

Edit: Ohhh wait no, you're saying you hit publish before the requests that populate the page have finished loading.

That's interesting.

Yes. Only when someone click publish too fast before the graphql response returned. This was noticed by a client where the requests for graphql was slow they could not click publish.

[GuySartorelli]

Note that the specific scenario in the issue description has been fixed - but this still represents a problem that if the page form elements haven't all fully loaded and someone submits the form, the results are currently undefined but could result in incorrect behaviour.

Because of that I'm keeping this open.

Ideally there would be some sort of "FormIsReady" boolean which is false until all elements on the form have fully rendered, though I don't know if we can do that in a sensible way with the current architecture.