зеркало из https://github.com/mozilla/gecko-dev.git
1e4e187165
Steps to reproduce: 1. Open https://bugzilla.mozilla.org/home (Note the cursor is already blinking in the <input> "Enter a bug number or some search terms") 2. Pinch-zoom in. 3. Tap on the <input> "Enter a bug number or some search terms." 4. Pan/scroll the page, and the scrolling is very laggy. Without this patch, AccessibleCaret disables APZ incorrectly via the above operations. Here's an analysis. In step 2, `OnScrollEnd()` called at the end of the pinch-zoom operation is supposed to reset `mIsScrollStarted` to `false`, but `GetCaretMode()` returns `CaretMode::Cursor` because the page already has a focus on <input>. We are early-returned from `OnScrollEnd()` because `mLastUpdateCaretMode` is still the default value `CaretMode::None`. In step 3, tapping the <input> will call `UpdateCaretsForCursorMode()`, setting `mIsCaretPositionChanged` to `true`. Then `UpdateShouldDisableApz()` incorrectly sets `mShouldDisableApz` to `true` because we still have `mIsScrollStarted=true`. In step 4, the operation is laggy because APZ is disabled. This patch fixed this bug by removing the guarding statement `mLastUpdateCaretMode != GetCaretMode()` from three callback methods. The statements were added in the very first patch introducing `AccessibleCaretManager`. I don't recall why we needed them. (Perhaps to avoid unnecessary updates notified from other PresShell?). Anyway, since then, these callbacks have evolved to update carets only if any caret is logically visible, so I don't see why we need these guards nowadays. By doing so, `mIsScrollStarted` can be reset to `false` in `OnScrollEnd()` in step 2. Differential Revision: https://phabricator.services.mozilla.com/D99284 |
||
|---|---|---|
| .. | ||
| TestAccessibleCaretEventHub.cpp | ||
| TestAccessibleCaretManager.cpp | ||
| moz.build | ||