Welcome to the rebirth of the "right-click blocking" scripts. Please, take a trip with me down memory lane, to the glorious days of DHTML in 1998, when there were serious attempts to use JavaScript to "prevent people from stealing your images and code!" <a href="http://www.java-scripts.net/javascripts/No-Right-Click.phtml" rel="nofollow">http://www.java-scripts.net/javascripts/No-Right-Click.phtml</a><p>What is old is new, what is new is old.
You can remove the DOMSubtreeModified event listener first, then you are free to modify "locked" content as desired. I hope to not see a day where the Web Inspector lacks proper facilities to inspect and modify a page.
Visited the page and ran this in the console:<p><pre><code> $("code.locked").after($("<code class=\"locked\">I circumvent you!</code>")).remove()
</code></pre>
Clearly this doesn't prevent scripts from changing it, nor does it prevent users from deleting the locked elements and replacing it with something else.<p>What's the point of this cat and mouse game?
It's cool, but I guess I don't see the point because I'm not sure how big the intersection is between users that can use Chrome developer tools, and those who can't disable this [0].<p>[0]: <a href="http://i.imgur.com/jvExNWT.png" rel="nofollow">http://i.imgur.com/jvExNWT.png</a>
Most of the comments here are bashing this for ease of defeat and not having a useful reason for it's existence.<p>While I agree that it's easy to defeat, it could be interesting in test cases to make sure there aren't any DOM side effects to an operation. You could also use it to ensure that there are proper side effects. Probably not the best way to do it, but still a cool idea in my opinion.
For those wondering, you can get around this globally by listening during the capture phase and stopping propagation.<p><pre><code> document.addEventListener('DOMSubtreeModified', function( e ) {
e.stopPropagation();
}, true );</code></pre>
So it's like those old scripts to stop right clicking/content selecting/other stuff then?<p>The ones that were (and still are) completely useless because the scripts are client side and trivially easy to 'bypass'? Yeah, I think I'll pass.<p>Funny enough, uBlock Origin doesn't seem to like this very much, since I just waltzed in and edited the 'protected' elements without so much as an alert:<p><a href="https://dl.dropboxusercontent.com/u/67216205/jqueryunlocked.png" rel="nofollow">https://dl.dropboxusercontent.com/u/67216205/jqueryunlocked....</a><p>What's next, a jQuery marquee plugin? Or maybe jQuery blinking text...
It might be more useful to silently report modifications to sensitive elements.<p>I could only really see this being useful for malicious browser plugins that aren't targeted at the specific site.
The `.lock` function takes two optional parameters: `alertMessage` and `customHandler`. `customHandler` is a callback invoked when a content change is attempted. `alertMessage` is a convenience function that calls `alert`; it could be trivially implemented by the client programmer using `customHandler`. The author is ostensibly suggesting that `alert` is a common use case. I think he's trolling us.<p>EDIT: Just saw that the author is a company. There goes my theory.
Does this not work on Firefox? I expected to not be able to change anything about the two "locked" elements, but I seem to be able to change the text, class, or even delete them with no issue.<p>Edit: Interestingly if I click "Edit as HTML" I can change them to my heart's content, but if I try just double clicking the text it won't let me make changes.
"The idea of the plugin is to prevent users without technical background from changing the page HTML. For example. many eCommerce customers change the price of the product using dev tools and send a screenshoot."<p>Yeah, good luck with that.
The idea of the plugin is to prevent users with no technical background from changing the page HTML. For example. many eCommerce customers change the price of the product using dev tools and send a screenshoot trying to get free discounts.