Re: [webkit-dev] does anyone use the advanced --print options to new-run-webkit-tests besides me?

On somewhat related note, can we simplify the output of new-run-webkit-tests on bots? It's way too noisy as is. Maybe hide all DEBUG information? - Ryosuke On Tue, Jan 24, 2012 at 5:37 PM, Dirk Pranke wrote: > Hi all, > > new-run-webkit-tests, in addition to the --verbose flag, offers the > abi

Re: [webkit-dev] optimising png files in LayoutTests - an experiment

On Tue, Jan 24, 2012 at 10:43 PM, Mike Lawther wrote: > Just thought I'd share the results of an experiment I did in optimising the > png files in LayoutTests. > > I used a tool on Mac called ImageOptim (http://imageoptim.pornel.net/) which > tries a set of different png lossless optimising tools

[webkit-dev] optimising png files in LayoutTests - an experiment

Hi guys, Just thought I'd share the results of an experiment I did in optimising the png files in LayoutTests. I used a tool on Mac called ImageOptim (http://imageoptim.pornel.net/) which tries a set of different png lossless optimising tools (like pngcrush - I also downloaded and included PNGOUT

[webkit-dev] does anyone use the advanced --print options to new-run-webkit-tests besides me?

Hi all, new-run-webkit-tests, in addition to the --verbose flag, offers the ability to turn on or off a number of different blocks of output by passing a list of options to --print. I suspect that I'm the only person who has ever really used these combinations, and I'm inclined to drastically col

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-25 00:57, Alexey Proskuryakov wrote: 24.01.2012, в 15:10, Julian Reschke написал(а): b) RFC 6266 works without UA sniffing if you're willing to serve plain ASCII to legacy browsers (IE< 9 and Safari) We are talking about how to encode existing non-ASCII file names, there is no

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 15:10, Julian Reschke написал(а): > b) RFC 6266 works without UA sniffing if you're willing to serve plain ASCII > to legacy browsers (IE < 9 and Safari) We are talking about how to encode existing non-ASCII file names, there is no equivalent plain ASCII to send instead. > We ha

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-25 00:02, Alexey Proskuryakov wrote: 24.01.2012, в 14:33, Julian Reschke написал(а): I know you don't like it but please stop spreading FUD. RFC 5987 allows senders to send the same thing to all clients without UA sniffing. If you have a different proposal for which this is true p

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 14:33, Julian Reschke написал(а): >>> I know you don't like it but please stop spreading FUD. RFC 5987 allows >>> senders to send the same thing to all clients without UA sniffing. If you >>> have a different proposal for which this is true please go ahead and write >>> it down.

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-24 23:28, Alexey Proskuryakov wrote: 24.01.2012, в 14:03, Julian Reschke написал(а): Having UTF-8 Content-Disposition served by all Web sites that offer downloads would be the ideal outcome from higher principles. RFC 5987 style gobbledygook really has no purpose here, and only co

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 14:03, Julian Reschke написал(а): >> Having UTF-8 Content-Disposition served by all Web sites that offer >> downloads would be the ideal outcome from higher principles. RFC 5987 style >> gobbledygook really has no purpose here, and only complicates life for >> implementors, site

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-24 22:50, Alexey Proskuryakov wrote: 24.01.2012, в 13:36, Julian Reschke написал(а): You may be right about the default browser encoding, but I'm pretty sure you are not right about UTF-8. Having UTF-8 Content-Disposition served by all Web sites that offer downloads would be the

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 13:36, Julian Reschke написал(а): > You may be right about the default browser encoding, but I'm pretty sure you > are not right about UTF-8. Having UTF-8 Content-Disposition served by all Web sites that offer downloads would be the ideal outcome from higher principles. RFC 5987

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-24 22:29, Alexey Proskuryakov wrote: 24.01.2012, в 11:07, Julian Reschke написал(а): My conclusion is that the "use the referring page's encoding" quirk isn't needed. You're welcome to prove me wrong. I'm happy that we agree on UTF-8 and default browser encoding being needed. Th

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 11:07, Julian Reschke написал(а): > My conclusion is that the "use the referring page's encoding" quirk isn't > needed. You're welcome to prove me wrong. I'm happy that we agree on UTF-8 and default browser encoding being needed. That's a huge step forward. Will this be reflected

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-24 19:44, Alexey Proskuryakov wrote: 24.01.2012, в 10:04, Julian Reschke написал(а): Sorry, Alexey. You did claim this is "needed for compatibility with existing content". Please be more careful with quotation marks. You are not quoting me, and I'm not sure what you actually ref

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 10:04, Julian Reschke написал(а): > Sorry, Alexey. > > You did claim this is "needed for compatibility with existing content". Please be more careful with quotation marks. You are not quoting me, and I'm not sure what you actually refer to. > But unless I'm missing something, *n

Re: [webkit-dev] Trouble tracking down flaky test results ...

It took a bit of poking around to find the checkbox, but it does solve the problem. Thanks, James On Tue, Jan 24, 2012 at 1:15 PM, Ryosuke Niwa wrote: > FYI, uncheck "Only unexpected results" in options and results.html will > show all failures. > > - Ryosuke > > > On Tue, Jan 24, 2012 at 10:1

Re: [webkit-dev] Trouble tracking down flaky test results ...

FYI, uncheck "Only unexpected results" in options and results.html will show all failures. - Ryosuke On Tue, Jan 24, 2012 at 10:13 AM, Mihai Parparita wrote: > results.html only links unexpected failures, and this is an expected > failure on Snow Leopard. > > Mihai > > On Tue, Jan 24, 2012 at 10

Re: [webkit-dev] Trouble tracking down flaky test results ...

Ahh, that explains why I was not seeing it. Thanks. James On Tue, Jan 24, 2012 at 1:13 PM, Mihai Parparita wrote: > results.html only links unexpected failures, and this is an expected > failure on Snow Leopard. > > Mihai > > On Tue, Jan 24, 2012 at 10:02 AM, W. James MacLean > wrote: > >> I s

Re: [webkit-dev] Trouble tracking down flaky test results ...

results.html only links unexpected failures, and this is an expected failure on Snow Leopard. Mihai On Tue, Jan 24, 2012 at 10:02 AM, W. James MacLean wrote: > I should add ... if I hunt through the raw directories in the results I > can find the *actual* raw output, but it's not linked in via r

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-24 19:00, Alexey Proskuryakov wrote: 24.01.2012, в 9:45, Julian Reschke написал(а): Did you find out for how long this was broken? I can't even recall the last Safari update, insofar I have my doubts that this change affected any real world content. I didn't check when exactly t

Re: [webkit-dev] Trouble tracking down flaky test results ...

The test is logged as having failed: 2012-01-20 13:31:01,307 914 worker.py:180 DEBUG worker/9 compositing/geometry/limit-layer-bounds-transformed-overflow.html failed: 2012-01-20 13:31:01,307 914 worker.py:182 DEBUG worker/9 Text diff mismatch And the results zip file (http://build.chromium.org/

Re: [webkit-dev] Trouble tracking down flaky test results ...

I should add ... if I hunt through the raw directories in the results I can find the *actual* raw output, but it's not linked in via results.html (or so it seems). On Tue, Jan 24, 2012 at 12:52 PM, W. James MacLean wrote: > I'm trying to track down test results for a flaky layout test > (composit

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 9:45, Julian Reschke написал(а): > Did you find out for how long this was broken? I can't even recall the last > Safari update, insofar I have my doubts that this change affected any real > world content. I didn't check when exactly this broke. As discussed earlier in this threa

[webkit-dev] Trouble tracking down flaky test results ...

I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-24 18:38, Alexey Proskuryakov wrote: 24.01.2012, в 02:41, Julian Reschke написал(а): Please see. Unless I'm testing the wrong thing (in which case I'd like to hear what's wrong!), it seems that neither Chrome nor Safari use the en

Re: [webkit-dev] Removing deprecatedFrameEncoding

24.01.2012, в 02:41, Julian Reschke написал(а): > Please see . > > Unless I'm testing the wrong thing (in which case I'd like to hear what's > wrong!), it seems that neither Chrome nor Safari use the encoding of the > referring page. At least

[webkit-dev] Embedded Font

Hello all, Is there a way to figure out if Embedded Font is applied via Font-Face src for a given tag in webkit ? Thanks. Tinu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Find adjacent Element by position rendered in webkit

How to figure out adjacent element by position given an element ? Eg., In below example is there a way to figure out the text Height next to Image. J In above case, it is height of J that needs to be determined. using previous/next sibling of image will work. But there could be elements based o

Re: [webkit-dev] Removing deprecatedFrameEncoding

On 2012-01-19 02:00, Julian Reschke wrote: ... Please see . Unless I'm testing the wrong thing (in which case I'd like to hear what's wrong!), it seems that neither Chrome nor Safari use the encoding of the referring page. At least not in th