On Mon, Aug 16, 2010 at 9:43 PM, Dean Jackson wrote:
> It was suggested I bring this to webkit-dev.
>
> There was some recent work to move the many parameters passed to the Page
> constructor into a single PageClients structure. The current assumption is
> that if a feature is enabled (at runtime
Hi all,
following is the related code. My question is why it returns false
when ScheduledRedirection.type is redirection.
>From the name of the function, I think if the url changes, it should return
true. Thus, for most of redirection, it should return true.
//FrameLoader.cpp
bool FrameLoader::is
Where-ever it goes, please don't put it on Document directly. :)
(Feel free to tie it to Document's lifetime, just don't add to
Document's 300+ methods.)
The madness must stop... Document is long overdue for some weightloss...
-eric
On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson wrote:
> Hi,
>
It was suggested I bring this to webkit-dev.
There was some recent work to move the many parameters passed to the Page
constructor into a single PageClients structure. The current assumption is that
if a feature is enabled (at runtime or compile time) then Page will always get
a non-null client
Hi,
I've been looking into implementing the clients for DeviceOrientation/Motion
Events. Currently, the controllers for these events are members of Page. I
think they are better suited on Document.
Here are a few reasons:
- Page isn't tied to any actual web page or document. Would we want to s
On Aug 16, 2010, at 4:26 PM, Darin Fisher wrote:
> On Mon, Aug 16, 2010 at 2:43 PM, Chris Marrin wrote:
>
>
> I'm not familiar with what update-webkit does. But the only reason ANGLE is
> in the root is because a couple of people here said that was the best way to
> do it. ANGLE is a pretty
On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote:
> On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak wrote:
>> 1) It means the access control goes in fewer places - we don't have to have
>> access control on every document property, only window properties.
>
> I'm not quite sure I understa
On Aug 16, 2010, at 12:44 PM, Ojan Vafai wrote:
> I agree that dealing with the script to generate tests and having the actual
> test content be in a different file is a significant maintenance overhead.
> But I also think that having standard testing code across many tests reduces
> the amoun
On Mon, Aug 16, 2010 at 2:43 PM, Chris Marrin wrote:
>
> On Aug 16, 2010, at 2:21 PM, David Hyatt wrote:
>
> > On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
> >
> >> On Sat, Aug 14, 2010 at 4:21 PM, wrote:
> >> >
> >> > On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
> >> >
> >> >> Hi,
>
The changes to ImageBuffer have landed. Here is what port authors need to know:
Image* image() on ImageBuffer is gone.
It has been replaced with:
PassRefPtr copyImage()
This function should always simply copy the image. It is used in any place
where you want to get a snapshot of the ImageBu
On Aug 16, 2010, at 2:21 PM, David Hyatt wrote:
> On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
>
>> On Sat, Aug 14, 2010 at 4:21 PM, wrote:
>> >
>> > On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
>> >
>> >> Hi,
>> >>
>> >> ANGLE looks like a graphics helper library. Why it is placed i
Joseph said "there is a proprietary web app that relies on this, but it
is used at a small company I no longer work for and have no access to" and
did report the original bug, so that would appear to be a real-world bug.
My understanding is that the the log spam problem is annoying for teams that
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
> On Sat, Aug 14, 2010 at 4:21 PM, wrote:
> >
> > On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
> >
> >> Hi,
> >>
> >> ANGLE looks like a graphics helper library. Why it is placed in the root
> >> WebKit directory? Perhaps WebCore/platform/gr
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
past.
I agree with Maciej that the current behavior is in many ways better, s
Is it possible to make the Qt/Windows EWS bots report what the build errors
actually were? Qt doesn't seem to provide any stdio output. MSVC does, but
it logs the output into BuildLog.htm files--would it be possible to scrape
the text information out of these files and make them available?
I ask b
I was wondering if there are any other thoughts on this. It seems like
there's real-world need from this (based on the usages I tracked down, and
log spam problem) and all other browsers (and the HTML5 spec) have the
exception-throwing behavior.
Thanks,
Mihai
On Fri, Aug 13, 2010 at 10:19 AM, Mih
I agree that dealing with the script to generate tests and having the actual
test content be in a different file is a significant maintenance overhead.
But I also think that having standard testing code across many tests reduces
the amount of effort it takes to understand a test.
We discussed this
17 matches
Mail list logo
