Re: [webkit-dev] ARM JIT for WinCE
Hi,
the dateProtoFuncGetTimezoneOffset does not use the argList argument,
while functionPrint does. Perhaps passing this argument is still not yet
WinCE compatible. ArgList contains a pointer to the arguments (JSValue
pointers), and the length of the arguments. This structure is 8 bytes on
32 bit machines (1 pointer, 1 int), and allocated on the stack, because
the function got a reference (pointer) to it.
Could you try the following JS code: print(a, 1, true)
The length should be 3.
Zoltan
Hi,
I did some further investigation today.
I did a quick hack in the privateCompileCTIMachineTrampolines to get the
same
maybe correct register values like without OPTIMIZE_NATIVE_CALL.
move(callFrameRegister, regT0);
+move(ARMRegisters::r2, ARMRegisters::r3);
+move(ARMRegisters::r1, ARMRegisters::r2);
+move(ARMRegisters::r0, ARMRegisters::r1);
-move(stackPointerRegister, ARMRegisters::r3);
+move(stackPointerRegister, ARMRegisters::r0);
-call(Address(regT1, OBJECT_OFFSETOF(JSFunction, m_data)));
+call(Address(regT2, OBJECT_OFFSETOF(JSFunction, m_data)));
addPtr(Imm32(sizeof(ArgList)), stackPointerRegister);
Now it produces the following code:
003E01B0 mulsr0, r3, r0
003E01B4 subsr1, r1, r0
003E01B8 str r1, [sp]
003E01BC ldr r2, [r1, #-4]
003E01C0 ldr r1, [r4, #-8]
003E01C4 mov r0, r4
003E01C8 mov r3, r2
003E01CC mov r2, r1
003E01D0 mov r1, r0
003E01D4 mov r0, sp
003E01D8 mov lr, pc
003E01DC ldr pc, [r2, #0x1C]
003E01E0 addssp, sp, #8
003E01E4 ldr r3, [pc, #0x80]
003E01E8 ldr r2, [r3]
003E01EC bicsr3, r2, #0
003E01F0 bne 003E0204
The arguments seam to be sane now in the call to
dateProtoFuncGetTimezoneOffset, but it crashes afterwards.
When i step through it with the debugger i get the following register
after
the function finished and it jumps to 0x000139d8 instead of 0x003e01e0:
(lr = 0x003e01e0 when i enter the function!)
R0 = 0x182af984 R1 = 0x003f8054 R2 = 0x00601500 R3 = 0x0060
R4 = 0x003f8054 R5 = 0x0200 R6 = 0x182af984 R7 = 0x003f8054
R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
R12 = 0x182af8f0 Sp = 0x182af95c Lr = 0x003e01e0
Pc = 0x000139d8 Psr = 0x201f
I then tried to return jsNaN(exec) always. So R4 won't be used and
prolog/epilog changed:
00071600 mov r12, sp
00071604 stmdb sp!, {r0 - r3}
00071608 stmdb sp!, {r4, r12, lr}
0007160C sub sp, sp, #0x1C
00071700 ldr r0, [sp, #8]
00071704 add sp, sp, #0x1C
00071708 ldmia sp, {r4, sp, pc}
changed to
000734EC mov r12, sp
000734F0 stmdb sp!, {r0 - r3}
000734F4 stmdb sp!, {r12, lr}
000734F8 sub sp, sp, #0x1C
000735A4 ldr r0, [sp, #8]
000735A8 add sp, sp, #0x1C
000735AC ldmia sp, {sp, pc}
I now get following registers and it jumps to the correct address
(0x003e01e0), but it crashes then in functionPrint.
R0 = 0x182af984 R1 = 0x182af8f8 R2 = 0x R3 = 0x182af984
R4 = 0x003f8080 R5 = 0x0200 R6 = 0x0060 R7 = 0x003e07c8
R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
R12 = 0x03fc2c50 Sp = 0x182af984 Lr = 0x0001bc18
Pc = 0x003e01e0 Psr = 0x601f
I tried jsc.exe with the following javascript file:
print(getTimeZoneDiff());
function getTimeZoneDiff() {
return (new Date(2000, 1, 1)).getTimezoneOffset();
}
This doesn't make many sense to me in the moment.
- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] File::Spec-tmpdir() on Leopard and Snow Leopard bots
Hello, in the process of making it possible to run more than one instance of run-webkit-tests at the same time (https://bugs.webkit.org/show_bug.cgi?id=33153), I'm trying to make the handling of running httpd processes more platform independent. My tries failed only on the Leopard bots. Unfortunately I have no access to a Leopard machine, so I had to guess, but now I have a strong supposition why the new script fails. The Leopard bots (Leopard and Snow Leopard) have set something like this: TMPDIR=/var/folders/FF/FFsVLEwYHre8vU9Sax877k+++TI/-Tmp-/ shown in the bot logs (http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/4018/steps/layout-test/logs/stdio). My assumption is, that calling File::Spec-tmpdir() in perl returns this path, not /tmp as expected, that is why there is no PID file where the script expects it to be (httpd.conf sets it to /tmp/WebKit). Is there any particular reason for setting a non-POSIX standard TMPDIR on these machines, especially because Tiger does not set this and thus has no problems with File::Spec-tmpdir()? Or am I wrong with my assumption? br, Andras (bbandix) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Did I break the build?
Eric Seidel wrote: http://build.webkit.org/console Will let you know. I love the console, thanks for adding this! tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Did I break the build?
Eric Seidel wrote: The Chromium developers, notably Nicolas Sylvain added /console. Mark Rowe is our kind BuildBot admin who updated our copy to the latest BuildBot version including this new feature. I was not involved. :) Then great thanks to both Nicolas and Mark!! :) tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about PopupMenuClient
Maybe add a virtual like: virtual PlatformPopupMenu platformPopupMenu() const = 0; to HostWindow.h ? That is an option but I do not know if that is the purpose of HostWindow. Much like Qt already returns QWebPageClient for 'platformPageClient()' ? Maybe you can even re-use this QWebPageClient for the popup menu delegation too? That was discussed, but then we would have to reimplement the method at least twise and maybe more in the future, or totally change the scope of that class. Cheers, Adam -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about PopupMenuClient
Thanks for the hints. I took a look at the code, and this seems easy to implement. Kenneth On Thu, Jan 7, 2010 at 7:51 PM, Darin Fisher da...@chromium.org wrote: Chromium actually does something like this. See ChromeClientChromium. In our case, we have two modes: one where the embedder just has to wrap the given PopupContainer with a window frame, and in another mode, where the embedder is responsible for drawing the popup menu. We are forced to delegate out to the embedding application because of Chromium's sandbox, which prevents WebKit from directly communicating with the native widget system (cannot directly create an HWND for example). In the case where the embedder only supplies framing, the popup menu is drawn by embedding a ScrollView. Then, all of the drawing happens in WebCore. You can see this code in PopupMenuChromium.cpp. -Darin On Thu, Jan 7, 2010 at 2:44 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Hi there, A co-worker of mine is implementing the ability to reimplement how popup menus (comboboxes) etc will appear from our Qt WebKit API. As these UI delegates are per page, we thought about adding a method to our ChromeClientQt like AbstractPopupMenu* createPopupMenu(PopupMenuClient* client), but currently PopupMenuClient has no access to the page so that we can get hold of that. I guess that it is not safe to assume that PopupMenuClient::hostWindow() is always a Chrome, so would it be acceptable substituting the PopupMenuClient::hostWindow() with a PopupMenuClient::page() [1] method and then change the uses to page-chrome() ? Cheers, Kenneth [1] easily implemented as return document()-page() instead of return document()-view-hostWindow() -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
08.01.2010, в 02:22, e...@webkit.org написал(а): * platform/mac/Skipped: Add http/tests/uri/escaped-entity.html to Skipped list since it affects later tests. I think that having this particular test enabled is much more important than having the patch it was affecting landed. Also, looks like this didn't even help, see http://trac.webkit.org/changeset/52990. * platform/mac/svg/W3C-SVG-1.1/filters-conv-01-f-expected.txt: Check in correct results. This should have included pixel results. 08.01.2010, в 06:22, o...@webkit.org написал(а): * platform/mac-snowleopard/Skipped: platform/mac/editing/input/devanagari-ligature.html skipped. Same for this test. How will we notice regressions in text input support if we disable tests? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] File::Spec-tmpdir() on Leopard and Snow Leopard bots
On Fri, January 8, 2010 at 12:39:41 AM, Andras Becsi wrote: in the process of making it possible to run more than one instance of run-webkit-tests at the same time (https://bugs.webkit.org/show_bug.cgi?id=33153), I'm trying to make the handling of running httpd processes more platform independent. My tries failed only on the Leopard bots. Unfortunately I have no access to a Leopard machine, so I had to guess, but now I have a strong supposition why the new script fails. The Leopard bots (Leopard and Snow Leopard) have set something like this: TMPDIR=/var/folders/FF/FFsVLEwYHre8vU9Sax877k+++TI/-Tmp-/ shown in the bot logs (http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/4018/steps/layout-test/logs/stdio). My assumption is, that calling File::Spec-tmpdir() in perl returns this path, not /tmp as expected, that is why there is no PID file where the script expects it to be (httpd.conf sets it to /tmp/WebKit). Is there any particular reason for setting a non-POSIX standard TMPDIR on these machines, especially because Tiger does not set this and thus has no problems with File::Spec-tmpdir()? Or am I wrong with my assumption? On Leopard and newer, the tmp directory under /var/folders is a per-user tmp directory (IIRC), which the Perl module apparently prefers over the shared tmp directory at /tmp. If you read the man page for File::Spec, tmpdir() simply returns the first directory in a list, and its implementation is platform-specific. It sounds like this method should not be used if there is code that expects the same directory to be returned on every platform. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
Hi, The r52976 revealed this strange sideeffect bug, we filed some bug on it. We skipped these tests, because commit-queue doesn't work if one of the core builder is red. I don't think it is a good idea to land different, platform dependent expected files with false data. On the one hand layout tests protect against regression (verification) and on the other hand they test a correctness of specific feature (validation). What is the more important? I think both of them. I hope fixing the bug ASAP is much more important than paper over the problem with rolling out a good and working patch which only revealed the bug. Alexey, what do you think, if we use this new feature on the basis of our original idea until fix? I mean it can be disabled by default, but we can use it with --http-as-last option and/or enverionment variable. br, Ossy Alexey Proskuryakov wrote: * platform/mac/Skipped: Add http/tests/uri/escaped-entity.html to Skipped list since it affects later tests. I think that having this particular test enabled is much more important than having the patch it was affecting landed. Also, looks like this didn't even help, see http://trac.webkit.org/changeset/52990. * platform/mac-snowleopard/Skipped: platform/mac/editing/input/devanagari-ligature.html skipped. Same for this test. How will we notice regressions in text input support if we disable tests? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] postProgressFinishedNotification
That’s not a question about development of WebKit. The place to ask is the webkit-help mailing list http://webkit.org/contact.html. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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] Did I break the build?
Date: Thu, 7 Jan 2010 16:21:49 -0800 From: Eric Seidel e...@webkit.org http://build.webkit.org/console Will let you know. If possible, it might be good to add this link to the http://build.webkit.org/ home page. Is it linked elsewhere? It doesn't look like the home page is stored in source control. Thanks, --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
Plan 3 seems like the best (and simplest) one until the infrastructure for the others (and/or a champion for fixing currently failing tests) is available. What would it take to go with plan 3? I guess someone needs to rebaseline everything that's currently failing, check them in, and then someone (like bdash?) needs to flip a switch on the bots...? Did I miss anything? Are there instructions on how to do the rebaselining anywhere? I've only ever created pixel baselines for Chromium before (where we have a pretty neat tool that pretty much does it for you). J On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene p...@chromium.org wrote: And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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] [webkit-changes] [52980] trunk/LayoutTests
On Jan 8, 2010, at 8:15 AM, Osztrogonac Csaba wrote: I don't think it is a good idea to land different, platform dependent expected files with false data. This is where I think the difference comes in. I don’t think these different expected files are accurately characterized as “false data”. I believe the differences are not major significant ones. And by landing new results we test all other aspects of the test, whereas if we use Skipped files, we turn off the entire test. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Scrolling / redraw issue on WinCE platform
I'm working on a port of webKit to WinCE, and am currently encountering what appears to be a redraw/paint issue when scrolling (horizontally, in this case) to a widget that is originally partially off-screen (an input button in a form). The text all appears to scroll just fine, and the image of the start of the button (which is initially on screen) is moved correctly as well through the backingStore. However, when a paintButton is issued, the button appears in the same location on the screen post-scroll as it does pre-scroll, i.e. in the same position and still partially off the screen, even though the rest of the screen has scrolled. I'm looking for someone that can help debug this a bit further; hopefully can someone point me at some places to break and look to see which values are being set wrong and why; or if you'd like some specific stack traces I can get those too. I've tracked the code from WebView::scrollBackingStore (where the correct dx,dy values are being used to scroll the entire screen), through WebView::updateBackingStore, through paint code in RenderBlock, into RenderTheme and finally RenderThemeWin::paint (and subsequently paintButton). At this last stage, the x,y,width,height values for my button are still holding their original values (positioning the button partially offscreen in its initial paint), which I believe is correct. drawControl in RenderThemeWin is called, which ends up at DrawFrameControl. However, at this point, the paint still positions the button incorrectly. It is interesting to note that button's text IS positioned correctly after the scroll, however the frame of the button is not. I've downloaded and built webkit in safari, stepped through and verified this code works correctly on a pc and screen coords, etc are the same, so I suspect the culprit is WinCE-specific code, however I've been unable to get further. The html that produces this behavior is: table form id=one method=post action=/ tr td nobr Much more text here to offset the whole input field area and require scrolling. It looks like more and more is why input type=submit value=Submit More Please! / And read this! /nobr /td /tr /form /table I can also send in some screen shots of the issue but I wasn't sure if this mailing list supported that. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Language Bindings
Hi, On Jan 7, 2010, at 5:15 PM, AS wrote: Hello I'm looking into adding bindings for Python to the webkit DOM objects. Ideally, what I would like to create is WebKit based application that can use Python for DHTML manipulation. From the code, I can see how there are perl scripts that parse the idl files and generate binding files, such as those for Javascript and Objective C, I would like to add a set that does the same for Python. From the generated files, I a bit unclear as to where the actual objects are instaniated, i.e. if some jscript created a new say node, is there a table of class names / ctores somewhere? Would it be possible for someone to give a quick overview of what process should be followed to create a new language binding. The wx port actually has this capability to some degree. (Not sure if it has been implemented elsewhere yet.) You can check the wxPython release for Mac and Win (Ubuntu is coming hopefully soon) here: http://wxwebkit.wxcommunity.com/index.php?n=Main.Downloads There's also a sample HTML editor app that uses DOM APIs to do all it's property changes. The source for it is here: http://eclass.svn.sourceforge.net/viewvc/eclass/trunk/htmleditor/htmleditor.py?revision=862view=markup Some methods in that code that touch the DOM are the GetParent method (finds if the current selection is inside a particular tag, such as A) and ShowEditorForTag, which uses a pre-defined attribute list to grab the current value from the DOM, show an editor, and then set the user-specified value on the DOM element when the editor is closed. I haven't landed the bindings yet in trunk as they are a somewhat large project and I'm still working on them. To create them, what I did was add a new bindings generator in WebCore/bindings/scripts that generated C++ bindings. (I based it off the CodeGeneratorCOM.pm script but I had to modify it quite a bit to output COM-free C++ code.) Then I used SWIG to wrap those as Python objects. Regards, Kevin thanks ___ 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] [webkit-changes] [52980] trunk/LayoutTests
On 08.01.2010, at 8:15, Osztrogonac Csaba wrote: I hope fixing the bug ASAP is much more important than paper over the problem with rolling out a good and working patch which only revealed the bug. Do you have a plan for re-enabling the skipped test? The failures were mysterious, and it's not clear if the root cause can be promptly fixed - especially since no one seems to have volunteered. I'd like to get the tests back soon, even if that means rolling out http-as-last patches again. While it's true that changing the order of test execution just uncovered a bug somewhere, we still want to ensure that we don't regress Devanagari input handling or escaped URI characters processing. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
On Fri, Jan 8, 2010 at 7:37 AM, Alexey Proskuryakov a...@webkit.org wrote: * platform/mac/Skipped: Add http/tests/uri/escaped-entity.html to Skipped list since it affects later tests. I think that having this particular test enabled is much more important than having the patch it was affecting landed. Agreed. But, I think it's inexcusable for a test to affect later results. I skipped it more on those grounds than that the test it was enabling was important. Also, looks like this didn't even help, see http://trac.webkit.org/changeset/52990. Yes, it seems that either other test trigger this same bug in webcore on Windows. We still don't know why earlier tests are able to cause the line box for that one SVG text run to change in size by 2 pixels. * platform/mac/svg/W3C-SVG-1.1/filters-conv-01-f-expected.txt: Check in correct results. This should have included pixel results. 08.01.2010, в 06:22, o...@webkit.org написал(а): * platform/mac-snowleopard/Skipped: platform/mac/editing/input/devanagari-ligature.html skipped. Same for this test. How will we notice regressions in text input support if we disable tests? I agree, disabling tests is bad. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
Two things which could very quickly resolve this issue is if these commands fail on their respective platforms or not: run-webkit-tests --skipped=ignore platform/mac/editing/input/devanagari-ligature.html run-webkit-testsw --skipped=ignore platform/mac/svg/W3C-SVG-1.1/filters-conv-01-f.svg I suspect that both will fail when run alone, suggesting that the results currently checked in are affected by previous tests. Using the methodology outlined in https://bugs.webkit.org/show_bug.cgi?id=33372 it would be straightforward for someone to find out what previous tests are affecting these results. That would give us a clearer picture of why these test are failing, and bring us closer to a fixed, or a more-appropriate set of skipped files. It's possible to simply unskip the URL test and nothing will fail, now. However at some later point something may fail, since that test has been demonstrated to cause at least one later test to fail. -eric On Fri, Jan 8, 2010 at 11:55 AM, Alexey Proskuryakov a...@webkit.org wrote: On 08.01.2010, at 8:15, Osztrogonac Csaba wrote: I hope fixing the bug ASAP is much more important than paper over the problem with rolling out a good and working patch which only revealed the bug. Do you have a plan for re-enabling the skipped test? The failures were mysterious, and it's not clear if the root cause can be promptly fixed - especially since no one seems to have volunteered. I'd like to get the tests back soon, even if that means rolling out http-as-last patches again. While it's true that changing the order of test execution just uncovered a bug somewhere, we still want to ensure that we don't regress Devanagari input handling or escaped URI characters processing. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
On 08.01.2010, at 11:56, Eric Seidel wrote: I think that having this particular test enabled is much more important than having the patch it was affecting landed. Agreed. But, I think it's inexcusable for a test to affect later results. I skipped it more on those grounds than that the test it was enabling was important. It's not clear where the bug is though. If there is an uninitialized memory read in a later test, then earlier tests that randomly affect it can be perfectly correct. The fact that on other platforms the problem was not fixed support this hypothesis to some degree. The opposite is sometimes true, as well - there were whole series of randomly crashing tests added to Skipped list by different persons, even though the fault lied with an earlier test. As I said before, it's good when flaky tests cause pain and impede progress (as long as those tests are correct, of course). That's their way of making us investigate problems which can quickly turn into exploitable security bugs in shipping software otherwise. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
On Fri, Jan 8, 2010 at 12:14 PM, Alexey Proskuryakov a...@webkit.org wrote: It's not clear where the bug is though. If there is an uninitialized memory read in a later test, then earlier tests that randomly affect it can be perfectly correct. The fact that on other platforms the problem was not fixed support this hypothesis to some degree. Agreed, we don't fully understand this issue, thus things are still broken. They're just differently broken than they were before. We could continue a slightly altered version of the previous brokenness by checking in failing results. I encouraged Ossy to skip them instead because at least with a skipped list we have a single list of issues to fix. With checked in failures it's never clear whether they're failures or not. I'm happy with either solution if you'd prefer checking in failing results, that's doable. Although I think rolling out the run-webkit-tests change is OK, I don't think it's the best solution. We shouldn't be afraid of re-ordering tests. We just have to make sure we try and discover the tests which affect other tests and properly skip them as we tried to do here. As I said before, it's good when flaky tests cause pain and impede progress (as long as those tests are correct, of course). That's their way of making us investigate problems which can quickly turn into exploitable security bugs in shipping software otherwise. I disagree. I see flaky tests as no value to the project whatsoever. The build bots are about maintaining a known good state, not about being a todo list. Skipped lists and bug lists should be our todo lists. A green bot running a few fewer tests is much more valuable than a bot which is occasionally red but runs all the tests. WebKit just needs to make an effort to drive our Skipped list to zero over time and be less scared to use it to keep the bots green. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
On Thu, Jan 7, 2010 at 8:18 PM, Darin Fisher da...@chromium.org wrote: On Thu, Jan 7, 2010 at 5:17 PM, Ojan Vafai o...@chromium.org wrote: Do we really need a separate set of bots for pixel tests? Lets just turn the pixel tests on for the current bots. The only thing stopping us doing that is the currently failing tests, hence the suggestion for adding an expectations file (or we could skip all the failures). I don't know enough about text metrics changes between Mac releases. With Windows releases, we've been able to support XP, Vista and 7 pretty easily by using a generic theme for OS controls. Also, I think we have some hooks to turn off cleartype or something. ...and making sure all of the right / same fonts are installed :) -darin We disable ClearType and do some minimal checking of the system UI theme to make sure you don't have custom font or widget sizes. All of our baselines use the fonts installed with the system, so there are no custom fonts that need to be installed. You do need QuickTime installed, or a few tests will fail, but otherwise it's pretty stock. IIRC, there are far fewer diffs between Leopard and Snow Leopard than there were between XP and Vista, so I doubt you would need the generic theme that we did on Windows; it's probably easier to just rebaseline the few files that do diff. I can't speak to the diffs between Tiger and Leopard. -- Dirk There are only ~10 tests that needed custom results for Vista Windows 7. I wonder if a similar set of steps could be taken for supporting different Mac releases. Ojan On Thu, Jan 7, 2010 at 5:08 PM, Eric Seidel e...@webkit.org wrote: I'm totally in favor of adding test_expectations.txt like functionality to webkit (and we'll get it for free when Dirk finishes up-streaming run_webkit_tests.py) But the troubles with the pixel tests in the past were more to do with text metrics changing between OS releases, and individual font differences between machines. I suspect that those issues are very solvable. I think we mostly need someone willing to set up the pixel test bots. -eric On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how does webkit handle special layout requirement
I am just curious how des webkit rendering engine handle the special layout format? For example, I do not want to have horizontal scroll and I have a fixed width widnow. But inside a html page, I have a image which size is bigger than the fixed width, how does webkit handle that case? Can we change the some render info on the fly to change the layout infomation or webkit will handle it automatically? BTW, where could I set the windth for the display window or those info will be get in the runtime from some system vairable? Frank ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Status bubbles and you
If you've been using bugs.webkit.org today, you might have noticed some new status indicators in the attachments list. These status bubbles show how the patch fared when it was run through the various review bots. Here's what the different colors mean: * Green. Everything went great! You rock! * Red. The patch failed. :( The failing bots should post a comment explaining what went wrong. * Yellow. The patch is currently being processed. If a patch is yellow for a long time, the bot probably died while processing it (this is rare). * Purple. The bot wasn't able to test your patch for some reason. There's currently a bug that patches that don't apply cleanly to the most recent revision (and so aren't tested by the bots) are shown in red instead of purple. Hopefully I have this fixed soon. If you hover your mouse over a bubble, a tool tip will show you how old the information is. If you click on a bubble, you'll see more detailed information about the patch's run, including log files for errors. One benefit of this new display is that the style-queue no longer spams the bug comments with pass messages. Instead, you can see that a patch passed style by looking for a green bubble labeled style. Enjoy! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Upstreaming an OpenVG graphics backend
Hi list, with help from Adam Treat, Eli Fidler, Yong Li and Genevieve Mak, I've implemented a graphics backend for native OpenVG. Now is (finally) the time to upstream that stuff, and for now I've started with two patches: https://bugs.webkit.org/show_bug.cgi?id=33403 https://bugs.webkit.org/show_bug.cgi?id=33405 More will follow as the preceding ones are being landed. It's still missing out on a couple of minor points - e.g. pattern fills for GraphicsContext, handling of system fonts, oh, and a build system for public demonstration - but apart from that, the backend is pretty functional and cross-platform by now, without adding much overhead. I hope you like it, and hopefully I can also get plenty of reviews and general advice :) Thanks, cheers, Jakob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
