core(tap-targets): Helper functions for working with ClientRects #6703

mattzeunert · 2018-12-02T11:00:01Z

Summary

Splitting this out from the main tap targets PR.

The tap targets gatherer collects a list of tappable targets and their client rects. The audit then checks if these client rects overlap.

The gatherer often collects multiple client rects for each tap target, but the client rects may overlap each other or can be ignored for some other reason. So simplifyClientRects prepares them to be consumed in the audit.

There are also a few general helper functions related to working with client rects.

Related Issues/PRs

Tap targets ticket: #4358

patrickhulce

Code all LGTM! Just a request for some explanations so future peeps won't think they know better

Thanks again for splitting this up!! MUCH easier to see what's going on :D

patrickhulce · 2018-12-03T21:32:48Z

lighthouse-core/lib/client-rect-functions.js

+ * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
+ * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+ */
+'use strict';


maybe add a quick note to the functions that are executed in the browser too?

the instanbul ignore next is a good clue but explicitly linking is even better :D

patrickhulce · 2018-12-03T21:37:52Z

lighthouse-core/lib/client-rect-functions.js

+ * @returns {LH.Artifacts.ClientRect[]}
+ */
+function filterOutTinyClientRects(clientRects) {
+  // 1x1px rect shouldn't be reason to treat the rect as something the user should tap on.


A tad unfortunate that we're letting the tap targets bit leak out into here :/

maybe we can clarify a bit in simplifyClientRects that it's removing small ones?

A tad unfortunate that we're letting the tap targets bit leak out into here :/

True... some of the logic isn't really useful in a more general way though, especially the simplifyClientRects logic is very specific to this audit.

Maybe we can split it into two files, rectHelpers and tapTargetClientRectHelpers? And in the rectHelpers we can address @hoten's point about renaming to just rects then.

I've thought about this a bit more, and I'm actually somewhat convinced that this is something we'd probably want to do with anything that's looking at real objects on a page, so it's really just the "tap" language I think I'm pushing back a bit on.

I'm fine either way with A) just documenting in the jsdoc what exactly it does to the rects during simplification or B) splitting into two files as you suggested

patrickhulce · 2018-12-03T21:38:12Z

lighthouse-core/lib/client-rect-functions.js

+  const nonTinyClientRects = clientRects.filter(
+    rect => rect.width > 1 && rect.height > 1
+  );
+  if (nonTinyClientRects.length > 0) {


maybe add a note why we want to return the tiny ones anyway if it's empty?

patrickhulce · 2018-12-03T21:40:38Z

lighthouse-core/lib/client-rect-functions.js

+ */
+function filterOutClientRectsContainedByOthers(clientRects) {
+  const filteredOutRects = new Set();
+  return clientRects.filter(cr => {


nit: the filter but also keeping state with a bool return has me a bit confused, maybe just refactor this to a normal double for loop so we can just return the set at the end?

We could keep track of the rects we want to keep instead of the ones we want to filter out, but then we'd need to infer what we decided to filter out based on that. I played around with some options, but I'm not quite sure what you have in mind.

Agreed that the current code doesn't read well.

I was thinking the flip to rects to keep too

wouldn't the check just then be !rectsToKeep.has(possiblyContainingRect)? or did I miss a step?

is the below the same?

for (const cr of clientRects) { for (const possiblyContainingRect of clientRects) { if (possiblyContainingRect === cr) continue if (!rectsToKeep.has(possiblyContainingRect)) continue if (rectContains()) { rectsToKeep.delete(cr); break; } } }

Oh, in my mind I was adding to rectsToKeep instead of deleting from it. This is much more sensible 👍

patrickhulce · 2018-12-03T21:44:08Z

lighthouse-core/lib/client-rect-functions.js

+ * @param {LH.Artifacts.ClientRect} crB
+ * @returns {boolean}
+ */
+function clientRectsTouch(crA, crB) {


nit: this sounds a little more like clientRectsTouchOrOverlap

patrickhulce · 2018-12-03T21:46:59Z

lighthouse-core/lib/client-rect-functions.js

+      const crB = clientRects[j];
+
+      /**
+       * Examples of what we want to merge:


Maybe a brief comment on why we wouldn't merge them if they overlap but don't align? perhaps this belongs on what simplify actually does, but it's not clear from this alone why it shouldn't merge them

We want to merge two rects if the user would perceive them as a single tappable area to tap on. The user would intuitively tap on the center of the merged rect – we try to determine that rect and then place the simulated finger area in the middle.

Tried to make this a bit clearer in the code.

Ah gotcha, thanks!

patrickhulce · 2018-12-03T21:50:21Z

lighthouse-core/lib/client-rect-functions.js

+          continue;
+        }
+
+        clientRects = clientRects.filter(cr => cr !== crA && cr !== crB);


maybe just a quick comment that we're replacing the two client rects with the merged version? the recursive call is a bit unexpected too, I'm guessing it was messy to deal with concurrent modification but a bit of explanation of heads up in function description would help

the recursive call is a bit unexpected too

Yeah it felt simpler to just start over than modifying the indices and checking if the mutation introduces any edge cases. For client rects the arrays are also rarely more than 5 rects, so starting again doesn't cause perf issues.

For client rects the arrays are also rarely more than 5 rects, so starting again doesn't cause perf issues.

👍 throwing that in a comment would also be ace :)

patrickhulce · 2018-12-03T21:51:19Z

lighthouse-core/lib/client-rect-functions.js

+ * @param {LH.Artifacts.ClientRect} rect2
+ */
+function getRectXOverlap(rect1, rect2) {
+  // https:// stackoverflow.com/a/9325084/1290545


nit: remove the space so this one's clickable :)

patrickhulce · 2018-12-03T21:51:27Z

lighthouse-core/lib/client-rect-functions.js

+ * @param {LH.Artifacts.ClientRect} rect2
+ */
+function getRectYOverlap(rect1, rect2) {
+  // https:// stackoverflow.com/a/9325084/1290545


nit: remove the space so this one's clickable :)

patrickhulce · 2018-12-03T21:52:13Z

lighthouse-core/lib/client-rect-functions.js

+ * @param {LH.Artifacts.ClientRect} clientRect
+ * @param {number} fingerSize
+ */
+function getFingerAtCenter(clientRect, fingerSize) {


nit: maybe rename from finger? getRectAtCenter

connorjclark · 2018-12-03T23:01:21Z

lighthouse-core/test/lib/client-rect-functions-test.js

+        width: 100,
+        height: 10,
+      }),
+      makeClientRect({


would be really neat to replace all the x/y/w/h rect definitions with some sort of visual ascii

const input = makeRects(` +--+--+--+ |..|..|..| +--+--+--+ `); const simple = simplifyClientRects(input) assertEqual(simple, makeRect(` +--------+ |........| +--------+ `));

Obviously this is way more work. Maybe if we had dozens of these tests it'd be worth it :)

connorjclark · 2018-12-03T23:06:04Z

lighthouse-core/lib/client-rect-functions.js

+    x: cr2.left,
+    y: cr2.bottom,
+  };
+  const bottomRight = {


maybe inline all these? Seems like rectContains will be a hot function, and most calls would fail on the first part of the below condition. Could be worth it to minimize object allocations

connorjclark · 2018-12-03T23:09:24Z

lighthouse-core/lib/client-rect-functions.js

@@ -0,0 +1,311 @@
+/**


Can all instances of client be removed? seems this could be generalized to just fun with rectangles.

Good point, I've split it into rect helpers and tap target audit specific code now.

mattzeunert · 2018-12-05T20:01:32Z

lighthouse-core/lib/client-rect-functions.js

+        const right = Math.max(crA.right, crB.right);
+        const top = Math.min(crA.top, crB.top);
+        const bottom = Math.max(crA.bottom, crB.bottom);
+        const replacementClientRect = addRectWidthAndHeight({


Move this stuff to getBoundingRect function.

paulirish · 2018-12-07T19:14:17Z

@patrickhulce if you're happy then this can land.

patrickhulce

sorrrrrrrrrrrry 😞 last thing I promise than I am so 🏅 on merging!

patrickhulce · 2018-12-07T20:09:43Z

lighthouse-core/test/lib/tap-target-rect-helpers-test.js

@@ -0,0 +1,246 @@
+/**


can we get this filename aligned with the source one? no preference and not sure if you already had some refactoring done that makes one name easier than the other, so up to you!

Sure, changed it to tappable-rects-test.js.

patrickhulce

huzzah! awesome job @mattzeunert!! 🎉 thank you 🙏

…gleChrome#6703)

Client rect functions

8aa6457

mattzeunert requested review from brendankenny and paulirish as code owners December 2, 2018 11:00

patrickhulce approved these changes Dec 3, 2018

View reviewed changes

connorjclark reviewed Dec 3, 2018

View reviewed changes

Address review feedback

5ad1ab2

mattzeunert commented Dec 5, 2018

View reviewed changes

mattzeunert added 7 commits December 7, 2018 09:17

Clean up filterOutClientRectsContainedByOthers

c2221fe

Add comments

7c78888

Inline rects

c1a044b

Update client-rect-functions.js

95000ab

Add test

43c6259

Split rect helpers and tap targets specific code

3d1097a

Add comments

10c0e9f

mattzeunert force-pushed the client-rect-helpers branch from c930e79 to 10c0e9f Compare December 7, 2018 15:13

Reorder functions

184550b

patrickhulce suggested changes Dec 7, 2018

View reviewed changes

Change filename to tappable-rects-test

e0cb2dc

patrickhulce approved these changes Dec 7, 2018

View reviewed changes

patrickhulce merged commit eb4544a into GoogleChrome:master Dec 7, 2018

mattzeunert added a commit to kdzwinel/lighthouse that referenced this pull request Dec 8, 2018

core(tap-targets): helper functions for working with ClientRects (Goo…

a7e8ffb

…gleChrome#6703)

mattzeunert mentioned this pull request Jan 19, 2019

new_audit(tap-targets): check that tap targets are big enough and don't overlap #5846

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core(tap-targets): Helper functions for working with ClientRects #6703

core(tap-targets): Helper functions for working with ClientRects #6703

mattzeunert commented Dec 2, 2018

patrickhulce left a comment

patrickhulce Dec 3, 2018

patrickhulce Dec 3, 2018

mattzeunert Dec 5, 2018

patrickhulce Dec 5, 2018

patrickhulce Dec 3, 2018

patrickhulce Dec 3, 2018

mattzeunert Dec 5, 2018

patrickhulce Dec 5, 2018

mattzeunert Dec 7, 2018

patrickhulce Dec 3, 2018

patrickhulce Dec 3, 2018

mattzeunert Dec 7, 2018

patrickhulce Dec 7, 2018

patrickhulce Dec 3, 2018

mattzeunert Dec 5, 2018 •

edited

Loading

patrickhulce Dec 5, 2018

patrickhulce Dec 3, 2018

patrickhulce Dec 3, 2018

patrickhulce Dec 3, 2018

connorjclark Dec 3, 2018

connorjclark Dec 3, 2018

connorjclark Dec 3, 2018

mattzeunert Dec 7, 2018

mattzeunert Dec 5, 2018

paulirish commented Dec 7, 2018

patrickhulce left a comment

patrickhulce Dec 7, 2018

mattzeunert Dec 7, 2018

patrickhulce left a comment

core(tap-targets): Helper functions for working with ClientRects #6703

core(tap-targets): Helper functions for working with ClientRects #6703

Conversation

mattzeunert commented Dec 2, 2018

patrickhulce left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattzeunert Dec 5, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulirish commented Dec 7, 2018

patrickhulce left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

patrickhulce left a comment

Choose a reason for hiding this comment

mattzeunert Dec 5, 2018 •

edited

Loading