RESOLVED WONTFIX 113670
Web Inspector: manually update local variable in UI after its value was changed
https://bugs.webkit.org/show_bug.cgi?id=113670
Summary Web Inspector: manually update local variable in UI after its value was changed
Peter Rybin
Reported 2013-03-31 18:08:36 PDT
Currently after user changed local variable, the old value is still on display. Variable only visible changes it value after debug step. This is due to the fact that protocol doesn't support rereading local variables. We should mechanically update display value on frontend. Without this UI is quite counterintuitive
Attachments
Patch (3.50 KB, patch)
2013-03-31 18:15 PDT, Peter Rybin
no flags
Patch (13.16 KB, patch)
2013-04-02 08:09 PDT, Peter Rybin
no flags
Patch (12.71 KB, patch)
2013-04-02 13:24 PDT, Peter Rybin
no flags
Peter Rybin
Comment 1 2013-03-31 18:15:16 PDT
Pavel Feldman
Comment 2 2013-04-01 02:16:10 PDT
Comment on attachment 195913 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=195913&action=review > Source/WebCore/inspector/front-end/RemoteObject.js:243 > + if (this._scopeRef) { So when should I pay attention to scopeRef and when I should not? Does RemoteObject now represent different entities from different domains?
Peter Rybin
Comment 3 2013-04-01 05:03:19 PDT
> > Source/WebCore/inspector/front-end/RemoteObject.js:243 > > + if (this._scopeRef) { > So when should I pay attention to scopeRef and when I should not? Does RemoteObject now represent different entities from different domains? ScopeRef logically couples with objectId. Having ScopeRef set means that the remote object is transient and some operation don't have meaning for it.
Peter Rybin
Comment 4 2013-04-02 08:09:08 PDT
Peter Rybin
Comment 5 2013-04-02 08:11:05 PDT
(In reply to comment #2) > (From update of attachment 195913 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=195913&action=review > > > Source/WebCore/inspector/front-end/RemoteObject.js:243 > > + if (this._scopeRef) { > > So when should I pay attention to scopeRef and when I should not? Does RemoteObject now represent different entities from different domains? RemoteObject is left intact (almost), as we discussed offline. ScopeRemoteObject inheriting class is introduced instead.
Pavel Feldman
Comment 6 2013-04-02 11:14:47 PDT
Comment on attachment 196142 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=196142&action=review > Source/WebCore/inspector/front-end/RemoteObject.js:185 > + getPropertiesImpl: function(ownProperties, callback) We typically say doGetProperties > Source/WebCore/inspector/front-end/RemoteObject.js:191 > + Extra space > Source/WebCore/inspector/front-end/RemoteObject.js:389 > + * @param {WebInspector.ScopeRef=} scopeRef Why is this optional? > Source/WebCore/inspector/front-end/RemoteObject.js:450 > + WebInspector.RemoteObject.prototype.setObjectPropertyValueImpl.call(this, result, name, callback); When do we get here and why?
Peter Rybin
Comment 7 2013-04-02 13:24:25 PDT
Peter Rybin
Comment 8 2013-04-02 13:31:27 PDT
> > Source/WebCore/inspector/front-end/RemoteObject.js:185 > > + getPropertiesImpl: function(ownProperties, callback) > We typically say doGetProperties Done > > Source/WebCore/inspector/front-end/RemoteObject.js:191 > > + > Extra space Done > > Source/WebCore/inspector/front-end/RemoteObject.js:389 > > + * @param {WebInspector.ScopeRef=} scopeRef > Why is this optional? Done > > Source/WebCore/inspector/front-end/RemoteObject.js:450 > > + WebInspector.RemoteObject.prototype.setObjectPropertyValueImpl.call(this, result, name, callback); > When do we get here and why? Done
Peter Rybin
Comment 9 2013-04-08 16:05:21 PDT
I no longer work on WebKit.
Csaba Osztrogonác
Comment 10 2013-11-05 08:54:33 PST
Comment on attachment 196216 [details] Patch Cleared review? from attachment 196216 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).
Note You need to log in before you can comment on or make changes to this bug.