Fix text fragment for user activation
For security reasons, text fragments must only be activated when navigated with a user gesture. However, browser initiated navigations (e.g. user typing in the omnibox, bookmarks) don't have the user gesture bit set despite being initiated by the user (see discussion in https://crrev.com/c/2132673 for details). Because of this limitation, text fragment code explicitly checked if the navigation was browser initiated, assuming that such navigations are always user activated. However, history navigations are a special case. They're intentionally considered to be browser initiated, even if they originate from renderer script (e.g. `history.back()`). This meant that our check above would allow script to use the history API to activate a text fragment without a user gesture. This CL explicitly forbids activating a text fragment if the navigation is of history type. This is a trivial change (in terms of UX) because a history navigation will restore the scroll position to where the user left off so the text fragment scroll is already clobbered. This change prevents a transient scroll that will be undone. Note: we had an explicit test for this case that failed to catch the failure. The reason was that the test was checking that the fragment wasn't activated by checking that the scroll offset after a navigation is 0. However, the text fragment's scroll would be clobbered (assuming by history scroll restoration) so this check would erroneously pass. We fix it in this CL by using a scroll listener so that we can tell a scroll occurred even if it is later restored. Bug: 1042986 Change-Id: Ia0ad9a8adcda2250603e6a7dd2b386193be2a6e6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2135407Reviewed-by:Charlie Reis <creis@chromium.org> Reviewed-by:
Daniel Cheng <dcheng@chromium.org> Reviewed-by:
Nick Burris <nburris@chromium.org> Commit-Queue: David Bokan <bokan@chromium.org> Cr-Commit-Position: refs/heads/master@{#758413}
Showing
Please register or sign in to comment