On Sep 14, 2010, at 9:58 PM, Jian Li wrote:
> Indeed when I implement BlobResourceHandle, I have taken the range request
> support into consideration and got it work. The problem is that current media
> element implementation does not route through ResourceHandle.
>
> However, introducing a Re
On Sep 14, 2010, at 5:54 PM, Andreas Kling wrote:
> I propose we add a "Canvas" component in Bugzilla. Thoughts?
Sounds OK to me.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-
On Tue, Sep 14, 2010 at 10:09 PM, Adam Barth wrote:
> One thing that Maciej suggested in #webkit was to interpose in the
> same way that appcache interposes. One advantage of that approach is
> economy of mechanism.
>
I think we have mostly done this. See BlobRegistry.
>
> (By the way, round
I think it makes sense to extend ResourceHandle.cpp to access the
BlobRegistry singleton in order to support blob URLs. This will work for
all ports that use ResourceHandle.cpp (everyone except Chromium AFAIK). I
don't think we need to overabstract this.
When designing this system, we took a har
One thing that Maciej suggested in #webkit was to interpose in the
same way that appcache interposes. One advantage of that approach is
economy of mechanism.
(By the way, roundtrips to WebCore are cheap for the WebKit layer;
there isn't much reason to avoid them.)
Adam
On Tue, Sep 14, 2010 at
On Tue, Sep 14, 2010 at 5:52 PM, Maciej Stachowiak wrote:
>
> On Sep 14, 2010, at 5:22 PM, Adam Barth wrote:
>
> >
> > In some sense, this is analogous to adding an HTTPResourceHandle and
> > implementing the HTTP protocol inside of WebCore. While its true that
> > most (all?) users of WebKit wi
Indeed when I implement BlobResourceHandle, I have taken the range request
support into consideration and got it work. The problem is that current
media element implementation does not route through ResourceHandle.
However, introducing a ResourceHandle subclass does not sound like an
elegant solut
Ok, after following down a few rabbit holes, I can with some degree of
certainty say that node->renderer()->node() == 0 can only at the end
of RenderWidget::destroy(), but that is clearly not the case we're
fishing for.
Even if we modify the loop to start at the parent, we're jumping into
the rend
Ojan could also autoupdate the extension to be a noop.
- a
On Tue, Sep 14, 2010 at 7:10 PM, Adam Barth wrote:
> Hi webkit-dev,
>
> I just landed a change to bugs.webkit.org to autocomplete email
> address for committers and reviewers. If you've been using Ojan's
> awesome extension, it's the sa
14.09.2010, в 19:10, Adam Barth написал(а):
> Let me know if you have feedback on the feature.
Yes, I do. It's awesome!
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/w
Sounds good, I will look into this. FWIW, when I remove this loop, I
see no regressions in layout tests, including the tests added with the
same commit as the loop.
:DG<
On Tue, Sep 14, 2010 at 5:55 PM, Maciej Stachowiak wrote:
>
> On Sep 14, 2010, at 5:41 PM, Dimitri Glazkov wrote:
>
>> Sorry,
Hi webkit-dev,
I just landed a change to bugs.webkit.org to autocomplete email
address for committers and reviewers. If you've been using Ojan's
awesome extension, it's the same code, just now natively part of
bugs.webkit.org thanks to William Siegrist being awesome. (Note that
if you have the e
On Tue, Sep 14, 2010 at 6:53 PM, Oliver Hunt wrote:
>
> On Sep 14, 2010, at 5:56 PM, David Levin wrote:
>
> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
>
>> What do you think of the idea of having a re-useable BlobCore module
>> that all the ports can share?
>>
>
> I don't think this is a
On Sep 14, 2010, at 5:56 PM, David Levin wrote:
> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> What do you think of the idea of having a re-useable BlobCore module
> that all the ports can share?
>
> I don't think this is a good idea. This "re-usable module" would only be used
> by the
On Sep 14, 2010, at 6:02 PM, Adam Barth wrote:
> On Tue, Sep 14, 2010 at 5:56 PM, David Levin wrote:
>> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
>>> What do you think of the idea of having a re-useable BlobCore module
>>> that all the ports can share?
>>
>> I don't think this is a go
On Tue, Sep 14, 2010 at 6:02 PM, Adam Barth wrote:
> On Tue, Sep 14, 2010 at 5:56 PM, David Levin wrote:
> > On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> >> What do you think of the idea of having a re-useable BlobCore module
> >> that all the ports can share?
> >
> > I don't think this
On Tue, Sep 14, 2010 at 5:56 PM, David Levin wrote:
> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
>> What do you think of the idea of having a re-useable BlobCore module
>> that all the ports can share?
>
> I don't think this is a good idea. This "re-usable module" would only be
> used by
On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> What do you think of the idea of having a re-useable BlobCore module
> that all the ports can share?
>
I don't think this is a good idea. This "re-usable module" would only be
used by the Safari WebKit port. As I understand it, Chromium wouldn
On Sep 14, 2010, at 5:41 PM, Dimitri Glazkov wrote:
> Sorry, I meant node->renderer()->node() != 0. My bad. This loop will
> always exit in in the first iteration.
It definitely is possible for renderers to have a null result from node(). I do
not know for sure that it's impossible for node->re
Hey folks!
I propose we add a "Canvas" component in Bugzilla. Thoughts?
-Kling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Sep 14, 2010, at 5:22 PM, Adam Barth wrote:
>
> In some sense, this is analogous to adding an HTTPResourceHandle and
> implementing the HTTP protocol inside of WebCore. While its true that
> most (all?) users of WebKit will need to wire WebCore up to an HTTP
> library, that doesn't necessari
I think it is a good idea but it will involve lots of work to figure out how
to build and test such module that could be used by all the ports. My
concern is that I do not have enough resource to speak of for all other
ports. Thanks.
On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth wrote:
> What do
What do you think of the idea of having a re-useable BlobCore module
that all the ports can share?
Adam
On Tue, Sep 14, 2010 at 5:39 PM, Jian Li wrote:
> When I implemented the blob scheme handling, I intentionally tried to have
> some common implementation that could be used by all applicable
Sorry, I meant node->renderer()->node() != 0. My bad. This loop will
always exit in in the first iteration.
:DG<
On Tue, Sep 14, 2010 at 4:45 PM, Adam Roben wrote:
> On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote:
>
>> I've been looking at this line here and it doesn't seem to make sense
>>
When I implemented the blob scheme handling, I intentionally tried to have
some common implementation that could be used by all applicable platforms.
But it seems that introducing BlobResourceHandle derived from ResourceHandle
might not be a good hook up point because ResourceHandle is only a wrapp
Jian Li just had a conversation in #webkit about where the code for
implementing the Blob URL scheme should live. I thought I'd open the
discussion to webkit-dev in case folks had a different perspective.
As part of the fileapi, we're introducing a new URL scheme, called
blob, which represents a
On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote:
> I've been looking at this line here and it doesn't seem to make sense
> to me:
> http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153
>
> It looks like the loop in question will always exit early, because it
> short-circui
On August 16, 2010, David Hyatt wrote:
> There is a temporary method implemented by all ports called:
>
> bool drawsUsingCopy() const; // If the image buffer has to
> render
using a
> copied image, it will return true.
>
> This method only exists right now because some of the port
Dear WebKit,
I've been looking at this line here and it doesn't seem to make sense
to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153
It looks like the loop in question will always exit early, because it
short-circuits to node->renderer()->node() == node, which seems
Build.webkit.org will be down tomorrow for a software upgrade starting around
8am PDT. Total downtime should be less than 1 hour. This is fairly short
notice, so I apologize for that, but we're trying to fix the performance issues
we've been experiencing. You may have trouble running webkit-pa
On Tue, Sep 14, 2010 at 10:38 AM, Jeremy Orlow wrote:
>
> It's worth noting that Android also uses v8 and skia. They only have one
> reviewer at the moment, but it still might be best to not associate Chromium
> with skia/v8 changes.
>
> As for the original questions: does anyone actually use any
On Tue, Sep 14, 2010 at 6:32 PM, David Levin wrote:
>
>
> On Tue, Sep 14, 2010 at 10:28 AM, Adam Barth wrote:
>
>> We're not very good at using these fields in Bugzilla. In this
>> situation, folks will usually prefix the summary of the bug with
>> "[Chromium]". This is a signal to reviewers t
On Tue, Sep 14, 2010 at 10:28 AM, Adam Barth wrote:
> We're not very good at using these fields in Bugzilla. In this
> situation, folks will usually prefix the summary of the bug with
> "[Chromium]". This is a signal to reviewers that they might be more
> or less interested in reviewing the pat
We're not very good at using these fields in Bugzilla. In this
situation, folks will usually prefix the summary of the bug with
"[Chromium]". This is a signal to reviewers that they might be more
or less interested in reviewing the patch depending on whether they
like/feel comfortably with review
Hi,
I tend to hit code which is often chromium-platform specific. It's hard to
know the appropriate "Platform" and "OS" fields for such a bug. For
instance, I am working on a small change to WebKit/chromium/src/WebKit.cpp.
It's not a Mac bug, its not a PC bug, its a Chromium bug.
Chromium is a
35 matches
Mail list logo
