Release lock when browsing away from locked form

I attached the patch version of the current merge request for those working with composer patches.

The last submitted patch, 35: 3160781-35.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

It's better not to post separate patches when using merge requests for the actual changes. It makes it confusing, as people often submit new patches rather than putting later changes into the MR. Just link to the MR patch file, which people can download.

https://git.drupalcode.org/project/content_lock/-/merge_requests/12.patch

But don't reference that merge request URL directly in your composer.json file. Its contents can change at any time, potentially silently breaking your website after new composer installs. Just keep your patch files locally, together with the rest of your website code.

Like the idea but feels like something that should be a form setting or another submodule like timeout is? thoughts.

It should probably be configurable with a setting. However, for content editors who have no idea about Drupal or its functionality, who just manage their content, they might have no idea what "Break lock" means, or they might forget if they do know. I think it's a good feature to add.

But it might not be a setting that all sites want.

Sure, anyone could turn off the setting.

I agree @solideogloria, I have been using this patch for about 2 years now on a website where I'm an editor, and in my opinion it's a very valuable feature. It would be good to get this in the module at some point. I couldn't imagine always having to unlock the form manually.

I've rebased MR!12, should probably be tested again.

There is a test failure. Is that related?

Also, I'm not sure if this fix is working at all. I have the latest changes applied to a site, I edit a node (locking it), and then I either click "view" to leave the editing screen or close the tab, but the content is still locked.

I can't seem to be able to apply the patch via composer to test.

You have to be using the dev version of the module. It doesn't apply to the latest release.

I couldn't applied #35 patch for dev or 2.4 version. Re-rolled patch for 2.4 version.

After using this for 2+ years I have to agree that the possibility to manually unlock still needs to be present. Automatic unlocking works in 95% of the cases, but it might not work if a user has JS disabled or if for example their device/browser crashes and it doesn't ping the unlock endpoint. Maybe the button shouldn't be there on the edit form to avoid confusion, but we could e.g. add an entity operation to overviews to unlock nodes that are stuck in a locked state. We should probably add two separate settings, 'Lock form using JS' and 'Unlock form using JS' instead of 1 combined setting.

Also, I just discovered the onunload event is deprecated:

Developers should avoid using this event.

Especially on mobile, the unload event is not reliably fired. For example, the unload event is not fired at all in the following scenario:

A mobile user visits your page.
The user then switches to a different app.
Later, the user closes the browser from the app manager.

https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event#usa...

I'll update the MR to use one of the other recommended events.

Never mind, I can't seem to make pagehide work and I saw that beforeunload is not deprecated, so using both unload and beforeonload seems like the best way to go.

Maybe the button shouldn't be there on the edit form to avoid confusion, but we could e.g. add an entity operation to overviews to unlock nodes that are stuck in a locked state.

I forgot about the status message with the unlock link that shows if the user has permission to unlock. That's probably sufficient.

To test this feature, I have userA in my primary window and I use google chrome's incognito window and sign in as userB.

Unlock form using JS

While having Unlock form using JS and verbose messaging enabled, I check out node1 as UserA. I do not see a message saying the node is checked out. When I navigate to the page as UserB I do not see the warning and in fact am able to submit the form with out issue.

Unlock/Lock form using JS

While having Unlock/Lock form using JS and verbose messaging enabled, I check out node1 as UserA. I do see the message saying I've checked out the node. When I navigate to the page as UserB I do see the warning. However, As UserA, when I navigate away from the page and refresh the window for UserB I still see the warning and am unable to submit the form.

Results

I would expect the regardless of my selection of Unlock/Lock form using JS the Verbose message will always display. Based off of my testing, navigating away from the page by either hitting the browser back or clicking the node view task, does not unlock the page.

Local setup.

• Drupal: 10.3
• Content lock: 3.0.0-alpha2
• Chrome: Version 129.0.6668.90

Can't apply Merge request !12 for 3.x

remco hoeneveld → made their first commit to this issue’s fork.

This patch does apply, and reflects the code and fixing in the MR : 3935b475

When I use this branch and activate "Unlock form using JS", I don't get lock entries in the database when I open a node.

Just including on patch #62 the line 296 available on MR to render the message after running the if/else conditional.

$this->messenger->addStatus($this->t($message));

• The unlocking route should be protected with a CSRF
• It'll be better to use a form value for the link rather than drupalSettings - see the work on 🐛 Content lock create access does not account for content translations Active - so placeholdering works as expected
• This issue will need a major update once 🐛 Remove the JS route for locking an entity Active lands but thats good because it already needs a major update.

I've discussed this issue with @daniel.bosen and @chr.fritsch a few times. We would all like to solve this in some way but every time we think yes let's do it another risk comes up. For example, we've just fixed a bug where previewing a change made it lock like content was no longer locked - see 🐛 Previewing appears to unlock node RTBC . So we've come to the conclusion that adding the this to the module is really risky. These same discussions made us realise that we should bring two pieces of functionality from content_lock_timeout into content_lock and support them even better. There are: having a timeout after which the content is considered unlocked and cleaning up a user's locks when they logout and we can count the number of open sessions they have. See 📌 Merge content_lock_timeout into content_lock Active for progress on this.

I will leave the issue open until August 2025 and then close it with a won't fix - maybe someone will come up with an amazing idea of how to make this work reliably.