[webkit-dev] Buildbots soon to require apache mod_bw
Hi, The patch to be landed soon for https://bugs.webkit.org/show_bug.cgi?id=45101 updates the apache config to require mod_bw. Can the buildbots admins please install it? I contacted the GTK+ bots admins already. The new test on this patch requires connection throttling but will run only on the GTK bots and I'll give it a try on the Chromium bots too. Philippe signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbots soon to require apache mod_bw
If you find a way to auto-install/auto-download the module as part of run-webkit-tests that's fine. On Fri, Nov 5, 2010 at 1:52 AM, Eric Seidel e...@webkit.org wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. This is not acceptable. -eric On Fri, Nov 5, 2010 at 1:30 AM, Philippe Normand pnorm...@igalia.com wrote: Hi, The patch to be landed soon for https://bugs.webkit.org/show_bug.cgi?id=45101 updates the apache config to require mod_bw. Can the buildbots admins please install it? I contacted the GTK+ bots admins already. The new test on this patch requires connection throttling but will run only on the GTK bots and I'll give it a try on the Chromium bots too. Philippe ___ 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] Buildbots soon to require apache mod_bw
On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. We already ask them to install python, perl, ruby, apache itself, php, in some cases additional codecs and whatnot. An additional apache module is not the end of the world, is it? Having said that, it just struck me that we have a few php scripts that are used by tests to cause intentional delays[0]. Perhaps we could use a similar pattern for this case too, and avoid this new requirement. Cheers, [0] LayoutTests/http/tests/misc/resources/slow-png-load.pl, for one -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbots soon to require apache mod_bw
Having said that, it just struck me that we have a few php scripts that are used by tests to cause intentional delays[0]. Perhaps we could use a similar pattern for this case too, and avoid this new requirement. Thanks for the hint Gustavo :) Actually I found video-throttled-load.cgi which nearly is perfect fit for my test. I just need to add Range requests support to it, having a look now. Philippe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbots soon to require apache mod_bw
On Fri, Nov 5, 2010 at 8:19 AM, Eric Seidel esei...@google.com wrote: On Fri, Nov 5, 2010 at 4:53 AM, Gustavo Noronha Silva g...@gnome.org wrote: On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. We already ask them to install python, perl, ruby, apache itself, php, in some cases additional codecs and whatnot. An additional apache module is not the end of the world, is it? These are relatively reasonable to expect in a default unix-like install. Every dependency we add hurts hackability, not of the code, so much as the general project. It's a pain in the ass to work on our windows port (even worse to work on Chrome's) partially due to the 10 things you have to install/configure before you can even build. Historically the WebKit port has had 0 install-to-hack dependencies on Mac. That's since increased, but 0 is the (possibly unrealistic) goal for any system. I'm glad another solution was found. Auto-install is also a totally fine solution. I suspect it's possible to pass Apache a module directory on the command line and have a python/perl script auto-download the module. Thanks, Eric Having said that, it just struck me that we have a few php scripts that are used by tests to cause intentional delays[0]. Perhaps we could use a similar pattern for this case too, and avoid this new requirement. Cheers, [0] LayoutTests/http/tests/misc/resources/slow-png-load.pl, for one -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ 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] Buildbots soon to require apache mod_bw
On Fri, Nov 5, 2010 at 4:53 AM, Gustavo Noronha Silva g...@gnome.org wrote: On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. We already ask them to install python, perl, ruby, apache itself, php, in some cases additional codecs and whatnot. An additional apache module is not the end of the world, is it? One thing you may have overlooked: installing software like this is a lot harder on platforms other than Linux. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbots soon to require apache mod_bw
On Fri, 2010-11-05 at 08:19 -0700, Evan Martin wrote: On Fri, Nov 5, 2010 at 4:53 AM, Gustavo Noronha Silva g...@gnome.org wrote: On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. We already ask them to install python, perl, ruby, apache itself, php, in some cases additional codecs and whatnot. An additional apache module is not the end of the world, is it? One thing you may have overlooked: installing software like this is a lot harder on platforms other than Linux. I was actually thinking of Windows when arguing my point =), since for us the module is one apt-get away, and I assume for Mac there would be a similarly easy way of getting it installed. But since we have other ways of solving the issue with reasonable effort, I don't think having one more requirement makes sense indeed. I'm just trying to argue that if (and I emphasize the if here) it was necessary, another module would not be that bad. I understand from Eric's message that Mac comes with ruby pre-installed, but that is not true for most GNU/Linux distributions or Windows, and that was certainly not a show-stopper when it got added to beautify diffs =). I do agree with the goal of keeping the number of requirements to a minimum, though, so let's see if we can get this done with the cgi Phillip found! Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Fri, Nov 5, 2010 at 6:32 PM, James Craig jcr...@apple.com wrote:
Ojan Vafai wrote:
How is [ DOMAttributeChangeRequestEvent ] any different than
DOMAttrModified? The spec claims it doesn't have the problems that
DOMAttrModified has, but I don't see how that's the case.
DOMAttrModified is a notification, but DOMAttributeChangeRequestEvent is a
request. The reason these all inherit from UIRequestEvent is because they
are all requests, not notifications. For example, the following sequences
may occur in a real user scenario.
*DOMAttrModified*
1. An attribute in the DOM changes (for whatever reason).
2. UA fires DOMAttrModified. This may recursively fire a series of other
mutation events, hence the performance problems.
*3. Web application (web page author) can do whatever, but this is a
notification of the change, not a request to make the change.*
*DOMAttributeChangeRequestEvent*
Path 1: ignored by the web application, so no DOM change occurs.
1. User performs some UI action. (e.g. VoiceOver user may press Ctrl+Opt+\)
2. AT interprets the intent of that action. (In VoiceOver, that key combo
means expand or collapse a tree node.)
3. UA fires a single DOMAttributeChangeRequestEvent (e.g. Web application,
please change 'aria-expanded' value of Node to 'true')
*4. Web application (web page author) ignores the event, so no DOM change
occurs.*
5. AT receives the unsupressed/uncancelled event at the end of the bubble
phase. (e.g. VoiceOver may beep to indicate to the user that no change
occurred.)
*DOMAttributeChangeRequestEvent*
Path 2: received by the web application, which makes the change on the
user's behalf.
1. User performs some UI action. (e.g. VoiceOver user may press Ctrl+Opt+\)
2. AT interprets the intent of that action. (In VoiceOver, that key combo
means expand or collapse a tree node.)
3. UA fires a single DOMAttributeChangeRequestEvent (e.g. Web application,
please change 'aria-expanded' value of Node to 'true')
4. Web application (web page author) has registered for the event, and
receives it.
*5. Web application (web page author) interprets the request, and calls
Node.setAttribute('aria-expanded',
'true')*
6. Web application (web page author) cancels or suppresses the event. (e.g.
UA, I have received your request, and have changed this DOM attribute on
your behalf.)
7. AT receives the supressed/cancelled event which indicates that the
'request' was successful.
8. AT can indicate to the user what happened. (e.g. VoiceOver might review
the AX API and speak expanded. 7 items enclosed.)
Or, phrased another way:
*DOMAttrModified*
I took your dollar. By the way, my dad and granddad are probably gonna
some cash from you, too.
*DOMAttributeChangeRequestEvent*
Path 1: Can I have a dollar? No? Okay.
Path 2: Can I have a dollar? Yes? Sweet.
This is far worse than an async DOMAttrModified since it means that all code
that attempts to change an attribute has to deal with the case where the
page cancels the change or makes arbitrary other changes. It also has worse
performance characteristics since it means that the browser would have to
fire the DOMAttributeChangeRequestEvent synchronously when it wanted to
change the attribute and wouldn't be allowed to batch up the events at all.
- James
___
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] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Fri, Nov 5, 2010 at 6:40 PM, James Robinson jam...@google.com wrote:
On Fri, Nov 5, 2010 at 6:32 PM, James Craig jcr...@apple.com wrote:
Ojan Vafai wrote:
How is [ DOMAttributeChangeRequestEvent ] any different than
DOMAttrModified? The spec claims it doesn't have the problems that
DOMAttrModified has, but I don't see how that's the case.
DOMAttrModified is a notification, but DOMAttributeChangeRequestEvent is a
request. The reason these all inherit from UIRequestEvent is because they
are all requests, not notifications. For example, the following sequences
may occur in a real user scenario.
DOMAttrModified
1. An attribute in the DOM changes (for whatever reason).
2. UA fires DOMAttrModified. This may recursively fire a series of other
mutation events, hence the performance problems.
3. Web application (web page author) can do whatever, but this is a
notification of the change, not a request to make the change.
DOMAttributeChangeRequestEvent
Path 1: ignored by the web application, so no DOM change occurs.
1. User performs some UI action. (e.g. VoiceOver user may press
Ctrl+Opt+\)
2. AT interprets the intent of that action. (In VoiceOver, that key combo
means expand or collapse a tree node.)
3. UA fires a single DOMAttributeChangeRequestEvent (e.g. Web
application, please change 'aria-expanded' value of Node to 'true')
4. Web application (web page author) ignores the event, so no DOM change
occurs.
5. AT receives the unsupressed/uncancelled event at the end of the bubble
phase. (e.g. VoiceOver may beep to indicate to the user that no change
occurred.)
DOMAttributeChangeRequestEvent
Path 2: received by the web application, which makes the change on the
user's behalf.
1. User performs some UI action. (e.g. VoiceOver user may press
Ctrl+Opt+\)
2. AT interprets the intent of that action. (In VoiceOver, that key combo
means expand or collapse a tree node.)
3. UA fires a single DOMAttributeChangeRequestEvent (e.g. Web
application, please change 'aria-expanded' value of Node to 'true')
4. Web application (web page author) has registered for the event, and
receives it.
5. Web application (web page author) interprets the request, and
calls Node.setAttribute('aria-expanded', 'true')
6. Web application (web page author) cancels or suppresses the
event. (e.g. UA, I have received your request, and have changed this DOM
attribute on your behalf.)
7. AT receives the supressed/cancelled event which indicates that the
'request' was successful.
8. AT can indicate to the user what happened. (e.g. VoiceOver might review
the AX API and speak expanded. 7 items enclosed.)
Or, phrased another way:
DOMAttrModified
I took your dollar. By the way, my dad and granddad are probably gonna
some cash from you, too.
DOMAttributeChangeRequestEvent
Path 1: Can I have a dollar? No? Okay.
Path 2: Can I have a dollar? Yes? Sweet.
This is far worse than an async DOMAttrModified since it means that all code
that attempts to change an attribute has to deal with the case where the
page cancels the change or makes arbitrary other changes. It also has worse
performance characteristics since it means that the browser would have to
fire the DOMAttributeChangeRequestEvent synchronously when it wanted to
change the attribute and wouldn't be allowed to batch up the events at all.
I could be misunderstanding, but it sounds like these events originate
with the AT software rather then when the DOM is modified. In that
sense, they sound more like KeyDown than DOMAttrModified.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
