Re: [webkit-dev] Is this a possible source of test flakiness?

[Xianzhu Wang]

Bug filed: https://bugs.webkit.org/show_bug.cgi?id=54942
I'll work on the bug this week.

2011/2/22 Darin Adler 

> I misread this and thought it was the unload attribute on the body element,
> not an iframe element.
>
> My answer was completely wrong for an iframe element!
>
>-- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Trouble with updating Chromium' slayout test expectations

[Hajime Morita]

Hi Chromium WebKit folks,

I'm looking for a help to retrieve the latest expectation files for
Chromium Mac LayoutTest.
At the weekend there was a change that triggers massive amount of
pixel test failures that requires rebaselining.
(https://bugs.webkit.org/b/54736)
But the buildbot doesn't have the latest result for part of them, that means

 * rebaseline-chromium-webkit-tests doesn't update pixel results
 * [layout test results] links on buildbot dashboard are broken.

Then now around 100 tests for Mac Chromium are
left marked as failed (BUGWK54736 lines), waiting for their fresh expectations.

Unfortunately I have no idea what's happening
but missing 100 tests will possibly hurt us.
How could I update these expectations?
Any suggestions and/or helps are appreciated.

Regards.
--
morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing the element

[Adam Bergkvist]

Hi,

On 2011-02-15 17:50, Leandro Graciá Gil wrote:
> Yes, the platform independent code in the device element will determine
> if a selection has been made, or altered, in the list of available
> devices
> Provided by the platform. Before passing it to the device element, the
> list can be filtered by the platform to exclude some entries for
> whatever
> reason. Selections can also be automatically applied without showing the
> Device selector based on, e.g., stored preferences. The device element
> will examine the list for selection changes to determine if a new device
> handler should be created (and a change event dispatched).
>
> Consider the following example:
> 1. The user clicks the device element button and a list of devices is
>presented.
> 2. The user selects a webcam in the list and clicks OK.
> *A new Stream is created*
> 3. The user once again clicks the device element button and the list
>is presented with the webcam selected from before.
> 4. The user clicks OK.
> *No new Stream is created*
> 5. The user once again clicks the device element button and the list
>is presented with the webcam selected from before.
> 6. The user selects a microphone in the list and clicks OK.
> *A new Stream is created*
>
> This is the behavior that should be consistent between ports.
>
>
> I agree that this behavior should be consisted between ports. However,
> we seem to be missing a case here: what happens if the user wants to
> revoke access to a device in the middle of a streaming session? We need
> to be able to allow this case for obvious privacy reasons.
>

I agree that this is definitively something we need to consider, but perhaps
as a (near) future improvement. In fact, we have previously been discussing
how to revoke device access and came to the conclusion that it must be done
via the browser chrome since the device element can be removed from the page
as soon as access has been granted. A natural choice would be to combine
this with the mechanism for indicating that a camera/mic is active
(discussed in the initial device thread
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0149.html).
That would however require additions to the WebKit API. We have left this
out in the first version, simply because it is not mentioned in the spec,
and prioritized to land an initial implemenation that could be used as a
basis for improvements. 

> We need a way to let the UA maintain the lifetime of Stream objects.
> These can be killed by the UA at any point (perhaps due to user action
> or hardware failure), so we need to specify what happens to these
> objects in such a case. We also need to design our implementation in a
> way that can handle this situation.
>
> As far as I know, and please correct me if I'm wrong, your proposed
> design doesn't provide the user a clear way to invalidate a stream if he
> wants to. The Stream's lifetime is something completely handled by the
> platform-specific client and with no presence at all in the common
> WebCore code. We think this should also be an essential part of the
> common behaviour across platforms.
>

The patch for bug 47264 does not contain anything related to Stream; it is
a device element only patch (bug 47265 is for the Stream API). We should
not confuse the lifetime of Stream objects (or any other device handler API)
with the API's way of handling errors (e.g. that its access to the device
has been revoked). Revoking access to a device should probably be handled in
the same way (in the device handler API) as physically unplugging the device. 

> It will be up to the device handler API (e.g. Stream) and its potential
> consumers to handle any errors that may occur. Exclusiveness for certain
> types of devices being one type of error. Another error occurs when a
> peripheral device is disconnected while in use. Even if you have
> established a "connection" to the device via the device element,
> handling such an error in the device handler API is still required since
> it is not possible to revoke a device handler instance.
>
>
> I think this impossibility to revoke a device handler instance is
> currently the essence of our main divergence point, and something that
> should be discussed in the specification.
>

Let me clearify what I meant. It is not possible to revoke the actual instance
of the device handler. The device handler API would need to handle that it no
longer has access to the device it was created to control.

> Do you see anything in our implementation that could not be easily
> delegated? As I said before, I would be happy to make any changes that
> would be required to implement the platform specific parts for Chromium.
>
>
> And we thank you for that, but before fixing any implementation details
> we think that the problem first needs to be discussed at the
> specification level.

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

[Mihai Parparita]

It looks like Drew checked in baselines with
http://trac.webkit.org/changeset/79034 (which may be why
rebaseline-chromium-webkit-tests isn't doing anything, since it
already has "correct" pixel baselines), but given
http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
any ideas why?

Mihai

On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita  wrote:
> Hi Chromium WebKit folks,
>
> I'm looking for a help to retrieve the latest expectation files for
> Chromium Mac LayoutTest.
> At the weekend there was a change that triggers massive amount of
> pixel test failures that requires rebaselining.
> (https://bugs.webkit.org/b/54736)
> But the buildbot doesn't have the latest result for part of them, that means
>
>  * rebaseline-chromium-webkit-tests doesn't update pixel results
>  * [layout test results] links on buildbot dashboard are broken.
>
> Then now around 100 tests for Mac Chromium are
> left marked as failed (BUGWK54736 lines), waiting for their fresh 
> expectations.
>
> Unfortunately I have no idea what's happening
> but missing 100 tests will possibly hurt us.
> How could I update these expectations?
> Any suggestions and/or helps are appreciated.
>
> Regards.
> --
> morrita
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Remote debugger

[Sergiy Temnikov]

OK, cool! Thanks a lot. Nice to see a functioning browser to browser debugging. 
Do you know if the Web Inspector protocol specification is stable and finalized 
now?
Thanks!

-Sergiy


De : Joseph Pecoraro [mailto:pecor...@apple.com]
Envoyé : vendredi 18 février 2011 19:31
À : Sergiy Temnikov
Cc : webkit-dev@lists.webkit.org; Pavel Feldman; loi...@chromium.org; 
pmue...@yahoo.com
Objet : Re: [webkit-dev] Remote debugger

Hello Sergiy,

I've got a bunch of links for different areas where work has been done.

Some information on the "protocol" and is outlined in the following links. I 
don't think they are up to date; I think things have improved and evolved since 
then. Pavel and Ilya may be able to comment more on the protocol since there 
has been quite a bit of work recently splitting it up into different domains to 
turn on/off debugging different "domains" or feature sets. But I think the 
protocol has been stable for a while. I think they even had some discussion 
with the Firebug team when they talked about a debugging protocol, but I can't 
seem to find where that discussion took place.
 Web Inspector: Remote debugging meta-bug
https://docs.google.com/document/edit?id=1d_N-OIb3UztuC-_g0piXsIIdp89HnMcDk-uSQ8uamW4&hl=en&authkey=CIf48O4J&pli=1#

Here is a screencast, previously posted to this list, of it working in Chromium:
https://lists.webkit.org/pipermail/webkit-dev/2010-August/013797.html
http://screencast.com/t/YTI2OTY4YTEt

There has been some work on an internal WebKit solution based on Web Sockets:
 Web Inspector: Remote Web Inspector support for 
QtWebKit [Already Landed]
 Web Inspector: Remote Web Inspector - Cross 
Platform InspectorServer [Open - Issues to be Worked Out]

External to WebKit, Patrick Mueller has been working on weinre. Patrick is on 
this list and might comment more:
http://pmuellr.github.com/weinre/index.html (https://github.com/pmuellr/weinre)
http://muellerware.org/papers/weinre/manual.html

- Joe

On Feb 18, 2011, at 7:04 AM, Sergiy Temnikov wrote:



Hello,

I'm working on a remote JavaScript debugger for a server which uses webkit to 
execute JavaScript code. The debugger is shaping up nicely and is already very 
much functional. We chose Crossfire as the debugging protocol and developed our 
own UI debugger client. However, being Crossfire-compatible, should allow us in 
the (hopefully near) future to debug the server-side JavaScript using Firefox 
with Firebug and Crossfire plug-ins. I was wondering if there are any plans in 
the webkit community to create a native remote JavaScript debugger as part of 
the webkit build. If there are such plans then what would be the debugging 
protocol of choice? Webkit is already available on mobile devices but because 
of the screen size limitations it is not always reasonable to debug the 
Javascript directly on a device. Instead, it would be nice to debug the 
device's  JavaScript from a regular PC over the network.
If any of you are already working on a similar subject then please share your 
thoughts and comments regarding your particular implementation, which protocol 
you use and how you see remote debugging appearing in webkit.

Regards,

-Sergiy Temnikov



<3fa2fb.png>

Sergiy Temnikov

Architecte Logiciel


Email :

sergiy.temni...@4d.com

Web :

www.4D.com


4D SAS

60, rue d'Alsace

92110 Clichy - France


Standard :

+33 1 40 87 92 00














___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Remote debugger

[Sergiy Temnikov]

Hello,

I have not been on the calls but I have posted about my remote debugger work on 
the FireBug working group message board. It is true that Crossfire is smaller 
than the Web Inspector protocol but it has all I need for the remote debugging 
of a faceless server that runs JavaScript.
In fact the two protocols are quite close to each other, at least the part 
related to the source code inspection and tracing. I might even support both 
seeing that it does not require too much work to reformat messages from one 
protocol to another. I wish the two protocols were unified and compatible :-)

-Sergiy



[cid:f9ed10.png@1aafdebe.4b9b52d9]
Sergiy Temnikov
Architecte Logiciel
Email : sergiy.temni...@4d.com
Web :   www.4D.com

4D SAS
60, rue d'Alsace
92110 Clichy - France
Standard :  +33 1 40 87 92 00


De : Patrick Mueller [mailto:pmue...@gmail.com]
Envoyé : vendredi 18 février 2011 20:08
À : Joseph Pecoraro
Cc : Sergiy Temnikov; webkit-dev@lists.webkit.org; Pavel Feldman; 
loi...@chromium.org
Objet : Re: [webkit-dev] Remote debugger

Hello Sergiy,

Have you been on any of the FireBug working group calls?  Wondering if John J 
Barton and Michael Collins (like me, they also work at IBM) are familiar with 
your work.  I join the calls occasionally, just to keep up to speed with 
CrossFire, and don't remember hearing from you - but I also don't pay a whole 
lot of attention during those calls :-)

My understanding is that CrossFire really only supports JS breakpoints at the 
moment - if you look at the protocol that Web Inspector uses, you'll see it's 
quite a bit larger.

In addition to everything Joe mentioned, there's a guy who has Web Inspector 
hooked up to node.js for doing source-level debugging with node with the WI 
front-end.  https://github.com/dannycoates/node-inspector - I keep meaning to 
get in touch with that guy, but haven't yet.
On Fri, Feb 18, 2011 at 13:31, Joseph Pecoraro 
mailto:pecor...@apple.com>> wrote:


On Feb 18, 2011, at 7:04 AM, Sergiy Temnikov wrote:




<>___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

[Drew Wilson]

Yeah, it's weird. I rebaselined those tests, but the chromium canaries still
showed them as red. Now, however, the canaries are showing many of them
passing. I was planning to remove the lines from test_expectations today to
see if they stay green.

-atw

On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita wrote:

> It looks like Drew checked in baselines with
> http://trac.webkit.org/changeset/79034 (which may be why
> rebaseline-chromium-webkit-tests isn't doing anything, since it
> already has "correct" pixel baselines), but given
> http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
> any ideas why?
>
> Mihai
>
> On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita  wrote:
> > Hi Chromium WebKit folks,
> >
> > I'm looking for a help to retrieve the latest expectation files for
> > Chromium Mac LayoutTest.
> > At the weekend there was a change that triggers massive amount of
> > pixel test failures that requires rebaselining.
> > (https://bugs.webkit.org/b/54736)
> > But the buildbot doesn't have the latest result for part of them, that
> means
> >
> >  * rebaseline-chromium-webkit-tests doesn't update pixel results
> >  * [layout test results] links on buildbot dashboard are broken.
> >
> > Then now around 100 tests for Mac Chromium are
> > left marked as failed (BUGWK54736 lines), waiting for their fresh
> expectations.
> >
> > Unfortunately I have no idea what's happening
> > but missing 100 tests will possibly hurt us.
> > How could I update these expectations?
> > Any suggestions and/or helps are appreciated.
> >
> > Regards.
> > --
> > morrita
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

[Mikhail Naganov]

I have a suspicion that the cause of canaries failures is described
here: 
https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d
In short, bots can run tests prematurely, emitting false failures. I
observed this during my gardening, and I think you should check which
revisions of WebKit and Chromium bots used while running tests.

On Tue, Feb 22, 2011 at 20:16, Drew Wilson  wrote:
> Yeah, it's weird. I rebaselined those tests, but the chromium canaries still
> showed them as red. Now, however, the canaries are showing many of them
> passing. I was planning to remove the lines from test_expectations today to
> see if they stay green.
> -atw
>
> On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita 
> wrote:
>>
>> It looks like Drew checked in baselines with
>> http://trac.webkit.org/changeset/79034 (which may be why
>> rebaseline-chromium-webkit-tests isn't doing anything, since it
>> already has "correct" pixel baselines), but given
>> http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
>> any ideas why?
>>
>> Mihai
>>
>> On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita  wrote:
>> > Hi Chromium WebKit folks,
>> >
>> > I'm looking for a help to retrieve the latest expectation files for
>> > Chromium Mac LayoutTest.
>> > At the weekend there was a change that triggers massive amount of
>> > pixel test failures that requires rebaselining.
>> > (https://bugs.webkit.org/b/54736)
>> > But the buildbot doesn't have the latest result for part of them, that
>> > means
>> >
>> >  * rebaseline-chromium-webkit-tests doesn't update pixel results
>> >  * [layout test results] links on buildbot dashboard are broken.
>> >
>> > Then now around 100 tests for Mac Chromium are
>> > left marked as failed (BUGWK54736 lines), waiting for their fresh
>> > expectations.
>> >
>> > Unfortunately I have no idea what's happening
>> > but missing 100 tests will possibly hurt us.
>> > How could I update these expectations?
>> > Any suggestions and/or helps are appreciated.
>> >
>> > Regards.
>> > --
>> > morrita
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

[Mihai Parparita]

But these were rebaselines, which don't depend on any code changes.

Mihai

On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov  wrote:
> I have a suspicion that the cause of canaries failures is described
> here: 
> https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d
> In short, bots can run tests prematurely, emitting false failures. I
> observed this during my gardening, and I think you should check which
> revisions of WebKit and Chromium bots used while running tests.
>
> On Tue, Feb 22, 2011 at 20:16, Drew Wilson  wrote:
>> Yeah, it's weird. I rebaselined those tests, but the chromium canaries still
>> showed them as red. Now, however, the canaries are showing many of them
>> passing. I was planning to remove the lines from test_expectations today to
>> see if they stay green.
>> -atw
>>
>> On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita 
>> wrote:
>>>
>>> It looks like Drew checked in baselines with
>>> http://trac.webkit.org/changeset/79034 (which may be why
>>> rebaseline-chromium-webkit-tests isn't doing anything, since it
>>> already has "correct" pixel baselines), but given
>>> http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
>>> any ideas why?
>>>
>>> Mihai
>>>
>>> On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita  wrote:
>>> > Hi Chromium WebKit folks,
>>> >
>>> > I'm looking for a help to retrieve the latest expectation files for
>>> > Chromium Mac LayoutTest.
>>> > At the weekend there was a change that triggers massive amount of
>>> > pixel test failures that requires rebaselining.
>>> > (https://bugs.webkit.org/b/54736)
>>> > But the buildbot doesn't have the latest result for part of them, that
>>> > means
>>> >
>>> >  * rebaseline-chromium-webkit-tests doesn't update pixel results
>>> >  * [layout test results] links on buildbot dashboard are broken.
>>> >
>>> > Then now around 100 tests for Mac Chromium are
>>> > left marked as failed (BUGWK54736 lines), waiting for their fresh
>>> > expectations.
>>> >
>>> > Unfortunately I have no idea what's happening
>>> > but missing 100 tests will possibly hurt us.
>>> > How could I update these expectations?
>>> > Any suggestions and/or helps are appreciated.
>>> >
>>> > Regards.
>>> > --
>>> > morrita
>>> > ___
>>> > webkit-dev mailing list
>>> > webkit-dev@lists.webkit.org
>>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> >
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

[Mikhail Naganov]

Ah, true. The code changes were long ago.

On Tue, Feb 22, 2011 at 21:40, Mihai Parparita  wrote:
> But these were rebaselines, which don't depend on any code changes.
>
> Mihai
>
> On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov  
> wrote:
>> I have a suspicion that the cause of canaries failures is described
>> here: 
>> https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d
>> In short, bots can run tests prematurely, emitting false failures. I
>> observed this during my gardening, and I think you should check which
>> revisions of WebKit and Chromium bots used while running tests.
>>
>> On Tue, Feb 22, 2011 at 20:16, Drew Wilson  wrote:
>>> Yeah, it's weird. I rebaselined those tests, but the chromium canaries still
>>> showed them as red. Now, however, the canaries are showing many of them
>>> passing. I was planning to remove the lines from test_expectations today to
>>> see if they stay green.
>>> -atw
>>>
>>> On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita 
>>> wrote:

 It looks like Drew checked in baselines with
 http://trac.webkit.org/changeset/79034 (which may be why
 rebaseline-chromium-webkit-tests isn't doing anything, since it
 already has "correct" pixel baselines), but given
 http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
 any ideas why?

 Mihai

 On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita  wrote:
 > Hi Chromium WebKit folks,
 >
 > I'm looking for a help to retrieve the latest expectation files for
 > Chromium Mac LayoutTest.
 > At the weekend there was a change that triggers massive amount of
 > pixel test failures that requires rebaselining.
 > (https://bugs.webkit.org/b/54736)
 > But the buildbot doesn't have the latest result for part of them, that
 > means
 >
 >  * rebaseline-chromium-webkit-tests doesn't update pixel results
 >  * [layout test results] links on buildbot dashboard are broken.
 >
 > Then now around 100 tests for Mac Chromium are
 > left marked as failed (BUGWK54736 lines), waiting for their fresh
 > expectations.
 >
 > Unfortunately I have no idea what's happening
 > but missing 100 tests will possibly hurt us.
 > How could I update these expectations?
 > Any suggestions and/or helps are appreciated.
 >
 > Regards.
 > --
 > morrita
 > ___
 > webkit-dev mailing list
 > webkit-dev@lists.webkit.org
 > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 >
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

[Drew Wilson]

That's an interesting thread. I had always assumed that either the testers
always synced to the same rev as the builders, or at least that they pulled
the layout test files/expectations from the builders along with the
executables. Not doing this just seems inherently broken, but I understand
why we do it.

BTW, I'm figuring that most of webkit-dev can't access that group - here's
the summary, pulled from the public chromium documentation:

*Breaks Canary bots.* Canary test bots pick the latest WebKit revision
available. Because test bots start later than build bots, test bots tend to
pick later revisions.  i.e. when a build bot picks a revision X, the
corresponding test bot will pick a revision X+delta where delta >= 0.  This
implies that any new tests added or rebaselines done in the interval (X,
X+delta] will result in test failures because the build didn't contain
necessary changes.  To detect failure caused by this, compare gclient
update's stdout on build bots and test bots.

On that note, I suspect this topic is of little interest to webkit-dev at
large, so we may want to move this to chrome-webkit-gardening for future
discussion.

-atw

On Tue, Feb 22, 2011 at 10:43 AM, Mikhail Naganov wrote:

> Ah, true. The code changes were long ago.
>
> On Tue, Feb 22, 2011 at 21:40, Mihai Parparita 
> wrote:
> > But these were rebaselines, which don't depend on any code changes.
> >
> > Mihai
> >
> > On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov 
> wrote:
> >> I have a suspicion that the cause of canaries failures is described
> >> here:
> https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d
> >> In short, bots can run tests prematurely, emitting false failures. I
> >> observed this during my gardening, and I think you should check which
> >> revisions of WebKit and Chromium bots used while running tests.
> >>
> >> On Tue, Feb 22, 2011 at 20:16, Drew Wilson  wrote:
> >>> Yeah, it's weird. I rebaselined those tests, but the chromium canaries
> still
> >>> showed them as red. Now, however, the canaries are showing many of them
> >>> passing. I was planning to remove the lines from test_expectations
> today to
> >>> see if they stay green.
> >>> -atw
> >>>
> >>> On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita 
> >>> wrote:
> 
>  It looks like Drew checked in baselines with
>  http://trac.webkit.org/changeset/79034 (which may be why
>  rebaseline-chromium-webkit-tests isn't doing anything, since it
>  already has "correct" pixel baselines), but given
>  http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
>  any ideas why?
> 
>  Mihai
> 
>  On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita 
> wrote:
>  > Hi Chromium WebKit folks,
>  >
>  > I'm looking for a help to retrieve the latest expectation files for
>  > Chromium Mac LayoutTest.
>  > At the weekend there was a change that triggers massive amount of
>  > pixel test failures that requires rebaselining.
>  > (https://bugs.webkit.org/b/54736)
>  > But the buildbot doesn't have the latest result for part of them,
> that
>  > means
>  >
>  >  * rebaseline-chromium-webkit-tests doesn't update pixel results
>  >  * [layout test results] links on buildbot dashboard are broken.
>  >
>  > Then now around 100 tests for Mac Chromium are
>  > left marked as failed (BUGWK54736 lines), waiting for their fresh
>  > expectations.
>  >
>  > Unfortunately I have no idea what's happening
>  > but missing 100 tests will possibly hurt us.
>  > How could I update these expectations?
>  > Any suggestions and/or helps are appreciated.
>  >
>  > Regards.
>  > --
>  > morrita
>  > ___
>  > webkit-dev mailing list
>  > webkit-dev@lists.webkit.org
>  > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>  >
> >>>
> >>>
> >>> ___
> >>> webkit-dev mailing list
> >>> webkit-dev@lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>>
> >>>
> >>
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Sharing the OpenGL GraphicsContext3D implementation

[Zan Dobersek]

Hi,

I'm writing this mail in order to propose changes that would make the OpenGL
implementation of the GraphicsContext3D a lot easier to share between the
Mac and Gtk port.

Currently the mentioned implementation is only used by the Mac port. The Gtk
port is also interested in using this implementation and there is already a
patch available in bug #31517[1] by Martin Robinson that brings the WebGL
functionality to daylight.

There is, however, the issue of the OpenGL extensions functions. Current
OpenGL implementation is Mac-only, and Mac port has a specific set of
extensions functions available. The same cannot be said for the Gtk port,
which can end up having extensions functions available that do not have the
same extension suffix as the Mac port's functions (EXT vs ARB). Because of
that the current proposed implementation acquires addresses of the OpenGL
extensions functions and then uses shims to make the GraphicsContext3D work.

I recommend a new class to be created for these two ports to use, named
something like OpenGLExtensionsFunctions. Extensions-specific functions in
the GraphicsContext3D class would then be replaced with calls to the
corresponding functions in this class, for example
OpenGLExtensionsFunctions::blitFramebuffer instead of current
::glBlitFramebufferEXT. Implementation for the Mac port would be simple,
passing arguments on to functions that are currently used in the
GraphicsContext3D class. Gtk port's implementation would simply call the
functions that were acquired, with no need to depend on shims.

Modifying the OpenGL implementation of the GraphicsContext3D class in this
way would ease the use of it for the Gtk port and perhaps any other port
that would go on to use this implementation with no damage to the Mac port.

I'd like to hear what Mac folks think of this approach and if there are any
other ideas that address this problem.

Regards,
Zan Dobersek

[1] https://bugs.webkit.org/show_bug.cgi?id=31517
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation

[Oliver Hunt]

I agree.  My hope was always that the OpenGL backend could be shared among all 
the webkit ports, my only suggestion is that rather than having a separate 
OpenGLExtensionsFunctions class, I think we probably want something like

GraphicsContext3DOpenGL.{h,cpp} for all the common logic

and then

GraphicsContext3DOpenGL{Gtk, Mac, Wx, Posix, ...}.cpp

etc

To implement the functions that can't be shared.

This would be in keeping with our normal design approach for using system 
platform specific APIs.

--Oliver


On Feb 22, 2011, at 12:53 PM, Zan Dobersek wrote:

> Hi,
> 
> I'm writing this mail in order to propose changes that would make the OpenGL 
> implementation of the GraphicsContext3D a lot easier to share between the Mac 
> and Gtk port.
> 
> Currently the mentioned implementation is only used by the Mac port. The Gtk 
> port is also interested in using this implementation and there is already a 
> patch available in bug #31517[1] by Martin Robinson that brings the WebGL 
> functionality to daylight.
> 
> There is, however, the issue of the OpenGL extensions functions. Current 
> OpenGL implementation is Mac-only, and Mac port has a specific set of 
> extensions functions available. The same cannot be said for the Gtk port, 
> which can end up having extensions functions available that do not have the 
> same extension suffix as the Mac port's functions (EXT vs ARB). Because of 
> that the current proposed implementation acquires addresses of the OpenGL 
> extensions functions and then uses shims to make the GraphicsContext3D work.
> 
> I recommend a new class to be created for these two ports to use, named 
> something like OpenGLExtensionsFunctions. Extensions-specific functions in 
> the GraphicsContext3D class would then be replaced with calls to the 
> corresponding functions in this class, for example 
> OpenGLExtensionsFunctions::blitFramebuffer instead of current 
> ::glBlitFramebufferEXT. Implementation for the Mac port would be simple, 
> passing arguments on to functions that are currently used in the 
> GraphicsContext3D class. Gtk port's implementation would simply call the 
> functions that were acquired, with no need to depend on shims.
> 
> Modifying the OpenGL implementation of the GraphicsContext3D class in this 
> way would ease the use of it for the Gtk port and perhaps any other port that 
> would go on to use this implementation with no damage to the Mac port.
> 
> I'd like to hear what Mac folks think of this approach and if there are any 
> other ideas that address this problem.
> 
> Regards,
> Zan Dobersek
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=31517
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] What is the minimal version of Python for webkit-patch?

[Benjamin]

Hello,

I would like to update webkit-patch to support Python 3 because that is what
I use by default.
I think that would not be too much problem to support Python >= 2.6. If we
have to support as low as Python 2.4, that could be a problem because of
some new syntax elements introduced in 2.6.

Should I wait before patching for Python 3? Anyone needs webkit-patch for
Python < 2.6?

cheers,
Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] What is the minimal version of Python for webkit-patch?

[Osztrogonac Csaba]

Hi,

We have Debian Lenny on Qt buildbots and Qt EWS with
python 2.5.2. Upgrading to Debian Squeeze is in progress,
I think we can finish it in this week.

If you can wait a little bit, it would be great.

br,
Ossy

Benjamin írta:
I would like to update webkit-patch to support Python 3 because that is 
what I use by default.
I think that would not be too much problem to support Python >= 2.6. If 
we have to support as low as Python 2.4, that could be a problem because 
of some new syntax elements introduced in 2.6.


Should I wait before patching for Python 3? Anyone needs webkit-patch 
for Python < 2.6?

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] What is the minimal version of Python for webkit-patch?

[Mark Rowe]

On 2011-02-22, at 13:20, Benjamin wrote:

> Hello,
> 
> I would like to update webkit-patch to support Python 3 because that is what 
> I use by default.
> I think that would not be too much problem to support Python >= 2.6. If we 
> have to support as low as Python 2.4, that could be a problem because of some 
> new syntax elements introduced in 2.6.
> 
> Should I wait before patching for Python 3? Anyone needs webkit-patch for 
> Python < 2.6?

Some versions of Mac OS X do not ship with Python 2.6.  Anyone working on such 
a version is likely to need things to work with an older version.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] What is the minimal version of Python for webkit-patch?

[Eric Seidel]

We expect all python in webkit to work in Python 2.5.

We arrived at that version by looking at the lowest version shipping
on the common platforms used for webkit development.  Mac OS X Leopard
was the platform with the lowest shipping python version (2.5).
If/when Apple stops actively developing WebKIt for Leopard (which I
don't expect to be until after Lion ships) we as a project will
certainly move to 2.6+ (as that's what Snow Leopard supports).

It's possible we'll move to requiring a newer python version for
WebKit before that time, but that's unlikely given that currently it's
annoying to have to upgrade everyone's development machines.

-eric

On Tue, Feb 22, 2011 at 1:20 PM, Benjamin  wrote:
> Hello,
> I would like to update webkit-patch to support Python 3 because that is what
> I use by default.
> I think that would not be too much problem to support Python >= 2.6. If we
> have to support as low as Python 2.4, that could be a problem because of
> some new syntax elements introduced in 2.6.
> Should I wait before patching for Python 3? Anyone needs webkit-patch for
> Python < 2.6?
> cheers,
> Benjamin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] What is the minimal version of Python for webkit-patch?

[Eric Seidel]

That said, I'm *very* excited to see patches supporting 3.0. :)  Just
please don't break 2.5 support.

On Tue, Feb 22, 2011 at 2:04 PM, Eric Seidel  wrote:
> We expect all python in webkit to work in Python 2.5.
>
> We arrived at that version by looking at the lowest version shipping
> on the common platforms used for webkit development.  Mac OS X Leopard
> was the platform with the lowest shipping python version (2.5).
> If/when Apple stops actively developing WebKIt for Leopard (which I
> don't expect to be until after Lion ships) we as a project will
> certainly move to 2.6+ (as that's what Snow Leopard supports).
>
> It's possible we'll move to requiring a newer python version for
> WebKit before that time, but that's unlikely given that currently it's
> annoying to have to upgrade everyone's development machines.
>
> -eric
>
> On Tue, Feb 22, 2011 at 1:20 PM, Benjamin  wrote:
>> Hello,
>> I would like to update webkit-patch to support Python 3 because that is what
>> I use by default.
>> I think that would not be too much problem to support Python >= 2.6. If we
>> have to support as low as Python 2.4, that could be a problem because of
>> some new syntax elements introduced in 2.6.
>> Should I wait before patching for Python 3? Anyone needs webkit-patch for
>> Python < 2.6?
>> cheers,
>> Benjamin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] beforeload & link (esp rel prefetch)

[蓋文彼德斯]

Hi!

I'm returning to this work now, and I see that folks have been quiet about
this since I posted my plan.  Here's how I'm going to proceed:

Step 1: I will add beforeload to prefetch & icon rel types.  Expect a CL for
this soon.
Step 2: I will add a new subresource rel type, which will have higher
priority than prefetch, otherwise be the same.
Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from
html/HTMLLinkElement.cpp
Step 4: We land the Link header parser directly (bug 51940)
Step 5: Add beforeload events to the Link header?

Comments?

On 24 January 2011 18:10, Adam Barth  wrote:

> 2011/1/20 Gavin Peters (蓋文彼德斯) :
> > I also have thought about how we can go forward, I'd like folks
> > comments on this:
> >
> > Step 1: Land bug 51941, a refactoring of the HTMLLinkPrefetch element
> > which pulls out loading for rel types prefetch, icon and dns-prefetch.
>
> That sounds like a reasonable first step if we want to go forward with
> Steps 4 and 5.  Perhaps it would make sense to delay this work until
> we're ready to do Step 4?
>
> > Step 2: Add beforeload to at least prefetch & icon rel types, and hey,
> > why not dns-prefetch too!  Do this to fix bug 52577.
>
> It seems reasonable to add beforeload events to prefetch.  Icon is
> probably worth doing too.  I'm less sure about dns-prefetch because
> that doesn't actually generate a "load" so to speak.  Maybe leave it
> off in the first iteration?
>
> My slight reservation here is that, from a privacy standpoint, there's
> no reasonable way to prevent a web site from leading information back
> to its server.  However, many privacy extensions take a "best effort"
> approach rather than an "airtight" approach.  In that sense,
> generating these events seems valuable because it improve what these
> folks can build.
>
> > Step 3: Add rel type subresource (same as rel type prefetch, only
> > higher priority for in-page resources) (need to create a bug for
> > this).
>
> This seems valuable.  My understanding is that subresource is similar
> to prefetch, just with a different priority (i.e., "please prefetch
> this URL in time for it to be used by a subresource of this page").
>
> > Step 4: Add Link header, providing rel types subresource, prefetch &
> > dns-prefetch only (currently bug 51940).
>
> This step also makes sense to me because these headers don't modify
> the semantics of the document.  Supporting them in headers means that
> web sites can optimize their performance using middleware boxes
> without hacking up their HTML.
>
> > Step 5: Add beforeload events to the Link header (as a followup after
> > bug 51940).
>
> This seems somewhat odd to me, but I guess it makes sense.  There's
> some question about where to fire these events, but presumably firing
> them on the document itself would be fine.
>
> I'm willing to believe that my perspective might be biased because
> I've been talking to Gavin about these features for a while.  I
> certainly don't want us to move forward here if folks don't think this
> is a beneficial course of action.
>
> Adam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Snow Leopard

[Eric Seidel]

The SL bot has been broken since yesterday.  Meaning the commit-queue
is now up to 22 patches pending.

There have been a couple media tests failing since checkin.  But more
concerning is there appears to be a marauding memory smasher:
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r79391%20(8893)/results.html
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r79388%20(8891)/results.html

I don't have good data on when the memory smasher started.  Maybe it's
still fallout from Darin's utf8 decoder change?

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Snow Leopard

[Mihai Parparita]

The SL bot is now green
(http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Tests)),
ever since http://trac.webkit.org/changeset/79390 rolled out a change
that resulted in "all layout tests are crashing on Snow Leopard" per
the comment. It doesn't look like the cq has done a full cycle with a
patch since then, perhaps it'll start landing patches now?

Mihai

On Tue, Feb 22, 2011 at 9:10 PM, Eric Seidel  wrote:
> The SL bot has been broken since yesterday.  Meaning the commit-queue
> is now up to 22 patches pending.
>
> There have been a couple media tests failing since checkin.  But more
> concerning is there appears to be a marauding memory smasher:
> http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r79391%20(8893)/results.html
> http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r79388%20(8891)/results.html
>
> I don't have good data on when the memory smasher started.  Maybe it's
> still fallout from Darin's utf8 decoder change?
>
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Snow Leopard

[Eric Seidel]

Mihai cleared things up for me in #webkit.  media tests were broke
from yesterday until this afternoon, then the crasher rolled in, then
it just got rolled out, and the other media test I was seeing was a
webkit2 failure not SL.

SL is green and the cq is landing in 5-way parallel. :)

-eric

On Tue, Feb 22, 2011 at 9:29 PM, Ryosuke Niwa  wrote:
> On Wed, Feb 23, 2011 at 2:20 PM, Mihai Parparita 
> wrote:
>>
>> The SL bot is now green
>>
>> (http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Tests)),
>> ever since http://trac.webkit.org/changeset/79390 rolled out a change
>> that resulted in "all layout tests are crashing on Snow Leopard" per
>> the comment. It doesn't look like the cq has done a full cycle with a
>> patch since then, perhaps it'll start landing patches now?
>
> Yeah, that rollout took forever on the waterfall to cycle as well so I
> wouldn't be surprised even if commit queues spent some extra time to catch
> up.
> - Ryosuke
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Fwd: Snow Leopard

[Ryosuke Niwa]

-- Forwarded message --
From: Ryosuke Niwa 
Date: Wed, Feb 23, 2011 at 2:29 PM
Subject: Re: [webkit-dev] Snow Leopard
To: Mihai Parparita 
Cc: Eric Seidel , WebKit Development <
webkit-dev@lists.webkit.org>


On Wed, Feb 23, 2011 at 2:20 PM, Mihai Parparita wrote:

> The SL bot is now green
> (http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Tests)
> ),
> ever since http://trac.webkit.org/changeset/79390 rolled out a change
> that resulted in "all layout tests are crashing on Snow Leopard" per
> the comment. It doesn't look like the cq has done a full cycle with a
> patch since then, perhaps it'll start landing patches now?
>

Yeah, that rollout took forever on the waterfall to cycle as well so I
wouldn't be surprised even if commit queues spent some extra time to catch
up.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation

[Maciej Stachowiak]

On Feb 22, 2011, at 1:01 PM, Oliver Hunt wrote:

> I agree.  My hope was always that the OpenGL backend could be shared among 
> all the webkit ports, my only suggestion is that rather than having a 
> separate OpenGLExtensionsFunctions class, I think we probably want something 
> like
> 
> GraphicsContext3DOpenGL.{h,cpp} for all the common logic
> 
> and then
> 
> GraphicsContext3DOpenGL{Gtk, Mac, Wx, Posix, ...}.cpp
> 
> etc
> 
> To implement the functions that can't be shared.
> 
> This would be in keeping with our normal design approach for using system 
> platform specific APIs.

The availability of particular OpenGL extensions likely does not correlate with 
WebKit port identity, so I'm not sure that particular approach is workable. 
This is likely to be a matter of the underlying OS, and in some cases may need 
to be handled at runtime, not just compile time. So Zan's original suggestion 
sounds more plausible to me.

 - Maciej

> 
> --Oliver
> 
> 
> On Feb 22, 2011, at 12:53 PM, Zan Dobersek wrote:
> 
>> Hi,
>> 
>> I'm writing this mail in order to propose changes that would make the OpenGL 
>> implementation of the GraphicsContext3D a lot easier to share between the 
>> Mac and Gtk port.
>> 
>> Currently the mentioned implementation is only used by the Mac port. The Gtk 
>> port is also interested in using this implementation and there is already a 
>> patch available in bug #31517[1] by Martin Robinson that brings the WebGL 
>> functionality to daylight.
>> 
>> There is, however, the issue of the OpenGL extensions functions. Current 
>> OpenGL implementation is Mac-only, and Mac port has a specific set of 
>> extensions functions available. The same cannot be said for the Gtk port, 
>> which can end up having extensions functions available that do not have the 
>> same extension suffix as the Mac port's functions (EXT vs ARB). Because of 
>> that the current proposed implementation acquires addresses of the OpenGL 
>> extensions functions and then uses shims to make the GraphicsContext3D work.
>> 
>> I recommend a new class to be created for these two ports to use, named 
>> something like OpenGLExtensionsFunctions. Extensions-specific functions in 
>> the GraphicsContext3D class would then be replaced with calls to the 
>> corresponding functions in this class, for example 
>> OpenGLExtensionsFunctions::blitFramebuffer instead of current 
>> ::glBlitFramebufferEXT. Implementation for the Mac port would be simple, 
>> passing arguments on to functions that are currently used in the 
>> GraphicsContext3D class. Gtk port's implementation would simply call the 
>> functions that were acquired, with no need to depend on shims.
>> 
>> Modifying the OpenGL implementation of the GraphicsContext3D class in this 
>> way would ease the use of it for the Gtk port and perhaps any other port 
>> that would go on to use this implementation with no damage to the Mac port.
>> 
>> I'd like to hear what Mac folks think of this approach and if there are any 
>> other ideas that address this problem.
>> 
>> Regards,
>> Zan Dobersek
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=31517
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev