Bug 251688

Summary: AX: Avoid hitting the main thread on "AXTextMarkerIsValid" calls.
Product: WebKit Reporter: Andres Gonzalez <andresg_22>
Component: AccessibilityAssignee: Andres Gonzalez <andresg_22>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, andresg_22, apinheiro, cfleizach, dmazzoni, ews-watchlist, jcraig, jdiggs, samuel_white, tyler_w, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch none

Description Andres Gonzalez 2023-02-03 07:23:07 PST
This call is hitting the main thread. Avoid using the new AXTextMarker class.
Comment 1 Radar WebKit Bug Importer 2023-02-03 07:23:21 PST
<rdar://problem/105005458>
Comment 2 Andres Gonzalez 2023-02-03 07:59:39 PST
Created attachment 464824 [details]
Patch
Comment 3 Tyler Wilcock 2023-02-03 11:47:35 PST
Comment on attachment 464824 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=464824&action=review

> Source/WebCore/accessibility/AXTextMarker.cpp:28
> +#include "AXLogger.h"

What requires the addition of this include?

> Source/WebCore/accessibility/AXTextMarker.cpp:112
> +    auto cache = AXTreeStore<AXObjectCache>::axObjectCacheForID(treeID());

Thoughts on using WeakPtr rather than auto here in terms of style? I like specifying WeakPtr, RefPtr, CheckedPtr, etc. over auto since these smart pointers have important semantics that are good to see at a glance. A lot of WebCore follows this pattern, too.

> LayoutTests/accessibility/mac/textmarker-for-index-out-of-bounds-crash.html:14
> +    output += expect("text.isTextMarkerNull(text.textMarkerForIndex(99999999999))", "false");

Can you help me understand why we need to add a new AccessibilityUIElement::isTextMarkerNull() method instead of using the existing AccessibilityUIElement::isTextMarkerValid()? Given these implementations:

AXTextMarker.h

bool isNull() const { return !treeID().isValid() || !objectID().isValid(); }
bool isValid() const { return object(); }

Isn't AcessibilityUIElement::isTextMarkerValid() + AXTextMarker::isValid() all that is necessary? Since we wouldn't be able to get a non-null object() if:

  1. The tree ID is invalid
  2. The object ID is invalid
  3. Both are valid, but the underlying object was deleted and removed from the cache / isolated tree.
Comment 4 Andres Gonzalez 2023-02-03 13:56:04 PST
Created attachment 464828 [details]
Patch
Comment 5 Andres Gonzalez 2023-02-03 14:15:08 PST
(In reply to Tyler Wilcock from comment #3)
> Comment on attachment 464824 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=464824&action=review
> 
> > Source/WebCore/accessibility/AXTextMarker.cpp:28
> > +#include "AXLogger.h"
> 
> What requires the addition of this include?

Every time you want to log something you have to add it again. I could leave some AXLOG to justify it but thought you would be a bit indulgent to me and let me keep it there. :-)
> 
> > Source/WebCore/accessibility/AXTextMarker.cpp:112
> > +    auto cache = AXTreeStore<AXObjectCache>::axObjectCacheForID(treeID());
> 
> Thoughts on using WeakPtr rather than auto here in terms of style? I like
> specifying WeakPtr, RefPtr, CheckedPtr, etc. over auto since these smart
> pointers have important semantics that are good to see at a glance. A lot of
> WebCore follows this pattern, too.


Agree, changed it, I've felt many times we abuse auto.
> 
> > LayoutTests/accessibility/mac/textmarker-for-index-out-of-bounds-crash.html:14
> > +    output += expect("text.isTextMarkerNull(text.textMarkerForIndex(99999999999))", "false");
> 
> Can you help me understand why we need to add a new
> AccessibilityUIElement::isTextMarkerNull() method instead of using the
> existing AccessibilityUIElement::isTextMarkerValid()? Given these
> implementations:
> 
> AXTextMarker.h
> 
> bool isNull() const { return !treeID().isValid() || !objectID().isValid(); }
> bool isValid() const { return object(); }
> 
> Isn't AcessibilityUIElement::isTextMarkerValid() + AXTextMarker::isValid()
> all that is necessary? Since we wouldn't be able to get a non-null object()
> if:
> 
>   1. The tree ID is invalid
>   2. The object ID is invalid
>   3. Both are valid, but the underlying object was deleted and removed from
> the cache / isolated tree.

!isNull is a weaker condition than isValid. The previous isValid was actually equivalent to !isNull. This test passes with !isNull but don't pass with the new isValid. I had to make the distinction in order to get this test passing.
Comment 6 Tyler Wilcock 2023-02-04 10:33:30 PST
> Agree, changed it, I've felt many times we abuse auto.
I think there are some other places where this patch uses auto instead of WeakPtr / RefPtr (e.g. all the calls to AXIsolatedTree::objectForID).
Comment 7 Andres Gonzalez 2023-02-06 05:23:09 PST
Created attachment 464863 [details]
Patch
Comment 8 Andres Gonzalez 2023-02-06 05:25:09 PST
(In reply to Tyler Wilcock from comment #6)
> > Agree, changed it, I've felt many times we abuse auto.
> I think there are some other places where this patch uses auto instead of
> WeakPtr / RefPtr (e.g. all the calls to AXIsolatedTree::objectForID).

I think I got all those now.
Comment 9 Andres Gonzalez 2023-02-06 09:15:13 PST
Created attachment 464865 [details]
Patch
Comment 10 Andres Gonzalez 2023-02-07 11:34:28 PST
Created attachment 464890 [details]
Patch
Comment 11 EWS 2023-02-08 08:21:36 PST
Commit message contains (OOPS!) and no reviewer found, blocking PR #None
Comment 12 Andres Gonzalez 2023-02-09 07:13:32 PST
Created attachment 464922 [details]
Patch
Comment 13 EWS 2023-02-09 09:58:31 PST
Committed 260069@main (caa465314d87): <https://commits.webkit.org/260069@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 464922 [details].