[Webkit-unassigned] [Bug 17896] Inspector console should autocomplete the id's in the document when completing document.getElementById

Thu Jul 1 17:20:06 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=17896

--- Comment #8 from Joseph Pecoraro <joepeck at webkit.org>  2010-07-01 17:20:05 PST ---

(In reply to comment #7)
> (From update of attachment 59228 [details])
> WebCore/inspector/front-end/ConsoleView.js:353
>  +      _getCurrentFunctionName: function(text)
> No 'get' prefix in WebKit?

Done.

> WebCore/inspector/front-end/InjectedScript.js:177
>  +      var elems = document.querySelectorAll("[id]");
> You are only querying current document, not touching iframes. Imagine the code is frames[0].document.getElementById(...

Currently we don't even support autocompletion across frames.
So "frames[0].do" wouldn't even complete to "document".
Autocompletion doesn't dig into either "obj[key]" or "obj.get(key)".
I don't know why it doesn't dig into the bracket syntax, but
certainly the call syntax might cause sideaffects if run.

So, that sounds like a different problem that should be tackled.

> WebCore/inspector/front-end/InjectedScript.js:380
>  +          case "getElementById":
> Now this is heuristics. How hard would it be to test whether this function is defined
> on the document object?

I thought about this at the time. I think ideally we should break
this down into 2 parts. With Example Input:

>             document.body.appendChild( a.b.c().d( someVar|

    - Current Typing Unit      =>  someVar

      This can autocomplete to variables and the usual things.
      Combining this with the next part, if we know its a particular
      function we can autocomplete with strings or restrict the
      variables to types that make sense.

    - Previous Unit            =>  a.b.c().d

      This can be checked against a known function, because it is
      being called with "(". Again here, we have a function call c(),
      so to be safe we don't evaluate it. But assuming that part
      wasn't there "a.b.d" we could compare against each frame's
      `document.getElementById` or something like that.

When I wrote this patch I didn't think far enough ahead. I just
wanted to play with it. I've already missed it while working on
my other machines!

> WebCore/inspector/front-end/InjectedScript.js:190
>  +      var elems = document.getElementsByTagName("*");
> Same here, this all needs to be done in native code as I've done it to the performSearch.

I don't know about that. I thought if the user types "document.getElementsByTagName("
they would only care about the tag names of elements in ^^^ that "document". Not inner
<iframe>s which that cannot access. Given:

    <body>
      <iframe src="data:text/html,<p>Hi</p>"></iframe>
      <script>
        setTimeout(function() {
            alert( document.getElementsByTagName("p").length ); // => 0
        }, 1000);
      </script>
    </body>

> WebCore/inspector/front-end/InjectedScript.js:235
>  +  InjectedScript._generatedCachedQueryObjects = [];
> We try to get rid of these...

Okay. I haven't stress tested this to see if caching is even useful.

> NOTE TO SELF: This would also need a test. If performSearch can
> be tested, this most certainly can be!

Noted.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.