Bug 174393 – AX: [iOS] Implement a way to retrieve a text marker range with desired text that is closest to a position

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Nan Wang]

On iOS, we should have a way to retrieve a text marker range with desired text that is closest to a certain position. So that clients that only know NSRange can get more accurate text range from the webcore.

[Radar WebKit Bug Importer]

<rdar://problem/33248006>

[Nan Wang]

Created attachment 315175 [details]
Patch

[Build Bot]

Comment on attachment 315175 [details]
Patch

Attachment 315175 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/4103555

New failing tests:
storage/indexeddb/modern/new-database-after-user-delete.html

[Build Bot]

Created attachment 315192 [details]
Archive of layout-test-results from ews100 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-elcapitan  Platform: Mac OS X 10.11.6

[chris fleizach]

Comment on attachment 315175 [details]
Patch

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

> Source/WebCore/accessibility/AXObjectCache.cpp:1756
> +    auto range = Range::create(m_document, startPosition, originalRange->startPosition());

does auto handle the RefPtr<Range> creation so that this gets released?

> Tools/DumpRenderTree/AccessibilityUIElement.cpp:1488
> +    JSStringRef searchText = 0;

nullptr

> Tools/DumpRenderTree/ios/AccessibilityUIElementIOS.mm:626
> +    NSArray *textMarkers = [NSArray arrayWithObjects:(id)startMarker->platformTextMarker(), (id)endMarker->platformTextMarker(), nil];

do we need to worry that startMarker->platformTextMarker() might be null?

[Nan Wang]

Comment on attachment 315175 [details]
Patch

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

>> Source/WebCore/accessibility/AXObjectCache.cpp:1756
>> +    auto range = Range::create(m_document, startPosition, originalRange->startPosition());
> 
> does auto handle the RefPtr<Range> creation so that this gets released?

Range::create will generate a reference, Range&

>> Tools/DumpRenderTree/ios/AccessibilityUIElementIOS.mm:626
>> +    NSArray *textMarkers = [NSArray arrayWithObjects:(id)startMarker->platformTextMarker(), (id)endMarker->platformTextMarker(), nil];
> 
> do we need to worry that startMarker->platformTextMarker() might be null?

Ok

[Nan Wang]

Comment on attachment 315175 [details]
Patch

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

>>> Source/WebCore/accessibility/AXObjectCache.cpp:1756
>>> +    auto range = Range::create(m_document, startPosition, originalRange->startPosition());
>> 
>> does auto handle the RefPtr<Range> creation so that this gets released?
> 
> Range::create will generate a reference, Range&

nevermind, will double check

[Nan Wang]

Created attachment 315196 [details]
patch

updated from review

[chris fleizach]

Comment on attachment 315196 [details]
patch

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

> Source/WebCore/accessibility/AXObjectCache.cpp:1752
> +    auto searchRange = Range::create(m_document, startPosition, endPosition);

another Range::Create here

> Source/WebCore/accessibility/AXObjectCache.h:336
> +    RefPtr<Range> rangeMatchesTextNearRange(RefPtr<Range> originalRange, const String& matchText);

probably don't need to put argument names here

> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:64
> +#import <UIKit/UIGeometry.h>

what is this one used for?

> Tools/DumpRenderTree/AccessibilityUIElement.cpp:1489
> +    AccessibilityTextMarker* startMarker = 0;

nullptr

> Tools/DumpRenderTree/AccessibilityUIElement.cpp:1490
> +    AccessibilityTextMarker* endMarker = 0;

nullptr

> Tools/WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm:1207
> +    

extra line

[Nan Wang]

Comment on attachment 315196 [details]
patch

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

>> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:64
>> +#import <UIKit/UIGeometry.h>
> 
> what is this one used for?

For [NSValue valueWithCGRect:rect]

[Nan Wang]

Created attachment 315210 [details]
patch

More review comments

[chris fleizach]

Comment on attachment 315210 [details]
patch

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

> Source/WebCore/accessibility/AXObjectCache.cpp:1732
> +    RefPtr<ContainerNode> root;

does this need to be initialized to nullptr?

> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:64
> +#import <UIKit/UIGeometry.h>

I think you can use valueWithRect which is in foundation/nsgeometry.h

I think that will just work. not sure if you even need an import for that

[Nan Wang]

Comment on attachment 315210 [details]
patch

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

>> Source/WebCore/accessibility/AXObjectCache.cpp:1732
>> +    RefPtr<ContainerNode> root;
> 
> does this need to be initialized to nullptr?

root will be set in indexForVisiblePosition(position, root), but yes I can initialize that.

[Nan Wang]

(In reply to Nan Wang from comment #13)
> Comment on attachment 315210 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=315210&action=review
> 
> >> Source/WebCore/accessibility/AXObjectCache.cpp:1732
> >> +    RefPtr<ContainerNode> root;
> > 
> > does this need to be initialized to nullptr?
> 
> root will be set in indexForVisiblePosition(position, root), but yes I can
> initialize that.

I've checked most use cases of indexForVisiblePosition(position, root) in the project, and they didn't initialize the ContainerNode scope. So I will keep the consistency.

[Nan Wang]

Created attachment 315214 [details]
patch

more updates

[Build Bot]

Comment on attachment 315214 [details]
patch

Attachment 315214 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/4106126

New failing tests:
imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/invalid-src.html

[Build Bot]

Created attachment 315226 [details]
Archive of layout-test-results from ews125 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews125  Port: ios-simulator-wk2  Platform: Mac OS X 10.12.5

[Nan Wang]

test failure shouldn't be related

[Nan Wang]

Committed r219409: <http://trac.webkit.org/changeset/219409>

[Matt Lewis]

The revision r21940 has broken the windows builds.

https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/2973/steps/compile-webkit/logs/stdio
https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/2974

[chris fleizach]

(In reply to Matt Lewis from comment #20)
> The revision r21940 has broken the windows builds.
> 
> https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> 2973/steps/compile-webkit/logs/stdio
> https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> 2974

Are we sure that's related. The error seems to be

===== BUILD FAILED ======

Please ensure you have run Tools/Scripts/update-webkit to install dependencies.

[chris fleizach]

(In reply to chris fleizach from comment #21)
> (In reply to Matt Lewis from comment #20)
> > The revision r21940 has broken the windows builds.
> > 
> > https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> > 2973/steps/compile-webkit/logs/stdio
> > https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> > 2974
> 
> Are we sure that's related. The error seems to be
> 
> ===== BUILD FAILED ======
> 
> Please ensure you have run Tools/Scripts/update-webkit to install
> dependencies.

Nevermind
here's the error

C:\cygwin\home\buildbot\slave\win-release\build\Tools\DumpRenderTree\AccessibilityUIElement.cpp(1724): error C2039: 'textMarkerRangeMatchesTextNearMarkers': is not a member of 'AccessibilityUIElement' [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\DumpRenderTree\DumpRenderTreeLib.vcxproj]

[Matt Lewis]

(In reply to chris fleizach from comment #22)
> (In reply to chris fleizach from comment #21)
> > (In reply to Matt Lewis from comment #20)
> > > The revision r21940 has broken the windows builds.
> > > 
> > > https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> > > 2973/steps/compile-webkit/logs/stdio
> > > https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> > > 2974
> > 
> > Are we sure that's related. The error seems to be
> > 
> > ===== BUILD FAILED ======
> > 
> > Please ensure you have run Tools/Scripts/update-webkit to install
> > dependencies.
> 
> Nevermind
> here's the error
> 
> C:\cygwin\home\buildbot\slave\win-
> release\build\Tools\DumpRenderTree\AccessibilityUIElement.cpp(1724): error
> C2039: 'textMarkerRangeMatchesTextNearMarkers': is not a member of
> 'AccessibilityUIElement'
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\DumpRenderTree\DumpRenderTreeLib.
> vcxproj]

Was about to respond with that! Thanks!

[Matt Lewis]

Reverted r219409 for reason:

The revision caused the Windows builds to fail.

Committed r219424: <http://trac.webkit.org/changeset/219424>

[Nan Wang]

Created attachment 315281 [details]
Patch

Fix windows build

[WebKit Commit Bot]

Comment on attachment 315281 [details]
Patch

Clearing flags on attachment: 315281

Committed r219426: <http://trac.webkit.org/changeset/219426>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.