LayoutTests/fast/events/elementsFromPoint.html - Issue 869813003: Implement elementsFromPoint

Side by Side Diff: LayoutTests/fast/events/elementsFromPoint.html

Issue 869813003: Implement elementsFromPoint (Closed) Base URL: https://chromium.googlesource.com/chromium/blink.git@master

Patch Set: Fix typeo Created 5 years, 11 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 <!DOCTYPE HTML>

	2 <style>

	3 html, body {

	4 margin: 0;

	5 padding: 0;

	6 }

	7 body {

	8 height: 500px;

	9 }

	10 #one {

	11 width: 200px;

	12 height: 200px;

	13 background-color: rgba(0,0,255,0.5);

	14 }

	15 #two {

	16 position: absolute;

	17 left: 50px;

	18 top: 50px;

	19 width: 100px;

	20 height: 100px;

	21 background-color: rgba(255,0,0,0.5);

	22 }

	23 #two::before {

	24 position: absolute;

	25 left: 20px;

	26 top: 20px;

	27 width: 100px;

	28 height: 100px;

	29 content: "::before";

	30 background-color: rgba(255,0,0,0.5);

	31 z-index: 9999;

	32 }

	33 #three {

	34 position: absolute;

	35 left: 100px;

	36 top: 100px;

	37 width: 100px;

	38 height: 100px;

	39 background-color: rgba(0,255,0,0.5);

	40 }

	41 #four {

	42 margin-top: -15px;

	43 width: 200px;

	44 height: 200px;

	45 background-color: rgba(0,0,0,0.5);

	46 }

	47 #five {

	48 float: right;

	49 background-color: yellow;

	50 width: 100px;

	51 height: 1em;

	52 }

	53 #six {

	54 position: absolute;

	55 left: 50px;

	56 top: 50px;

	57 width: 100px;

	58 height: 300px;

	59 background-color: rgba(0,0,0,0.1);

	60 pointer-events: none;

	61 }

	62 #results {

	63 position: absolute;

	64 top: 0px;

	65 left: 250px;

	66 background-color: #eee;

	67 border: 1px solid black;

	68 }

	69 </style>

	70 <div id="one"></div>

	71 <div id="two"></div>

	72 <div id="three"></div>

	73 <div id="four"><div id="five"></div></div>

	74 <div id="six"></div>

	75 <div id="results"></div>

	76

	77 <script>

	78 if (window.testRunner)

	79 testRunner.dumpAsText();

	80

	81 function elementTestFromPoint(x, y) {

	82 var elements = document.elementsFromPoint(x, y);

	83 var resultText = "elementsFromPoint(" + x + "," + y + "): ";

	84 if (elements) {

	85 for (var elementIndex = 0; elementIndex < elements.length; elementIndex++) {

	86 var element = elements[elementIndex];

	87 if (elementIndex > 0)

	88 resultText += ", ";

	89 resultText += element.tagName;

	90 if (element.id)

	91 resultText += '#' + element.id;
	Rick Byers 2015/02/04 10:34:03 I find it hard to tell at a glance whether the tes I find it hard to tell at a glance whether the test output is correct. Perhaps you could also add shouldBe/assert calls that verify that each element is in the list if and only if the supplied co-ordinates are inside one of the rects returned by getClientRects and pointer-events is not none? I'm guessing there might be a bit of a tail of edge cases here, so it would be nice if the tests had a system for cross-checking results. If you wanted to, you could also cross-check the order of the returned values by doing repeated elementFromPoint calls, temporarily setting each return value to pointer-events: none. I guess that's a good cross-check in itself - the list created via that hack should be identical to the elementsFromPoint list, right? pdr. 2015/02/17 04:10:13 Done. Show quoted text On 2015/02/04 at 10:34:03, Rick Byers wrote: > I find it hard to tell at a glance whether the test output is correct. Perhaps you could also add shouldBe/assert calls that verify that each element is in the list if and only if the supplied co-ordinates are inside one of the rects returned by getClientRects and pointer-events is not none? Done. Show quoted text > > I'm guessing there might be a bit of a tail of edge cases here, so it would be nice if the tests had a system for cross-checking results. > > If you wanted to, you could also cross-check the order of the returned values by doing repeated elementFromPoint calls, temporarily setting each return value to pointer-events: none. I guess that's a good cross-check in itself - the list created via that hack should be identical to the elementsFromPoint list, right? I ran all of our layouttests with elementFromPoint(x, y) stubbed out to return elementsFromPoint(x, y)[0] and did find one bug: http://crbug.com/459070. Because this affects all rect-based hit testing, I'd like to fix it in a followup. Rick Byers 2015/02/20 20:02:23 Looks like you now verify that you get the expecte Show quoted text On 2015/02/17 04:10:13, pdr wrote: > On 2015/02/04 at 10:34:03, Rick Byers wrote: > > I find it hard to tell at a glance whether the test output is correct. > Perhaps you could also add shouldBe/assert calls that verify that each element > is in the list if and only if the supplied co-ordinates are inside one of the > rects returned by getClientRects and pointer-events is not none? > > Done. Looks like you now verify that you get the expected element, but not what other elements you're getting or that you aren't getting any incorrect elements returned. In addition to checking for the presence of the expected element in the returned list, I was thinking you could look at each element in the returned list and verify that it has a client rect surrounding the point you hit. That would be a much more rigorous test of the API's behavior. It's your call though, it's OK with me as-is if you prefer, but I wasn't trying to suggest you should weaken your tests expectations... Show quoted text > I ran all of our layouttests with elementFromPoint(x, y) stubbed out to return > elementsFromPoint(x, y)[0] and did find one bug: http://crbug.com/459070. > Because this affects all rect-based hit testing, I'd like to fix it in a > followup. Nice. Sounds good.
	92 }

	93 }

	94 var result = document.createElement('div');

	95 result.innerText = resultText;

	96 document.getElementById('results').appendChild(result);

	97 }

	98

	99 elementTestFromPoint(-1, -1);

	100 elementTestFromPoint(10000, 1);

	101 elementTestFromPoint(25, 25);

	102 elementTestFromPoint(75, 75);

	103 elementTestFromPoint(125, 125);

	104 elementTestFromPoint(175, 175);

	105 elementTestFromPoint(175, 190);
	Rick Byers 2015/02/04 10:34:03 Can you add a case that hits on top of the documen Can you add a case that hits on top of the document scrollbar since that is called out explicitly in the spec? Iframes are a sufficiently special-case that I think you need at least some simple iframe tests. Have you compared behavior against IE for some other special cases? Eg. I'd be interested to see the results for tables, SVG, and inlines with multiple line boxes. pdr. 2015/02/17 04:10:13 Done in new elementsFromPoint-invalid-cases.html. Show quoted text On 2015/02/04 at 10:34:03, Rick Byers wrote: > Can you add a case that hits on top of the document scrollbar since that is called out explicitly in the spec? Done in new elementsFromPoint-invalid-cases.html. This also caught a bug where I failed to return the HTML element when the empty document was clicked. Show quoted text > > Iframes are a sufficiently special-case that I think you need at least some simple iframe tests. Done in new elementsFromPoint-iframes.html. Show quoted text > > Have you compared behavior against IE for some other special cases? Eg. I'd be interested to see the results for tables, SVG, and inlines with multiple line boxes. I'm not /too/ worried because this patch is largely built on the back of our stress-tested elementFromPoint (singular) and rect-based touch hit testing code. Rick Byers 2015/02/20 20:02:23 Heh heh, that's exactly why I AM worried :-). I k Show quoted text > > > > Have you compared behavior against IE for some other special cases? Eg. I'd > be interested to see the results for tables, SVG, and inlines with multiple line > boxes. > > I'm not /too/ worried because this patch is largely built on the back of our > stress-tested elementFromPoint (singular) and rect-based touch hit testing code. Heh heh, that's exactly why I AM worried :-). I know we paper over all sorts of issues with the rect-based touch hit testing code because we always use the resulting point in a new point-based hit-test. But regardless it's not like you're likely to break a bunch of existing websites with this new API, so I'm probably being overly paranoid.
	106 elementTestFromPoint(50, 390);

	107 </script>

OLD	NEW

« no previous file with comments | « no previous file | LayoutTests/fast/events/elementsFromPoint-expected.txt » ('j') | Source/core/dom/TreeScope.h » ('J')