Tested the issue on windows 7 using chrome M59 #59.0.3071.86 and followed below steps :

1. Launched chrome and opned chrome://site-engagement and edited the points value and observed the js error in console.

Attached screencast for reference.

@giggig-- Could you please check attached screencast and confirm us if this is the issue you are talking about and also please provide us the screenshot or video of the expected behavior.

Thanks!

Deleted: 730434.mp4 568 KB

	730434.mp4 568 KB View Download

@hdodda

Yes the attached screencast confirms the issue reported. I am unable to provide my own screencast of the expected behaviour. 

This functionality was working as expected in Chrome 58. 

Manually setting a value against a site engagement record was being recorded correctly, and persisting. 

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Doesn't seem like a DevTools issue so I'm re-assigning the issue component.

Crud. This has been broken between https://codereview.chromium.org/2788413003 landing (prior to M59 branch cut) and https://codereview.chromium.org/2811643002 (after M59 branch cut). The latter CL's fix was never merged to 59.....

+cc abdul/amineer: is M59 likely to need a respin? This issue is caused by an incorrect JavaScript call, and the fix is calling the right method name (+4 characters in a WebUI JS file). chrome://site-engagement is actually fairly important right now since it's used by devs to work with/around Html5ByDefault's Flash blocking on desktop.\

Ping amineer / abdulsyed for thoughts.

I'm checking in here because we were going to file a bug o this issue as well.

We unfortunately still have some legacy educational flash content which we are actively phasing out. 

Our dev and QA team use the editable site-engagement fields to undo or redo the flash block to get around the HBD flag when doing local testing. 

This is completely broken for v59+ because the values don't persist.

Approved for M59 branch 3071.  Android will be respinning soon, this might have missed the desktop train - abdulsyed@ will know for sure.

Thanks for getting on this so quickly. Would this go out for v59 or v60 for desktops? 

c#12: v60 should already be fixed (so if you use the current Chrome dev, beta, or canary channels chrome://site-engagement should work). I am putting together a fix for M59 stable that should hopefully go out asap, depending on when the next mid-refresh of stable occurs.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d5baec557d94596cef90ba652dbbe546bc6ab5ee

commit d5baec557d94596cef90ba652dbbe546bc6ab5ee
Author: dominickn <dominickn@chromium.org>
Date: Mon Jun 19 00:41:56 2017

Fix an incorrect method name on the chrome://site-engagement WebUI page.

TBR=calamity@chromium.org
BUG= 730434 
NOTRY=true
NOPRESUBMIT=true
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2947593003
Cr-Commit-Position: refs/branch-heads/3071@{#801}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/d5baec557d94596cef90ba652dbbe546bc6ab5ee/chrome/browser/resources/engagement/site_engagement.js

This should be fixed across all channels now, and is just awaiting the next respin of M59 to go live so that the fix goes to stable.

Verified this issue on Mac 10.12.4, Win 10 and Linux Ubuntu 14.04 as well using latest Chrome version #59.0.3071.109.

Observed now Score is recording correctly and JS error was not thrown. Hence adding verified labels

Please find the screen cast

Thanks

Deleted: Jun 20 2017 2-50 PM.webm 1.5 MB

	Jun 20 2017 2-50 PM.webm 1.5 MB View Download