[webkit-dev] WebGL test breakage on build bots
Earlier today I landed https://bugs.webkit.org/show_bug.cgi?id=33416 by hand (because the commit queue was blocked), and unfortunately this broke some of the WebGL layout tests on the bots. These tests are passing locally, so the best guess I can make is that the hardware or OpenGL versions on the bots are insufficient or buggy. A couple of questions: 1. Is there any way to get the per-test output from the test runs on the bots? 2. Is there any way to temporarily disable these tests on the bots until we can figure out a resolution? The patch for 33416 is generally sound, and was blocking further work, so it would be preferable not to have to roll it out. Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebGL test breakage on build bots
On Mar 16, 2010, at 1:45 PM, Kenneth Russell wrote: Earlier today I landed https://bugs.webkit.org/show_bug.cgi?id=33416 by hand (because the commit queue was blocked), and unfortunately this broke some of the WebGL layout tests on the bots. These tests are passing locally, so the best guess I can make is that the hardware or OpenGL versions on the bots are insufficient or buggy. A couple of questions: 1. Is there any way to get the per-test output from the test runs on the bots? Yes. Here is an example from a test run that had WebGL failures: http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r56077%20(11505)/results.html 2. Is there any way to temporarily disable these tests on the bots until we can figure out a resolution? The patch for 33416 is generally sound, and was blocking further work, so it would be preferable not to have to roll it out. I would recommend we fully investigate other avenues before considering that route. Regression tests are not very effective if we just disable them whenever they start failing. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit produces wrong result on autocomplete, after user uses back button
Current WebKit based browsers (as of 3/16/2010), e.g. Safari and
Chrome, exhibit the following bugs. Perhaps someone can take a look.
Thanks.
Bug 1: If a page A has multiple form elements F1 and F2, and the first
(in order of appearance in HTML) form, F1, has autocomplete set to
off (i.e. form ... autocomplete=off), but F2 has autocomplete
set to on (default behavior), then after navigating away from page
A, and then hitting browser back button to go back to page A, F1 and
F2 may be auto-completed incorrectly. In particular, if F1 and F2 both
have input elements with the same name and type, say N and T (i.e.
input name=N type=T ...), then when navigating back to page A
using the back button, F1.N's value will be autocompleted with F2.N's
value.
Bug 2: First, browser hits page A, and server returns an HTML page
with form elements F1 and F2 (both forms have autocomplete set to on).
Then, user navigates away from page A, and subsequently returns to
page A using the browser back button. On the second visits to page A,
WebKit issues another request for A to the server (this differs from
FireFox's behavior, where on back button no addition request is issued
to server). If the server returns a different HTML page (e.g. because
user session has logged out), with form elements F3 and F4 that are
different from F1 and F2, but consisting of input elements with the
same name and type, then F3 and F4 will be autocompleted with F1 and
F2 input element values, even for input element type hidden and
submit.
WORK AROUND
Bug 1: never use autocomplete=off unless you have this set for ALL
the forms on the same HTML page.
Bug 2: case specific, no good generic solution. We found an acceptable
work around by including hidden forms to make sure two versions of
page A have similar forms; first version has F1, F2, F3, and second
one has F1, F2', and F3, where F2' is a hidden version of F2. If we
don't include F2', then the second version of page A is F1, and F3,
and F3 will be auto-completed with F2's element values, even for
hidden and submit elements in F3.
ANALYSIS of WebKit CODE
These two bugs occur in the same part of the code, but can probably be
considered as two separate bugs. The code are in WebCore sub-directory
of the WebKit code tree.
Bug 1: in Document::formElementsState, input elements that have
autocomplete turned ON (checked via
HTMLInputElement::saveFormControlState), have their states saved in a
vector. However, in
HTMLFormControlElementWithState::finishParsingChildren, every form
element, regardless if autocomplete is ON or OFF, restores state from
the aforementioned vector. This results in bug 1.
Bug 1 Fix: this should be a fairly straight-forward fix -
finishParsingChildren should not restore state if element has
autocomplete turned OFF.
Disclaimer: I don't develop on Mac. I only use it and we develop a
website. I just browse the WebKit code today. Hence, I have not
created or tested a patch.
Bug 2. This is much more complex.
I assume that in a design decision unrelated to autocomplete, WebKit
is designed to re-fetch page A if user is using the back button to go
back in history to page A.
(I'd be interested in hearing about this too)
Fundamentally, WebKit makes the incorrect assumption that the second
fetch of page A results in the same HTML, or at least the same set of
forms, as the first fetch. If this is not the case, then the
autocomplete logic no longer produces the correct/expected behavior.
When WebKit saves state for a page, it calls
Document::formElementsState, which simply creates a map of pairs, and
puts each input element's name+type and value pair into the map. If
two input elements in two separate forms have the same name and type,
both the values are saved.
For example, say page A has forms F1 and F2, and F1 has input elements
with names a1 and a2, with types t1 and t2, with values v1 and v2
respectively. F2 has input elements with names a3 and a2, with types
t1 and t2, and values v3 and v4, respectively. WebKit saves the state
of this page as (in JSON notiation)
{ a1,t1 : [ v1 ], a2,t2 : [ v2, v4 ], a3,t1 : [ v3 ] }
If user revisits page A using the browser back button, WebKit will try
to autocomplete forms on the new version of page A, fetched from the
server, using the above state. If the new version of page A has
exactly the same forms as the last, then everything works. If not,
then WebKit produces incorrect behavior. For example, assume the
second time page A is fetched, server returns just one form F3, and F3
has input elements with names a4 and a2, with types t1 and t2, then
F3's a2 element will be populated with v2, saved from the previous
page.
(Note: actual logic of storing state and recovering state, as used in
the code, are slightly different, but the idea is the same)
This problem manifests itself on websites when user sessions may
expire, and after a session expires, hitting page A may produce
slightly different HTML. E.g. may give you a please login
Re: [webkit-dev] WebKit produces wrong result on autocomplete, after user uses back button
Thanks for yourinterest in WebKit. Sending mail to this list is not the correct way to file a bug report. Please see http://webkit.org/quality/reporting.html, which describes how to do that. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebGL test breakage on build bots
On Tue, Mar 16, 2010 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 16, 2010, at 1:45 PM, Kenneth Russell wrote: Earlier today I landed https://bugs.webkit.org/show_bug.cgi?id=33416 by hand (because the commit queue was blocked), and unfortunately this broke some of the WebGL layout tests on the bots. These tests are passing locally, so the best guess I can make is that the hardware or OpenGL versions on the bots are insufficient or buggy. A couple of questions: 1. Is there any way to get the per-test output from the test runs on the bots? Yes. Here is an example from a test run that had WebGL failures: http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r56077%20(11505)/results.html Thanks. 2. Is there any way to temporarily disable these tests on the bots until we can figure out a resolution? The patch for 33416 is generally sound, and was blocking further work, so it would be preferable not to have to roll it out. I would recommend we fully investigate other avenues before considering that route. Regression tests are not very effective if we just disable them whenever they start failing. What is your recommendation? I hate to leave tests broken on the bots for hours at a time. Looking at the test failures, the OpenGL implementation on the bots is completely broken when turning on FBO multisampling so we are going to need to figure out a way to detect this case and not try to turn it on. Is there a way to tell what graphics hardware is in each of the bots, in particular Intel integrated graphics vs. ATI/AMD vs. NVIDIA? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit produces wrong result on autocomplete, after user uses back button
Thanks. I was kind of hoping someone close to the code would be willing to expand on some of the questions I had in the bug report, such as decisions to re-fetch pages in history, and, given those decisions, how, if possible, to solve the problem I discovered. But I understand your point. I apologize. On Tue, Mar 16, 2010 at 5:05 PM, Darin Adler da...@apple.com wrote: Thanks for yourinterest in WebKit. Sending mail to this list is not the correct way to file a bug report. Please see http://webkit.org/quality/reporting.html, which describes how to do that. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] git.webkit.org is missing svn revision r49890
It was discovered recently that the git repository on git.webkit.org is missing svn revision r49890. http://trac.webkit.org/changeset/49890 This causes problems if you're using a single git repository, pulling from git.webkit.org, and using git-svn-fetch from svn.webkit.org (so that you can push commits back to the svn repository from your git repo). Fixing git.webkit.org to include the missing revision will be disruptive for anyone pulling from the repository, but it would be more correct than leaving it alone. Please add comments to this bug instead of replying to this message: git.webkit.org repository is missing svn revision r49890 https://bugs.webkit.org/show_bug.cgi?id=36193 Thanks. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Frustrations with WebKit Font Representation
Recently, an update that attempted to share more Cairo-related font code was added to the WebKit repository (http://trac.webkit.org/changeset/55510). While this was no doubt of great benefit to the Gtk-based ports, it had the unintended side effect of breaking the WinCairo port, as it placed a FontPlatformData.h file (which had previously been hidden in a platform-specific gtk directory) into the Cairo directory. This file was set up to support Pango or FreeType as rendering backends, and so failed when attempting to build using the WinCairo GDI-based backend. My initial thought was to simply copy the salient elements from the win/FontPlatformData.h file (shared between the Windows CG-based and Cairo-based builds) into the new cairo/FontPlatformData.h. However, this will probably make it easier for the CG port to drift out of sync with the WinCairo port, creating maintenance difficulty. After all, I mostly want to replicate the way Apple's CG port works with fonts, the only fundamental difference being that WinCairo performs rendering of the GDI fonts via the Cairo library, while Apple's CG port naturally uses the CoreGraphics library for its drawing. After discussing the issue with Adam Roben for a bit, he made the excellent observation that the main problem was that the FontPlatformData type was providing the wrong layer of abstraction. It has morphed into an object type that attempts to encapsulate both the underlying operating system's concept of a font/glyph (e.g., GDI, FreeType, Pango, etc.) and the mechanism used to render the font to screen (e.g., Cairo, CoreGraphics, Skia, etc.). The various ports have managed to cobble together a system that works, but in the process have created a Byzantine structure full of duplicated file names (FontPlatformData.h, FontCustomPlatformData.h, etc. for each platform) that generally expose incompatible API's and data structures. Based on the existing implementation, I wonder if a better approach might be possible that would separate the rendering process from the underlying font representation. That way, a Windows application using GDI fonts with a cairo rendering layer could largely share the same underlying font representation with a CoreGraphics. Similarly, all ports built on top of Cairo could use different font representations (e.g., GDI, Pango, FreeType) but still pipe the drawing logic through the Cairo layer. Has anyone else run into these kinds of issues, and might have some suggestions for how to better approach this problem? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrations with WebKit Font Representation
On Tue, Mar 16, 2010 at 3:49 PM, Brent Fulgham bfulg...@gmail.com wrote: Has anyone else run into these kinds of issues, and might have some suggestions for how to better approach this problem? On the Chromium side, Brett Wilson is our master of font code. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebGL test breakage on build bots
On Tue, Mar 16, 2010 at 2:06 PM, Kenneth Russell k...@google.com wrote: On Tue, Mar 16, 2010 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 16, 2010, at 1:45 PM, Kenneth Russell wrote: Earlier today I landed https://bugs.webkit.org/show_bug.cgi?id=33416 by hand (because the commit queue was blocked), and unfortunately this broke some of the WebGL layout tests on the bots. These tests are passing locally, so the best guess I can make is that the hardware or OpenGL versions on the bots are insufficient or buggy. A couple of questions: 1. Is there any way to get the per-test output from the test runs on the bots? Yes. Here is an example from a test run that had WebGL failures: http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r56077%20(11505)/results.html Thanks. 2. Is there any way to temporarily disable these tests on the bots until we can figure out a resolution? The patch for 33416 is generally sound, and was blocking further work, so it would be preferable not to have to roll it out. I would recommend we fully investigate other avenues before considering that route. Regression tests are not very effective if we just disable them whenever they start failing. What is your recommendation? I hate to leave tests broken on the bots for hours at a time. Looking at the test failures, the OpenGL implementation on the bots is completely broken when turning on FBO multisampling so we are going to need to figure out a way to detect this case and not try to turn it on. Is there a way to tell what graphics hardware is in each of the bots, in particular Intel integrated graphics vs. ATI/AMD vs. NVIDIA? We're working on the real fix (actually heuristics to detect and work around broken graphics drivers) under https://bugs.webkit.org/show_bug.cgi?id=36194 , but in the meantime to unblock the commit queue I've temporarily disabled these tests under https://bugs.webkit.org/show_bug.cgi?id=36200 . We'll re-enable them as soon as the larger fix is ready, hopefully by tomorrow. -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebGL test breakage on build bots
On Mar 16, 2010, at 4:42 PM, Kenneth Russell wrote: We're working on the real fix (actually heuristics to detect and work around broken graphics drivers) under https://bugs.webkit.org/show_bug.cgi?id=36194 , but in the meantime to unblock the commit queue I've temporarily disabled these tests under https://bugs.webkit.org/show_bug.cgi?id=36200 . We'll re-enable them as soon as the larger fix is ready, hopefully by tomorrow. In the future for situations like this, I'd prefer to see the change that caused failures rolled out and redone in a way that doesn't break tests, instead of temporarily disabling tests. But if it's all straightened out tomorrow, I won't complain too much. Thanks for addressing the breakage. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
