Re: [webkit-dev] More ports on nightly.webkit.org?
I couldn't find nightly.webkit.org in the SVN repo. Below is a patch that adds the Google Chrome Canary to the list of available WebKit nightly builds. The referenced image (download-chromium.png) can be obtained from: http://src.chromium.org/svn/trunk/src/chrome/app/theme/chromium/product_logo_32.png The image is available under the following BSD-style license: http://src.chromium.org/svn/trunk/src/LICENSE Thanks, Adam diff --git a/index.html b/index.html index 9d7e845..cbc132f 100644 --- a/index.html +++ b/index.html @@ -52,6 +52,17 @@ /dd dt +a href=http://tools.google.com/dlpage/chromesxs;img src='/images/download-chromium.png' alt='Download Google Chrome Canary' width='32' height='32'/a + /dt + dd +div class='latest-build' + h2Google Chrome Canary/h2 + pstronga href=http://tools.google.com/dlpage/chromesxs;Google Chrome Canary/a/strong auto-updates to the latest nightly build. +Available for Windows, Mac OS X, and Linux./p +/div + /dd + + dt a href=http://builds.nightly.webkit.org/files/trunk/src/WebKit-r95022.tar.bz2;img src='/images/download-src.png' alt='Download WebKit for Source' width='32' height='32'/a /dt dd On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth aba...@webkit.org wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing ENABLE_SINGLE_THREADED and ENABLE_JSC_MULTIPLE_THREADS
Hi Geoffrey, From what I understand, HTML5 Web Worker doesn't rely on threaded GC because each worker thread has its own heap. The other place affected by ENABLE_JSC_MULTIPLE_THREADS is JSLock. However it is also said platforms other than MacOS doesn't need to implement JSLock. It seems the only use of ENABLE_JSC_MULTIPLE_THREADS is to use JS API from another thread. Is this correct? Thanks, Yong Li 2011/9/8 Geoffrey Garen gga...@apple.com: Hi folks. To help move WebKit and JavaScriptCore forward, I'd like to remove old platform cruft that creates particular pain points for development. To that end, I'd like to remove ENABLE_SINGLE_THREADED and !ENABLE_JSC_MULTIPLE_THREADS. I believe these code paths are untested by core WebKit developers. Also, in the modern world of multicore CPUs, it seems prudent to allow programmers to assume that all OS's running WebKit at least know what a thread is how to create one. Thoughts? Thanks, Geoff ___ 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] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
I agree - a media element with controls ought to be keyboard-accessible by
default. Right now it doesn't appear that you can even make an audio or
video element play in WebKit even if it is focused.
Firefox seems to treat the whole set of controls as one focusable element -
you can use the spacebar to play/pause and the arrow keys plus modifiers to
skip around. I couldn't figure out a way to access the volume control.
An alternative approach would be to make each individual subcontrol
focusable - the play/pause button, the seek slider, and the volume slider,
plus potentially other controls for video.
- Dominic
On Tue, Sep 13, 2011 at 12:04 PM, Deepak Sherveghar bpw...@motorola.comwrote:
Hi All,
As with current Webkit behavior, only media elements with tab-index
attribute specified can be focused with keyboard (TAB key).
From a usability as well as accessibility perspective, we should be able to
focus (via keyboard using TAB key)
media elements that have controls attribute specified but do not have a
tab-index attribute specified.
ie: video controls src=../media/content/test.mp4/video //should be
focused by tabbing.
This would help in making the media element keyboard accessible.
Firefox and Opera both support this behavior ie: focus media element by
tabbing without the need for tab-index.
you can verify this using the link :
http://yves.vg/testcases/webkit/video.html
I have already implemented this and uploaded my patch in BUG 67190.
My approach to support this is as follows:
In HTMLMediaElement.cpp., add
bool HTMLMediaElement::supportsFocus() const
{
// Return true if control attribute present else If no controls
specified, we should still be able to focus the element if it has tabIndex.
return controls() || HTMLElement::supportsFocus();
}
Antonio Gomes suggested that since my patch would be changing a general
behavior of all webkit based browsers
(and according to the spec it is up to the UA to implement that or not), we
could have a discussion in webkit-dev mailing list first.
Also Ian 'Hixie' Hickson is of the opinion that:
Whether something is interactive content or not has no bearing on
whether it is focusable or not: the definition of focusable doesn't
refer to whether something is interactive content:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#focusable
Whether something should be focusable or not is essentially up to the
browser vendor (you). I would recommend making it possible
to focus video controls if they are present, of course. But that's not a
spec conformance matter, it's a usability matter.
According to me, making media element focusable without tab-index (but
control attribute specified), would be first step in making the
media element keyboard accessible which would further help us make the
media element 'Interactive
(W3C Draft categorizes video and audio in Interactive Content) using
keyboard (ie play/pause media using space bar)
Need suggestion or feedback on this.
Whether we should go ahead with this or follow any other approach
Also a bug on second aspect of media element ie: to make it interactive
using keyboard is already being filled by Yves Van Goethem :
BUG: 31786 : https://bugs.webkit.org/show_bug.cgi?id=31786. I have marked
31786 bug as dependent on BUG: 67190.
Thanks in advance.
-Deepak Sherveghar
___
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] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
On Tue, Sep 13, 2011 at 12:04 PM, Deepak Sherveghar bpw...@motorola.comwrote: As with current Webkit behavior, only media elements with tab-index attribute specified can be focused with keyboard (TAB key). From a usability as well as accessibility perspective, we should be able to focus (via keyboard using TAB key) media elements that have controls attribute specified but do not have a tab-index attribute specified. ie: video controls src=../media/content/test.mp4/video //should be focused by tabbing. This would help in making the media element keyboard accessible. This seems like a good change provided we're not violating any standards by doing so. Also Ian 'Hixie' Hickson is of the opinion that: Whether something is interactive content or not has no bearing on whether it is focusable or not: the definition of focusable doesn't refer to whether something is interactive content: http://www.whatwg.org/specs/web-apps/current-work/complete.html#focusable Whether something should be focusable or not is essentially up to the browser vendor (you). I would recommend making it possible to focus video controls if they are present, of course. But that's not a spec conformance matter, it's a usability matter. I'm a bit surprised by this response. Since the concept of focus is exposed to the Web, it seems like we should be standardizing the behavior. But then I'm not opposed to this idea because not having a spec gives us more freedom. Need suggestion or feedback on this. Whether we should go ahead with this or follow any other approach Given the information provided here, I support making this change. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
On Wed, Sep 14, 2011 at 7:30 AM, Dominic Mazzoni dmazz...@google.comwrote: An alternative approach would be to make each individual subcontrol focusable - the play/pause button, the seek slider, and the volume slider, plus potentially other controls for video. What would script see as focused if we allow subcontrols be focusable? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Contributor list (was: Do you maintain OS(WINCE)?)
Ryosuke, On 09/13/2011 07:06 PM, Ryosuke Niwa wrote: Yeah, they're outdated to say the least. Can we merge those two lists? I think we can move information inside committers.py into a JSON file and load it automatically on the wiki. I don't know how to add arbitrary HTML on a wiki page, but I made a page that loads loads committers.py and presents it in a web-friendly way: http://people.profusion.mobi/~leandro/webkit-contributors.html With filtering by port or area of expertise this can be quite handy. Thoughts on how this could be improved? Specially if it can be kept up to date without too much work. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Contributor list (was: Do you maintain OS(WINCE)?)
On Wed, Sep 14, 2011 at 10:36 AM, Leandro Pereira lean...@profusion.mobiwrote: I don't know how to add arbitrary HTML on a wiki page, but I made a page that loads loads committers.py and presents it in a web-friendly way: http://people.profusion.mobi/~**leandro/webkit-contributors.**htmlhttp://people.profusion.mobi/~leandro/webkit-contributors.html With filtering by port or area of expertise this can be quite handy. Thoughts on how this could be improved? Specially if it can be kept up to date without too much work. It seems like we duplicated the work. I have my prototype posted on https://bugs.webkit.org/show_bug.cgi?id=68045. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
Hi Patrick. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing ENABLE_SINGLE_THREADED and ENABLE_JSC_MULTIPLE_THREADS
From what I understand, HTML5 Web Worker doesn't rely on threaded GC because each worker thread has its own heap. That's the current implementation, yes. (But we may be able to do something more efficient if we allow workers to rely on threaded GC.) The other place affected by ENABLE_JSC_MULTIPLE_THREADS is JSLock. However it is also said platforms other than MacOS doesn't need to implement JSLock. I think it's more accurate to say that platforms willing to crash if you use the JS API from multiple threads without explicit locking do not need to implement JSLock. (Of course, I'm trying to change that so the threading behavior of the JS API is consistent across all platforms. This is a key first step toward evolving the threading model in JSC.) Another feature currently guarded by ENABLE_JSC_MULTIPLE_THREADS is lazy block freeing in the heap. It seems the only use of ENABLE_JSC_MULTIPLE_THREADS is to use JS API from another thread. Is this correct? Not quite. Also, bear in mind that I'm talking about the set of ENABLE_SINGLE_THREADED, ENABLE_JSC_MULTIPLE_THREADS, and ENABLE_WTF_MULTIPLE_THREADS. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
One of the things I admire about the WebKit project is that historically the project has been very inclusive. One common thread that's woven through a number of recent discussions is that folks feel we've taken on too much complexity and that it's harder to make fundamental improvements to the engine. Maybe it's time to adjust that balance slightly, but I hope we adjust our behavior deliberately. Adam On Wed, Sep 14, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com wrote: Hi Patrick. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff ___ 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] What is an active port? [WAS: Do you maintain OS(WINCE)?]
Hi, I completely agree with all of your points. I also don't think that it's your task to keep every part time port working with every change. IMO most of the is active questions come with a when do we remove the old code/port from trunk question. That's not very cool to hear after the hard upstreaming work. But that's only my personal view. More interesting questing is: How do part time maintainers get informed about fundamental changes? I'd prefer cc'ing on a bug which might break a build. So it's possible for the maintainer to try to build with the patch locally and implement the missing parts. At least for me it's easier to fix compiler errors than answering questions about a possible build break on webkit-dev. ;-) - Patrick Am 14.09.2011 um 21:08 schrieb Geoffrey Garen: Hi Patrick. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
Maybe we need a webkit-port-maintainers@ list that one could easily cc rather than trying to add people by hand? -- Dirk On Wed, Sep 14, 2011 at 1:00 PM, Patrick Gansterer par...@paroga.com wrote: Hi, I completely agree with all of your points. I also don't think that it's your task to keep every part time port working with every change. IMO most of the is active questions come with a when do we remove the old code/port from trunk question. That's not very cool to hear after the hard upstreaming work. But that's only my personal view. More interesting questing is: How do part time maintainers get informed about fundamental changes? I'd prefer cc'ing on a bug which might break a build. So it's possible for the maintainer to try to build with the patch locally and implement the missing parts. At least for me it's easier to fix compiler errors than answering questions about a possible build break on webkit-dev. ;-) - Patrick Am 14.09.2011 um 21:08 schrieb Geoffrey Garen: Hi Patrick. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit update problem
hi i want to update source tree using update-webkit script but i have this error : svn: OPTIONS of 'http://svn.webkit.org/repository/webkit/trunk': Could not resolve hostname `svn.webkit.org': Temporary failure in name resolution ( http://svn.w ebkit.org) what should i do ? -- *There's nothing like waking up with God in your heart. * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
To mitigate this issue, Leandro (acidx) and I are working on change log parser that can automatically detect active patch contributors and reviewers. (See https://bugs.webkit.org/show_bug.cgi?id=68061). Having said that, I think contributors should help maintaining ports that have bots on build.webkit.org or EWS bots. - Ryosuke On Wed, Sep 14, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com wrote: In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff ___ 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] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
What would script see as focused if we allow subcontrols be focusable? Since controls are part of shadow DOM, scripts wont be able to see that. In this case then they would probably end up with respective media element. Well, then that should be layout tested as well. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
On 9/14/11 2:02 PM, Antonio Gomes wrote: What would script see as focused if we allow subcontrols be focusable? Since controls are part of shadow DOM, scripts wont be able to see that. In this case then they would probably end up with respective media element. Well, then that should be layout tested as well. Does the accessibility tree contain appropriate information about the text description and role of the shadow elements? Is the shadow DOM something that may be exposed publicly, the future? Such that a script can interact with those control elements. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ENABLE flag cleanup strawman proposal
I've updated the spreadsheet of all ENABLE flags to match TOT (as of this afternoon): https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Yncauthkey=CJCDiooKhl=en_US#gid=0 I've gone through the list and marked some of them that we might want to change, listed below. I expect this list to be somewhat controversial. Please consider it as a starting point for discussion. This proposal introduces a new kinds of flag: DEBUG. A DEBUG flag is only that we expect will only be used by developers locally to debug WebKit. For example, ENABLE(DEBUG_MATH_LAYOUT) and ENABLE(SAMPLING_COUNTERS) are only used to debug locally, not to ship to end users. The main benefit of labeling these flags as DEBUG-only, for example as DEBUG(MATH_LAYOUT), is that contributors don't need to worry as much about breaking them. (Of course, we still shouldn't try to break them capriciously.) I'd like to emphasize again that this list is just a starting point for discussion. I look forward to your feedback. Thanks, Adam == Rename == ENABLE(DATABASE) = ENABLE(SQL_DATABASE) ENABLE(LEVELDB) = USE(LEVELDB) ENABLE(ON_FIRST_TEXTAREA_FOCUS_SELECT_ALL) = Should be an editing behavior ENABLE(OPENTYPE_SANITIZER) = USE(OPENTYPE_SANITIZER) ENABLE(SYMBIAN_DIALOG_PROVIDERS) = USE(SYMBIAN_DIALOG_PROVIDERS) ENABLE(TILED_BACKING_STORE) = USE(TILED_BACKING_STORE) == Always Disable (Delete Code) == ENABLE(APPLICATION_CACHE_DYNAMIC_ENTRIES) ENABLE(FTPDIR) ENABLE(ICONDATABASE) ??? ENABLE(WBXML) ENABLE(WCSS) ENABLE(XHTMLMP) == Always Enable == ENABLE(DETAILS) ??? ENABLE(DOM_STORAGE) ENABLE(EVENTSOURCE) ENABLE(INSPECTOR) ??? ENABLE(METER_TAG) ENABLE(OFFLINE_WEB_APPLICATIONS) ENABLE(PROGRESS_TAG) ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) ENABLE(WEB_TIMING) ??? (I think Maciej has concerns about this feature, so maybe keep configurable.) ENABLE(WTF_MULTIPLE_THREADS) -- ggaren is already making this happen, right? ENABLE(XHR_RESPONSE_BLOB) = Gated by ENABLE(BLOB) ENABLE(XPATH) ENABLE(XSLT) == Mark as for Debugging == ENABLE(CODEBLOCK_SAMPLING) = DEBUG(CODEBLOCK_SAMPLING) ENABLE(DEBUG_MATH_LAYOUT) = DEBUG(MATH_LAYOUT) ENABLE(DEBUG_WITH_BREAKPOINT) = DEBUG(WITH_BREAKPOINT) ENABLE(FAST_MALLOC_MATCH_VALIDATION) = DEBUG(FAST_MALLOC_MATCH_VALIDATION) ENABLE(GC_VALIDATION) = DEBUG(GC_VALIDATION) ENABLE(OPCODE_SAMPLING) = DEBUG(OPCODE_SAMPLING) ENABLE(OPCODE_STATS) = DEBUG(OPCODE_STATS) ENABLE(REGEXP_TRACING) = DEBUG(REGEXP_TRACING) ENABLE(SAMPLING_COUNTERS) = DEBUG(SAMPLING_COUNTERS) ENABLE(SAMPLING_FLAGS) = DEBUG(SAMPLING_FLAGS) ENABLE(SAMPLING_THREAD) = DEBUG(SAMPLING_THREAD) ENABLE(WTF_MALLOC_VALIDATION) = DEBUG(WTF_MALLOC_VALIDATION) ENABLE(YARR_JIT_DEBUG) = DEBUG(YARR_JIT) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
For those of you interested in this stuff, I have a patch to add a webkit.org/team.html that auto-generates a list of contributors from committers.py on https://bugs.webkit.org/show_bug.cgi?id=68045. This version doesn't include area of expertise but we can add it easily once the bug 68061 is fixed (i.e. a script to detect active contributors and reviewers is added). - Ryosuke On Wed, Sep 14, 2011 at 1:08 PM, Ryosuke Niwa rn...@webkit.org wrote: To mitigate this issue, Leandro (acidx) and I are working on change log parser that can automatically detect active patch contributors and reviewers. (See https://bugs.webkit.org/show_bug.cgi?id=68061). Having said that, I think contributors should help maintaining ports that have bots on build.webkit.org or EWS bots. - Ryosuke On Wed, Sep 14, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com wrote: In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff ___ 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] ENABLE flag cleanup strawman proposal
== Always Enable == ENABLE(DETAILS) ??? ENABLE(DOM_STORAGE) ENABLE(EVENTSOURCE) ENABLE(INSPECTOR) ??? ENABLE(METER_TAG) ENABLE(OFFLINE_WEB_APPLICATIONS) ENABLE(PROGRESS_TAG) ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) ENABLE(WEB_TIMING) ??? (I think Maciej has concerns about this feature, so maybe keep configurable.) ENABLE(WTF_MULTIPLE_THREADS) -- ggaren is already making this happen, right? ENABLE(XHR_RESPONSE_BLOB) = Gated by ENABLE(BLOB) ENABLE(XPATH) ENABLE(XSLT) Is your proposal that since these ENABLE()s are always true, that we delete the compile guards from the codebase and build scripts? If so that sounds like a great idea in general (although I'm not saying that necessarily makes sense for everything in this list). - James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE flag cleanup strawman proposal
On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote: ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) I think Eric is planning to get rid of these flags for SVG sub-features. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE flag cleanup strawman proposal
On Wed, Sep 14, 2011 at 4:14 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote: ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) I think Eric is planning to get rid of these flags for SVG sub-features. Yep. I should have noted that in the same way I noted ggaren's work. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
