What is XBL? As far as I can tell, there's no way this code can even
build. It's incredibly stale. Can we remove it?
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
http://en.wikipedia.org/wiki/XBL , I guess?
XBL (XML Binding Language) is an XML-based markup language used to
declare the behavior and look of XUL-widgets and XML elements.
I don't think we need that :-)
Kenneth
On Wed, Aug 25, 2010 at 4:22 AM, Adam Barth aba...@webkit.org wrote:
What is
Sorry for the late-night webkit-dev spam, but in deploying adoptPtr,
I've noticed a number of places where have a HashMap that owns its
values as OwnPtrs. Unfortunately, this very clumsy currently. Each
instance of this pattern has its own way of hacking around the
problem, which might or might
From: kenneth.christian...@gmail.com
Date: Wed, 25 Aug 2010 04:24:49 -0300
To: aba...@webkit.org
CC: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] What is XBL?
http://en.wikipedia.org/wiki/XBL , I guess?
XBL (XML Binding Language)
On Tue, Aug 24, 2010 at 11:50 PM, Chinmaya Sn chinm...@gmail.com wrote:
Thanks All. I think I am getting the general idea of what can get into
to WebKit and how things fit.
Right now both the standard and implementation are WIP, spec is intended to
be a Web standard. At this point, neither
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and I discussed at WWDC (yes, this email has been a
long time coming) is better programming patterns to prevent memory
leaks. As I'm sure you know, whenever you allocate a RefCounted
object, you need to call adoptRef to prevent a memory
http://en.wikipedia.org/wiki/XBL , I guess?
FYI XBL has been superseded by XBL 2.0 that is not backward compatible
with the first version [1]. Thus our code is just obsolete.
Regards,
Julien
[1] http://www.w3.org/TR/xbl/#relationship
___
webkit-dev
On Aug 25, 2010, at 9:11 AM, Julien Chaffraix wrote:
http://en.wikipedia.org/wiki/XBL , I guess?
FYI XBL has been superseded by XBL 2.0 that is not backward compatible
with the first version [1]. Thus our code is just obsolete.
All XBL-related code in WebKit is for XBL2. It seems as if
The existing code is very confused. For example, it doesn't seem to
know that RefCounted objects start with an initial ref. My guess is
that it was written a long time ago and then was abandoned. As the
project moved forward, this code got left behind.
Adam
On Wed, Aug 25, 2010 at 9:26 AM,
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmus supersti...@gmx.de wrote:
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and I discussed at WWDC (yes, this email has been a
long time coming) is better programming patterns to prevent memory
leaks. As I'm sure you know, whenever you
I recommend removing the XBL code. Hyatt started it years ago.
Jullien works on it for a summer as my GSoC mentee.
Anyone who wants to write a fully working XBL2 implementation can look
in svn history. As-is, it's untested, unbuildable, and a drag on the
project.
-eric
On Wed, Aug 25, 2010 at
I think Hyatt should comment on this before we decide. I do think that removing
the code would be good but he may have some additional insight.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
There seem to be a bunch of files missing too. For example, I can't
find XBLDocument or XMLBindingsManager.
I don't mean to hate on XBL, I just started looking at it when
deploying adoptPtr and was surprised by what I found, that's all.
Adam
On Wed, Aug 25, 2010 at 10:13 AM, Darin Adler
Ok. I've posted a patch:
https://bugs.webkit.org/show_bug.cgi?id=44621
Adam
On Wed, Aug 25, 2010 at 10:17 AM, Adam Barth aba...@webkit.org wrote:
There seem to be a bunch of files missing too. For example, I can't
find XBLDocument or XMLBindingsManager.
I don't mean to hate on XBL, I
On Tue, Aug 24, 2010 at 5:31 PM, Darin Adler da...@apple.com wrote:
If overloading can be used to determine how to do the
take a ref and release a ref functions, then many different
subsystems can share a single PassRefPtr/RefPtr class.
One complication in the GObject case, is that the
Furthermore, any loops like this:
for (RefPtrNode child = m_element-firstChild(); child;) {
which allow synchronous javascript execution (i.e. take an
ExceptionCode parameter) are vulnerable to crashes/security holes. :(
All of those enclose* functions use such loops. :(
-eric
On Wed, Aug
My comments apply to all of the enclose* APIs in that file.
On Wed, Aug 25, 2010 at 11:46 AM, Eric Seidel e...@webkit.org wrote:
/*!
Encloses the contents of this element with the result of parsing \a markup.
This element becomes the child of the deepest descendant within \a markup.
/*!
Encloses the contents of this element with the result of parsing \a markup.
This element becomes the child of the deepest descendant within \a markup.
\sa encloseWith()
*/
void QWebElement::encloseContentsWith(const QString markup)
Could you file bugs for these?
Also, do you know of any other way of accomplishing the same behaviour
without having security issues/crashes?
Kenneth
On Wed, Aug 25, 2010 at 3:51 PM, Eric Seidel e...@webkit.org wrote:
Furthermore, any loops like this:
for (RefPtrNode child =
They are methods for manipulating the DOM, modelled after jQuery. The
documentation should explain pretty well what they do.
Is it possible to accomplish the same behaviour with the new parser
API? We need to continue supporting this API due to our binary
compatibility, plus because of the fact
Btw, Eric,
We have unit tests for the QWebElement API in
WebKit/qt/tests/qwebelement/ so you can see the use-cases, if that
helps.
Cheers,
Kenneth
On Wed, Aug 25, 2010 at 3:58 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
They are methods for manipulating the DOM,
The code can be removed.
dave
On Aug 25, 2010, at 12:17 PM, Adam Barth wrote:
There seem to be a bunch of files missing too. For example, I can't
find XBLDocument or XMLBindingsManager.
I don't mean to hate on XBL, I just started looking at it when
deploying adoptPtr and was surprised by
Sorry for the late-night webkit-dev spam, but in deploying adoptPtr,
I've noticed a number of places where have a HashMap that owns its
values as OwnPtrs. Unfortunately, this very clumsy currently. Each
instance of this pattern has its own way of hacking around the
problem, which might or
Am 25.08.2010 18:35, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmussupersti...@gmx.de wrote:
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and I discussed at WWDC (yes, this email has been a
long time coming) is better programming patterns to prevent memory
On Wed, Aug 25, 2010 at 2:31 PM, Stephan Assmus supersti...@gmx.de wrote:
Am 25.08.2010 18:35, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmussupersti...@gmx.de
wrote:
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and I discussed at WWDC (yes, this email has
On Wed, Aug 25, 2010 at 2:34 PM, Adam Barth aba...@webkit.org wrote:
On Wed, Aug 25, 2010 at 2:31 PM, Stephan Assmus supersti...@gmx.de
wrote:
Am 25.08.2010 18:35, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmussupersti...@gmx.de
wrote:
Am 24.08.2010 19:46, schrieb
Am 25.08.2010 23:34, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 2:31 PM, Stephan Assmussupersti...@gmx.de wrote:
Am 25.08.2010 18:35, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmussupersti...@gmx.de
wrote:
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and
On Aug 25, 2010, at 1:46 PM, Geoffrey Garen wrote:
Sorry for the late-night webkit-dev spam, but in deploying adoptPtr,
I've noticed a number of places where have a HashMap that owns its
values as OwnPtrs. Unfortunately, this very clumsy currently. Each
instance of this pattern has its own
Just to clarify, I'm only looking to add exception throwing to
cross-origin property accesses of the location object, not for the
whole window object.
As for real-world uses of location.href throwing an exception, a new
comment just got added to:
On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig sam.weinig at gmail.com wrote:
I am not sure I agree. Does our behavior actually cause any real bugs in
the places you have tracked down? The log spam really doesn't seem like an
issue, we can remove it if we want to, but have found it useful in the
On Aug 25, 2010, at 6:06 PM, Rob Barreca wrote:
We need a way to test for the security exception or at least detect some
other property of window.top and then do window.open(url) instead when that
security error is trapped or we detect different-origin.
Does checking the value of
On Wed, Aug 25, 2010 at 3:23 PM, Darin Adler da...@apple.com wrote:
Does checking the value of window.top.location.href afterward work? Or
maybe that doesn’t happen until some unpredictable amount of time later when
the load makes progress?
Hey Darin, thanks for the reply. Unfortunately
32 matches
Mail list logo
