[Webkit-unassigned] [Bug 52791] Buffer overrun in WebCore::InspectorBasicValue::writeJSON

[bugzilla-daemon at webkit.org]

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





--- Comment #23 from Mikołaj Małecki <m.malecki at samsung.com>  2011-02-07 23:37:12 PST ---
(In reply to comment #21)
> > That's correct, so in this case you can accept my patch without additional tests, right?
> 
> That is correct, my "Nit:" statement in the review was not a landing requirement. Bug url was.

Ups sorry, updated patch is now submitted. :)
I was sure that the latest patch already contains the bug URL.

> > I'm using setInjectedScriptSource to 'pin in' this injected script. We are using another injected script, which is slightly modified the default one (we needed a bit more information about the objects being inspected).
> 
> There is no setInjectedScriptSource on the tip of the tree. What additional information are you providing? Most likely, you should suggest adding it to the default implementation of the injected script instead.

module core {
    interface [Conditional=INSPECTOR] Inspector {

...
        [handler=Backend] void setInjectedScriptSource(in String scriptSource);
...
  };
}

Maybe it has been removed, but I hope not.

> > But there was no other code in WebKit to hang in.
> 
> Right. WebKit's responsibility today is to establish transport that would deliver messages between backend and front-end without parsing them.

I just found no place in the frontend that would be suitable to hang in.

> > Maybe we haven't used the best source for communication with web inspector, but we have already done it and we don't have infinite time for fixing it or writing it anew. Actually I don't think it's used outside the inspector, although the inspector client we have written is used for external communication using the data.
>
> When I say 'inside inspector', I mean internals of WebCore/inspector folder. Explain what you are doing in greater detail and I am happy to suggest alternative or confirm present approach.

Creating a view with JS debugging set and with my new inspector client. This client then receives messages (by getting a function called with a command given by string) and sends responses by calling a callback function. Inside it translates this communication to a communication based on the inspector protocol.

> > Because we needed it in webkit itself and we needed that it be implemented in native language, to have it working with another native code. The web inspector's C++ API gives us direct access to the objects and events happening in the web inspector. Practically this was the only thing that was ready for use for it.
> 
> Are you saying that the front-end you are emulating leaves inside your WebKit port?

I have just created an inspector client, alternative to InspectorClientEfl. It's being created instead of this client depending on view creation function's arguments.

> > I understand that this is maybe not the best way to implement it, but we haven't found any better one. I have opened another bug for discussing it counting for that I will get some help about a best way to do it, but I got no valuable response.
> 
> Could you link to it from here?

Not yet, sorry. But as long as we finish our work, the patch with the whole code will be submitted.

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