Closed Bug 606461 Opened 14 years ago Closed 13 years ago

Firefox echoes character after running JS code on twitter.com, Chrome echoes immediately

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: djst, Unassigned)

References

(
URL
)

Details

http://www.flickr.com/photos/djst/5104316427/ Chrome "echoes" the character immediately when pressing the key, and then updates Twitter's character counter afterwards. Minefield, on the other hand, updates the counter and echoes the character in the text box at the same time. It's even easier to see the difference in behavior when I hold a key down -- in Chrome, the characters are filling the textbox while the counter remains at 140, but in Minefield, the counter updates for every added character. Is this another example of how we could easily tweak Firefox's perceived performance?
I should have added some platform info: this is on Ubuntu 10.10 "Maverick Meerkat" running: Build identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101022 Firefox/4.0b8pre Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3 I have also tested on Firefox 3.6.11 and the behavior is the same as in Minefield.
Bug 579488 is tracking slow typing on Twitter; this might be related.
We used to synchronously reflow+repaint on every character typed. This causes performance problems, so we moved the handling of those reflows+repaints to the normal async codepath. That means they can get coalesced with other updates. But what's happening in the "hold the key" down case in Chrome can't be explained by that difference.
Hmm. So I seem to not have a twitter account (though _someone_ has "bzbarsky"), and the twitter page doesn't even load the textbox if saved locally. David, what's triggering those counter updates? I know it's a pain to dig into their crap with the dynamic script loading they do, sorry....
I don't think I have the skills required to do this without investing a lot of time. I've temporarily changed my twitter password so you can try this out yourself. Check your bugzilla account e-mail address... Let me know if I can help in other ways though.
Fwiw, the console gives me the following output when typing a character: 17:56:29.595: Warning: The 'charCode' property of a keydown event should not be used. The value is meaningless. Source File: https://twitter.com/ Line: 0, Column: 0 Category: DOM Events 17:56:29.610: Warning: The 'charCode' property of a keyup event should not be used. The value is meaningless. Source File: https://twitter.com/ Line: 0, Column: 0 Category: DOM Events
Interestingly, the keydown event is triggered repeatedly even when holding the key down. Is that expected?
OK, Mike hooked me up with a test account. In Gecko, the JS code that updates the counter (verified, for example, that it's the code that's appending a text node with the text "139" in the DOM) runs off this in Gecko: #97 0x00379b4d in nsTextControlFrame::FireOnInput (this=0x28d281b0) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/forms/nsTextControlFrame.cpp:1332 However, I've verified that webkit also fires the input event on every char typed: <!DOCTYPE html> <body> <div id="x"></div> <textarea oninput="document.getElementById('x').textContent = this.value"> </textarea> </body> It's hard to tell what else might be going on, given the obfuscated code, overuse of jquery, and browser-sniffing that the latter does. Probably doable with several days work, but do we have any twitter contacts that might be able to just tell us whether they use different codepaths here?
David, the behavior of keydown events when the key is held down is platform-dependent, iirc....
>Is this another example of how we could easily tweak Firefox's perceived >performance? Ideally there shouldn't be any lag when the user is typing, and also the counter would stay perfectly in sync with the number of characters typed. Having the counter change after the user has been typing feels slower, like it had to catch up.
Sure. But if twitter goes out and tries to solve traveling salesman problems on every counter update (not saying they do, fwiw!), there isn't much we can do about it. It's probably worth a separate bug where we profile exactly what takes the time. And perhaps a separate bug on the behavior difference with a key held down, and make them both block this one?
Note that the different behavior doesn't just apply when you keep the key held down -- even when just hitting the key once, you can see that Firefox updates both the text box and counter during the keydown event, while Chrome updates the text box on keydown and the counter on keyup.
Yeah, it really makes me wonder whether the site is running the same code for us and webkit.... John, any idea?
Doing some testing with oninput vs onkeyup on my reduced testcase in bug 579488 on Windows and Linux with Firefox and Chrome I would not be surprised if the difference is that twitter.com uses oninput for Firefox and onkeyup for Chrome because Firefox and Chrome seem to match in my reduced testcase using both.
Need someone to either dig into the twitter JS or talk to the twitter folks....
Keywords: qawanted
This seems fixed by Twitter now - at least the behavior of Chrome and Firefox is now the same (both now update the counter before echoing the character). There is still a small but noticeable perf difference between the browsers (Chrome seems a bit faster at reacting to the keypresses) but the bug as reported here is resolved.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Keywords: perf, qawanted
You need to log in before you can comment on or make changes to this bug.