Re: [webkit-dev] Resource Cache in WebKit2

2011-04-06 Thread Sachin Puranik 
Hi,
so is there a specific reason for not having multiprocess and we are working
on dual process model.

Regards,
Sachin.

On Apr 7, 2011 11:12 AM, "Aneesh Bhasin"  wrote:

---Resending : Had accidentally replied only to Darin - adding the
list too in CC now.. my apologies ! ---

Hi Darin,


On Wed, Apr 6, 2011 at 7:26 PM, Darin Adler  wrote:
> WebKit2 has only one web pro...
Yes, I saw that when I was going through the code. But it is still
possible (please correct me if I am wrong here) to create a new Web
Context every time,say, a new window/tab is opened. And each web
context will have its own Web Process in such a case - all
communicating to the same 'UI Process'. So, my question was in
reference to such a use case. Right now, each web context (and hence
each Web Process) will have its own independent resource cache - right
?

Also, as and when a WebContext starts supporting multiple Web Process,
will there be single unified resource cache for each context shared
amongst all the web processes in that context ?

Thanks for your reply..

Regards,
Aneesh

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

Re: [webkit-dev] Resource Cache in WebKit2

2011-04-06 Thread Aneesh Bhasin 
---Resending : Had accidentally replied only to Darin - adding the
list too in CC now.. my apologies ! ---

Hi Darin,

On Wed, Apr 6, 2011 at 7:26 PM, Darin Adler  wrote:
> WebKit2 has only one web process at this time.
>

Yes, I saw that when I was going through the code. But it is still
possible (please correct me if I am wrong here) to create a new Web
Context every time,say, a new window/tab is opened. And each web
context will have its own Web Process in such a case - all
communicating to the same 'UI Process'. So, my question was in
reference to such a use case. Right now, each web context (and hence
each Web Process) will have its own independent resource cache - right
?

Also, as and when a WebContext starts supporting multiple Web Process,
will there be single unified resource cache for each context shared
amongst all the web processes in that context ?

Thanks for your reply..

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

Re: [webkit-dev] An update on new-run-webkit-tests

2011-04-06 Thread Dirk Pranke 
On Wed, Apr 6, 2011 at 9:01 PM, Maciej Stachowiak  wrote:
>
> On Apr 6, 2011, at 7:39 PM, Dirk Pranke wrote:
>
>>
>> There are also a number of bugs currently listed as blocking that I
>> don't think really qualify. Unless told otherwise, I'm plannning to
>> remove the blocking flag from the following on Monday 4/11 (if they
>> haven't been fixed first):
>>
>> 57640 [GTK] overlapping drag&drop tests fail on NRWT
>> 55909 new-run-webkit-tests --run-singly option is busted
>> 55163 new-run-webkit-tests: enable multiple processes by default on Chromium 
>> Win
>> 47240 new-run-webkit-tests: getting an "error 2" back from ImageDiff
>> 37426 new-run-webkit-tests should use the ServerProcess abstraction in
>> chromium.py
>> 37007 fast/tokenizer/doctype-search-reset.html fails when run out of
>> order (new-run-webkit-tests)
>> 35359 fast/repaint/renderer-destruction-by-invalidateSelection-crash.html
>> fails intermittently
>> 35266 new-run-webkit-tests --platform=mac-leopard timeout limit should
>> match run-webkit-tests
>> 35049 http/tests/security/cross-frame-access-put.html fails
>> intermittently under new-run-webkit-tests
>> 35006 fast/dom/global-constructors.html is failing based on previous tests
>>
>> Also, just because I don't think they should block a cutover, I do
>> still think they should be fixed, so don't worry about that :)
>
> I think the ones that represent tests newly failing or becoming flaky should 
> be fixed before cutting over. We wouldn't want to lose test coverage when we 
> do the switch, right?
>

Hi Maciej,

I'm not sure I understand you, but if I do, this is what I was
attempting to talk about in the paragraph above, about expecting some
tests to be flaky or failing under NRWT simply because NRWT isn't
exactly identical to ORWT. NRWT may be exposing bugs in the code that
ORWT didn't trigger (e.g., because tests ran in a slightly different
order, or because of the concurrency issues).

It may be that you're thinking that either we run the test and it
fails, or we put the test in the Skipped file, because that was our
only choice with ORWT. In the new system, we can mark the test as
expected to fail in a particular way, but continue to run it (in order
to ensure that the test doesn't get worse and maintaining coverage).

Certainly running both systems in parallel for a while and shaking out
bugs that the NRWT bots reveal prior to cutting over is a good idea,
but I don't know that it's realistic to target all tests passing 100%
of the time prior to cutover. Then again, it may be that I'm more used
to Chromium bots where we have a large number of tests that aren't
expected to pass for one reason or another, and the Apple Mac port
will be more stable and easier to converge on.

Does that address your concerns?

And, just to be clear, I am not presuming to decide when anyone can or
should cut over (besides Chromium, of course). It's up to the
respective bot owners to decide to reconfigure their bots and switch
over if and when they're ready to do so. I'm just trying to make it
look appealing :)

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

Re: [webkit-dev] An update on new-run-webkit-tests

2011-04-06 Thread Maciej Stachowiak 

On Apr 6, 2011, at 7:39 PM, Dirk Pranke wrote:

> 
> There are also a number of bugs currently listed as blocking that I
> don't think really qualify. Unless told otherwise, I'm plannning to
> remove the blocking flag from the following on Monday 4/11 (if they
> haven't been fixed first):
> 
> 57640 [GTK] overlapping drag&drop tests fail on NRWT
> 55909 new-run-webkit-tests --run-singly option is busted
> 55163 new-run-webkit-tests: enable multiple processes by default on Chromium 
> Win
> 47240 new-run-webkit-tests: getting an "error 2" back from ImageDiff
> 37426 new-run-webkit-tests should use the ServerProcess abstraction in
> chromium.py
> 37007 fast/tokenizer/doctype-search-reset.html fails when run out of
> order (new-run-webkit-tests)
> 35359 fast/repaint/renderer-destruction-by-invalidateSelection-crash.html
> fails intermittently
> 35266 new-run-webkit-tests --platform=mac-leopard timeout limit should
> match run-webkit-tests
> 35049 http/tests/security/cross-frame-access-put.html fails
> intermittently under new-run-webkit-tests
> 35006 fast/dom/global-constructors.html is failing based on previous tests
> 
> Also, just because I don't think they should block a cutover, I do
> still think they should be fixed, so don't worry about that :)

I think the ones that represent tests newly failing or becoming flaky should be 
fixed before cutting over. We wouldn't want to lose test coverage when we do 
the switch, right?

Regards,
Maciej

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

Re: [webkit-dev] An update on new-run-webkit-tests

2011-04-06 Thread Dirk Pranke 
On Wed, Apr 6, 2011 at 7:39 PM, Dirk Pranke  wrote:
> Hi all,
>
> I am getting increasingly close to having new-run-webkit-tests running
> correctly on the apple mac platform with full feature parity to
> old-run-webkit-tests. (And, of course, it continues to run on all of
> the Chromium bots as well). I am hoping to close the remaining issues
> blocking full parity over the next couple weeks.
>
> You can track the issues where NRWT still falls behind ORWT here:
>
> https://bugs.webkit.org/show_bug.cgi?id=34984
>
> Note that I expect some tests to fail or be flaky under NRWT when it
> is running multiple processes/threads at a time. Doing so can both
> expose test dependencies on the environment or change the order of
> tests that are run by a DumpRenderTree, and I don't consider those to
> be bugs that should stop people from using NRWT. The new tool has a
> "test_expectations" mechanism that can be used to track expected
> failures and we should use it (IMO).
>
> That said, if there are significant issues making the tool unstable,
> causing lots of tests to fail, or just missing functionality, now's
> the time to let me know.
>
> Also, for anyone building / maintaining webkit ports other than the
> chromium and apple ones, I strongly encourage you to take another look
> at getting NRWT running on your implementations. I hope to at least
> make some attempt to run some of the GTK and QT bots myself, but I'm
> not about to sign up to test every build variant personally :)
>
> Note that  I believe that NRWT is fully usable today and people should
> seriously start using it. That said, I believe the following bugs
> should be fixed before we attempt to switch the apple mac port over.
> You may wish to wait for these fixes before switching your port over
> as well:
>
> 56731 new-run-webkit-tests doesn't support sample-on-timeout
> 56729 new-run-webkit-tests doesn't support WebKit2
> 55907 new-run-webkit-tests should upload crash logs
> 37739 new-run-webkit-tests does not report stderr output
> 37736 new-run-webkit-tests output is different from (and worse than)
> original run-webkit-tests
>
> There are also a number of issues keeping the apple win port from
> working at the moment that I plan to work on shortly.
>
> There are also a number of bugs currently listed as blocking that I
> don't think really qualify. Unless told otherwise, I'm plannning to
> remove the blocking flag from the following on Monday 4/11 (if they
> haven't been fixed first):
>
> 57640 [GTK] overlapping drag&drop tests fail on NRWT

Minor revision ... this one might actually qualify as a blocker :)

-- Dirk

> 55909 new-run-webkit-tests --run-singly option is busted
> 55163 new-run-webkit-tests: enable multiple processes by default on Chromium 
> Win
> 47240 new-run-webkit-tests: getting an "error 2" back from ImageDiff
> 37426 new-run-webkit-tests should use the ServerProcess abstraction in
> chromium.py
> 37007 fast/tokenizer/doctype-search-reset.html fails when run out of
> order (new-run-webkit-tests)
> 35359 fast/repaint/renderer-destruction-by-invalidateSelection-crash.html
> fails intermittently
> 35266 new-run-webkit-tests --platform=mac-leopard timeout limit should
> match run-webkit-tests
> 35049 http/tests/security/cross-frame-access-put.html fails
> intermittently under new-run-webkit-tests
> 35006 fast/dom/global-constructors.html is failing based on previous tests
>
> Also, just because I don't think they should block a cutover, I do
> still think they should be fixed, so don't worry about that :)
>
> Lastly, over the next couple weeks I also plan to produce some better
> documentation for both how to use NRWT and how the code itself is
> structured for anyone that wants to hack on it or port it to new
> platforms.
>
> Comments definitely welcome,
>
> -- Dirk
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] An update on new-run-webkit-tests

2011-04-06 Thread Dirk Pranke 
Hi all,

I am getting increasingly close to having new-run-webkit-tests running
correctly on the apple mac platform with full feature parity to
old-run-webkit-tests. (And, of course, it continues to run on all of
the Chromium bots as well). I am hoping to close the remaining issues
blocking full parity over the next couple weeks.

You can track the issues where NRWT still falls behind ORWT here:

https://bugs.webkit.org/show_bug.cgi?id=34984

Note that I expect some tests to fail or be flaky under NRWT when it
is running multiple processes/threads at a time. Doing so can both
expose test dependencies on the environment or change the order of
tests that are run by a DumpRenderTree, and I don't consider those to
be bugs that should stop people from using NRWT. The new tool has a
"test_expectations" mechanism that can be used to track expected
failures and we should use it (IMO).

That said, if there are significant issues making the tool unstable,
causing lots of tests to fail, or just missing functionality, now's
the time to let me know.

Also, for anyone building / maintaining webkit ports other than the
chromium and apple ones, I strongly encourage you to take another look
at getting NRWT running on your implementations. I hope to at least
make some attempt to run some of the GTK and QT bots myself, but I'm
not about to sign up to test every build variant personally :)

Note that  I believe that NRWT is fully usable today and people should
seriously start using it. That said, I believe the following bugs
should be fixed before we attempt to switch the apple mac port over.
You may wish to wait for these fixes before switching your port over
as well:

56731 new-run-webkit-tests doesn't support sample-on-timeout
56729 new-run-webkit-tests doesn't support WebKit2
55907 new-run-webkit-tests should upload crash logs
37739 new-run-webkit-tests does not report stderr output
37736 new-run-webkit-tests output is different from (and worse than)
original run-webkit-tests

There are also a number of issues keeping the apple win port from
working at the moment that I plan to work on shortly.

There are also a number of bugs currently listed as blocking that I
don't think really qualify. Unless told otherwise, I'm plannning to
remove the blocking flag from the following on Monday 4/11 (if they
haven't been fixed first):

57640 [GTK] overlapping drag&drop tests fail on NRWT
55909 new-run-webkit-tests --run-singly option is busted
55163 new-run-webkit-tests: enable multiple processes by default on Chromium Win
47240 new-run-webkit-tests: getting an "error 2" back from ImageDiff
37426 new-run-webkit-tests should use the ServerProcess abstraction in
chromium.py
37007 fast/tokenizer/doctype-search-reset.html fails when run out of
order (new-run-webkit-tests)
35359 fast/repaint/renderer-destruction-by-invalidateSelection-crash.html
fails intermittently
35266 new-run-webkit-tests --platform=mac-leopard timeout limit should
match run-webkit-tests
35049 http/tests/security/cross-frame-access-put.html fails
intermittently under new-run-webkit-tests
35006 fast/dom/global-constructors.html is failing based on previous tests

Also, just because I don't think they should block a cutover, I do
still think they should be fixed, so don't worry about that :)

Lastly, over the next couple weeks I also plan to produce some better
documentation for both how to use NRWT and how the code itself is
structured for anyone that wants to hack on it or port it to new
platforms.

Comments definitely welcome,

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

[webkit-dev] Disallowing modal dialogs during unload events

2011-04-06 Thread Sreeram Ramachandran 
We'd like to disallow modal dialogs (i.e., those arising from calls to
alert, confirm, prompt or showModalDialog) during unload events
(beforeunload, unload and pagehide) [1]. Chromium wants to do this
[2]. Since this affects web compatibility, I'd like to get agreement
from the other webkit ports as well.

The benefits are:
+ Fewer annoyances for users who are trying to leave a page.
+ In the case of tab close, allows the browser to hide the tab before
it has finished running the unload or pagehide event handlers (doesn't
apply to beforeunload); gives the impression of better performance.

This doesn't affect returning a non-null value from beforeunload; that
will still cause the browser to show the stay-or-leave dialog. We
think that is sufficient to satisfy legitimate needs to warn the user
about data loss, etc.

Outside webkit, this has been discussed on whatwg, but without a
definite conclusion [3]. Firefox seems to be considering this as well
[4].

All in favour, say aye!

[1] https://bugs.webkit.org/show_bug.cgi?id=56397
[2] http://code.google.com/p/chromium/issues/detail?id=68780
[3] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025080.html
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] LayoutTest failures on Windows due to fonts/metric (yet again, any update?)

2011-04-06 Thread Dan Bernstein 

On Apr 6, 2011, at 3:11 PM, Pere Martir wrote:

> On Wed, Apr 6, 2011 at 11:50 PM, Adam Roben  wrote:
>> It's possible that you need the fonts from a specific version of Mac OS X. I 
>> don't know what version that would be, though.
> 
> What if I want to submit a patch and I am working on Windows ?
> Switching to Mac OS X is my best option ? I am not currently working
> on any Windows specific issue, but I wonder that how the others submit
> the windows-port patches without first passing all regression tests ?
> 
> Maybe --tolerance can be allowed ?

The --tolerance option controls the failure threshold for pixel tests (where 
two images are compared); it has no effect on the render tree comparison, where 
the actual results are required to be identical to the expected results.

> 
> Is it possible to contact who setup the Windows build slaves ?
> 
>> It is a known issue that it's so hard to get correct test results on 
>> Windows. I don't think we have a bug filed about it.
> 
> Should I submit one since I have all artifacts - test logs, fonts
> which fail the tests, etc.
> ___
> 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] LayoutTest failures on Windows due to fonts/metric (yet again, any update?)

2011-04-06 Thread Pere Martir 
On Wed, Apr 6, 2011 at 11:50 PM, Adam Roben  wrote:
> It's possible that you need the fonts from a specific version of Mac OS X. I 
> don't know what version that would be, though.

What if I want to submit a patch and I am working on Windows ?
Switching to Mac OS X is my best option ? I am not currently working
on any Windows specific issue, but I wonder that how the others submit
the windows-port patches without first passing all regression tests ?

Maybe --tolerance can be allowed ?

Is it possible to contact who setup the Windows build slaves ?

> It is a known issue that it's so hard to get correct test results on Windows. 
> I don't think we have a bug filed about it.

Should I submit one since I have all artifacts - test logs, fonts
which fail the tests, etc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Canvas backing resolution

2011-04-06 Thread David Hyatt 
On Apr 6, 2011, at 3:01 PM, Charles Pritchard wrote:

> On 4/6/2011 12:32 PM, David Hyatt wrote:
>> He wants a way to detect Desktop zoom (which is done two different ways in 
>> WebKit).  It's difficult to figure out how to expose these, since Desktop 
>> zoom is ultimately just the CSS zoom property, which can be applied to any 
>> element (so folding it into a global makes little sense).  The other kind of 
>> Desktop zoom that involves a fixed scale factor applies a transform.  Again, 
>> transforms can be applied to descendant elements as well, so relying solely 
>> on what happened to be specified at the document level makes little sense.
> The descendant elements are under the control of the author.
> 
> That is, if I decide to use  body.style.webkitTransform, in my scripting 
> environment, I'm going to know that,
> because I initiated the request, and I'll add that to my calculations.
> 

Yeah, that's a good point.

> I see adding a pixel ratio property to window.screen as the cleanest solution.

This seems like a decent solution to me.  Probably simplest to just match what 
WinIE did for compatibility (even though it's two properties).

dave
(hy...@apple.com)

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

Re: [webkit-dev] LayoutTest failures on Windows due to fonts/metric (yet again, any update?)

2011-04-06 Thread Adam Roben 
On Apr 6, 2011, at 7:43 AM, Pere Martir wrote:

> I am working on Windows and I am planning to submit some patches
> (plugin loading) but I have problem make all regression tests
> (run-webkit-tests) pass without unmodified code.
> 
> I followed all the instructions:
> 
>   http://trac.webkit.org/wiki/BuildingOnWindows#Font-metric-relatedfailures
> 
> but as it warned, I saw "metric-related failures".
> 
> And recently aroben just told me on IRC that I may still have
> difference in the metrics so that I suppose that this problem has not
> be resolved.
> 
> The most related posts that I could find in this list is kinda old.
> * Eric Seidel, Oct 2008 - http://markmail.org/message/ihjhh4dre2ztu6v4
> * Darin Adler, Apr 2009 - http://markmail.org/message/wsnz67kqm7l7mtk6
> 
> However, on WebKit BuildBot I saw that Windows release and debug build
> are both "green". I don't see the option "--tolerance" specified.
> There must be some tricks of setting up the machine. Any clue please ?
> 
> @@ -1,15 +1,15 @@
> layer at (0,0) size 800x600
>   RenderView at (0,0) size 800x600
> -layer at (0,0) size 800x70
> -  RenderBlock {HTML} at (0,0) size 800x70
> -RenderBody {BODY} at (8,8) size 784x54
> -  RenderText {#text} at (0,0) size 770x36
> +layer at (0,0) size 800x79
> +  RenderBlock {HTML} at (0,0) size 800x79
> +RenderBody {BODY} at (8,8) size 784x63
> +  RenderText {#text} at (0,0) size 770x41
> 
> (full result of 2 failures attached)
> 
> One thing may make he difference. In my MacBook, I found *almost all*
> fonts listed in:
> 
> https://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/win/DumpRenderTree.cpp#L319
> 
> except "Times *.ttf". I did find "Times New Roman8.ttf" so that I
> renamed the later.
> 

It's possible that you need the fonts from a specific version of Mac OS X. I 
don't know what version that would be, though.

It is a known issue that it's so hard to get correct test results on Windows. I 
don't think we have a bug filed about it.

-Adam

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

Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows

2011-04-06 Thread Adam Roben 
On Apr 6, 2011, at 12:25 PM, Pere Martir wrote:

> On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben  wrote:
>> The best way to report a bug like this is to file a new bug at 
>> . In this case, this is a known issue 
>> (), so you don't need to do anything. There isn't 
>> a workaround at this time, other than to skip those tests or use a Release 
>> build.
> 
> That's why there is no "Windows 7 Debug (Tests)" in BuildBot ?

No. That's mostly a historical accident. At first we weren't able to capture 
crash logs on Windows 7 bots, and it seemed important to have crash logs for 
assertion failures, so the Debug bots all ran Windows XP. Now we can capture 
crash logs on Windows 7, but we haven't had a need to change things.

I'd say that the lack of a Windows 7 Debug (Tests) bot is part of the reason 
why that assertion hasn't been fixed yet, though.

-Adam

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

Re: [webkit-dev] Canvas backing resolution

2011-04-06 Thread Charles Pritchard 

On 4/6/2011 12:32 PM, David Hyatt wrote:

He wants a way to detect Desktop zoom (which is done two different ways in 
WebKit).  It's difficult to figure out how to expose these, since Desktop zoom 
is ultimately just the CSS zoom property, which can be applied to any element 
(so folding it into a global makes little sense).  The other kind of Desktop 
zoom that involves a fixed scale factor applies a transform.  Again, transforms 
can be applied to descendant elements as well, so relying solely on what 
happened to be specified at the document level makes little sense.

The descendant elements are under the control of the author.

That is, if I decide to use  body.style.webkitTransform, in my scripting 
environment, I'm going to know that,

because I initiated the request, and I'll add that to my calculations.

Worst case, I can always walk the DOM, grab the transform style, and use 
CSSMatrix to calculate values.


With desktop zoom, the user initiates through the UA, which sends a 
resize event through to window,
but the scale is not directly exposed to the scripting environment in 
WebKit.


I am simply looking for the scale factor; this is an accessibility 
issue, for users who are using the UA zoom.



I'm not really sure how to easily solve this problem.  I suppose we could just 
mix in document-level zoom and transform state into devicePixelRatio, but that 
feels inelegant to me given that individual child elements can change the zoom 
and transform.  It wouldn't necessarily be accurate.  I also don't like the 
idea of having to re-resolve style just because the zoom level changed.  That 
would just slow things down.
Current use of window.devicePixelRatio is static, we might as well keep 
it that way.
On mobile devices, authors disable UA scaling and handle the entire 
process themselves.


I see adding a pixel ratio property to window.screen as the cleanest 
solution.


CSS checks work, they're not slow, but they're extra work on the author, 
and in-elegant,
as media matches return booleans, not float values. They're inefficient, 
but not slow in any practical sense.


I'm really open to any kind of help I can give here.

I've full experience implementing the stack, from multi-level descendant 
transforms starting at document.body,
to the hacks necessary to get window.screen.pixelRatio, and still 
support an additional magnification AT,
such as ZoomText or the OS magnifier. I also have experience with 
transform3d/webgl, but that's a different issue.


I've spoken to reps from both Google (re: TV) and Microsoft about having 
distinct X and Y ratios, as MS currently does in screen.
Robert O suggested that tracking horizontal and vertical scaling 
separately was unnecessary (non square pixels)
on modern displays. Both reps agreed. It doesn't harm anything, to have 
both X and Y scale values, but it does not seem to be necessary.

http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx

Netscape exposes the value to trusted scripts as screenPixelsPerCSSPixel
through their Utils Components interface.
https://developer.mozilla.org/en/NsIDOMWindowUtils


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

Re: [webkit-dev] Canvas backing resolution

2011-04-06 Thread David Hyatt 
He wants a way to detect Desktop zoom (which is done two different ways in 
WebKit).  It's difficult to figure out how to expose these, since Desktop zoom 
is ultimately just the CSS zoom property, which can be applied to any element 
(so folding it into a global makes little sense).  The other kind of Desktop 
zoom that involves a fixed scale factor applies a transform.  Again, transforms 
can be applied to descendant elements as well, so relying solely on what 
happened to be specified at the document level makes little sense.

I'm not really sure how to easily solve this problem.  I suppose we could just 
mix in document-level zoom and transform state into devicePixelRatio, but that 
feels inelegant to me given that individual child elements can change the zoom 
and transform.  It wouldn't necessarily be accurate.  I also don't like the 
idea of having to re-resolve style just because the zoom level changed.  That 
would just slow things down.

dave
(hy...@apple.com)

On Apr 6, 2011, at 9:17 AM, Darin Adler wrote:

> On Apr 5, 2011, at 9:52 PM, Charles Pritchard wrote:
> 
>> Long-story-short, can we please expose some of the CSS pixel scaling, either 
>> through window.devicePixelRatio
> 
> I typed javascript:alert(devicePixelRatio) in Safari on my iPhone 4, and got 
> the value 2.
> 
> Isn’t this what you are asking for?
> 
>-- 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

Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows

2011-04-06 Thread Pere Martir 
On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben  wrote:
> The best way to report a bug like this is to file a new bug at 
> . In this case, this is a known issue 
> (), so you don't need to do anything. There isn't 
> a workaround at this time, other than to skip those tests or use a Release 
> build.

That's why there is no "Windows 7 Debug (Tests)" in BuildBot ?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Ahem have different vertical metrics in Qt?

2011-04-06 Thread Andreas Kling 

On 02/08/2011 08:42 PM, ext Dan Bernstein wrote:

What is causing this difference? How does it affect other fonts and real
websites? Is there a way to fix this?


This is caused by the behavior of QFontMetricsF::descent() which returns 
the descent minus one for historical reasons.


I've opened https://bugs.webkit.org/show_bug.cgi?id=57954 to fix it. :-)

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

Re: [webkit-dev] All webkit.org services seem to be down

2011-04-06 Thread William Siegrist 
On Apr 6, 2011, at 8:08 AM, Adam Roben wrote:

> Hi Bill-
> 
> bugs.webkit.org, svn.webkit.org, www.webkit.org, trac.webkit.org all seem to 
> be down. Is this expected? Any idea when they might return? Thanks!
> 


The database service had a problem and had to be restarted. Everything is back. 

-Bill


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

[webkit-dev] All webkit.org services seem to be down

2011-04-06 Thread Adam Roben 
Hi Bill-

bugs.webkit.org, svn.webkit.org, www.webkit.org, trac.webkit.org all seem to be 
down. Is this expected? Any idea when they might return? Thanks!

-Adam

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

Re: [webkit-dev] Canvas backing resolution

2011-04-06 Thread Darin Adler 
On Apr 5, 2011, at 9:52 PM, Charles Pritchard wrote:

> Long-story-short, can we please expose some of the CSS pixel scaling, either 
> through window.devicePixelRatio

I typed javascript:alert(devicePixelRatio) in Safari on my iPhone 4, and got 
the value 2.

Isn’t this what you are asking for?

-- Darin

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

Re: [webkit-dev] Resource Cache in WebKit2

2011-04-06 Thread Darin Adler 
WebKit2 has only one web process at this time.

-- Darin

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

[webkit-dev] LayoutTest failures on Windows due to fonts/metric (yet again, any update?)

2011-04-06 Thread Pere Martir 
I am working on Windows and I am planning to submit some patches
(plugin loading) but I have problem make all regression tests
(run-webkit-tests) pass without unmodified code.

I followed all the instructions:

   http://trac.webkit.org/wiki/BuildingOnWindows#Font-metric-relatedfailures

but as it warned, I saw "metric-related failures".

And recently aroben just told me on IRC that I may still have
difference in the metrics so that I suppose that this problem has not
be resolved.

The most related posts that I could find in this list is kinda old.
* Eric Seidel, Oct 2008 - http://markmail.org/message/ihjhh4dre2ztu6v4
* Darin Adler, Apr 2009 - http://markmail.org/message/wsnz67kqm7l7mtk6

However, on WebKit BuildBot I saw that Windows release and debug build
are both "green". I don't see the option "--tolerance" specified.
There must be some tricks of setting up the machine. Any clue please ?

@@ -1,15 +1,15 @@
 layer at (0,0) size 800x600
   RenderView at (0,0) size 800x600
-layer at (0,0) size 800x70
-  RenderBlock {HTML} at (0,0) size 800x70
-RenderBody {BODY} at (8,8) size 784x54
-  RenderText {#text} at (0,0) size 770x36
+layer at (0,0) size 800x79
+  RenderBlock {HTML} at (0,0) size 800x79
+RenderBody {BODY} at (8,8) size 784x63
+  RenderText {#text} at (0,0) size 770x41

(full result of 2 failures attached)

One thing may make he difference. In my MacBook, I found *almost all*
fonts listed in:

https://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/win/DumpRenderTree.cpp#L319

except "Times *.ttf". I did find "Times New Roman8.ttf" so that I
renamed the later.


layout-test-results.tar.gz
Description: GNU Zip compressed data
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit BiDi sprint summary

2011-04-06 Thread Jeremy Moskovich 
Sorry, missed one:

Progress made on

   - Bug 50912 * - Add support for the
   unicode-bidi:isolate CSS property*


On Wed, Apr 6, 2011 at 10:04 AM, Jeremy Moskovich wrote:

> Hi,
>
> This past week 10 WebKit community members and a number of native Hebrew
> speakers gathered in Google's Tel Aviv office for a week-long sprint to fix
> BiDi issues.  Although BiDi issues affect millions of WebKit users, they're
> notoriously difficult to understand, let alone fix--even, sometimes, for
> native speakers!  Not only did we fix a number of long-standing bugs, we
> were also able to establish a foundation of understanding that will help us
> fix more issues in the future, too.
>
> Fixed
>
>- Bug 23124  - RTL:
>Directionality always reset on hard line break
>- Bug 9272  - Left/Right
>borders/padding/margins are not always added correctly when rendering
>multiline inline boxes with bidi elements
>- Bug 56377  - WebKit's
>behavior for text-align inherit differs from other browsers
>- Bug 50951  - Implement text-align:
>-webkit-match-parent.
>- Bug 38087  - Clicking
>below last line of right-to-left editable text that puts caret in the wrong
>place
>- Bug 50961  - 
>should support dir attribute
>- Bug 57336  -
>Experiment with moving caret by word in visual order
>
>
> Ready to land
>
>- Bug 57232  - Add  
> 
>text-align:-webkit-match-parent to default stylesheet.
>
>
> Progress made on
>
>- Bug 23457  - Weird behavior when trying to
>select Hebrew text.
>- Bug 25298  - Ctrl +
>Right/Left arrow move forward/backward through document instead of
>right/left in RTL text
>- Bug 50952  - Inputs of
>type "text" and "search" should support interoperable "set direction"
>functionality
>- Bug 54623  - RTL web
>content should have left-hand scrollbar
>- Bug 50949  - Add
>support for unicode-bidi:plaintext CSS property
>- Bug 49111  - [RTL]
>Arabic/AB - after typing a date, cursors doesn't go back
>
>
> Closed without code changes
>
>- Bug 53696  - Caret is rendered at an incorrect
>position at the boundary of Arabic number in a LTR context.
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit BiDi sprint summary

2011-04-06 Thread Ryosuke Niwa 
Thank you Jeremy for organizing this event.  The sprint was great!

We should have more of these hacking events for specific features or
components.  I learned a lot about how WebCore handles BiDi text, and it was
really nice to work closely with other contributors in person.

- Ryosuke

On Wed, Apr 6, 2011 at 10:04 AM, Jeremy Moskovich wrote:

> Hi,
>
> This past week 10 WebKit community members and a number of native Hebrew
> speakers gathered in Google's Tel Aviv office for a week-long sprint to fix
> BiDi issues.  Although BiDi issues affect millions of WebKit users, they're
> notoriously difficult to understand, let alone fix--even, sometimes, for
> native speakers!  Not only did we fix a number of long-standing bugs, we
> were also able to establish a foundation of understanding that will help us
> fix more issues in the future, too.
>
> Fixed
>
>- Bug 23124  - RTL:
>Directionality always reset on hard line break
>- Bug 9272  - Left/Right
>borders/padding/margins are not always added correctly when rendering
>multiline inline boxes with bidi elements
>- Bug 56377  - WebKit's
>behavior for text-align inherit differs from other browsers
>- Bug 50951  - Implement text-align:
>-webkit-match-parent.
>- Bug 38087  - Clicking
>below last line of right-to-left editable text that puts caret in the wrong
>place
>- Bug 50961  - 
>should support dir attribute
>- Bug 57336  -
>Experiment with moving caret by word in visual order
>
>
> Ready to land
>
>- Bug 57232  - Add  
> 
>text-align:-webkit-match-parent to default stylesheet.
>
>
> Progress made on
>
>- Bug 23457  - Weird behavior when trying to
>select Hebrew text.
>- Bug 25298  - Ctrl +
>Right/Left arrow move forward/backward through document instead of
>right/left in RTL text
>- Bug 50952  - Inputs of
>type "text" and "search" should support interoperable "set direction"
>functionality
>- Bug 54623  - RTL web
>content should have left-hand scrollbar
>- Bug 50949  - Add
>support for unicode-bidi:plaintext CSS property
>- Bug 49111  - [RTL]
>Arabic/AB - after typing a date, cursors doesn't go back
>
>
> Closed without code changes
>
>- Bug 53696  - Caret is rendered at an incorrect
>position at the boundary of Arabic number in a LTR context.
>
>
> ___
> 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] WebKit BiDi sprint summary

2011-04-06 Thread Jeremy Moskovich 
Hi,

This past week 10 WebKit community members and a number of native Hebrew
speakers gathered in Google's Tel Aviv office for a week-long sprint to fix
BiDi issues.  Although BiDi issues affect millions of WebKit users, they're
notoriously difficult to understand, let alone fix--even, sometimes, for
native speakers!  Not only did we fix a number of long-standing bugs, we
were also able to establish a foundation of understanding that will help us
fix more issues in the future, too.

Fixed

   - Bug 23124  - RTL:
   Directionality always reset on hard line break
   - Bug 9272  - Left/Right
   borders/padding/margins are not always added correctly when rendering
   multiline inline boxes with bidi elements
   - Bug 56377  - WebKit's
   behavior for text-align inherit differs from other browsers
   - Bug 50951  - Implement text-align:
   -webkit-match-parent.
   - Bug 38087  - Clicking
   below last line of right-to-left editable text that puts caret in the wrong
   place
   - Bug 50961  - 
   should support dir attribute
   - Bug 57336  - Experiment
   with moving caret by word in visual order


Ready to land

   - Bug 57232  - Add

   text-align:-webkit-match-parent to default stylesheet.


Progress made on

   - Bug 23457  - Weird behavior when trying to select
   Hebrew text.
   - Bug 25298  - Ctrl +
   Right/Left arrow move forward/backward through document instead of
   right/left in RTL text
   - Bug 50952  - Inputs of
   type "text" and "search" should support interoperable "set direction"
   functionality
   - Bug 54623  - RTL web
   content should have left-hand scrollbar
   - Bug 50949  - Add support
   for unicode-bidi:plaintext CSS property
   - Bug 49111  - [RTL]
   Arabic/AB - after typing a date, cursors doesn't go back


Closed without code changes

   - Bug 53696  - Caret is rendered at an incorrect
   position at the boundary of Arabic number in a LTR context.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev