[webkit-dev] Adding File/DirectoryEntry access support for drag-and-drop (if ENABLE(FILE_SYSTEM))
Hi WebKit-dev folks,
Last year I proposed [1] adding support to access dropped/selected
files/directories
via {File,Directory}Entry defined in FileSystem API [2] for better
directory drag-
and-drop support. The proposal got positive feedbacks in general and
I would like to land the changes that expose the feature to experiment this.
[1] Proposal thread on whatwg:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html
[2] File API: Directories and System http://www.w3.org/TR/file-system-api/
To be more specific, I am adding following two APIs:
1) DataTransferItem.getAsEntry() (.webkitGetAsEntry()) for giving access
to Entry's for dropped files/directories via native HTML5 DnD, and
2) HTMLInputElement.entries (.webkitEntries) for input type=file tag.
They are enabled if and only if FILE_SYSTEM flag is enabled.
Most changes are / will be placed under WebCore/Modules/filesystem
or in platform-specific code, though some changes ( 100 lines) need to be
made in the common code.
Umbrella bug: https://bugs.webkit.org/show_bug.cgi?id=76809
Any comments are welcome.
For some more context:
Currently WebKit supports directory drag-and-drop via input using
'webkitdirectory' experimental attribute (iff DIRECTORY_UPLOAD is
enabled),
but it requires a full recursive directory traversal in advance to find
all the
subdirs/files, which could slow down responsiveness and could cause
bad user experience.
We (and some of people who supported the idea on whatwg) think
DirectoryEntry's asynchronous API has a big advantage in such situation
and would like to experiment it.
Thanks,
Kinuko
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] paged media update?
Hey Dave, thanks for the information (and sorry for not answering sooner). Do you have any (rough) ETA on when the required refactorings are going to land in WebKit trunk? Is there maybe a way for me to stay notificated about updates, i.e. some bug report used to track the refactoring? If possible, I would really like to get an estimate on when one could theoretically start hacking on paged media module support. Cheers On Wednesday 16 May 2012 14:25:20 David Hyatt wrote: The difficulty with implementing paged media right now is that I'm beginning work on re-architecting pagination to unify columns, pages and regions. You can see the beginnings of this with the new multi-column classes that have been added to the tree. The basic idea is that multi-column layout is being separated from RenderBlock and moved to a subclass, RenderMultiColumnBlock. Similar to how regions work, the content is represented by a flow thread and by regions that the flow thread is placed into. In order to avoid creating thousands of regions for columns, I've introduced the concept of a region set, i.e., RenderMultiColumnSet. Pages ultimately need to be rebuilt to work the same way, i.e., to have a RenderPageFlowThread and a RenderPageSet. Once we have actual renderers that represent these objects, it will be a lot easier to make real boxes for things like margins, headers, footers, etc. The idea is that a set represents a contiguous run of objects that can all be rendered identically. If you're forced to have a different kind of object, e.g., a page with a different width/height or different style, then you break up the RenderPageSet and have multiple sets for each (this is similar to how regions work by default, although I hope to apply the same optimization to regions eventually as well if runs of same width/height regions are detected that are also siblings in the render tree). dave -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions 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] Using ref tests for repaint bugs
I want to give everyone an update on how things are evolving. For now, I've focused most of the development on the Mac platform. For the ref-tests-as-repaint-tests path, I've added an optional parameter to LTC.display() that should control if the repaint rectangles are tracked or not. If not specified or true, the repaint rectangles are tracked. After running very basic experiments, this seems to detect if repaint artifacts are present in a test. For the repaint-rects-as-repaint-tests path, I have some questions about what should be the best testing methodology. I'm thinking about something along these lines: * I don't think a new script option or DRT parameter are necessary; the repaint rectangles for a test can be extracted together with the pixel results * The format for the rectangles data should be simple, maybe X,Y,W,H separated by new-lines? Or the smallest rectangle that includes all of the repaint rectangles? Or another suggestion? * When initially running a repaint test, both a PNG and RR (repaint-rectangles) files are generated as baselines. At subsequent executions of the test, the RR expected output is preferred over the pixel results. This means that if the test author modifies the expected PNG, the test should still pass because the RR baseline exists. However, if a pixel test in preferred, deleting the expected RR output will force the test runner to fallback on the classic image diff code path. * A port may chose to repaint everything, even for partial canvas invalidation. Do you think it's correct to evaluate a test as passed if the expected repaint rectangles are included in the actual repaint rectangles? The simplest and straightforward way to compare the actual results with the expected ones is a simple bytes diff, but I'm not convinced it's correct. Any thoughts on this? The chromium DRT project has a different strategy for masking with the repaint rectangles; could someone help me understand better what happens in the WebViewHost::paintInvalidatedRegion() method and why exactly is iterating 3 times through that code necessary? (the comment looks a little obsoleted and I'd appreciate some clarifications). Overall, I see some difficulties in keeping the repaint rectangles based testing to be platform independent. Do you have any suggestions that may help with this? Once I'm finished patching the Python scripts to support the RR tests, I'll upload a patch so people can look over the approach. Thx, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Hi webkit-dev! I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator Looking forward to your comments. -Annie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Our past experience with this sort of thing at Apple is that it led to bugs we didn’t find until after we shipped “final” software because they did not show up during earlier testing. Since then, we’ve gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Maybe you could make your case for the usefulness of the attribute? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOM tree traversal on detached nodes
[Summary]
What values should span.parentNode and span.firstChild return in the
following code? (test html http://haraken.info/null/ref_count2.html).
div = document.createElement(div);
document.body.appendChild(div);
div.innerHTML = 'pppspan
id=spanbrbrbrtext/span/p/p/p';
span = document.getElementById(span);
div.innerHTML = ;
alert(span); // span
alert(span.parentNode); // ???
alert(span.firstChild); // ???
(a) span.parentNode = p, span.firstChild = br
(b) span.parentNode = null, span.firstChild = br
(c) span.parentNode = p, span.firstChild = null
(d) span.parentNode = null, span.firstChild = null
(e) Any value is OK (i.e. the behavior is UNDEFINED)
[Behavior in browsers]
Safari 5.1.7: (b)
Chrome 20.0: (b)
Firefox 12.0: (a)
Opera 11.64: (a)
IE 9: (d)
[How WebKit behaves as (b)]
The behavior is caused by the reference counting algorithm of Node objects (
TreeShared.hhttp://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/TreeShared.hexact_package=chromiumq=treeshared.htype=cs).
In the TreeShared algorithm, a Node X is destructed if the ref-count of X
is 0 and X's parent is NULL. So div.innerHTML = causes the following
steps:
(0) The ref-counts of three ps are 0.
(1) div.innerHTML = is executed.
(2) The parent of the first p becomes NULL. The first p is destructed.
(3) The parent of the second p becomes NULL. The second p is destructed.
(4) The parent of the third p becomes NULL. The third p is destructed.
On the other hand, brbrbr are not destructed because span is
referenced from the JS side and thus the parent of the first br does not
become NULL. Note that X is destructed if the ref-count of X is 0 and X's
parent is NULL implies that If X has a ref count, then all the nodes
under X are kept alive. That's why ppp are destructed but
brbrbr are not destructed.
[Other weird behaviors]
The behavior (b) is weird, and it causes other subtle issues. For example,
editing. Consider the following code (test
htmlhttp://haraken.info/null/ref_count4.html
):
div contentEditable
apbpcpdspan id=spanebrfbrgbrh/pi/pj/pk
/div
/body
script
span = document.getElementById(span);
setTimeout(function () {
// Please manually delete the texts in div within 10 seconds
alert(span = + span); // span
alert(span.parentNode = + span.parentNode); // p
alert(span.parentNode = + span.parentNode.parentNode); // null
alert(span.firstChild = + span.firstChild); // e
}, 1);
I am not sure why span.parentNode returns p
but span.parentNode.parentNode returns null. Maybe an undo stack keeps
reference to p?
Here is another example. According to the behavior (b), the following
result makes sense (test html http://haraken.info/null/ref_count3.html):
htmlbodypspan id=spanbr/span/p/body
script
span = document.getElementById(span);
document.body.innerHTML = ;
alert(span = + span); // span
alert(span.parentNode = + span.parentNode); // null
alert(span.firstChild = + span.firstChild); // br
/script
/html
However, if we omit /span and /p, the result changes (test
htmlhttp://haraken.info/null/ref_count3-2.html
):
htmlbodypspan id=spanbr/body
script
span = document.getElementById(span);
document.body.innerHTML = ;
alert(span = + span); // span
alert(span.parentNode = + span.parentNode); // p
alert(span.firstChild = + span.firstChild); // br
/script
/html
Maybe the HTML parser has a list of not-yet-closed tags and the tag entry
keeps reference to p? I am not sure.
Anyway, the point is that the behavior (b) is UNDEFINED from the
perspective of JS programmers. The behavior depends on what JS objects are
being used and what data structures are implicitly being allocated in
WebCore.
[Discussion]
First of all, it seems that the behavior is not defined in the spec.
IMHO, (a) would be the best semantics. The semantics of (a) is very
straightforward from the perspective of JS programmers, i.e. Reachable DOM
nodes from JS are kept alive. On the other hand, (b) and (c) are not good
in that the semantics is UNDEFINED (i.e. the semantics depends on the
implementation details). Consequently, in terms of the semantics, WebKit
might want to change the current behavior to (a).
That being said, I am not sure if the semantics is practically important in
the real world. As explained above, indeed the behavior (b) will cause a
lot of weird bugs, but it would be rare cases. In fact, considering that
IE, FIrefox, Opera, Chrome and Safari has been behaving differently, the
current confusing semantics has not caused a big practical issue. This
would imply that the behavior does not matter in the real world. If you
know any bugs caused by the behavior, I am super happy to know.
[Why I am discussing this]
I've been designing V8 GC for DOM objects. I investigated a couple of
ideas, one of which requires the semantics that Reachable DOM nodes are
kept alive. The semantics is required to reclaim DOM
Re: [webkit-dev] DOM tree traversal on detached nodes
The semantics will fix the
FIXMEhttp://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSNodeCustom.cppexact_package=chromiumq=jsnodecustomtype=csl=112
in
JSC GC.
Sorry, the link was wrong. Correction:
Herehttp://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSNodeCustom.cppexact_package=chromiumq=jsnodecustomtype=csl=91
On Thu, Jun 7, 2012 at 10:14 AM, Kentaro Hara hara...@chromium.org wrote:
[Summary]
What values should span.parentNode and span.firstChild return in the
following code? (test html http://haraken.info/null/ref_count2.html).
div = document.createElement(div);
document.body.appendChild(div);
div.innerHTML = 'pppspan
id=spanbrbrbrtext/span/p/p/p';
span = document.getElementById(span);
div.innerHTML = ;
alert(span); // span
alert(span.parentNode); // ???
alert(span.firstChild); // ???
(a) span.parentNode = p, span.firstChild = br
(b) span.parentNode = null, span.firstChild = br
(c) span.parentNode = p, span.firstChild = null
(d) span.parentNode = null, span.firstChild = null
(e) Any value is OK (i.e. the behavior is UNDEFINED)
[Behavior in browsers]
Safari 5.1.7: (b)
Chrome 20.0: (b)
Firefox 12.0: (a)
Opera 11.64: (a)
IE 9: (d)
[How WebKit behaves as (b)]
The behavior is caused by the reference counting algorithm of Node objects
(TreeShared.hhttp://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/TreeShared.hexact_package=chromiumq=treeshared.htype=cs).
In the TreeShared algorithm, a Node X is destructed if the ref-count of X
is 0 and X's parent is NULL. So div.innerHTML = causes the following
steps:
(0) The ref-counts of three ps are 0.
(1) div.innerHTML = is executed.
(2) The parent of the first p becomes NULL. The first p is destructed.
(3) The parent of the second p becomes NULL. The second p is
destructed.
(4) The parent of the third p becomes NULL. The third p is destructed.
On the other hand, brbrbr are not destructed because span is
referenced from the JS side and thus the parent of the first br does not
become NULL. Note that X is destructed if the ref-count of X is 0 and X's
parent is NULL implies that If X has a ref count, then all the nodes
under X are kept alive. That's why ppp are destructed but
brbrbr are not destructed.
[Other weird behaviors]
The behavior (b) is weird, and it causes other subtle issues. For example,
editing. Consider the following code (test
htmlhttp://haraken.info/null/ref_count4.html
):
div contentEditable
apbpcpdspan id=spanebrfbrgbrh/pi/pj/pk
/div
/body
script
span = document.getElementById(span);
setTimeout(function () {
// Please manually delete the texts in div within 10 seconds
alert(span = + span); // span
alert(span.parentNode = + span.parentNode); // p
alert(span.parentNode = + span.parentNode.parentNode); // null
alert(span.firstChild = + span.firstChild); // e
}, 1);
I am not sure why span.parentNode returns p
but span.parentNode.parentNode returns null. Maybe an undo stack keeps
reference to p?
Here is another example. According to the behavior (b), the following
result makes sense (test html http://haraken.info/null/ref_count3.html):
htmlbodypspan id=spanbr/span/p/body
script
span = document.getElementById(span);
document.body.innerHTML = ;
alert(span = + span); // span
alert(span.parentNode = + span.parentNode); // null
alert(span.firstChild = + span.firstChild); // br
/script
/html
However, if we omit /span and /p, the result changes (test
htmlhttp://haraken.info/null/ref_count3-2.html
):
htmlbodypspan id=spanbr/body
script
span = document.getElementById(span);
document.body.innerHTML = ;
alert(span = + span); // span
alert(span.parentNode = + span.parentNode); // p
alert(span.firstChild = + span.firstChild); // br
/script
/html
Maybe the HTML parser has a list of not-yet-closed tags and the tag entry
keeps reference to p? I am not sure.
Anyway, the point is that the behavior (b) is UNDEFINED from the
perspective of JS programmers. The behavior depends on what JS objects are
being used and what data structures are implicitly being allocated in
WebCore.
[Discussion]
First of all, it seems that the behavior is not defined in the spec.
IMHO, (a) would be the best semantics. The semantics of (a) is very
straightforward from the perspective of JS programmers, i.e. Reachable DOM
nodes from JS are kept alive. On the other hand, (b) and (c) are not good
in that the semantics is UNDEFINED (i.e. the semantics depends on the
implementation details). Consequently, in terms of the semantics, WebKit
might want to change the current behavior to (a).
That being said, I am not sure if the semantics is practically important
in the real world. As explained above, indeed the behavior (b) will
Re: [webkit-dev] DOM tree traversal on detached nodes
On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree traversal on detached nodes
On Thu, Jun 7, 2012 at 10:27 AM, Darin Adler da...@apple.com wrote: On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I’d love to see that proposal. Is it written up anywhere? Regarding efficiency: what are the constraints? -- Darin ___ 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] PSA: FAIL test expectation does not encompass MISSING, CRASH, or TIMEOUT
Hi, As much as it doesn't make any sense to me, FAIL test expectation doesn't cover MISSING, CRASH, and TIMEOUT test expectations as it is currently interpreted by new-run-webkit-tests. Meaning that BUGRNIWA : some-pixel-test-i-am-adding.html = FAIL is logically equivalent to BUGRNIWA : some-pixel-test-i-am-adding.html = IMAGE TEXT IMAGE+TEXT Thus, if you're adding a pixel test and only adding the corresponding expected result to, say, Mac, then you need to add MISSING results to some platforms (e.g. Qt, GTK+, etc...) that cannot find this expected result as in: BUGRNIWA : some-pixel-test-i-am-adding.html = MISSING If you're expecting the test to fail with image, text, or image and text failures, or pass, then do: BUGRNIWA : some-pixel-test-i-am-adding.html = FAIL PASS If you're expecting the test to timeout, crash, or, fail (image, text, or image and text), or pass, then do: BUGRNIWA : some-pixel-test-i-am-adding.html = TIMEOUT CRASH FAIL PASS Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Rename FAIL to DIFF Was (Re: PSA: FAIL test expectation does not encompass MISSING, CRASH, or TIMEOUT)
Now that everyone knows the problem, I propose to rename FAIL to DIFF. FAIL should mean that the test fails, not that it fails with image, text, or image and text failures. DIFF, on the other hand, has no ambiguity. It can't be interpreted as timeout, crash, or pass but can easily be associated with image and text differences. - Ryosuke On Wed, Jun 6, 2012 at 9:42 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, As much as it doesn't make any sense to me, FAIL test expectation doesn't cover MISSING, CRASH, and TIMEOUT test expectations as it is currently interpreted by new-run-webkit-tests. Meaning that BUGRNIWA : some-pixel-test-i-am-adding.html = FAIL is logically equivalent to BUGRNIWA : some-pixel-test-i-am-adding.html = IMAGE TEXT IMAGE+TEXT Thus, if you're adding a pixel test and only adding the corresponding expected result to, say, Mac, then you need to add MISSING results to some platforms (e.g. Qt, GTK+, etc...) that cannot find this expected result as in: BUGRNIWA : some-pixel-test-i-am-adding.html = MISSING If you're expecting the test to fail with image, text, or image and text failures, or pass, then do: BUGRNIWA : some-pixel-test-i-am-adding.html = FAIL PASS If you're expecting the test to timeout, crash, or, fail (image, text, or image and text), or pass, then do: BUGRNIWA : some-pixel-test-i-am-adding.html = TIMEOUT CRASH FAIL PASS Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename FAIL to DIFF Was (Re: PSA: FAIL test expectation does not encompass MISSING, CRASH, or TIMEOUT)
On Wed, Jun 6, 2012 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: Now that everyone knows the problem, I propose to rename FAIL to DIFF. FAIL should mean that the test fails, not that it fails with image, text, or image and text failures. DIFF, on the other hand, has no ambiguity. It can't be interpreted as timeout, crash, or pass but can easily be associated with image and text differences. I don't think DIFF is any better. It sounds like it means the output is different than what we wanted, thus it effectively means didn't pass, and one would expect it to match MISSING/CRASH/TIMEOUT as much as one would expect FAIL to. Personally I'd prefer to resolve this -- if we need to -- by removing FAIL entirely. Being explicit about your expectations isn't a bad thing. Plus, the number of cases that are truly TEXT IMAGE IMAGE+TEXT seems likely to be small. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
