On Tue, May 26, 2009 at 9:18 PM, David Levin wrote:
>
>
> On Tue, May 26, 2009 at 8:57 PM, Sam Weinig wrote:
>
>>
>>
>> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson wrote:
>>
>>>
>>>
>>> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig wrote:
>>>
On Tue, May 26, 2009 at 4:20 PM, Drew
On May 26, 2009, at 9:05 PM, David Levin wrote:
I think the principle is simple "classes that can avoid virtuals
should." There are lots of tricky situations, but in general make a
good effort to avoid virtual methods (which to me means be prepared
to answer why you need a virtual method
On May 26, 2009, at 7:00 PM, John Abd-El-Malek wrote:
This will work fine for appcache and localstorage, but isn't
sufficient for workers since the same caller gets different objects
depending on which process this is running in. This doesn't happen
for appcache and localstorage.
It
On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote:
Did you say partly because it's more complicated than just splitting
one class (and only having 1-way sync communication)? If so, then
we're still on the same page, because that's what I'll be doing as
well. I was just using the StorageB
On Tue, May 26, 2009 at 8:57 PM, Sam Weinig wrote:
>
>
> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson wrote:
>
>>
>>
>> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig wrote:
>>
>>>
>>>
>>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson wrote:
>>>
To give the list some insight into the discussio
I think the principle is simple "classes that can avoid virtuals should."
There are lots of tricky situations, but in general make a good effort to
avoid virtual methods (which to me means be prepared to answer why you *need
* a virtual method in a given place).
By avoid them, there isn't a quest
On Tue, May 26, 2009 at 5:04 PM, Drew Wilson wrote:
>
>
> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig wrote:
>
>>
>>
>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson wrote:
>>
>>> To give the list some insight into the discussions we've had with the
>>> Chrome UX folks:
>>>
>>> 1) We want to ass
It might also be worth bringing back up the unanswered quesiton of whether
this is even worth it for AppCache and LocalStorage. As I mentioned, my
(less than scientific) testing indicated no.* Maybe we're prematurely
optimizing here? I definitely agree that virtual functions should be
avoided in
On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow wrote:
> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow wrote:
>
>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote:
>>
>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow wrote:
>>>
The common case is definitely that we know whether we want the
On Tue, May 26, 2009 at 5:00 PM, Sam Weinig wrote:
> On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek wrote:
>
>> I agree that this approach is powerful. However there are (not too
>> frequent) situations when a port like Chromium wants to use both the WebKit
>> implementation and its own imp
I think we're on the same page. What you described sounds good to me.
I think ResourceHandle case is different because its involved in more
than appcache specific stuff. In chrome the calls into the appcache
while resource loading would occur on the chrome-side of the wire from
chrome specific cod
On Tue, May 26, 2009 at 6:02 PM, Michael Nordman wrote:
> > To clarify, I'm saying that your question made me realize that we
> probably
> > can make a hard split between the frontend and backend code (i.e. what
> would
> > live in a sandbox and handle page rendering and what wouldn't live in a
>
> To clarify, I'm saying that your question made me realize that we probably
> can make a hard split between the frontend and backend code (i.e. what would
> live in a sandbox and handle page rendering and what wouldn't live in a sand
> box and store the actual DOM Storage data). In single process
On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow wrote:
> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote:
>
>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow wrote:
>>
>>> The common case is definitely that we know whether we want the proxy (for
>>> IPC) or the implementation at compile time. In
On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote:
> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow wrote:
>
>> The common case is definitely that we know whether we want the proxy (for
>> IPC) or the implementation at compile time. In some cases (like Chromium)
>> this is not known until initia
On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow wrote:
> The common case is definitely that we know whether we want the proxy (for
> IPC) or the implementation at compile time. In some cases (like Chromium)
> this is not known until initialization time.
What do you mean by "initialization time"
On Tue, May 26, 2009 at 4:20 PM, Drew Wilson wrote:
> To give the list some insight into the discussions we've had with the
> Chrome UX folks:
>
> 1) We want to associate some set of enhanced permissions with a given
> origin (e.g. https://mail.yahoo.com), and we want the user to be presented
> w
On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek wrote:
> I agree that this approach is powerful. However there are (not too
> frequent) situations when a port like Chromium wants to use both the WebKit
> implementation and its own implementation, switching in runtime. For
> workers, this ha
Hi,
I'm Kyounga interested in web browser.
While I'm doing internet surfing, I found out Safari 4 has wrong rendering
result on "Yhaoo".
I investigated to figure out if this is really issue or just follows web
standard.
But, I'm confused to understand web standard.
I attached the reduced test pa
To give the list some insight into the discussions we've had with the Chrome
UX folks:
1) We want to associate some set of enhanced permissions with a given origin
(e.g. https://mail.yahoo.com), and we want the user to be presented with a
single "do you want to grant permissions to https://mail.ya
The common case is definitely that we know whether we want the proxy (for
IPC) or the implementation at compile time. In some cases (like Chromium)
this is not known until initialization time. So the ideal is a clean way to
handle the "not known until initialization" while optimizing for the comp
John's point about switching which impl to use at runtime is a good
one. For example, I was planning on doing something similar for the
ApplicationCacheFrontend interface, but with a difference. I was
planning on returning one concrete instance when called on the main
thread, and another when calle
On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak wrote:
>
> On May 22, 2009, at 10:19 AM, John Gregg wrote:
>
> Sure. We have the following plan for how to handle opt-in:
> - Use of the feature by script, if permission isn't granted to the origin,
> should throw an exception, not present perm
On May 26, 2009, at 2:01 PM, Drew Wilson wrote:
Has John sufficiently addressed people's concerns about this issue?
Perhaps some of the people who previously expressed concerns in the
bug could chime in here saying whether or not they are bought in now.
We'd like to move forward on getting
On May 22, 2009, at 10:19 AM, John Gregg wrote:
Sure. We have the following plan for how to handle opt-in:
- Use of the feature by script, if permission isn't granted to the
origin, should throw an exception, not present permissions UI. So
your insistent porn site would have no effect on
Has John sufficiently addressed people's concerns about this issue? Perhaps
some of the people who previously expressed concerns in the bug could chime
in here saying whether or not they are bought in now.
We'd like to move forward on getting a reviewer on this change, but we're
not certain what t
Just for the record. I just tried nytimes.com in our Webkit/EFL port
(unofficial) and all went fine w/ the supposed problematic top bar.
I will working on get a reduced test case for it, and get it properly
tracked on bugzilla.
br
On Mon, May 25, 2009 at 5:44 AM, Holger Freyther wrote:
> On Mon
On May 26, 2009, at 1:42 PM, ying lcs wrote:
Hi,
In here http://webkit.org/blog/114/webcore-rendering-i-the-basics/, it
talks about DOM tree and Render tree.
Can you please tell me does it mean for each DOM element,
* there will be a Render Object (1-to-1 mapping)?
What about invisible
element?
Hi,
In here http://webkit.org/blog/114/webcore-rendering-i-the-basics/, it
talks about DOM tree and Render tree.
Can you please tell me does it mean for each DOM element,
* there will be a Render Object (1-to-1 mapping)? What about invisible
element? e.g.
* does each DOM element will have it uniq
On May 26, 2009, at 10:43 AM, Drew Wilson wrote:
Thanks for the explanation, Maciej. I actually looked at
ResourceRequest prior to sending my mail, but I wasn't clear what
makefile magic was being used to load the correct version of
ResourceRequest.h for a given platform.
For example, if
Note that Chromium uses the same binary/libraries for the render process and
the browser process, which means that the decision can't be made in compile
time for us.
There might be ways (like what you mentioned) to allow the compiler to skip
all the virtual stuff for implementations where the deci
I agree that this approach is powerful. However there are (not too
frequent) situations when a port like Chromium wants to use both the WebKit
implementation and its own implementation, switching in runtime. For
workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
the interf
Thanks for the explanation, Maciej. I actually looked at ResourceRequest
prior to sending my mail, but I wasn't clear what makefile magic was being
used to load the correct version of ResourceRequest.h for a given platform.
For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see onl
On May 26, 2009, at 10:21 AM, Darin Adler wrote:
On May 26, 2009, at 10:16 AM, Drew Wilson wrote:
OK, I've got two strong votes for the interface + static factory
approach. Any objections from the rest of the WebKit team? If I
don't hear any counter proposals, I'll do that.
I think it's
On May 26, 2009, at 10:16 AM, Drew Wilson wrote:
OK, I've got two strong votes for the interface + static factory
approach. Any objections from the rest of the WebKit team? If I
don't hear any counter proposals, I'll do that.
I think it's unpleasant to pay run-time cost for a compile-time
OK, I've got two strong votes for the interface + static factory approach.
Any objections from the rest of the WebKit team? If I don't hear any counter
proposals, I'll do that.
-atw
On Mon, May 25, 2009 at 10:41 PM, John Abd-El-Malek wrote:
>
>
> On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow w
On May 26, 2009, at 9:09 AM, Jack Wootton wrote:
OK. To confirm, I need to obtain the Window JSObjectRef since any
custom objects I wish to add are themselves attributes of the "window"
object and so must be added accordingly?
Yes. The most common way to make a named object visible to JavaScri
OK. To confirm, I need to obtain the Window JSObjectRef since any
custom objects I wish to add are themselves attributes of the "window"
object and so must be added accordingly?
On Tue, May 26, 2009 at 5:06 PM, Darin Adler wrote:
> On May 26, 2009, at 8:59 AM, Jack Wootton wrote:
>
>> Thank you
On May 26, 2009, at 8:59 AM, Jack Wootton wrote:
Thank you for taking the time to respond. I am using the S60 port of
WebKit. So the platform is Symbian.
OK. For that port I don’t know the answer. Perhaps someone familiar
with that platform would know.
Inside WebCore, to convert the JSDOM
Hello,
Thank you for taking the time to respond. I am using the S60 port of
WebKit,. So the platform is Symbian.
Many thanks,
Jack
On Tue, May 26, 2009 at 4:56 PM, Darin Adler wrote:
> On May 26, 2009, at 8:32 AM, Jack Wootton wrote:
>
>> 1. I'm attempting to use the JavaScriptCore API to add
On May 26, 2009, at 8:32 AM, Jack Wootton wrote:
1. I'm attempting to use the JavaScriptCore API to add new JSObjects
to the JavaScript environment. In order to use the API I include
"JavaScriptCore.h". However in doing so, JSStringRefCF.h contains
errors. The system include CoreFoundation/Co
Hello,
I have two questions I hope I can get some help with:
1. I'm attempting to use the JavaScriptCore API to add new JSObjects
to the JavaScript environment. In order to use the API I include
"JavaScriptCore.h". However in doing so, JSStringRefCF.h contains
errors. The system include CoreFo
Hi,
Maybe you need touch the directory of JavaScriptCore/API/ and the file of
JavaScriptCore/API/test/testapi.c.
Thanks.
-Xiong
On Tue, May 26, 2009 at 5:26 PM, Harry Zhang wrote:
> Dear all, can anyone kindly share some code snippets on how to create and
> attach an JS object, e.g. "window.fo
Dear all, can anyone kindly share some code snippets on how to create and
attach an JS object, e.g. "window.foo" to window object via C bridge?
(btw, my dev environment is Ubuntu, i want to enable this in webkitgtk+)
Many thanks in advance!
Regards,
Harry
_
44 matches
Mail list logo
