[webkit-dev] How to obtain IntRect of each option element of select element?
Hi webkit-dev, Is there any method to obtain the position (or IntRect) of each option element in the select element? So far I can get the offsetLeft offsetTop via methods of Element class but this seems to be the screen offset of the select element. Thanks. Regards, yang ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
We could have both const and non-const versions. For document(), we will certainly need both. I think these APIs can become less useful because the strict const-ness is yet to be deployed widely. We can apply the rule for fresh classes line new Web APIs since these rule worry little about older, less-const code. We'll need certain level of compromise for existing code. This means we cannot automate these check but it looks a reasonable starting point. -- morrita On Fri, Oct 26, 2012 at 12:53 PM, Elliott Sprehn espr...@chromium.orgwrote: This requires weird contortions in the DOM and Render tree and removes nice guarantees. For example Node.h has: TreeScope* treeScope() const; Document* document() const; Node* childNode(unsigned index) const; Returning a const Document* or Node* from childNode makes the DOM API's suddenly less useful, and marking them as non-const is confusing. These methods shouldn't be making mutations and the compiler should enforce that (or at least try to), and the const is also good documentation. On Thu, Oct 25, 2012 at 1:02 PM, Peter Kasting pkast...@google.com wrote: On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling kl...@webkit.org wrote: So, I propose that we allow only these two signature formats for raw pointers: - const Foo* foo() const; - Foo* foo(); ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
This thread stalled out because although there seemed to be majority agreement that hermetic/repeatable tests are a good thing, there was a requirement that all ports be updated to the new behavior at the same time, and I'm only competent to do the chromium DRT (see https://bugs.webkit.org/show_bug.cgi?id=93195 for details). Is anyone interested in stepping up and doing the equivalent (clear caches between tests) for the mac and/or gtk ports' DRTs? On Wed, Aug 8, 2012 at 2:35 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Aug 8, 2012 at 10:47 AM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Given that the way we run tests in parallel in NRWT means that different processes get different lists of tests each time, it sounds like we may be getting a fair amount of nondeterminism from the cache not being cleared between tests. That seems bad, so I'm in favor of clearing the cache :) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Where is the Gtk+ DOM API?
Hello. I used Webkitgtk3 (webkit 1.8) on my Ubuntu 12.04 for a program I'm developing. I used the webkit_dom_html_element_click() function call to trigger click events on elements. But now, when I look into the newer code (webkit 1.10) there's no trace of these API calls. What happened? Greets, Luka ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Wed, Aug 8, 2012 at 9:54 PM, Eric U er...@google.com wrote: On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org wrote: I can see some downsides to emptying the cache before each test: - we won't be getting any test coverage for cache behavior when it hits non-trivial size; Then let's add a cache test explicitly for this. Otherwise we just have to hope it gets tested accidentally along the way. Cache has subtle interactions with other things being tested (-flakiness). More explicit cache tests would be nice but we can't hope the replicate all the accidental testing we now get. We are going to lose a large chunk of existing test coverage if we do this. antti - this may well make tests measurably slower; - this will be yet another cause of subtle difference between platforms, as some will undoubtedly have this unimplemented for a long time. Both good points, but probably worth it, given the reliability improvement in the tests IMO. Eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Where is the Gtk+ DOM API?
On Fri, Oct 26, 2012 at 11:35 AM, Luka Napotnik luka.napot...@gmail.com wrote: Hello. I used Webkitgtk3 (webkit 1.8) on my Ubuntu 12.04 for a program I'm developing. I used the webkit_dom_html_element_click() function call to trigger click events on elements. But now, when I look into the newer code (webkit 1.10) there's no trace of these API calls. What happened? This list is for general WebKit development. For the WebKit GTK API, try the list bellow: http://lists.webkit.org/mailman/listinfo/webkit-gtk Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 1:44 AM, Antti Koivisto koivi...@iki.fi wrote: Cache has subtle interactions with other things being tested (-flakiness). More explicit cache tests would be nice but we can't hope the replicate all the accidental testing we now get. We are going to lose a large chunk of existing test coverage if we do this. The reality is that this test coverage today shows up as flakiness and so is ignored anyway, meaning we don't actually have useful coverage here. Even when flakiness is investigated, the fix is to cache-bust using unique URL params, which just means we lose the coverage you describe for that test, anyway. Brian notes in the bug that GTK wk2 GTK+ are done. I believe that just leaves chromium mac. Anyone wanting to step up to do mac, and, I guess, wk2 mac? -a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
It is valid for a const method to return you a new object ie a const factory object. In that case, const-ness would not be desired. Rik On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling kl...@webkit.org wrote: Yo WebKittens! After some mild morning discussion in #webkit, I'm wondering if we should amend our style guide to disallow returning mutable pointers (Foo*) from const methods, like so: - Foo* foo() const; While this is useful when you want to be able to take a strong reference to the returned object, i.e by assigning it to a RefPtrFoo, it's counter-intuitive as it encourages read-only methods to hand out read/write references to internal data. I've been using const-ness to prevent certain classes of bugs at compile time for the immutable/mutable implementations of WebCore's ElementAttributeData and StylePropertySet. It's especially important that the immutable versions of these objects don't have their internal data modified by unwitting external clients, since they may be shared between multiple owners. While using assertions helps us catch incorrect use of these objects, it's obviously optimal to catch the bugs already at compile time. I just now discovered that you can grab at a mutable CSSValue* pointer in an immutable const StylePropertySet* by going through propertyAt(index).value(), since we have CSSValue* CSSProperty::value() const. This is bad, because it means that we have a bunch of call sites operating on mutable pointers into what's supposed to be an immutable object! While I haven't identified any real bugs caused by this (yet), it would be easy to introduce one by mistake. So, I propose that we allow only these two signature formats for raw pointers: - const Foo* foo() const; - Foo* foo(); Moreover, for methods that return references to objects where call sites are expected to take a strong reference, we should really be using PassRefPtrFoo as the return type. Thoughts? Objections? Am I missing something? -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier caban...@gmail.com wrote: It is valid for a const method to return you a new object ie a const factory object. In that case, const-ness would not be desired. Not really. The point of this thread is that such functions may not modify an object's state themselves, but they vend access that can be used by the caller to modify it. Consider for example: Child* Parent::getNewChild() const; Assuming the Parent doesn't have a list of its children (questionable), we can implement this without mutable pointers. But then a caller can do: Child* child = parent-getNewChild(); child-parent-mutate(); If you generalize this you find there are very, very few cases where a const object can vend a non-const pointer that cannot possibly be used to change the state of the world the const object sees. Which is why the rule of thumb suggested in this thread is safer and easier than trying to reason about individual cases. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS and CORS
Hi WebKit folks,
I have a question to origin restriction and CSS. First the context:
CSS Masking[1] aims to combine the two different 'mask' property
implementations from WebKit and Firefox. To make it short, 'mask' takes an URL
and this can either be a reference to an image, or to an mask element:
svg
mask id=mask
…
/mask
/svg
style
img {
mask: url(#mask); /* references an SVG Mask element for masking
operation (Firefox), OR */
-webkit-mask: url(test.png); / takes a reference to an image and
operates the masking with the image (WebKit) */
/style
img … /
CSS Masking tries to make both possible in the future.
The problem is, that a mask can be in an external SVG file and be referenced
by SVG fragments: url(http://external.com/mask.svg#mask). It would still not be
sure it the fragment points to a graphical element like a path (then the SVG
file would be interpreted as image) or if it references a mask element, in
which case it will be an external resource. You need to download the file and
parse it to know that.
Does it matter to know if it is an external resource or image before
downloading?
A mask element can have events, which run JavaScript: mask
onload=console.log('CORS? Of course!'). Running the mask element will fire
the event, which is maybe a violation against CORS, since the SVG file can come
from a different origin.
For images, we don't care about the origin, don't run scripts and don't fire
events.
My question is if we have already an CSS property, widely implemented in
WebKit, where CORS matters? When do we decide not to go on with the
interpretation of a resource because of violation of CORS? Before we even
download the resource? After we may already parsed it?
Firefox does care about that before parsing and does not load the entire SVG
file if it is from a different origin. Since Firefox does not support image
references for 'mask', they always assume that the reference is an external
reference and not an image.
Opera does not care about the origin, but scripts are not executed and events
don't fire.
Greetings,
Dirk
[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property
PS: WebKit has support for 'mask' property with referencing of mask elements.
Currently, external files are not supported. The mask element must be in the
same document.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
On Fri, Oct 26, 2012 at 9:06 AM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier caban...@gmail.com wrote: It is valid for a const method to return you a new object ie a const factory object. In that case, const-ness would not be desired. Not really. The point of this thread is that such functions may not modify an object's state themselves, but they vend access that can be used by the caller to modify it. Consider for example: Child* Parent::getNewChild() const; Assuming the Parent doesn't have a list of its children (questionable), we can implement this without mutable pointers. But then a caller can do: Child* child = parent-getNewChild(); child-parent-mutate(); this would only be possible if that parent object is casting away a 'const' somewhere or accessing a global non-const object. Maybe there should be a rule that 'mutable' or 'const_cast' should not be allowed. If you generalize this you find there are very, very few cases where a const object can vend a non-const pointer that cannot possibly be used to change the state of the world the const object sees. Which is why the rule of thumb suggested in this thread is safer and easier than trying to reason about individual cases. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
I don't know that there was consensus that every port had to be updated at the same time; in fact Balazs said Qt and EFL already clear the cache. I think you should just land the change for Chromium and let others update their ports as needed. The value in reduced flakiness and more predictability outweighs anything else in my book. Test coverage that you can't explain or rely on doesn't count for much to me. -- Dirk On Fri, Oct 26, 2012 at 1:20 AM, Ami Fischman fisch...@chromium.org wrote: This thread stalled out because although there seemed to be majority agreement that hermetic/repeatable tests are a good thing, there was a requirement that all ports be updated to the new behavior at the same time, and I'm only competent to do the chromium DRT (see https://bugs.webkit.org/show_bug.cgi?id=93195 for details). Is anyone interested in stepping up and doing the equivalent (clear caches between tests) for the mac and/or gtk ports' DRTs? On Wed, Aug 8, 2012 at 2:35 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Aug 8, 2012 at 10:47 AM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Given that the way we run tests in parallel in NRWT means that different processes get different lists of tests each time, it sounds like we may be getting a fair amount of nondeterminism from the cache not being cleared between tests. That seems bad, so I'm in favor of clearing the cache :) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 6:09 PM, Ami Fischman fisch...@chromium.org wrote: The reality is that this test coverage today shows up as flakiness and so is ignored anyway, meaning we don't actually have useful coverage here. Even when flakiness is investigated, the fix is to cache-bust using unique URL params, which just means we lose the coverage you describe for that test, anyway. When making cache related changes I have frequently found bugs from my patches because some seemingly random test started failing and I investigated. Without the test coverage some of those bugs would probably now be in the tree. antti Brian notes in the bug that GTK wk2 GTK+ are done. I believe that just leaves chromium mac. Anyone wanting to step up to do mac, and, I guess, wk2 mac? -a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote: ... I agree this is a good change but it appears that we should add more cache/loader tests before changing DRT's behavior given that there are active contributors who rely on the current DRT behaviors to detect regressions. Can we add a flag to control this behavior? Then Antti could run the tests without cache clearing when modifying things possibly related to the cache code. We could even run a separate cr-linux bot like we do for debug builds. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn espr...@chromium.orgwrote: On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote: ... I agree this is a good change but it appears that we should add more cache/loader tests before changing DRT's behavior given that there are active contributors who rely on the current DRT behaviors to detect regressions. Can we add a flag to control this behavior? Then Antti could run the tests without cache clearing when modifying things possibly related to the cache code. We could even run a separate cr-linux bot like we do for debug builds. I think having a set of tests that tests loaders/caches explicitly is more useful. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote: ... I agree this is a good change but it appears that we should add more cache/loader tests before changing DRT's behavior given that there are active contributors who rely on the current DRT behaviors to detect regressions. Can we add a flag to control this behavior? Then Antti could run the tests without cache clearing when modifying things possibly related to the cache code. We could even run a separate cr-linux bot like we do for debug builds. I think having a set of tests that tests loaders/caches explicitly is more useful. I think having a set of tests for loaders and caches would be more useful as well, but I don't think it's fair to make that a requirement to changing the default behavior here, especially since it's not clear who all would be best suited to writing those tests or what the extent of that work is. I think Eliot's suggestion is a good one. I think the overall cost to the project by having flakiness in the tests probably outweighs the value we get in mysterious additional coverage, and it seems like having a flag would be a good compromise. -- Dirk - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote: I agree this is a good change but it appears that we should add more cache/loader tests before changing DRT's behavior given that there are active contributors who rely on the current DRT behaviors to detect regressions. Not knowing the specifics of the regressions in question, I don't have any idea what these new cache-related tests would be. -a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
26.10.2012, в 11:04, Antti Koivisto koivi...@iki.fi написал(а): The reality is that this test coverage today shows up as flakiness and so is ignored anyway, meaning we don't actually have useful coverage here. Even when flakiness is investigated, the fix is to cache-bust using unique URL params, which just means we lose the coverage you describe for that test, anyway. I think that this is the real issue here. Test flakiness is very important to investigate, this often leads to discovery of bad bugs, including security ones. The phrase flaky test often misplaces the blame. When making cache related changes I have frequently found bugs from my patches because some seemingly random test started failing and I investigated. Without the test coverage some of those bugs would probably now be in the tree. I agree with Antti. Finding regressions is what tests are for, and it would be difficult to make enough explicit tests to compensate for such loss of coverage. It would certainly be very unfortunate to lose test coverage without even an attempt to compensate for that. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
Should we add random sleeps to DRT? It'll certainly help find some regressions (and even security bugs). Of course the down-side is that it makes tests non-repeatable and difficult to reason about. I'm baffled by your priorities and don't know how to continue this conversation productively. Sorry. Cheers, -a On Fri, Oct 26, 2012 at 12:43 PM, Alexey Proskuryakov a...@webkit.org wrote: 26.10.2012, в 11:04, Antti Koivisto koivi...@iki.fi написал(а): The reality is that this test coverage today shows up as flakiness and so is ignored anyway, meaning we don't actually have useful coverage here. Even when flakiness is investigated, the fix is to cache-bust using unique URL params, which just means we lose the coverage you describe for that test, anyway. I think that this is the real issue here. Test flakiness is very important to investigate, this often leads to discovery of bad bugs, including security ones. The phrase flaky test often misplaces the blame. When making cache related changes I have frequently found bugs from my patches because some seemingly random test started failing and I investigated. Without the test coverage some of those bugs would probably now be in the tree. I agree with Antti. Finding regressions is what tests are for, and it would be difficult to make enough explicit tests to compensate for such loss of coverage. It would certainly be very unfortunate to lose test coverage without even an attempt to compensate for that. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 11:43 AM, Dirk Pranke dpra...@chromium.org wrote: On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote: ... I agree this is a good change but it appears that we should add more cache/loader tests before changing DRT's behavior given that there are active contributors who rely on the current DRT behaviors to detect regressions. Can we add a flag to control this behavior? Then Antti could run the tests without cache clearing when modifying things possibly related to the cache code. We could even run a separate cr-linux bot like we do for debug builds. I think having a set of tests that tests loaders/caches explicitly is more useful. I think having a set of tests for loaders and caches would be more useful as well, but I don't think it's fair to make that a requirement to changing the default behavior here, especially since it's not clear who all would be best suited to writing those tests or what the extent of that work is. I’m sure Antti, Alexey, and others who have worked on the loader and other parts of WebKit are happy to write those tests or list the kind of things they want to test. Heck, I don’t mind writing those tests if someone could make a list. I totally sympathize with the sentiment to reduce the test flakiness but loader and cache code have historically been under-tested, and we’ve had a number of bugs detected only by running non-loader tests consecutively. On the contrary, we’ve had this DRT behavior for ages. Is there any reason we can’t wait for another couple of weeks or months until we add more loader cache tests before making the behavior change? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Fri, Oct 26, 2012 at 2:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Is there any reason we can’t wait for another couple of weeks or months until we add more loader cache tests before making the behavior change? There is no time pressure here other than a desire to avoid this falling between the cracks and (continuing to) never being done. Is anyone signing up to write or enumerate the tests, who can do the work in the next weeks/months, but not immediately? -a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
26.10.2012, в 14:57, Dirk Pranke dpra...@chromium.org написал(а): Perhaps a slight variant of this is that we can agree to make the changes on the Chromium port to clear the cache (much like the Qt and EFL ports already do), and you can continue to not clear the cache on the Apple Mac port until you feel comfortable that you've added additional tests? This means that when someone introduces flakiness into resource caching, it will be only seen on Apple Mac bots. How is this good for anyone? I personally find this unacceptable, as this will reduce usefulness of Apple Mac bots. The whole idea to clear cache between tests seems very arbitrary to me. There are lot of things remaining in the process across tests runs, and I'm not sure why you are picking on the one with the least explicit test coverage. Historically, test flakiness appears to increase whenever we do anything to address it without actual investigation of the root cause. Not long ago, we could run tests without re-running flaky tests, and get 100% pass. Now, we have many more flaky tests, re-run them, but flakiness remains even after second run. I don't think that this is a result of project scale change - I think that this is a result of the desire to get green bots without doing real WebCore work to fix underlying bugs. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Experimental implementation of interactive autocomplete
Hello webkit-dev'ers, In response to the email “Improving autocomplete” to wha...@whatwg.org [1], I plan to implement an experimental version of the proposed API (HTMLFormElement#requestAutocomplete, onautocomplete, onautocompleteerror). This feature uses information derived from the new autocomplete spec [2] to present a JS API for web developers to opt-in into a native, interactive autocomplete flow. This will be behind the default-off feature flag ENABLE(REQUEST_AUTOCOMPLETE) and will be enabled for Chromium specifically when more code on Chromium's side is landed. You can follow along here: https://bugs.webkit.org/show_bug.cgi?id=100560 Thanks, Dan Beam db...@chromium.org [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037711.html [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS and CORS
On Oct 26, 2012, at 9:04 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Oct 26, 2012 at 9:08 AM, Dirk Schulze dschu...@adobe.com wrote:
Hi WebKit folks,
I have a question to origin restriction and CSS. First the context:
CSS Masking[1] aims to combine the two different 'mask' property
implementations from WebKit and Firefox. To make it short, 'mask' takes an
URL and this can either be a reference to an image, or to an mask element:
svg
mask id=mask
…
/mask
/svg
style
img {
mask: url(#mask); /* references an SVG Mask element for masking
operation (Firefox), OR */
-webkit-mask: url(test.png); / takes a reference to an image and
operates the masking with the image (WebKit) */
/style
img … /
CSS Masking tries to make both possible in the future.
The problem is, that a mask can be in an external SVG file and be
referenced by SVG fragments: url(http://external.com/mask.svg#mask). It
would still not be sure it the fragment points to a graphical element like a
path (then the SVG file would be interpreted as image) or if it references
a mask element, in which case it will be an external resource. You need to
download the file and parse it to know that.
Does it matter to know if it is an external resource or image before
downloading?
Ouch. That sounds like a bad constraint. How do you plan to
implement that? I guess you'd need to load the SVG as an SVGImage and
then either extract the path or the bitmap depending if there is an
element with a given ID? At what point do you check for the ID? For
example, do you want for DOMContentLoaded, or do you wait to see if an
ID gets added by JavaScript executing in the page? Can mask.svg
execute JavaScript? (Normally we ban the execution of JavaScript
inside SVGImage.)
We could load the external file as a document (similar to iframe), check for
the header first, if it is an SVG document we check the element if it is a mask
or not. That was at least my naive idea. :)
A mask element can have events, which run JavaScript: mask
onload=console.log('CORS? Of course!'). Running the mask element will
fire the event, which is maybe a violation against CORS, since the SVG file
can come from a different origin.
I see! If the mask element can execute JavaScript, then we cannot
load the resource in an SVGImage because we forbid JavaScript
execution in an SVGImage. Where do you plan to load mask.svg?
Yes. But I just learned that Gecko never executes scripts on external
resources. External references don't have a browser context in Gecko and
therefore don't run JavaScript. Opera does support scripts if it is from the
same origin. However, this is unspecified in SVG and I am working towards
finding a common and secure solution. The approach from Gecko seems to be sane.
For images, we don't care about the origin, don't run scripts and don't fire
events.
Correct.
My question is if we have already an CSS property, widely implemented in
WebKit, where CORS matters?
CORS is supposed to matter for @font-face. I'm not sure whether it
does in our current implementation. In any case, it's easy to add
CORS support for a load. You can look at how the crossorigin
attribute for img works.
When do we decide not to go on with the interpretation of a resource because
of violation of CORS? Before we even download the resource? After we may
already parsed it?
The CORS go/no-go decision happens when we receive the response
headers, before we start parsing the resource.
Firefox does care about that before parsing and does not load the entire SVG
file if it is from a different origin. Since Firefox does not support image
references for 'mask', they always assume that the reference is an external
reference and not an image.
That seems vastly more sane. Supporting both images and mask
elements with the same syntax seems very difficult, if not impossible
given the constraints that we need to execute JavaScript for the
mask case.
Yes, the scripting part is a bit odd. I think following Gecko and don't allow
scripting on any external document seems sane.
Opera does not care about the origin, but scripts are not executed and
events don't fire.
Can we do that? Note: You still need to sorry about CORS because this
API lets you query for whether a document contains an element of a
given ID, which isn't something you're supposed to be able to learn
about cross-origin resources.
It would be a bit like the solution from Gecko, if no browser context, then no
script. Gecko added CORS as an additional restriction, which seems to be more
secure. clipPath for instance contributes to hit testing.
PS: WebKit has support for 'mask' property with referencing of mask
elements. Currently, external files are not supported. The mask element must
be in the same document.
Can we continue to do that? Referencing external files in
[webkit-dev] FrameView::setBaseBackgroundColor
Hi all, I had a doubt regardingFrameView::setBaseBackgroundColor. Is it used to set the default background color of the web page? say for example if background css property is not preset, I can use this API is override the default white color? Thanks, --Vineeth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
