[Webkit-unassigned] [Bug 116046] In Voice over, activating a fragment URL should transfer focus and caret to the destination
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Apr 8 21:45:59 PDT 2016
https://bugs.webkit.org/show_bug.cgi?id=116046
Ryosuke Niwa <rniwa at webkit.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #275781|review? |review-
Flags| |
--- Comment #17 from Ryosuke Niwa <rniwa at webkit.org> ---
Comment on attachment 275781
--> https://bugs.webkit.org/attachment.cgi?id=275781
patch
View in context: https://bugs.webkit.org/attachment.cgi?id=275781&action=review
> Source/WebCore/ChangeLog:3
> + FKA: activating a fragment ID URL (in-page link or external link with hash) should transfer focus and caret to the fragment target element with ID or name matching the fragment identifier
I've shorted the bug title. Please update this line accordingly.
> Source/WebCore/ChangeLog:8
> + Used a Range object to represent the sequential focus navigation starting point. When
I don't think we should be using Range for this.
> Source/WebCore/dom/Document.cpp:693
> + m_focusNavigationStartingPoint = nullptr;
I'd call this focusNavigationStartingNode instead since "point" usually refers to either a graphical coordinate
or a single point in DOM tree (e.g. Position / VisiblePosition).
> Source/WebCore/dom/Document.cpp:3754
> + // Set the focus starting point to the previous focused element.
This comment repeats the code beneath it. Please remove it.
> Source/WebCore/dom/Document.cpp:3952
> + if (!m_focusNavigationStartingPoint)
> + m_focusNavigationStartingPoint = Range::create(*this);
> +
> + ExceptionCode ec = 0;
> + m_focusNavigationStartingPoint->selectNodeContents(node, ec);
> + if (ec)
> + m_focusNavigationStartingPoint = nullptr;
We should just store node instead.
r- because these function calls are expensive and setFocusedElement is a hot function in Speedometer benchmark.
> Source/WebCore/dom/Document.h:1479
> + RefPtr<Range> m_focusNavigationStartingPoint;
Why are we using Range for this?
> LayoutTests/ChangeLog:3
> + FKA: activating a fragment ID URL (in-page link or external link with hash) should transfer focus and caret to the fragment target element with ID or name matching the fragment identifier
Ditto about updating the title.
> LayoutTests/fast/dom/fragment-activation-focuses-target.html:51
> -shouldBe("document.activeElement", "link2");
> +shouldBe("document.activeElement", "document.body");
You should justify this change in the change log.
> LayoutTests/fast/events/sequential-focus-navigation-starting-point.html:5
> +<script src="../../resources/testharness.js"></script>
> +<script src="../../resources/testharnessreport.js"></script>
> +<script src="../forms/resources/common.js"></script>
For these WebKit specific tests, we'd prefer using js-test-pre.js instead of testharness.js since testharness.js is only useful for tests to be exported to W3C.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160409/5ebd13ab/attachment-0001.html>
More information about the webkit-unassigned
mailing list