Closed Bug 1403623 Opened 8 years ago Closed 8 years ago

ctrl-f sometimes does not open findbar in newly opened tab

Categories

(Firefox :: Keyboard Navigation, defect, P2)

All
Windows
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox57 + fix-optional
firefox58 --- affected

People

(Reporter: bkelly, Unassigned)

Details

(Keywords: qawanted, regression, regressionwindow-wanted)

On FF58 nightly I'm seeing some strange behavior. Rough STR: 1. Open https://twitter.com/Paul_Kinlan/status/913069132618321920 2. Click the link to https://paul.kinlan.me/the-web-is-my-api/ 3. Quickly hit ctrl-f after it loads. Maybe 40% of the time ctrl-f fails to open the findbar. Some times it recovers and the second or third hit of ctrl-f will work. Sometimes the findbar never opens until I switch tabs and then switch back to try again. I looked in browser console and don't see any errors. I also just reproduced this in FF57 beta. I can't reproduce in release FF55, but it is intermittent. I'm going to call this a 57 regression for right now.
I tried the STR, for me on win10 only 1 out of 10 times ctrl+F did not load the findbar. Tracked for 57 for now. If this isn't so widespread and perhaps not a new regression, we might defer to 58.
Component: Untriaged → Keyboard Navigation
FWIW on Google Docs I've been seeing Firefox's find bar open (if I press it at the right moment during page load?) instead of the in-content GDocs-provided find functionality. Not sure if it's related.
Stone, do you think this could be due to the prioritized input event queue (I'm probably reaching here ...)? I was told the STR from comment 0 can be done on Linux so maybe we can use rr to figure it out?
Flags: needinfo?(sshih)
(In reply to Andrew Overholt [:overholt] from comment #3) > Stone, do you think this could be due to the prioritized input event queue > (I'm probably reaching here ...)? I was told the STR from comment 0 can be > done on Linux so maybe we can use rr to figure it out? I found that the content's keypress handler return false to stop browser default action so that we didn't open the findbar. Although I have no idea why it doesn't happen on FF55.
Flags: needinfo?(sshih)
> Maybe 40% of the time ctrl-f fails to open the findbar. Some times it > recovers and the second or third hit of ctrl-f will work. I can reproduce this part. > Sometimes the > findbar never opens until I switch tabs and then switch back to try again. I cannot reproduce this part. Keep trying.
Dao, how would you categorize the priority here. It seems pretty bad but I don't want to mark it P1 since you're the triage owner :)
Flags: needinfo?(dao+bmo)
Priority: -- → P1
I seem to be having a hard time reproducing this on Ubuntu. Ben, could you please try to find a regression range using mozregression? This would be most useful in order to make this bug actionable.
Flags: needinfo?(dao+bmo) → needinfo?(bkelly)
It has a reproduction rate of like 10% on my machine. That is really low and would make bisection unreliable. I'm sorry, but I'm not sure I have time to do this myself. Can anyone else reproduce on windows machines?
Flags: needinfo?(bkelly)
(In reply to Ben Kelly [:bkelly] from comment #8) > Can anyone else reproduce on windows machines? I cannot, FWIW.
I can't reproduce any more actually. :-\
OS: Unspecified → Windows
Priority: P1 → P2
Hardware: Unspecified → All
(In reply to Andrew Overholt [:overholt] from comment #6) > Dao, how would you categorize the priority here. It seems pretty bad but I > don't want to mark it P1 since you're the triage owner :) Oh man, bkelly just pointed out that I did in fact set the priority to P1. Oops, sorry /o\.
Let's close this, since ppl can't repro.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.