Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 17895dbfb088246548c5753ecddda506317e5d8d
      
https://github.com/WebKit/WebKit/commit/17895dbfb088246548c5753ecddda506317e5d8d
  Author: Tim Horton <[email protected]>
  Date:   2024-09-08 (Sun, 08 Sep 2024)

  Changed paths:
    M 
LayoutTests/http/tests/scroll-to-text-fragment/generation-can-pass-inline-boundaries.html
    A 
LayoutTests/http/tests/scroll-to-text-fragment/generation-does-not-pass-block-boundaries-expected.txt
    A 
LayoutTests/http/tests/scroll-to-text-fragment/generation-does-not-pass-block-boundaries.html
    A 
LayoutTests/http/tests/scroll-to-text-fragment/generation-expands-context-for-ambiguous-matches-expected.txt
    A 
LayoutTests/http/tests/scroll-to-text-fragment/generation-expands-context-for-ambiguous-matches.html
    M Source/WebCore/Headers.cmake
    M Source/WebCore/WebCore.xcodeproj/project.pbxproj
    M Source/WebCore/dom/FragmentDirectiveGenerator.cpp
    M Source/WebCore/dom/FragmentDirectiveParser.cpp
    M Source/WebCore/dom/FragmentDirectiveParser.h
    M Source/WebCore/dom/FragmentDirectiveRangeFinder.cpp
    M Source/WebCore/dom/FragmentDirectiveUtilities.h
    M Source/WebCore/page/LocalFrameView.cpp
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp

  Log Message:
  -----------
  Selecting large text that ends with a common phrase results in text 
highlighting incorrectly
https://bugs.webkit.org/show_bug.cgi?id=279330
rdar://133786985

Reviewed by Wenson Hsieh.

First, to fix the issue in the title (where a suffix might match multiple 
possible ranges),
we extend the fragment directive generator to be able to test directives that 
it generates,
and increase the amount of context that we vend if it doesn't match the correct 
range.

In order to keep links small, we add one word at a time, and give up if we add 
more than 4 words.
Add a test for this.

Secondly, fix an issue from 283294@main, where we now would allow context 
generation
to walk across block boundaries, caused by a spurious incorrect operator== for 
Node&
(coming from CanMakeCheckedPtrBase). Work around this by comparing Node 
addresses instead.
Add a test for this too.

* 
LayoutTests/http/tests/scroll-to-text-fragment/generation-can-pass-inline-boundaries.html:
* 
LayoutTests/http/tests/scroll-to-text-fragment/generation-does-not-pass-block-boundaries-expected.txt:
 Added.
* 
LayoutTests/http/tests/scroll-to-text-fragment/generation-does-not-pass-block-boundaries.html:
 Added.
Test for the operator== bug.

* 
LayoutTests/http/tests/scroll-to-text-fragment/generation-expands-context-for-ambiguous-matches-expected.txt:
 Added.
* 
LayoutTests/http/tests/scroll-to-text-fragment/generation-expands-context-for-ambiguous-matches.html:
 Added.
Test for the main bug.

* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/dom/FragmentDirectiveGenerator.cpp:
(WebCore::positionsHaveSameBlockAncestor):
Fix for the operator== bug mentioned above.

(WebCore::FragmentDirectiveGenerator::generateFragmentDirective):
Test the generated directive and increase context (up to a limit) if necessary 
to disambiguate matches.

* Source/WebCore/dom/FragmentDirectiveParser.cpp:
(WebCore::FragmentDirectiveParser::parseFragmentDirective):
* Source/WebCore/dom/FragmentDirectiveParser.h:
* Source/WebCore/dom/FragmentDirectiveRangeFinder.cpp:
(WebCore::FragmentDirectiveRangeFinder::findRangeFromTextDirective):
Make the fragment search code treat null and empty strings equally; neither is
acceptable to pass into string search code (and results in assertion failures).

* Source/WebCore/dom/FragmentDirectiveUtilities.h:
Move ParsedTextDirective here, so we can re-use it. Also make the order and
spelling of the struct members consistent with other code.

* Source/WebCore/page/LocalFrameView.cpp:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
Build fixes.

Canonical link: https://commits.webkit.org/283323@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to