WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 89554
Web Inspector: Having a "Scroll into view" for nodes through web inspector.
https://bugs.webkit.org/show_bug.cgi?id=89554
Summary
Web Inspector: Having a "Scroll into view" for nodes through web inspector.
sam
Reported
2012-06-20 01:55:26 PDT
Web inspector currently does not have an option for getting the node to scroll into view.
Attachments
screenshot illustrating scroll into view option in menu.
(107.72 KB, image/png)
2012-06-20 01:59 PDT
,
sam
no flags
Details
Patch
(2.69 KB, patch)
2012-06-22 06:03 PDT
,
sam
no flags
Details
Formatted Diff
Diff
Patch
(3.68 KB, patch)
2012-07-04 22:33 PDT
,
sam
no flags
Details
Formatted Diff
Diff
Patch
(4.13 KB, patch)
2012-07-05 02:20 PDT
,
sam
no flags
Details
Formatted Diff
Diff
Patch
(4.12 KB, patch)
2012-07-05 02:31 PDT
,
sam
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
sam
Comment 1
2012-06-20 01:58:08 PDT
I am looking into this and will upload the patch soon. Also attached is the screen shot for illustration purpose. Plz do let me know if there are any suggestions/comments.
sam
Comment 2
2012-06-20 01:59:07 PDT
Created
attachment 148525
[details]
screenshot illustrating scroll into view option in menu.
Yury Semikhatsky
Comment 3
2012-06-20 02:11:18 PDT
This can be achieved by evaluating "$0.scrollIntoViewIfNeeded(true)" in the console. I'm not sure if it's worth a context menu action.
Pavel Feldman
Comment 4
2012-06-20 07:27:36 PDT
I like the context menu part, it does not clutter UI, user does not need to be aware of console API. I would put it lower though, so that it was below all edit / copy operations.
sam
Comment 5
2012-06-22 03:36:15 PDT
Thanks Yury, Pavel for your feedbacks. I was just wondering if including a new api to execute expressions through console will be ok. This would basically a very tiny one - work similar to executeThroughConsoleUsingTextPrompt but will neither set record nor print result and will also not show console panel - only direct execution. I guess it might be used in later use cases also. Or is there something else also which I might be missing/getting wrong?
Yury Semikhatsky
Comment 6
2012-06-22 04:27:09 PDT
(In reply to
comment #5
)
> Thanks Yury, Pavel for your feedbacks. > > I was just wondering if including a new api to execute expressions through console will be ok. This would basically a very tiny one - work similar to executeThroughConsoleUsingTextPrompt but will neither set record nor print result and will also not show console panel - only direct execution. > I guess it might be used in later use cases also. > > Or is there something else also which I might be missing/getting wrong?
What do you mean by "including a new api"? We already have RuntimeAgent.evaluate(...) method on the front-end that allows you to perform evaluation in the inspected page, current console UI invokes that method, isn't it enough for your needs?
sam
Comment 7
2012-06-22 06:03:31 PDT
Created
attachment 149009
[details]
Patch
sam
Comment 8
2012-06-22 06:09:20 PDT
(In reply to
comment #6
)
> (In reply to
comment #5
) > > Thanks Yury, Pavel for your feedbacks. > > > > I was just wondering if including a new api to execute expressions through console will be ok. This would basically a very tiny one - work similar to executeThroughConsoleUsingTextPrompt but will neither set record nor print result and will also not show console panel - only direct execution. > > I guess it might be used in later use cases also. > > > > Or is there something else also which I might be missing/getting wrong? > > What do you mean by "including a new api"? We already have RuntimeAgent.evaluate(...) method on the front-end that allows you to perform evaluation in the inspected page, current console UI invokes that method, isn't it enough for your needs?
Ya true, i just meant to include a wrapper like executeThroughConsoleUsingTextPrompt, but later realized that eval can be done by direct call. Thank you Yury.
Yury Semikhatsky
Comment 9
2012-06-22 06:15:15 PDT
Comment on
attachment 149009
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=149009&action=review
> Source/WebCore/inspector/front-end/ElementsTreeOutline.js:1073 > + var expression = "$0.scrollIntoView(true)";
Note that $0 may not necessarily be a DOM node, e.g. it may be last element selected in a heap profile.
> Source/WebCore/inspector/front-end/ElementsTreeOutline.js:1074 > + WebInspector.consoleView.evalInInspectedWindow(expression, "console", true, false, false, null);
Instead of going through the consoleView, you should be able to get current selected node and evaluate .scrollIntoView(true) on it using RuntimeAgent.evaluate
Pavel Feldman
Comment 10
2012-06-22 07:06:42 PDT
Comment on
attachment 149009
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=149009&action=review
>> Source/WebCore/inspector/front-end/ElementsTreeOutline.js:1074 >> + WebInspector.consoleView.evalInInspectedWindow(expression, "console", true, false, false, null); > > Instead of going through the consoleView, you should be able to get current selected node and evaluate .scrollIntoView(true) on it using RuntimeAgent.evaluate
Here is the hint on how to do what Yury suggests: WebInspector.RemoteObject.resolveNode(nodeId, "", callback); function callback(object) { function scrollIntoView() { this.scrollIntoView(true); } if (object) object.callFunction(scrollIntoView, []); }
sam
Comment 11
2012-07-04 22:33:34 PDT
Created
attachment 150877
[details]
Patch
Pavel Feldman
Comment 12
2012-07-04 23:49:12 PDT
Comment on
attachment 150877
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=150877&action=review
Looks good. Couple of nits and it is ready to land.
> Source/WebCore/inspector/front-end/ElementsTreeOutline.js:1920 > + scrollIntoView: function()
Should be private (_scrollIntoView)
> Source/WebCore/inspector/front-end/ElementsTreeOutline.js:1930 > + object.callFunction(scrollIntoView, undefined);
No need to pass undefined, just declare this parameter as optional.
> Source/WebCore/inspector/front-end/RemoteObject.js:287 > + if (!callback)
You need to declare callback optional in the jsdoc.
sam
Comment 13
2012-07-05 02:20:37 PDT
Created
attachment 150899
[details]
Patch
Pavel Feldman
Comment 14
2012-07-05 02:23:38 PDT
Comment on
attachment 150899
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=150899&action=review
> Source/WebCore/inspector/front-end/RemoteObject.js:275 > + * @param {(Array.<RuntimeAgent.CallArgument>|undefined)=} args
no need for "|undefined" now that this parameter is optional.
sam
Comment 15
2012-07-05 02:31:29 PDT
Created
attachment 150903
[details]
Patch
sam
Comment 16
2012-07-05 02:31:58 PDT
(In reply to
comment #14
)
> (From update of
attachment 150899
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=150899&action=review
> > > Source/WebCore/inspector/front-end/RemoteObject.js:275 > > + * @param {(Array.<RuntimeAgent.CallArgument>|undefined)=} args > > no need for "|undefined" now that this parameter is optional.
err, will upload it again. Thanks for the review Pavel.
Pavel Feldman
Comment 17
2012-07-05 02:53:03 PDT
Comment on
attachment 150903
[details]
Patch Thanks!
WebKit Review Bot
Comment 18
2012-07-05 03:34:09 PDT
Comment on
attachment 150903
[details]
Patch Clearing flags on attachment: 150903 Committed
r121896
: <
http://trac.webkit.org/changeset/121896
>
WebKit Review Bot
Comment 19
2012-07-05 03:34:15 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug