Hello.
I want to partially prevent the user from loosing focus from the
current page being displayed. As I see, this can be done by saving the
current state of webkit which means serializing the DOM tree. But I
don't know if traversing the DOM tree is sufficient and which
information is relevant
Are you calling NPN_CreateObject using the function pointers that were
exchanged during initialization?
You're probably aware that the browser provides pointers to the
browser side of the NPAPI and it is your job as the plugin author to
populate the function pointers that make up the plugin side
Hi Luke,
I think your webkit-dev emails are becoming disruptive. Sending
profanity-laced walls of text is not an appropriate use of this list.
Please find a way to communicate without annoying the rest of the
list, or I will ask the list administrators to censor you from the
mailing list
Zhang,
The napi.h is located under WebCore/bridge folder. Please check to see
why it didn't include in the build.
-Hieu
-Original Message-
From: webkit-dev-boun...@lists.webkit.org
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Jack Wootton
Sent: Monday, July 13, 2009 4:50 PM
I think your webkit-dev emails are becoming disruptive. Sending
profanity-laced walls of text is not an appropriate use of this list.
Please find a way to communicate without annoying the rest of the
list, or I will ask the list administrators to censor you from the
mailing list for the
On 7/13/09, Maciej Stachowiak m...@apple.com wrote:
Hi Luke,
hi maciej,
I think your webkit-dev emails are becoming disruptive.
whilst at the same time apologising for being disruptive, i'd like to
ask you why you consider that to be a bad thing.
Sending
profanity-laced walls of text
I concur with Maciej.
Luke, in some other culture your posts are already considered derogatory and
insulting.
dear ariya,
i apologise for that. i invite you to consider this, especially in
light of the subject being discussed: if there was not a deep seated
problem with the way that
On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote:
I concur with Maciej.
Luke, in some other culture your posts are already considered derogatory
and
insulting.
also - (i apologise for not thinking of this earlier) - it's worth
emphasising that
early on
On 7/13/09, Maciej Stachowiak m...@apple.com wrote:
Hi Luke,
I think your webkit-dev emails are becoming disruptive. Sending
profanity-laced
[apologised and explained already]
walls of text
maciej,
i thought i'd best pick up on this one and nip it in the bud, even
though i've replied
Hi,
I need to get Rect region where a node is rendered.
As per my understanding xPos() and yPos() methods on any Renderer of a
node, give coordinates relative to parent node but not exact coordinates
where rendering happens for that Renderer.
Is there any way to find Render
On Monday 13 July 2009 13:47:13 Luke Kenneth Casson Leighton wrote:
On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com
wrote:
I concur with Maciej.
Luke, in some other culture your posts are already considered
derogatory and insulting.
also - (i apologise
I need to get Rect region where a node is rendered.
Please post such questions to webkit-help, see
http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
Rationale: read
https://lists.webkit.org/pipermail/webkit-dev/2009-July/008681.html
Am 13.07.2009 um 15:33 schrieb Holger Freyther:
On Monday 13 July 2009 13:47:13 Luke Kenneth Casson Leighton wrote:
On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com
wrote:
I concur with Maciej.
Luke, in some other culture your posts are already considered
derogatory
Hi,
This should help you going:
class Element : public ContainerNode {
PassRefPtrClientRectList getClientRects() const;
PassRefPtrClientRect getBoundingClientRect() const;
}
Christophe
JayaSai Kishore wrote:
Hi,
I need to get Rect region where a node is rendered.
As
I noticed that some new form validation code is landing (e.g.,
http://trac.webkit.org/changeset/45739). That change adds stubs for the
ValidityState object. What I didn't see in that patch is any kind of ENABLE
flag. I suspect there should be one since otherwise it becomes difficult
for a web
On Mon, Jul 13, 2009 at 10:40 AM, Darin Fisher da...@chromium.org wrote:
I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or
something similarly named). I'm writing this to webkit-dev because I want
to make sure that other new web platform features that may be in development
I agree. We should formalize this as policy too in my opinion. Maybe
something time-based, e.g., if you have an implementation of a new Web
technology that is going to take (1month?) to implement, then the
feature should be landed inside ENABLE ifdefs (that can then be
removed when the
2009/7/13 Darin Fisher da...@chromium.org:
I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or something
similarly named). I'm writing this to webkit-dev because I want to make
sure that other new web platform features that may be in development get
similar treatment while
2009/7/13 Peter Kasting pkast...@google.com:
When it relands I will see if I can figure out what the ENABLE flag should
cover and make sure it's covered. I'm concerned about other things already
in the tree with valid in their name, e.g. readonly attribute boolean
willValidate -- not sure if
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote:
I agree. We should formalize this as policy too in my opinion. Maybe
something time-based, e.g., if you have an implementation of a new Web
technology that is going to take (1month?) to implement, then the feature
should
Hello,
I am looking for pointers to module(s) that change the webserver
configuration (in-memory and maybe also in the config files on disk) for any
reason. Are there any such modules? Or is Apache inherently an ecosystem
where the config (config files) are not written to by the webserver itself?
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote:
I agree. We should formalize this as policy too in my opinion.
Maybe something time-based, e.g., if you have an implementation of a
new Web technology that is going to
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote:
I agree. We should formalize this as policy too in my opinion. Maybe
something time-based, e.g., if
On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com
wrote:
I agree. We should formalize this as policy too in my
On Mon, Jul 13, 2009 at 11:57 AM, David Hyatt hy...@apple.com wrote:
On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt
Generate Your Projects, or GYP, was designed around Chromium's needs.
Maintaining distinct project files for different build environments
and different platforms put a great burden on our team, and was never
intended to be a long-term solution. We really wanted to have a
single canonical
On Mon, Jul 13, 2009 at 12:24 PM, Mark Mentovai m...@chromium.org wrote:
We also considered CMake, and had it demonstrably working for some of
our smaller projects as well.
BTW, Mark's list of issues with CMake is non-exhaustive (we can share more
if desired), but we're not trying to slag
1. Is it correct for the ExecState to carry the thisValue?
As Adam realized later (I think), ExecState carries the value for
this inside the calling function. It does not carry the object whose
property is being accessed.
Geoff
___
webkit-dev
Re-sending from correct address.
On Mon, Jul 13, 2009 at 1:23 PM, Eric Seidelesei...@google.com wrote:
I'm looking at this more today.
I'm first fixing JSCell::new subclasses to make sure they're always
allocating in the correct heap. If we're to map from objects to the
associated
Our current thinking is to add a parameter to toJS() to receive the
JSGlobalObject in which to create the wrapper.
Seems logical.
Once we do that, the question is how to find the proper
JSGlobalObject at each call site.
In most cases, you have another JSObject sitting around that is from
Is it definitely right for document.body to make a wrapper using
prototypes
from the document's host window, rather than from the accessing
function's
window? What do other browsers do?
That's correct. Other browser's get this case right.
Is there a particular security or other benefit
I'm first fixing JSCell::new subclasses to make sure they're always
allocating in the correct heap. If we're to map from objects to the
associated globalobject via the heap, we need to fix allocation
first.
I'm not sure what you guys have been meaning by the phrase correct
heap. Barring
One belated comment on this topic. It would be neat if some port
agreed to be the guinea pig to see if gyp could plausibly work for
more than Google's ports. The Wx port probably has the lowest
resources of any complete port in the tree, so they might not be the
best choice of
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garengga...@apple.com wrote:
I'm not sure what you guys have been meaning by the phrase correct heap.
Barring workers, all WebCore objects are allocated from the same heap.
We had wrongly assumed that each window got its own. OK. This
invalidates
On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote:
One belated comment on this topic. It would be neat if some port agreed to
be the guinea pig to see if gyp could plausibly work for more than Google's
ports. The Wx port probably has the lowest resources of any complete
On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel e...@webkit.org wrote:
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garengga...@apple.com wrote:
I'm not sure what you guys have been meaning by the phrase correct
heap.
Barring workers, all WebCore objects are allocated from the same heap.
We had
On Mon, Jul 13, 2009 at 2:18 PM, Sam Weinigsam.wei...@gmail.com wrote:
I discussed this a bit with Darin and Geoff, and we came to the conclusion
that the correct fix is to have each JS DOMObject store a JSGlobalObject
pointer and augment the toJS methods to pass a global object instead of an
On Jul 13, 2009, at 2:03 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak m...@apple.com
wrote:
One belated comment on this topic. It would be neat if some port
agreed to be the guinea pig to see if gyp could plausibly work for
more than Google's ports. The Wx
1. Pass a current global object through to all toJS calls (lots of
callsites changed)
2. Store a current global object off of the ExecState (set by the
JS engine before leaving into custom native code for property lookup
or function execution).
I discussed this a bit with Darin and Geoff, and
On Jul 13, 2009, at 2:18 PM, Sam Weinig wrote:
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store a
JSGlobalObject pointer and augment the toJS methods to pass a global
object instead of an ExecState (close
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState (close to you #1).
You probably mean in addition to
I discussed this a bit with Darin and Geoff, and we came to the
conclusion
that the correct fix is to have each JS DOMObject store a
JSGlobalObject
pointer and augment the toJS methods to pass a global object
instead of an
ExecState (close to you #1).
There are classes in JavaScriptCore
On Jul 13, 2009, at 11:57 AM, David Hyatt wrote:
On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com
wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com
wrote:
On Mon, Jul 13, 2009 at 2:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 13, 2009, at 11:57 AM, David Hyatt wrote:
On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting
On Mon, Jul 13, 2009 at 1:33 PM, Geoffrey Garengga...@apple.com wrote:
Is it definitely right for document.body to make a wrapper using
prototypes
from the document's host window, rather than from the accessing
function's
window? What do other browsers do?
That's correct. Other browser's
On Jul 13, 2009, at 5:02 PM, Darin Fisher wrote:
This small interval rule-of-thumb idea sounds pretty good, but I
still wish it didn't put the burden on the guy doing the branch to
figure out what is or isn't incomplete about a particular snapshot
of WebKit. That guy might not be savy
On Mon, Jul 13, 2009 at 2:26 PM, Maciej Stachowiakm...@apple.com wrote:
For the few cases where
cross-origin access is allowed, we would *not* want to expose the home
window's prototype chain. So for Window.postMessage for instance,
cross-origin access need to give you a distinct wrapper.
On Jul 13, 2009, at 5:17 PM, David Hyatt wrote:
It's the organization shipping their product that should be working
to determine when their product is shippable.
This may in fact be the most incomprehensible sentence I have ever
typed. :)
dave
(hy...@apple.com)
Maciej Stachowiak wrote:
Another note, based on some #chromium conversations: if someone
passionate made CMake (or any other tool) into something compelling
enough to work better for Chromium than gyp does (or at least to work
close-to-as-well), and that tool was more plausible for other ports
Is there a particular security or other benefit here, or do we just
want to
make this change to match other browsers?
Our current behavior is buggy, unpredictable, and out of spec. This
has led to security bugs in the past and will lead to security bugs in
the future.
I don't disagree with
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState (close to you #1). I would
not advocate storing more
It seems like you have confused this mailing list with another one.
~Brady
On Jul 13, 2009, at 11:10 AM, Elison Smith wrote:
Hello,
I am looking for pointers to module(s) that change the webserver
configuration (in-memory and maybe also in the config files on disk)
for any reason. Are
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garengga...@apple.com wrote:
Our current behavior is buggy, unpredictable, and out of spec. This
has led to security bugs in the past and will lead to security bugs in
the future.
I don't disagree with you, but I'm not immediately convinced that a
Which spec did you have in mind? I'd like to read it.
Essentially, the ECMAScript spec requires this. In spec-land, these
objects are all created at the beginning of time. The fact that we
create them lazily is what leads to this bug. Depending on who
touches them first, they end up with
Yep... My guess is that (a) is probably better, but you two are more
expert on why we use lazy construction.
Heh -- lazy construction in JSC is even older than I am! :)
The goal is to reduce memory use and startup cost in cases where
certain functions aren't used. I'm not sure how much of a
On Mon, Jul 13, 2009 at 3:17 PM, David Hyatt hy...@apple.com wrote:
On Jul 13, 2009, at 5:02 PM, Darin Fisher wrote:
This small interval rule-of-thumb idea sounds pretty good, but I still
wish it didn't put the burden on the guy doing the branch to figure out what
is or isn't incomplete
On Jul 13, 2009, at 3:36 PM, Geoffrey Garen wrote:
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState
Consider this case, which does not involve a DOM object:
frames[0].Array.prototype.push.__proto__ ==
Array.prototype.push.__proto__
Built-in classes work somewhat differently. I believe they use the
calling function's global object (lexical global object) rather
than having some notion
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garengga...@apple.com wrote:
That's correct. Other browser's get this case right. Here are a
couple test cases you might find interesting:
http://webblaze.org/abarth/tests/protoconfused/test1.html
On Jul 13, 2009, at 3:40 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garengga...@apple.com
wrote:
Our current behavior is buggy, unpredictable, and out of spec. This
has led to security bugs in the past and will lead to security
bugs in
the future.
I don't disagree
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiakm...@apple.com wrote:
Built-in classes work somewhat differently. I believe they use the calling
function's global object (lexical global object) rather than having some
notion of home object.
You might be thinking of boxing primitive values,
On Jul 13, 2009, at 4:12 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiakm...@apple.com
wrote:
Built-in classes work somewhat differently. I believe they use the
calling
function's global object (lexical global object) rather than
having some
notion of home
On Jul 13, 2009, at 4:11 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garengga...@apple.com
wrote:
That's correct. Other browser's get this case right. Here are a
couple test cases you might find interesting:
http://webblaze.org/abarth/tests/protoconfused/test1.html
On Mon, Jul 13, 2009 at 4:20 PM, Maciej Stachowiakm...@apple.com wrote:
My own interest would be in weighing the tradeoffs. In the Pro column:
1) Are there aspects of this issue that create security holes?
CVE-2009-1702 is an example of such as security hole. I'm sure that I
can find more if
On Jul 13, 2009, at 4:34 PM, Adam Barth wrote:
CVE-2009-1702 is an example of such as security hole. I'm sure that I
can find more if I look for them.
I think objects attached to the global object and accessible cross-
origin are a special case here. (The advisory cited is about Location
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiakm...@apple.com wrote:
If security is one motivation for this work, then I'd like us to understand
the pattern we want to use for cross-origin-accessible objects. Should they
use the home global object prototype but protect it from mutation or
On Jul 13, 2009, at 5:34 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiakm...@apple.com
wrote:
If security is one motivation for this work, then I'd like us to
understand
the pattern we want to use for cross-origin-accessible objects.
Should they
use the home
Any chance HTMLTidy will be integrated into Safari?
http://zappatic.net/safaritidy/
Firebug is also a must: http://getfirebug.com/
Those are the only things keeping me from ditching Firefox, well aside
from the Web Developer Toolbar: http://chrispederick.com/work/web-developer/
and Tamper
On 2009-07-13, at 19:28, Juan Madrigal wrote:
Any chance HTMLTidy will be integrated into Safari?
http://zappatic.net/safaritidy/
Firebug is also a must: http://getfirebug.com/
Those are the only things keeping me from ditching Firefox, well
aside from the Web Developer Toolbar:
On Jul 13, 2009, at 7:28 PM, Juan Madrigal wrote:
Any chance HTMLTidy will be integrated into Safari?
http://zappatic.net/safaritidy/
Firebug is also a must: http://getfirebug.com/
Those are the only things keeping me from ditching Firefox, well
aside from the Web Developer Toolbar:
On Jul 13, 2009, at 7:28 PM, Juan Madrigal wrote:
Firebug is also a must: http://getfirebug.com/
Why is Firebug a must, when we have the WebKit inspector? Is there
something missing from the inspector tool? Or do you find performing
certain actions less efficient?
Thanks,
-Brent
71 matches
Mail list logo
