[webkit-dev] Resource Cache in WebKit2
Hi All, I have been looking at the WebKit2 code in the latest git version to get more understanding about it. As fas as I could understand, the Resource Cache is still managed by each WebProcess individually (and the sample application is using the DOCUMENT_VIEWER cache model for now) and there is no concept of having a 'shared' resource cache among multiple web processes - is that correct. If so, then there will be no resue of the cache in one WebProcess even if the same page is open in another WebProcess (both communicating to a common UI Process). Also, are there any immediate plans to implement a shared cache model (common to all the WebProcess) ? Thanks in advance for your help ! Regards, Aneesh ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit BiDi sprint summary
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 https://bugs.webkit.org/show_bug.cgi?id=23124 - RTL: Directionality always reset on hard line break - Bug 9272 https://bugs.webkit.org/show_bug.cgi?id=9272 - Left/Right borders/padding/margins are not always added correctly when rendering multiline inline boxes with bidi elements - Bug 56377 https://bugs.webkit.org/show_bug.cgi?id=56377 - WebKit's behavior for text-align inherit differs from other browsers - Bug 50951 http://webk.it/50951 - Implement text-align: -webkit-match-parent. - Bug 38087 https://bugs.webkit.org/show_bug.cgi?id=38087 - Clicking below last line of right-to-left editable text that puts caret in the wrong place - Bug 50961 https://bugs.webkit.org/show_bug.cgi?id=50961 - title should support dir attribute - Bug 57336 https://bugs.webkit.org/show_bug.cgi?id=57336 - Experiment with moving caret by word in visual order Ready to land - Bug 57232 https://bugs.webkit.org/show_bug.cgi?id=57232 - Add http://webk.it/50951 text-align:-webkit-match-parent to default stylesheet. Progress made on - Bug 23457 http://webk.it/23457 - Weird behavior when trying to select Hebrew text. - Bug 25298 https://bugs.webkit.org/show_bug.cgi?id=25298 - Ctrl + Right/Left arrow move forward/backward through document instead of right/left in RTL text - Bug 50952 https://bugs.webkit.org/show_bug.cgi?id=50952 - Inputs of type text and search should support interoperable set direction functionality - Bug 54623 https://bugs.webkit.org/show_bug.cgi?id=54623 - RTL web content should have left-hand scrollbar - Bug 50949 https://bugs.webkit.org/show_bug.cgi?id=50949 - Add support for unicode-bidi:plaintext CSS property - Bug 49111 https://bugs.webkit.org/show_bug.cgi?id=49111 - [RTL] Arabic/AB - after typing a date, cursors doesn't go back Closed without code changes - Bug 53696 http://webk.it/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] Resource Cache in WebKit2
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
Re: [webkit-dev] Canvas backing resolution
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] All webkit.org services seem to be down
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] All webkit.org services seem to be down
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
Re: [webkit-dev] Why does Ahem have different vertical metrics in Qt?
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] Many crashs of regresion tests in 64-bit Windows
On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben aro...@apple.com wrote: The best way to report a bug like this is to file a new bug at http://webkit.org/new-bug. In this case, this is a known issue (http://webkit.org/b/52913), 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] Canvas backing resolution
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] Canvas backing resolution
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] Many crashs of regresion tests in 64-bit Windows
On Apr 6, 2011, at 12:25 PM, Pere Martir wrote: On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben aro...@apple.com wrote: The best way to report a bug like this is to file a new bug at http://webkit.org/new-bug. In this case, this is a known issue (http://webkit.org/b/52913), 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] LayoutTest failures on Windows due to fonts/metric (yet again, any update?)
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.
layout-test-results.tar.gz
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] Canvas backing resolution
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?)
On Wed, Apr 6, 2011 at 11:50 PM, Adam Roben aro...@apple.com 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
[webkit-dev] An update on new-run-webkit-tests
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 dragdrop 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
Re: [webkit-dev] An update on new-run-webkit-tests
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 dragdrop 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
On Wed, Apr 6, 2011 at 9:01 PM, Maciej Stachowiak m...@apple.com 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 dragdrop 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] Resource Cache in WebKit2
---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 da...@apple.com 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
