For help with porting or similar questions, please direct your queries
to .
- Maciej
On Jul 13, 2009, at 11:25 PM, Naveen Pal wrote:
Hello All,
I have created webkitgtk browser on OpenSuse. Now I want to port
this on PXA270 board.
Following are the h/w and s/w details.
- Hardware sp
Hello All,
I have created webkitgtk browser on OpenSuse. Now I want to port this on PXA270
board.
Following are the h/w and s/w details.
- Hardware spec.: PXA270, NOR Flash, NAND Flash, MDOC,
3.5" LCD with touch screen,
PCF50606 (Philips) PMI
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
Maciej,
Can we separate the tools from WebKit menu? I want to run them as a
stand-alone and connect to existing WebKit instance.
Regards,
-Hieu
-Original Message-
From: webkit-dev-boun...@lists.webkit.org
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Maciej
Stachowiak
Sent: T
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: http:/
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: http://chr
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 Dat
On Jul 13, 2009, at 5:34 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiak
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" prot
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiak 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
> access to
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:20 PM, Maciej Stachowiak 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 I look for t
On Jul 13, 2009, at 4:11 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garen
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
http://webblaze.org/
On Jul 13, 2009, at 4:12 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiak
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
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiak 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, which do in
On Jul 13, 2009, at 3:40 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garen
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
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garen 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
>> http://webblaze.org/abarth/tests/protoconfused/test2.html
>
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 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 (close
On Mon, Jul 13, 2009 at 3:17 PM, David Hyatt 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 about a part
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
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 diff
On Mon, Jul 13, 2009 at 3:36 PM, Geoffrey Garen wrote:
> Sam and I just noticed that, to fully support this behavior, any host object
> that lazily constructs function properties using the functions in lookup.h
> must either
>
> (a) change in the same way as DOM objects must change
>
> or
>
> (b) e
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garen 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 large
> des
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 the
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 data
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
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
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)
___
On Mon, Jul 13, 2009 at 2:26 PM, Maciej Stachowiak 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.
That's correct
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 enou
On Mon, Jul 13, 2009 at 1:33 PM, Geoffrey Garen 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 Mon, Jul 13, 2009 at 2:55 PM, Maciej Stachowiak 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 wrote:
>
>> On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
>>
>> On Mon, Jul 1
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
wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt
wrote:
I agree. We should formalize t
On Jul 13, 2009, at 2:36 PM, Maciej Stachowiak wrote:
Don't you need an ExecState to report exceptions, including the
uncatchable out-of-memory exception? Or does that work differently
now?
It works differently now. A JSGlobalData is all you need to report
exceptions.
-- Darin
On Jul 13, 2009, at 2:28 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 (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).
There are classes in JavaScriptCore wi
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" rath
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 t
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,
On Jul 13, 2009, at 2:03 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak
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 ha
On Mon, 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
On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel wrote:
> On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen 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
On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak 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 port in
> the
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen 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 using heaps as a
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 experimenta
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 w
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 he
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
t
Re-sending from correct address.
On Mon, Jul 13, 2009 at 1:23 PM, Eric Seidel 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 globalobject via the he
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-de
On Mon, Jul 13, 2009 at 12:24 PM, Mark Mentovai 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 CMake - it's a goo
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 descripti
On Mon, 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 wrote:
>
>> On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
>>
>> On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt wrote:
>>
>>> I agree. W
On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt wrote:
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt
wrote:
I agree. We should formalize this as policy too in my opinion.
Maybe something ti
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt wrote:
> On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
>
> On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt wrote:
>
>> I agree. We should formalize this as policy too in my opinion. Maybe
>> something time-based, e.g., if you have an implementat
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt 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?)
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 Mon, Jul 13, 2009 at 10:47 AM, David Hyatt 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 be landed i
2009/7/13 Peter Kasting :
> 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 these shoul
2009/7/13 Darin Fisher :
> 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 they are still in
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
On Mon, Jul 13, 2009 at 10:40 AM, Darin Fisher 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
> get similar trea
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 de
Hi,
This should help you going:
class Element : public ContainerNode {
PassRefPtr getClientRects() const;
PassRefPtr getBoundingClientRect() const;
}
Christophe
JayaSai Kishore wrote:
>
> Hi,
> I need to get Rect region where a node is rendered.
> As per my understanding
You can't restore a page from only the serialized DOM.
The CachedPage class may help.
I have looked at CachedPage.h, but I don't see any method to
serialize the cached page to files and then de-serialize it later.
Can you please tell me how can I do that with cached page?
I'm not sure CachedP
On Mon, Jul 13, 2009 at 3:37 AM, ZHOU Xiao-bo wrote:
> You can't restore a page from only the serialized DOM.
> The CachedPage class may help.
>
I have looked at CachedPage.h, but I don't see any method to
serialize the cached page to files and then de-serialize it later.
Can you please tell me h
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 >
wrote:
I concur with Maciej.
Luke, in some other culture your posts are already considered
derogatory and insulting.
also - (i apo
> 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
https://lists.webkit.org/pipermail/webkit-dev/2
On Monday 13 July 2009 13:47:13 Luke Kenneth Casson Leighton wrote:
> On 7/13/09, Luke Kenneth Casson Leighton
wrote:
> > > I concur with Maciej.
> > >
> > > Luke, in some other culture your posts are already considered
> > > derogatory and insulting.
>
> also - (i apologise for not thinking
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 region
On 7/13/09, Maciej Stachowiak 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 already.
On 7/13/09, Luke Kenneth Casson Leighton 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 in the #16401 devel
> 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, Maciej Stachowiak 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 is not an ap
> 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 th
You can't restore a page from only the serialized DOM.
The CachedPage class may help.
2009/7/13 Luka Napotnik
> 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 mea
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
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 lis
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 o
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 t
80 matches
Mail list logo
