1439007 - AwesomeBar completion can cause Shift to be ignored when typing in the address bar

Status: RESOLVED INCOMPLETE

(Firefox :: Address Bar, defect, P3)

Description

[Stephan Sokolow]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180209162511

Steps to reproduce:

0a. Verify that your Shift key is working consistently at the pressure you typically apply to it (Check, and I have a buckling-spring keyboard to boot)
0b. Verify that, under normal circumstances, typing all-caps strings functions as expected in the Firefox address bar.

1. Visit http://nsis.sourceforge.net/ to prime the completion store
1. Hit Ctrl+L
2. Type "NSIS" as quickly as you possibly can

(I can provide more details on my Firefox setup and the environment I'm running it in, if they're needed to reproduce.)


Actual results:

Depending on how quickly you type and how busy the browser is, one or more of the characters may be entered in lowercase.

(I saw "Nsis", "NsiS", "NsIS", and "NSiS" in my testing.)

Given how the characters appear as lowercase and then almost instantly snap to uppercase when I type "BUGZILLA" with the completion primed, I assume this is some kind of race condition where typing too quickly causes the "then snap to uppercase" part to be overlooked for some characters.

(Does the algorithm possibly rely on a simple "processed the most recent character" boolean rather than a "last processed character" offset?)


Expected results:

All characters should have been uppercase.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180217100053

I can't seem to reproduce this. Can you reproduce it in a brand new profile in the latest Nightly?

https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles
https://nightly.mozilla.org

Comment 2

[Stephan Sokolow]

Yep. Just downloaded Nightly now, created a profile named "nightly", and, with only one about:blank tab open, followed the reproduction instructions I gave. I got "NSiS" on the first try.

(Don't mind the User-Agent on this post. Thunderbird still opens clicked links in Firefox 52 ESR while I evaluate my options for replacing the copy of DownThemAll I use with my RSS feeds.)

The following details which I didn't mention before might be relevant somehow:

1. I'm running Kubuntu Linux 14.04 LTS (I notice that you're on Windows 10. Perhaps the X11 vs. Windows distinction is significant?)

2. I have an AMD Athlon II X2 270 (a dual-core CPU) and the total utilization is around 70% before Firefox is added on (Perhaps you're not bogging your CPU down enough?)

3. I'm running purely rotating-platter hard drives and my ext4-based /home partition is down around 6GiB free out of ~350GiB (you're advised to keep ~20% free so the fragmentation avoidance algorithms have room to work) and it's been a LONG time since I created it (there is no defragmentation tool for ext4). (Perhaps the disk your Firefox profile is on responds too quickly for the bug to appear.

4. I've got three monitors hanging off an nVidia GeForce GTX750 in a 1280x1024, 1920x1080, 1280x1024 configuration, desktop compositing is enabled, and, both times, I had a paused copy of Stardew Valley fullscreened to the center monitor and showing through the translucent taskbar but otherwise covered up by Firefox. (Perhaps it's somehow significant that the KWin compositor has been forced to temporarily suspend its "unredirect fullscreen OpenGL applications" performance optimization on a large desktop driven by a low-end card, despite my not noticing any graphics latency. In case it is, I'm using the nVidia binary drivers, version 384.111)

Comment 3

[Drew Willcoxon :adw]

Please go to about:config and search for "browser.urlbar.autoFill".  Is the value in the Value column true?  I'm guessing so.  If you double-click it to set it to false, can you still reproduce the problem?

Comment 4

[Stephan Sokolow]

Disabling browser.urlbar.autoFill does make reproducing the problem impossible as far as I can tell.

Also, successful reproduction DOES depend on bogging down the system in some way. My relatively new Developer Edition profile with dozens of tabs open has no problem reproducing it, but I've just confirmed that a fresh Nightly profile needs something heavy running in the background for reproduction to be possible.

(The first time I reproduced it on Nightly, I happened to have my copy of Stardew Valley sitting paused in the background. The second time, I was feeling lazy and reopened it just in case. This time, I verified the bug's presence with Stardew Valley running in the background, then closed the game and couldn't reproduce it, then ran Python in a terminal and started a `while True: pass` loop and was able to reproduce it once more.)

Comment 5

[Drew Willcoxon :adw]

Thanks for replying.  What may be happening is that autofill is replacing the string in the textbox as you're typing, but it's not preserving the case properly.  I thought we're being careful with regard to case in the relevant code, but maybe not, or maybe there's some scenario we're not handling properly, or maybe there's a race condition somewhere.  I'll confirm the bug even though I can't reproduce it at the moment since it deserves some investigation.  We're also currently rewriting large parts of autofill in bug 1239708, so I'll mark that as a see-also.

Comment 6

[Marco Bonardo [:mak]]

yes, autofill tries to preserve user's input casing.

Comment 7

[Marco Bonardo [:mak]]

I still cannot reproduce this, I'll mark as incomplete since it's not actionable, it would be interesting to know if anyone can still reproduce it.