Find in page closes prematurely |
||||||||
Issue descriptionChrome Version: 57.0.2987.98 (Official Build) (64-bit) OS: 10.12.3 (16D32) Reproducibility with these steps for me is around 50%. What steps will reproduce the problem? (1) Travel to https://skia-review.googlesource.com/c/7033/?polygerrit=1 (2) Use ctrl+f find-in-page to search for "irgen" (3) Dismiss find-in-page (in this way the phrase "irgen" is still loaded in the search textbox). (4) Tap the [Show Diffs] button at the top of the file list to start expanding the diffs. (5) While the UI is still progressively rendering the diffs, quickly use ctrl+f to search several times using the [enter] key. (6) Observe that (sometimes) the find-in-page searchbox dismisses itself, returning focus to the page, which has its own handler for the [enter] key. What is the expected result? Focus should not be taken away from the find-in-page box. What happens instead? Focus is taken away from the find-in-page box and the enter key event that was intended for find-in-page is handled by the page. The result of this bug is that native find-in-page can't be confidently used to search diff content because it might suddenly dismiss. Alternative reproduction steps at the following Gerrit bug, (and bugs merged into it): https://bugs.chromium.org/p/gerrit/issues/detail?id=5297 https://bugs.chromium.org/p/gerrit/issues/detail?id=5786 https://bugs.chromium.org/p/gerrit/issues/detail?id=5754 https://bugs.chromium.org/p/gerrit/issues/detail?id=5571 Possible clues: * While the diffs are being rendered, much text content is being added to the page. However, it sometimes happens after rendering has finished. * The PolyGerrit UI uses Polymer and this bug is observed in "shady DOM" mode. Please feel free to reach out if I can clarify anything.
,
Apr 5 2017
Verified on Windows and Linux too. Easiest repro seems to be: (1) Load <https://skia-review.googlesource.com/c/7033/?polygerrit=1>. (2) Use ctrl+f to search for "irgen". (3) Reload. (4) Type ctrl+f, then start typing "irgen" again.
,
May 4 2017
Paul, can you take a look at this bug? This is a high-priority issue which is making the Gerrit user experience worse for chromium devs.
,
May 4 2017
Wow... just tried the repro steps, and that's really annoying! I'm not sure what is causing this, but I would guess that the find bar believes that navigations are finishing and that is why the find bar closes. I'll look into this.
,
May 4 2017
,
May 5 2017
Okay, so after a bit of debugging, I can see that the reason the find bar is closing is because the FindController thinks that the page is reloading (when it really isn't).
,
May 8 2017
,
May 8 2017
Okay, I'm starting to unravel this. It looks like when first loading the repro page from C#1, this does not happen. Only after reloading the page and then trying to find, the issue presents itself. Can anyone else confirm this?
,
May 8 2017
I can see that pattern also. It's far easier to repro after the first reload.
,
May 10 2017
I'm finding more details about this. It turns out that the page is calling history.replaceState(), which is internally treated as a navigation. It is calling this every time the page is scrolled. Because the latest navigation entry is reused rather than replaced, if the last entry was a main frame reload (which it will be if the page was just reloaded), then essentially every scroll will be treated like a page reload. Since using find-in-page results in the page scrolling, this is what is causing the find bar to close. What's unclear here is whether this is actually a bug in Chrome, or just a bug in how this particular website is using history.replaceState().
,
May 30 2017
Reassigning to japhet@ for potentially further investigation or retriage. I'm still not sure if this is really a bug and where exactly it might be, but it looks like it doesn't actually have anything to do with find-in-page.
,
Jul 21 2017
,
Sep 19
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by meh...@chromium.org
, Mar 23 2017